Re: Bring together merge and rebase

From: Carl Baldwin <carl@ecbaldwin.net>
Date: Dec 27, 2017, 02:44 UTC
Message-ID: <20171227024413.GA26579@Carl-MBP.ecbaldwin.net>
In-Reply-To: <20171226040843.h7o6txkrp6zlv7u5@glandium.org>

On Tue, Dec 26, 2017 at 01:08:45PM +0900, Mike Hommey wrote:

> FWIW, your proposal has a lot in common (but is not quite equivalent)
> to mercurial's obsolescence markers and changeset evolution features.

I've had experience with mercurial but not since about 2009. After reading up a little bit on this changeset evolution feature, it looks very much like what I'm proposing. Obsolescence markers look a lot like replaces references except, as illustrated by this blog [1], they point the other way! Hence, the illustrations confused me for a moment. It seems more natural to embed the reference in the new commit pointing at the old. That said, the illustrated direction of the arrows doesn't really affect the usefulness of the idea.

His third example (#3-working-with-other-people), appears to be the kind of collaboration that I'm trying to describe here. To quote the blog:

  In git or vanilla (no extension) mercurial, you would have to figure
  out that b’ and b” are two new versions of b and merge them. Changeset
  evolution detects that situation, marks b’ and b” as being divergent.
  It then suggests automatic resolution with a merge and preserves
  history.

This is the kind of thing that I had to deal with manually in gerrit. I hadn't seen this feature in mercurial but I'm glad to know now there is a precedent for it.

Carl

[1] https://blog.laurentcharignon.com/post/2016-02-02-changeset-evolution/