If you don’t do many changes then most of the time you can fast-forward. Other projects prefer to keep the history intact, so it’s fine if you merge. Some projects prefer a linear history, in those cases you must rebase. OK, so if the branches have diverged you have two options ( merge or rebase), which one should you pick? The answer is: it depends. In this case the diverging commit of the local branch “master” (D) is recreated on top of “origin/master” (C) so the resulting history is linear (as if it never had diverged in the first place and the base of the local branch was C). fast-forwardĪ fast-forward is simple: if the local branch and the remote branch have not diverged, then the former can be easily updated to the latter. In Mercurial hg pull is the equivalent of git fetch, so in Mercurial hg push and hg pull are symmetric, but not in git.Īt some point in time a path to make git pull be symmetric to git push was delineated, but the maintainer of the Git project considered it “ mindless mental masturbation“, so forget about it.Īfter you have pulled the changes with git fetch, then there’s two possibilities: fast-forward and diverging. The mirror of git push is git fetch which simply pulls the remote changes locally so you can decide later on how to integrate those changes. OK, so we need to “integrate” the remote changes with git pull, so presumably git pull is the mirror of git push, so it makes sense.Įxcept it’s not, and git pull was never designed with this use case in mind. Hint: See the 'Note about fast-forwards' in 'git push -help' for details. Hint: 'git pull …') before pushing again. Hint: Updates were rejected because the tip of your current branch is behind ! master -> master (non-fast-forward)Įrror: failed to push some refs to 'origin' “origin/master”), in particular because if they don’t, git push fails with: To origin “master”) with the corresponding remote branch (e.g. What most people want to do is synchronize their local branch (e.g. The rest of the article is with them in mind, who unfortunately are the vast majority of users, especially novices. That leaves developers who work on a centralized workflow (e.g. If you are a developer (non-maintainer), and use a topic branch workflow, then you don’t even need git pull. It was created for maintainers: when you send a pull request, a maintainer is supposed to run git pull on the other side. Let’s start by explaining where git pull is not broken. The problem is that the short version is actually too short:īut why? Even thought it’s obvious for me, and many other developers why git pull is broken and should not be used by most users, presumably a lot of people don’t know that, since they continue to use it. section depends on the answers to questions (2-4).A lot of people complained that my previous post– git update: the odyssey for a sensible git pull–was too long (really? an article documenting 13 years of discussions was long?), and that a shorter version would be valuable. In any case, here's a way to tackle updating local refs based on remote refs (after running git fetch -p for instance): for ref in $(git for-each-ref refs/remotes/origin/ -format '%(refname)') do If there is some other answer, (2-4) become problematic. It should not have a work directory, and perhaps it should not accept pushes either, in which case the remaining questions just go away. If the answer to (1) is "because devhost is not actually for development, but rather is a local mirror that simply keeps a locally-available copy of the github repo so that all our actual developers can read from it quickly instead of reading slowly from github", then you want a "mirror" rather than a "normal" repo.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |