Jeremy White wrote:
I gather some folks do prefer to use pull; I don't understand the difference, to be honest.
If you do not do any development there is none. Git pull is just easier to type. If you do development and apply patches then there are differences. The main difference is what happens under the hood in the repository and not in the checkout code: git pull == git fetch origin + merge origin back into your active branch. All history is preserved; pull command can be seen as "merge commit" in the history. git rebase origin == git format-patch old origin + throw away your active branch and replace it with a copy of the new origin + apply all the patches git format-patch generated.
As Rob pointed out with git pull you loose the ability to use git format-patch as that uses the commit history to decide what the differences are. The code in the origin and your master can be bit by bit identical but have a totaly different history how those branches got to have that code. Different history means git format-patch will spit patches out even if the source is the same(*). Been there did that. No thanks. With git rebase your not yet submitted/accepted patches will be always on top of the origin. The master has always a clean history so git format-patch dosn't get confused. Eric says that using stgit would be even better for this task of following the main Wine devel tree carrying around a couple of patches but didn't try it out yet. If you want want to visualize the difference between git pull and git rebase just create two branches and commit a couple of patches to both. 1 of those branches you keep up to date by using git pull and the other by git fetch+rebase. After a week or so look with gitk at both branches: git rebase: 1 straight line with the applied patches at the top git pull: 1 line that branches into two lines: origin and your branch connected by short lines going from origin to your branch which represent the merges (git pull).
(*) If *ALL* the patches from origin and master are the same diff but differ only in the commit message (timestamp, commiter, changelog, etc.) then it looks like git format-patch is still able to do it's work and get a meaningfull output. But god forbid that Alexandre modified your patch before commiting or you merged two of your commits into one before sending the patch upstream or you used git revert or you etc'ed and git format-patch origin will produce garbage.
But I have to confess that git makes my head hurt. That just could be because this old dog can't learn this trick. But I think the fundamental problem is that the git data structure is a radical new approach to SCM, and the tools are not very refined. So the tools make sense if you grok the structure of git, and make much less sense if you don't. What's more, the tools don't have a whole lot of safety catches on them, so it's pretty easy to cut yourself while learning. Luckily, most things seem to be undoable as well, although figuring out how to undo is a @#$@#$.
Amen brother. But i got used to git and it's quircks. Requires quite a little bit of rtfm.
Pulling a new archive is probably easier, although you should never need to do that, in theory.
You realy do not need to do that. You can just branch your exiting mess (just in case to have an easy to find backup) and reset your master to be an exact copy of origin. *NEVER* use git prune, at least not after you did a disruptive change to your repository.
I'll let you know if that's right if I ever grok the structure... :-/
bye michael