[RFC] git rebase -s ours

[RFC] git rebase -s ours

[Mike Hommey]

Hi,

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

Mike

Re: [RFC] git rebase -s ours

[Jeff King]

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.

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?

-Peff

Re: [RFC] git rebase -s ours

[Mike Hommey]

On Sat, Mar 01, 2008 at 08:05:27PM -0500, Jeff King wrote:
> 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

Re: [RFC] git rebase -s ours

[Jeff King]

On Sun, Mar 02, 2008 at 01:48:48PM +0100, Mike Hommey wrote:

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

I'm not sure I follow. Can you elaborate?

-Peff

Re: [RFC] git rebase -s ours

[Mike Hommey]

On Mon, Mar 03, 2008 at 12:41:26AM -0500, Jeff King wrote:
> On Sun, Mar 02, 2008 at 01:48:48PM +0100, Mike Hommey wrote:
> 
> > 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.
> 
> I'm not sure I follow. Can you elaborate?

Starting with a history like this:

                      G---H 
                     /
        A---B---C---D---E---F

Where A, B, C, ... are *trees*, not commits, the expected result would
be

        A---B---C---D---E---F---G---H

This is what might happen with git-filter-branch if you graft G to F. (I
don't know if it actually works in cases where the grafted commit had a
parent, originally)

Mike

Re: [RFC] git rebase -s ours

[Jeff King]

On Mon, Mar 03, 2008 at 07:55:21AM +0100, Mike Hommey wrote:

> Starting with a history like this:
> 
>                       G---H 
>                      /
>         A---B---C---D---E---F
> 
> Where A, B, C, ... are *trees*, not commits, the expected result would
> be
> 
>         A---B---C---D---E---F---G---H
> 
> This is what might happen with git-filter-branch if you graft G to F. (I
> don't know if it actually works in cases where the grafted commit had a
> parent, originally)

Ah, OK. That makes some sense, and I think would work if "git
merge-ours" actually did a "git read-tree && git checkout-index" on
the "us" parameter instead of just assuming that the working tree is
what is desired.

I'm still not sure it is all that useful in practice.

-Peff

Re: [RFC] git rebase -s ours

[Mike Hommey]

On Mon, Mar 03, 2008 at 07:55:21AM +0100, Mike Hommey wrote:
> On Mon, Mar 03, 2008 at 12:41:26AM -0500, Jeff King wrote:
> > On Sun, Mar 02, 2008 at 01:48:48PM +0100, Mike Hommey wrote:
> > 
> > > 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.
> > 
> > I'm not sure I follow. Can you elaborate?
> 
> Starting with a history like this:
> 
>                       G---H 
>                      /
>         A---B---C---D---E---F
> 
> Where A, B, C, ... are *trees*, not commits, the expected result would
> be
> 
>         A---B---C---D---E---F---G---H
> 
> This is what might happen with git-filter-branch if you graft G to F. (I
> don't know if it actually works in cases where the grafted commit had a
> parent, originally)

Obviously, HEAD would be the commit with tree H before rebase, and you
would be asking to rebase onto the commit with tree F.

Mike