Re: Bring together merge and rebase

From: Carl Baldwin <carl@ecbaldwin.net>
Date: Dec 26, 2017, 21:07 UTC
Message-ID: <20171226210727.GB22855@Carl-MBP.ecbaldwin.net>
In-Reply-To: <1514319542.2717.406.camel@mad-scientist.net>

On Tue, Dec 26, 2017 at 03:19:02PM -0500, Paul Smith wrote:

Show 5 quoted lines

> As someone working in an environment where we do a lot of rebasing and
> very little merging, I read these proposals with interest.  I'm not
> convinced that we would switch to using a "replaces"-type feature, but
> I'm pretty sure that the "null-merge and rebase" trick described
> previously would not be something we're interested in using.

In the near term, maybe. I'm still working with it to be sure I understand it right.

Show 6 quoted lines

> Although "git log" doesn't follow these merges (unless requested), all
> the graphical tools that are used to display history WOULD show all
> those branches.  In a "replaces"-type environment I think the point is
> that we would not want to see them (certainly not by default) as they
> would be used mainly for deeper spelunking, but since they just seem
> like normal merges I don't see any way to turn them off.

You've touched on some of my concerns with the null-merge approach. I want the end result to be as clean as possible which I think is what lures many to the rebase methodology in the first place.

Show 5 quoted lines

> If "replaces" was a separate capability then it could be treated
> differently by history browsing tools, and shown or not shown as
> desired.  For example, a commit that had a "replaces" element could be
> selected somehow and you could expand that set of commits that were
> replaced, or something like that.

Exactly!

Carl