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

[Eli Zaretskii <eliz@gnu.org>]

> From: David Engster <deng@randomsample.de>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Dec 2014 00:13:20 +0100
> 
> > Sorry, I still don't understand.  Which commits from what branches
> > does Git merge after 'rebase=preserve'?
> 
> It merges the branch that is implicitly created by moving
> 'origin/emacs-24' to a newer parent.

That's the missing link, thanks.

So this means that:

  . Using "pull --rebase=preserve" always rewrites the merge to come
    from some unnamed branch, which is different from the branch that
    originated the merged commits.

  . This is true for merges from local branches as well.  Therefore,
    using this option is not advisable for local branches, because
    doing that would mean trouble when I next merge from master into
    my local branch -- I will get the same commits back again.

  . IOW, rebase=preserve is not useful in a merge-based workflow.

Is my interpretation correct?

If it is, then here's my conundrum.  When I make changes in master, I
don't want them to look as if they were made on some branch when I
push them.  Why? for starters, because "log --first-parent" won't show
them.  So I use "pull --rebase" to avoid that.  This works well as
long as I didn't make any local merge-commits, be it from my local
branches or from public branches such as emacs-24.  I thought that
using rebase=preserve would cover the latter use cases as well, but
now I understand I was mistaken: I can use "pull --rebase" only if
there were no merge-commits since the last refs update; otherwise I
need to use "pull".  So I cannot configure Git to always use some
option when pulling, and forget about that.

AFAIU, an alternative, when I have local merge-commits, is to use
"pull --ff-only", and when it refuses to pull, use "reset --hard
origin/master", and then "merge -no-ff" and commit, before pushing.
That's significantly more complicated, sigh.

Which means there's no easy way with Git to support a workflow that
preserves mainline, without jumping through some hoops.

Is that correct?  Or is there a better workflow that preserves the
mainline?

If there is no better workflow, perhaps we need to radically rethink
our recommended project workflow, like not base it on merges but on
rebase, or push fixes to master and then cherry-pick them to the
release branch, or something else.  Because what bzr supported easily
and almost seamlessly, Git doesn't -- in the sense that emulating the
same workflow is more complicated and thus error-prone.  To me, this
spells that we fight the tool, i.e. our workflow should change.

> You can't at the same time move a branch onto a new parent (which is
> what rebase does) and then merge it, so that it looks like you've merged
> the original one which had another parent.

I only use rebase because I don't know of another way of being able to
work on master without having my commits look as if they were made on
a branch, after I push them, which AFAIU will happen if someone else
pushes before I push my local commits made on master.  If there's a
reasonably simple way to avoid this effect without rebasing, I guess
I'll switch to that.  I didn't use rebase with bzr, because there was
a simple way to preserve the mainline without rebasing.

Btw, I think we need to do something urgently in gitmerge.el to avoid
this kind of mistakes.  Otherwise, people will keep making these
mistakes, and no amount of explanations will ever be able to prevent
that.

Thanks.