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

[Steinar Bang <sb@dod.no>]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Once again, the problem is in this situation:

>  . My work on a feature branch is almost finished, so I merge from
>    master to make sure my feature doesn't break anything and isn't
>    broken by development on master.

>  . I then merge from the feature branch to master and attempt to push,
>    but the push is rejected.

>  . I then pull --rebase=preserve and push again

> It's the last step that causes trouble, and the "trouble" here is that
> commits I merged from master before merging back might be merged again
> in the future, if I need for some reason to continue working on that
> feature branch again.

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

and at this point I have no idea what the branches look like, since
I've never used "--rebase=preserve".

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?

Have you seen this happen? 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).

At least, if you were doing ordinary merges in pull, it would never be
a problem... but I'm guessing (note: "guessing") now that what happens
is that what you end up with on master, is a rebased version of the
merge commit "g", ie. 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"?
(I saw later that my guessing might be off, see below for more)

Hm... what would happend if you continue to work on eli-feature-1 and
then merge back into master, I have no idea... probably nothing good.

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". 

You could pop off "g" of eli-feature-1, ie.
 git checkout eli-feature-1
 git reset --hard HEAD~1
and then merge in master to get "h" in its place
 git merge master

But it amounts to the more or less same thing (and it all depends on
the behaviour being like I describe, which may not be the case, since
I'm just guessing).

> Where will origin/master help in this situation?

Not directly, but you can prepare for the newest that will be on
master after the pull before push, without moving off your feature
branch, ie.
 git fetch
 git merge origin/master

>> But actually, instead of merging master into your feature
>> branch, I'd rather recommend rebasing it *onto* master, but explicitly

> That'd lose too much information, so I'd like to avoid that if
> possible.  It might also cause complications if I have more than 1
> active feature branch, and want to compare or merge between them.  It
> is also a bad idea when the branch is a public one, as you point out.

FWIW I agree on all of Eli's saying here.

[snip! rebasing feature branches]
> I would like to have the same workflow for both local branches and
> public ones, such as emacs-24, if at all possible.  That will
> relieve the "memory pressure" and reduce the probability of errors.

I'm again in complete agreement with Eli.

[snip!]
> I actually don't mind merge commits, as long as they reflect what
> was actually done, as opposed to being generated by Git out of thin
> air.

+10

> 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...? 

If so that's bad! (I *knew* there were good reasons to shun rebase,
and if this is the case I have some real ammunition the next time a
discussion with a rebase entusiast comes up)