From: Peter Krefting Date: Tue, 03 Nov 2009 07:01:38 GMT Subject: Re: git pull --rebase and losing commits Message-ID: In-Reply-To: <20091102151022.GA3995@atjola.homenet> Thomas Rast: > Not very surprising if you use the 'ours' strategy, which doesn't merge at > all but instead takes the 'ours' side (IIRC that's the upstream for a > rebase, but I always have these mixed up). Sounds like it should be called "theirs", then. Or the documentation should be clarify. > So what happens is that git-rebase rebuilds some commit C from your side > on some base B from the remote, but the 'ours' strategy turns the *tree* > for C' into that of B. Right. I thought it was working on the individual blobs (I want it to automatically resolve conflicts by applying the version that is in the repository I am running the rebase from, no matter what). Björn Steinbrink: > The "ours" strategy doesn't just avoid merge conflicts, it avoids making > any changes at all. The ours strategy means "just keep our state, just > pretend that we've merged". And rebase will see that there were no > changes and conclude: > > Already applied: 0001 test commit > > And thus it will drop the commit. I've seen that message show up in my logs a couple of times. I'd better drop the --strategy=ours, then. :-/ Now to figure out if it is possible to get a setup like this working at all. Maybe dropping rebase in favour of regular merge may help a bit, but I still want it to auto-resolve any conflicts for me. -- \\// Peter - http://www.softwolves.pp.se/