Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy

[Jeff King <peff@peff.net>]

On Tue, Jul 29, 2008 at 10:36:32AM +0100, Mike Ralphson wrote:

> > I just didn't want history thrown away for two reasons:
> >
> >  - historical interest; some of the commits had counterparts in devel
> >    that were done differently (because the two branches had diverged),
> >    but it might later be interesting to see how and why the stable
> >    changes were done (e.g., if a similar situation arose)
> >
> >  - this project did not rebase, favoring the simplicity of "git pull"
> >    over clean history.
> >
> > Bear in mind that this project was not very big. I think devel had ~20
> > commits, and stable had about ~5. So it was easy to get such confidence.
> 
> Is there any reason you couldn't have reverted the stable commits in
> preparation for the merge from devel?

No, there is no technical reason. I think that is a perfectly valid way
of accomplishing the same goal (as is switching to the "kept" branch and
using "-s ours"). It's just that we had a particular mental model, and
the simplest way of translating that model into a git history graph was
as I described.

Again, I don't think this is a common problem, and I have certainly not
been aching for "-s theirs". The question was whether such a thing might
be useful, and I think it is, if only because it most directly matches
how a user might be thinking of the problem; for other users, or other
similar situations, one of the other methods might make more sense.

To me, seeing a commit that joins two histories with a comment saying
"these two branches are now becoming the same, but we don't care about
what happened down this ancestry chain because of X" most directly
models what happened (in my case).

-Peff