Re: git pull --rebase and losing commits

From: Peter Krefting <peter@softwolves.pp.se>
Date: Nov 3, 2009, 07:01 UTC
Message-ID: <alpine.DEB.2.00.0911030757400.15633@ds9.cixit.se>
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:

Show 8 quoted lines

> 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/