Peter Krefting wrote:
> # Update tree (--strategy=ours avoids merge conflicts)
> git pull --rebase --strategy=ours origin master
[...]
> However, this seems to lose commits. When I ran it today, it commited an
> automatic change, and then pulled a tree that did not contain that change,
> making the changed file just disappear.
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). It is *not*
the often requested (but ill-defined and hence never implemented)
"resolve all conflict hunks in favour of ours" strategy.
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. Then git-rebase sees that the trees
haven't changed, and concludes that C has already been applied and
drops it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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