![]() ![]() In a normal (no fork point stuff needed) rebase case you have something like this. This code uses the reflog to handle cases best shown by drawing part of the commit graph. ![]() The most important item here (for sure) is the fork point code. Normally it flattens away merges and only the interactive rebase script has code to preserve them (this code actually re-does the merges since there's no other way to deal with them). I'm not sure this actually matters here (hence "may be involved" above). When git rebase is instructed to preserve merges, it uses the interactive rebase code (non-interactively). When run with arguments, the fork-point machinery is disabled unless explicitly requested with -fork-point. When git rebase is run with no arguments it has a special case that invokes the fork-point machinery. Git pull runs git fetch, then either git merge or git rebase per instructions, but when it runs git rebase it uses the new fork-point machinery to "recover from an upstream rebase". ![]() In any case, there are two or three key items here (depending on how you count and split these up, I'll make it into 3): Meanwhile, the old git pull script was also rewritten in C recently so it's harder to see what it does (though you can set environment variable GIT_TRACE to 1 to make git show you commands as it runs them internally). It's a bit hard to be sure but the fact that your local branch follows your other local branch which is getting rebased is quite suggestive. And, I suspect your automatic preserve-merges may be involved. There are a few differences between manual and pull-based git rebase (fewer now in 2.7 than there were in versions of git predating the -fork-point option in git merge-base). It is now virtually certain that it is due to the fork-point option.) (Edit, : see also this answer to Why is git rebase discarding my commits?. I have the following in my ~/.gitconfig: Note: My git pull -rebase here should actually be read as a -rebase=preserve, if that matters. When it does work for a commit, though, it works every time. Unfortunately, this is not 100% reproducible for all commits. This seems to directly contradict my understanding of how git pull works, unless git fetch. The commits have been applied correctly and my new commits on feature are still present. (from branch feature): $ git rebase master Now, if I reset my position, and instead do the following: (from branch feature): $ git reset -hard # rewind to before second git pull (from branch feature): $ git pull -rebaseĪt this point, the few commits ahead I was on feature have now been lost. (from branch master): $ git checkout feature Sometimes, I will lose commits by running the following sequence of steps (from branch master): $ git pull -rebase branch feature is set up to track local branch master, and ahead of master by several commits.branch master is set up to track origin/master, and is behind master by several commits.branch origin/master references branch master on remote origin.In my workspace, I have the following setup: I seem to have found some case where this doesn't work as expected. (from branch master): $ git rebase origin/master ![]() According to my understanding of git pull -rebase origin master, it should be the equivalent of running the following commands: (from branch master): $ git fetch origin ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |