I have a case where 'git pull --rebase' does not do the Right Thing
(according to me).
If I run 'git rebase origin/master', that rebase does the right thing,
perfectly reapplying my *single* commit on top of the upstream.
'git pull --rebase' ends up reapplying a bunch of much earlier commits
and ends up with a conflict.
The documentation for git pull --rebase states: "Instead of a merge,
perform a rebase after fetching. If there is a remote ref for the
upstream branch, and this branch was rebased since last fetched, the
rebase uses that information to avoid rebasing non-local changes." I do
not understand
I'm studying the git-pull script right now, but I have to admit this is
beyond me. I'm sure if I stare hard enough, I'll get it.
I mistakenly have assumed 'git pull' = 'git fetch; git merge' and that
'git pull --rebase' = 'git fetch; git rebase'. Does anyone want to
clarify what is really going on? Unfortunately, I can't publish the
repository in question.
Thanks!
Josh
--
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