Re: [RFC] git rebase -s ours

From: Mike Hommey <mh@glandium.org>
Date: Mar 2, 2008, 12:48 UTC
Message-ID: <20080302124848.GB8696@glandium.org>
In-Reply-To: <20080302010527.GB22843@coredump.intra.peff.net>

On Sat, Mar 01, 2008 at 08:05:27PM -0500, Jeff King wrote:

Show 24 quoted lines

> On Sat, Mar 01, 2008 at 12:17:16PM +0100, Mike Hommey wrote:
> 
> > What do you think git rebase -s ours should be considering as "ours"?
> > If I'm not mistaken, at the moment, "ours" stands for "upstream", which
> > is kind of confusing...
> 
> Sort of. It actually works as "what is in the working tree is fine" so
> it ends up not applying _any_ commits. In other words,
> 
>   git rebase --strategy=ours upstream
> 
> is equivalent to
> 
>   git reset --hard upstream
> 
> So I think the current behavior is nonsensical, and I assume nobody uses
> it.
> 
> OTOH, what exactly are you trying to accomplish? If you have "ours" mean
> "always take the rebased content", then aren't you stomping on original
> commits? You might mean something like "do a regular 3-way merge, and
> for every textual conflict, choose the rebased content". That at least
> makes some sense, but I suspect it will produce uncompilable results in
> most cases.

That's actually almost what I would have liked when I looked at the git-rebase manpage to see what I could do. Except that the 'ours' merge strategy doesn't do that. But considering what the 'ours' strategy does, I wanted to see what it would do anyways, and it just does nothing, which is somehow sad.

> What I am getting at is: what 'ours' should mean in a rebase depends on
> how it can usefully be used in a workflow. Do you have a workflow in
> mind?

I don't have a workflow in mind, but I have expectations: considering the documentation, I would expect git rebase -s ours to do what git filter-branch can do with grafts.

Mike