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

[Eli Zaretskii <eliz@gnu.org>]

> From: Steinar Bang <sb@dod.no>
> Date: Wed, 17 Dec 2014 10:58:15 +0100
> 
> Let me see if I understand, you branch off from master like so:
> 
>  -a---b-c-d- master
>      \
>       e-f- eli-feature-1
> 
> Then you wish to prepare for a push so you merge in master:

>  -a---b-c-d--- master
>      \      \
>       e-f----g- eli-feature-1
> 
> (where "g" is the merge commit)

> You merge your feature branch into master (ff merge):

>  -a---b-c-d------ master
>      \      \  /
>       e-f----g---- eli-feature-1
> 
> And then push of master fails, and you do 
>  git pull --rebase=preserve

Yes, this is the workflow and the scenario I was describing.  With
bzr, it actually happened more or less every time I finished a feature
and was about to land it on trunk.  So naturally, I would like to
preserve the workflow if it's practically possible.

> But if I understand you correctly, you're concerned that if you
> continue to work on eli-feature-1 and then merge into master, then the
> commits "b", "c", and "d" that were merged into your feature branch
> will be re-applied?

Yes.

Also note that I'm not only concerned about myself alone, but about
all those who read or will read GitForEmacsDevs, and try to follow the
instructions there.  They current suggest "pull --rebase", although
stop short of mentioning rebase=preserve.

> Have you seen this happen?

No, not yet (thankfully).

> The "git merge" command seems to be generally very good at backing
> off when the changes are already in place (e.g. when I cherry pick
> changes from master back to a release branch, and later merge the
> release branch, I rarely see conflicts).

I know and agree, but I'd prefer not to rely on sheer luck, even if
the chances are very high.  If the danger exists, then the costs of
the failure, however rare, can be too high, so I'd like to avoid that
completely, especially for the audience of GitForEmacsDevs.

> The simplest way to proceed would be to just delete the existing
> eli-feature-1 and create a new eli-feature-1 off the rebased merge
> commit "h". 

That's mostly what happens, at least in my sandboxes.  But again,
there are others who might not delete the branch right away, and
there's emacs-24, of course.

> > What I certainly want to avoid is any kind of rebasing, cherry-picking
> > or similar things that will then put me at risk of having the same
> > commits merged again, because the original commits are rewritten or
> > not recorded in the DAG.
> 
> Aah... so that's what happens: "b", "c", "d" in the example above
> (that come from master into your feature branch), are rebased, and
> then later reapplied...? 

Yes.