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

[Eli Zaretskii]

> From: Steinar Bang <address@hidden>
> Date: Wed, 17 Dec 2014 11:52:54 +0100
> 
> > and at this point I have no idea what the branches look like, since
> > I've never used "--rebase=preserve".
> 
> I still haven't used it, but I have googled a bit, and I found this:
>  http://stackoverflow.com/a/15915431

Yes, I've read it when I tried to understand what exactly does
rebase=preserve do.

> Example 3 looks a lot like what I outlined, ie. you would get something
> like this:

> >  -a---b-c-d-i-j-h- master
> >      \      \  /
> >       e-f----\/
> >               \g---- eli-feature-1
> 
> > where "i" and "j" are the commits that blocked your push, and "h" is a
> > rebased version of "g"?
> 
> And if so, there will never be a problem with "b", "c", and "d", because
> they are recorded in "h" (which is the rebased "g").
> 
> But there _will_ be a problem if you continue with eli-feature-1 with
> "g" in the graph.

Yes, that's the problem.

AFAIU, there are 2 possible ways to escape this problem:

  . Let go of the desire to keep the "mainline" linear, and just use
    "pull" when updating master from upstream.

  . Use "pull --ff-only", and if it refuses to pull, cancel the merge,
    pull, and merge again using "merge --no-ff".  This will probably
    preserve the mainline (unless Git has more surprises ;-), and also
    keep the merge-commits intact, but at the cost of more complicated
    and error-prone workflow.

For GitForEmacsDevs, I tend to prefer the former, since I don't hear
too many voices in support of the linear mainline desire.