Holger Hellmuth <hellmuth@xxxxxxxxxx> writes: > On 23.07.2014 21:33, Sergei Organov wrote: >> What actually bothers me is the unfortunate consequence that "git pull" >> is not always a no-op when nothing was changed at the origin since the >> last "git pull". THIS is really surprising and probably should better be >> fixed. Requiring -f is just one (obvious) way to fix this. > > That would invalidate the simple rule that "git pull" is equivalent to > "git fetch" + "git rebase". Sorry, I don't see how it would invalidate this. My suggestion even won't change git-pull source code at all, only git-rebase code. > git rebase depends on both branches it operates on, not just one. The > same goes for "git merge", I assume it is just a coincidence that git > merge does have this characteristic you now expect both to have. git pull --reabse=false git pull --rebase=preserve both have this property. git pull --rebase=true almost always has this property, unless there are local merge commits to be rebased. So, I'd rather say it's likely behavior of "git pull --rebase=true" that is a coincidence. -- Sergey. -- 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