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

[Eli Zaretskii]

> From: David Engster <address@hidden>
> Cc: address@hidden
> Date: Sun, 14 Dec 2014 22:40:41 +0100
> 
> 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?

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

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

Sad.

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

But rebase=preserve seemed to be advertised to give you the best of
both worlds.  Now it turns out to be a sales gimmick at best, and a
time bomb at worst...

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

No.  When development was on a branch, I generally want to preserve
that branch in the history, not flatten it.  My commits on a feature
branch follow some logic that is important to me (and documented in
the commit log messages), so that long after the job is done these
commits make it easier to understand why something was done the way it
was, and also find the reasons for bugs or misfeatures.

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

Yes.  Like I said: more complicated.

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

Discipline I have.  It's memory that I no longer have enough to
prevent me from making mistakes when certain everyday actions need
small variations.

Thanks.