From: Peter Krefting Date: Tue, 03 Nov 2009 10:12:13 GMT Subject: Re: git pull --rebase and losing commits Message-ID: In-Reply-To: Johannes Schindelin: >> Sounds like it should be called "theirs", then. > Why should it be called "theirs" when it takes "ours"? Because it took "their" (= upstream) tree, not "our" (= local branch) tree. Seems to me the name is a bit confusing in the case of a rebase, as I am "merging" my changes *onto* the upstream, not the other way round as would be the case with a regular merge. > Note: the thing I think Thomas wanted to clarify is that this strategy > does not _resolve conflicts_ to "our" version, but it just outright > ignores "theirs". IOW, after a merge with the "ours" strategy, > "HEAD^{tree}" and "HEAD^^{tree}" will point to _exactly the same object_. And in the case of a rebase, the other way around: With --rebase --strategy=ours, I am basically asking to throw all my local commits away? > If you want to use any merge strategy, you must understand what it does > first. There is no way around that. No change in UI, or in the core code > of Git, can relieve you of this obligation. No, that is why I recommended that what needed clarification was the documentation. I read the documentation of "ours": "This resolves any number of heads, but the result of the merge is always the current branch head. It is meant to be used to supersede old development history of side branches." and thought that it meant that it a) could resolve a merge conflict, no matter the number of branches involved ("resolves any number of heads"). b) would replace any merge conflict with the contents in the current repository's branch ("result of the merge is always the current branch head"). Apparently, the "used to supersede old development history" means that it actually throws the entire contents of one of the branches out, which is not what I wanted. I didn't understand that from the documentation, however. -- \\// Peter - http://www.softwolves.pp.se/