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