Mike HommeyHi,
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
Mike Hommey
Jeff KingRe: [RFC] git rebase -s ours
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
Mike HommeyRe: [RFC] git rebase -s ours
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
Jeff KingRe: [RFC] git rebase -s ours
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
Mike HommeyRe: [RFC] git rebase -s ours
On Mon, Mar 03, 2008 at 12:41:26AM -0500, Jeff King wrote:
Show 7 quoted lines
> 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---FWhere 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
Jeff KingRe: [RFC] git rebase -s ours
On Mon, Mar 03, 2008 at 07:55:21AM +0100, Mike Hommey wrote:
Show 14 quoted lines
> 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
Mike HommeyRe: [RFC] git rebase -s ours
On Mon, Mar 03, 2008 at 07:55:21AM +0100, Mike Hommey wrote:
Show 23 quoted lines
> 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