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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
