{"thread":{"id":"12404","subject":"[RFC] git rebase -s ours","startedAt":"2008-03-01T11:17:16Z","lastAt":"2008-03-03T07:04:37Z","messageCount":7,"participants":["Mike Hommey","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"70514","messageId":"20080301111716.GA3263@glandium.org","threadId":"12404","inReplyTo":null,"subject":"[RFC] git rebase -s ours","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-03-01T11:17:16Z","receivedAt":"2008-03-01T11:17:16Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nWhat do you think git rebase -s ours should be considering as \"ours\"?\nIf I'm not mistaken, at the moment, \"ours\" stands for \"upstream\", which\nis kind of confusing...\n\nMike\n"},{"id":"70567","messageId":"20080302010527.GB22843@coredump.intra.peff.net","threadId":"12404","inReplyTo":"20080301111716.GA3263@glandium.org","subject":"Re: [RFC] git rebase -s ours","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-02T01:05:27Z","receivedAt":"2008-03-02T01:05:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 01, 2008 at 12:17:16PM +0100, Mike Hommey wrote:\n\n> What do you think git rebase -s ours should be considering as \"ours\"?\n> If I'm not mistaken, at the moment, \"ours\" stands for \"upstream\", which\n> is kind of confusing...\n\nSort of. It actually works as \"what is in the working tree is fine\" so\nit ends up not applying _any_ commits. In other words,\n\n  git rebase --strategy=ours upstream\n\nis equivalent to\n\n  git reset --hard upstream\n\nSo I think the current behavior is nonsensical, and I assume nobody uses\nit.\n\nOTOH, what exactly are you trying to accomplish? If you have \"ours\" mean\n\"always take the rebased content\", then aren't you stomping on original\ncommits? You might mean something like \"do a regular 3-way merge, and\nfor every textual conflict, choose the rebased content\". That at least\nmakes some sense, but I suspect it will produce uncompilable results in\nmost cases.\n\nWhat I am getting at is: what 'ours' should mean in a rebase depends on\nhow it can usefully be used in a workflow. Do you have a workflow in\nmind?\n\n-Peff\n"},{"id":"70632","messageId":"20080302124848.GB8696@glandium.org","threadId":"12404","inReplyTo":"20080302010527.GB22843@coredump.intra.peff.net","subject":"Re: [RFC] git rebase -s ours","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-03-02T12:48:48Z","receivedAt":"2008-03-02T12:48:48Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Mar 01, 2008 at 08:05:27PM -0500, Jeff King wrote:\n> On Sat, Mar 01, 2008 at 12:17:16PM +0100, Mike Hommey wrote:\n> \n> > What do you think git rebase -s ours should be considering as \"ours\"?\n> > If I'm not mistaken, at the moment, \"ours\" stands for \"upstream\", which\n> > is kind of confusing...\n> \n> Sort of. It actually works as \"what is in the working tree is fine\" so\n> it ends up not applying _any_ commits. In other words,\n> \n>   git rebase --strategy=ours upstream\n> \n> is equivalent to\n> \n>   git reset --hard upstream\n> \n> So I think the current behavior is nonsensical, and I assume nobody uses\n> it.\n> \n> OTOH, what exactly are you trying to accomplish? If you have \"ours\" mean\n> \"always take the rebased content\", then aren't you stomping on original\n> commits? You might mean something like \"do a regular 3-way merge, and\n> for every textual conflict, choose the rebased content\". That at least\n> makes some sense, but I suspect it will produce uncompilable results in\n> most cases.\n\nThat's actually almost what I would have liked when I looked at the\ngit-rebase manpage to see what I could do. Except that the 'ours' merge\nstrategy doesn't do that. But considering what the 'ours' strategy does,\nI wanted to see what it would do anyways, and it just does nothing,\nwhich is somehow sad.\n\n> What I am getting at is: what 'ours' should mean in a rebase depends on\n> how it can usefully be used in a workflow. Do you have a workflow in\n> mind?\n\nI don't have a workflow in mind, but I have expectations: considering\nthe documentation, I would expect git rebase -s ours to do what git\nfilter-branch can do with grafts.\n\nMike\n"},{"id":"70741","messageId":"20080303054126.GB24210@coredump.intra.peff.net","threadId":"12404","inReplyTo":"20080302124848.GB8696@glandium.org","subject":"Re: [RFC] git rebase -s ours","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-03T05:41:26Z","receivedAt":"2008-03-03T05:41:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Mar 02, 2008 at 01:48:48PM +0100, Mike Hommey wrote:\n\n> I don't have a workflow in mind, but I have expectations: considering\n> the documentation, I would expect git rebase -s ours to do what git\n> filter-branch can do with grafts.\n\nI'm not sure I follow. Can you elaborate?\n\n-Peff\n"},{"id":"70746","messageId":"20080303065521.GA18152@glandium.org","threadId":"12404","inReplyTo":"20080303054126.GB24210@coredump.intra.peff.net","subject":"Re: [RFC] git rebase -s ours","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-03-03T06:55:21Z","receivedAt":"2008-03-03T06:55:21Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Mar 03, 2008 at 12:41:26AM -0500, Jeff King wrote:\n> On Sun, Mar 02, 2008 at 01:48:48PM +0100, Mike Hommey wrote:\n> \n> > I don't have a workflow in mind, but I have expectations: considering\n> > the documentation, I would expect git rebase -s ours to do what git\n> > filter-branch can do with grafts.\n> \n> I'm not sure I follow. Can you elaborate?\n\nStarting with a history like this:\n\n                      G---H \n                     /\n        A---B---C---D---E---F\n\nWhere A, B, C, ... are *trees*, not commits, the expected result would\nbe\n\n        A---B---C---D---E---F---G---H\n\nThis is what might happen with git-filter-branch if you graft G to F. (I\ndon't know if it actually works in cases where the grafted commit had a\nparent, originally)\n\nMike\n"},{"id":"70751","messageId":"20080303070327.GB22810@coredump.intra.peff.net","threadId":"12404","inReplyTo":"20080303065521.GA18152@glandium.org","subject":"Re: [RFC] git rebase -s ours","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-03T07:03:27Z","receivedAt":"2008-03-03T07:03:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 03, 2008 at 07:55:21AM +0100, Mike Hommey wrote:\n\n> Starting with a history like this:\n> \n>                       G---H \n>                      /\n>         A---B---C---D---E---F\n> \n> Where A, B, C, ... are *trees*, not commits, the expected result would\n> be\n> \n>         A---B---C---D---E---F---G---H\n> \n> This is what might happen with git-filter-branch if you graft G to F. (I\n> don't know if it actually works in cases where the grafted commit had a\n> parent, originally)\n\nAh, OK. That makes some sense, and I think would work if \"git\nmerge-ours\" actually did a \"git read-tree && git checkout-index\" on\nthe \"us\" parameter instead of just assuming that the working tree is\nwhat is desired.\n\nI'm still not sure it is all that useful in practice.\n\n-Peff\n"},{"id":"70750","messageId":"20080303070437.GA19082@glandium.org","threadId":"12404","inReplyTo":"20080303065521.GA18152@glandium.org","subject":"Re: [RFC] git rebase -s ours","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-03-03T07:04:37Z","receivedAt":"2008-03-03T07:04:37Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Mar 03, 2008 at 07:55:21AM +0100, Mike Hommey wrote:\n> On Mon, Mar 03, 2008 at 12:41:26AM -0500, Jeff King wrote:\n> > On Sun, Mar 02, 2008 at 01:48:48PM +0100, Mike Hommey wrote:\n> > \n> > > I don't have a workflow in mind, but I have expectations: considering\n> > > the documentation, I would expect git rebase -s ours to do what git\n> > > filter-branch can do with grafts.\n> > \n> > I'm not sure I follow. Can you elaborate?\n> \n> Starting with a history like this:\n> \n>                       G---H \n>                      /\n>         A---B---C---D---E---F\n> \n> Where A, B, C, ... are *trees*, not commits, the expected result would\n> be\n> \n>         A---B---C---D---E---F---G---H\n> \n> This is what might happen with git-filter-branch if you graft G to F. (I\n> don't know if it actually works in cases where the grafted commit had a\n> parent, originally)\n\nObviously, HEAD would be the commit with tree H before rebase, and you\nwould be asking to rebase onto the commit with tree F.\n\nMike\n"}]}