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

["Stephen J. Turnbull" <stephen@xemacs.org>]

David Engster writes:

 > up anew. If HEAD is your merge commit, this would mean doing
 > 
 >   git branch -D branchname
 >   git branch branchname HEAD^2
 > 
 > (You have to delete with '-D', since Git won't see your non-rebased
 > branch as merged...).

Aside: can't you do this in one operation with "git branch -f
branchname HEAD^2"?  (Real question, I don't understand your reference
to "seeing ... branch as merged".  The docs seem to indicate it should
work.)

 > > 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.  Then we can
see how to create it using primitives, and finally see if there's a
reasonable shortcut by using more complex commands and appropriate
options (where "reasonable" is defined "Eli feels comfortable with it
for the purposes he has in mind" -- we have to ask Eli :-).

 > OK, let me try to summarize what I think are the two main conflicting
 > requirements:
 > 
 > . You want to handle merges of local feature branches and public
 >   branches (like 'emacs-24') in the same way.
 > 
 > I think this one is the strongest requirement, since it means you simply
 > cannot use 'rebase' in any way. Also, you've pointed out several other
 > problems with 'rebase', like loosing the "real" history of a feature
 > branch, and accidental merging of rebased commits.
 > 
 > Therefore, I think a purely merge-based workflow is really the only
 > option for you, which however brings us to
 > 
 > . 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.  I agree this is problematic.
It's more complex, but if you do

    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.  The problems
are (1) a convenient discipline for those last three commands and (2)
recovery from failed push due to concurrent development.  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.  I don't know about the failed merge recovery,
though.

 > Of course, while *you* can take care in keeping the correct ordering of
 > mainline, others won't do that (I guess most are not even aware of this
 > issue),

All bzr fans are aware of it though.  It's an important part of
Bazaar's identity in VCS space.  The problem will be git users who are
used to a spaghetti DAG.

 > 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.  I
don't intend to speak for Stefan, just to encourage you to not give up
on the idea of a hook before you've clarified the point with him.

Footnotes: 
[1]  I think Eli means that in his feature branch workspace he uses a
branch named for the feature rather than master, but we need to be
clear about this.