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

[David Engster]

Eli Zaretskii <address@hidden> writes:
>> From: David Engster <address@hidden>
>> Cc: address@hidden
>> Date: Mon, 15 Dec 2014 21:39:58 +0100
>> 
>> >     when I work on a feature branch that takes weeks, sometimes
>> > months, to complete, I merge from master near the end of the
>> > development, to make sure landing the feature will not introduce
>> > regressions.  Sometimes there's more than one such merge, especially
>> > if I discover subtle issues as result of merging.
>
>> I see. I guess you could avoid those problems by merging origin/master
>> instead.
>
> Sorry, I don't understand: doesn't origin/master have the same commits
> as master (modulo the local commits I did on master since the last
> pull)?  If so, how would merging origin/master help me?
>
> 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.

Thank you for explaining it again. You are right that 'origin/master'
won't help you in this case. As soon as you rebase, merge and push, you
simply cannot work on your old branch. You have to delete it and set it
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...). This is why I prefer an explicit rebase onto
master, as it will not keep the old one lying around.

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

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.

>> - If the push fails because there are new commits upstream, instead of
>>   using 'pull --rebase=preserve', I rather delete the merge so that I
>>   get a "normal" fast-forward pull and merge again. If I'm really
>>   unlucky, this new commit from upstream causes a conflict now, in which
>>   case I usually just resolve it, simply hoping that the push will work
>>   next time.
>
> If "merge --no-ff" and aborting the merge when a push is rejected are
> to be used anyway, why do I need to rebase the feature branch onto
> master?  That doesn't seem necessary.  I could use normal merges, no?

Yes. I do that instead of merging master into my feature branch. I just
happen to not like this "merge from trunk" business, and I also prefer
to resolve conflicts commit-by-commit. Also, I usually do an interactive
rebase to clean up my branch before merging (I usually never get a
feature branch "right" the first time).

>> look like they were made on another branch, but if I understand you
>> correctly now, you mean you don't want to have merge commits from master
>> before pushing, but you rather prefer to rebase (to which I agree as
>> well).
>
> 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.
>
> 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.

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 happen to dislike that about Git as well, but I agree with Stefan that
this is not something we should worry about. Probably the easiest way
without resorting to rebase you've already said yourself: delete the
merge, do a fast-forward pull, merge again.

An alternative would be to swap the parents after the merge of a normal
'git pull', but that requires some Git plumbing, which however can be
easily scripted.

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), so I'm afraid you will be greeted with git's usual spaghetti
history soon enough. 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.

-David