Re: master c6f03ed: Fix a problem in url.el without GnuTLS

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>     emacs-devel@gnu.org
> Date: Thu, 18 Dec 2014 13:55:26 +0900
> 
>  > > That'd lose too much information, so I'd like to avoid that if
>  > > possible.
>  > 
>  > What kind of information do you mean here? I'm guessing you want to see
>  > the merges from master and how you reacted to them? You're right that
>  > this will be lost.
> 
> I think this is the crucial question.  git documents are very good at
> explaining implementations, but people have a habit of deciding what
> they think a command does based on its name.  That matters a little
> for Eli, and a lot for GitForEmacsDevs.
> 
> We really need to see what DAG Eli wants to construct.

The one that would be there if the push from master following a merge
from a feature branch succeeded.  I hope this is clear enough; if not,
please ask more specific questions.

> (where "reasonable" is defined "Eli feels comfortable with it
> for the purposes he has in mind" -- we have to ask Eli :-).

I don't think I've invented something unnatural here.  What I'd like
is to have a merge-based workflow where the DAG reflects all the
merges between 2 branches as they happened in real time.  Race
conditions interfere with that, but I'd like to resolve that issue
in a way that only affects the last merge before the final successful
push from the local master to upstream.

>  > . You want to keep a clear history of 'mainline', meaning you want to
>  >   achieve a similar log view to that from Bazaar, using 'git log
>  >   --first-parent'.
>  > 
>  > This conflicts with how Git orders the parents of a merge. The first
>  > parent is always the tip of the branch you're currently on. And since
>  > you do 'git pull' while being on your local master, that will be the
>  > first parent.

> I don't see a conflict here.  What I do see is an ambiguity in the
> discription of entry conditions.  If you bzr-think, on a feature
> branch the "local master" is likely to be the feature branch.[1]  That
> is, the workflow is

>     git clone git:emacs ./feature-1
>     cd feature-1
>     emacs file1 ...
>     git commit
>     git pull git:emacs    # we've just swapped master and
>                           # origin/master, ie, the public mainline,
>                           # when we push mainline is nonlinear
> 
> without actually defining a branch.

This is not how work on a branch happens (and not how it happened with
bzr).  There's an actual named branch, and changes are merged from
there to master, before pushing them.

>     git clone git:emacs ./feature-1
>     cd feature-1
>     git checkout -b feature-1
>     emacs file1 ...
>     git commit
>     git pull git:emacs      # origin/master contains public mainline
>                             # feature-1 contains local mainline

> To push to public:

>     git checkout master
>     git push                # public mainline is preserved
>     git checkout feature-1  # #### these three commands are error-prone

> AFAICS this is what you need to do for emacs-24, too.

What I do for emacs-24 is similar, but not identical:

  git clone git:emacs ./emacs-24
  cd emacs-24
  git checkout emacs-24
  <hack, hack>
  git commit
  git push
  cd ../trunk # another clone
  git checkout master
  git pull
  git merge origin/emacs-24
  <test, fix problems, commit>
  git push

> The problems are (1) a convenient discipline for those last three
> commands

What is error-prone about them?

> I think that one way to provide convenience and discipline would be
> to (a) require that the feature branch workspace be located in a
> directory with the same name as the feature branch, and (b) provide
> git-pull-emacs and git-push-emacs scripts that check for $(basename
> $cwd) == feature-name as a precondition.

Sounds complicated, and I'm not sure it's really needed.  Local
feature branches (unlike emacs-24) don't need to be in a separate
directory, because they usually don't diverge from master enough to
justify that.  What remains is the requirement to be aware of the
currently checked-out branch, something that is quite easy both at the
shell prompt (where Git instructs Bash to show the branch) and in
Emacs.

A significant disadvantage of this proposal, at least for me, is that
it defines a set of commands and some details of the workflow that are
specific to Emacs and not available and/or unneeded in any other
project that uses Git.  So it gets in the way of a more efficient
learning to use Git by combining the experience from other projects.

>  > One could implement a git hook that checks for a linear git history
>  > of mainline and that rejects pushes otherwise, but I guess Stefan
>  > isn't very inclined to agree to that.
> 
> My impression is that Stefan is not inclined to encourage work on this
> problem; he thinks it's a waste of time.  I think he'd come around
> quickly if presented with either another problem that would be solved
> by the same workflow that preserves linear mainline, or a
> "sufficiently convenient" workflow that preserves linear mainline.

But there doesn't appear to be such a sufficiently convenient
workflow, not with Git.

> [1]  I think Eli means that in his feature branch workspace he uses a
> branch named for the feature rather than master

Of course!