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

[David Engster <deng@randomsample.de>]

Eli Zaretskii writes:
> 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.

Yes.

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

Do you mean you have a long-living local branch which you regularly
merge to master? You're right that in this case doing 'pull
--rebase=preserve' is problematic. If you continue to work on your
branch and merge from master, you will indeed merge the rebased
commits. To avoid that, you would have to delete the old branch and
continue working on the rebased one.

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

Rebasing is the anti-thesis to merging, so a purely merge-based workflow
wouldn't touch it in the first place (see: Bazaar).

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

Isn't flattening of the history precisely what you want when you have
merges of local branches, so that they appear like they were made on
master?

> 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 would also mean you have to fix conflicts again (unless you use the
'rerere' feature, but let's not go there yet).

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

I would say it is. AFAIK, Git has no notion of 'mainline' like Bazaar
had, so trying to preserve it does require a lot of discipline.

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

Cherry-picking to emacs-24 would indeed make some things easier. Most
importantly, it would make gitmerge.el obsolete (which I consider a good
thing).

-David