OK, call me a git, but git fetch doesn't grab the latest changes, while git pull does. i.e. after git fetch, I can look at a file that's listed as changed on the wine-cvs archive, and it hasn't been updated; but after git pull, it has been. So what good is git fetch? Is some other command needed to actually apply the changes that were fetched?
On Wed, Jul 12, 2006 at 10:52:51PM -0700, Dan Kegel wrote:
git rebase origin
is listed by the GitWine wiki too.
ciao, Marcus
On 7/12/06, Marcus Meissner marcus@jet.franken.de wrote:
Yes, and it doesn't seem to do anything. (Sorry I didn't mention it before.) But I'll make sure I try it again... next time I blow away my git tree. Until then, I'll keep trying pull. - Dan
Dan Kegel wrote:
My understanding is that git fetch only operates on the underlying database of source objects, but does not change the currently checked out branch.
The pattern I always followed was: git fetch <source-server> (retrieve new objects from a source) git rebase <source-branch> <my-current-branch> (change my current branch by applying new patches from the source-branch).
e.g. git fetch winehq git rebase winehq master
I gather some folks do prefer to use pull; I don't understand the difference, to be honest.
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 @#$@#$. Pulling a new archive is probably easier, although you should never need to do that, in theory.
I'll let you know if that's right if I ever grok the structure... :-/
Cheers,
Jeremy
Jeremy White wrote:
git pull prevents you using git-format-patch to send the patches back.
Also note that "git fetch" will automatically forward your current branch to the latest version if you have no patches in the current branch, so if you then try to rebase you will get a message saying "nothing to do".
If that happens, you should get a message from "git fetch" saying something like "fast-forward..."
On Thu, 13 Jul 2006 08:06:56 -0500, Jeremy White wrote:
Doubtful, it's always made my head hurt too and I was playing with arch, svk and similar tools years ago :) I think it's just not got a very well designed user interface (though gitweb is pretty good). SVK may not have been strictly as powerful but it managed to get by with about 13-14 pretty obvious commands, and using it was mostly like using CVS in the common case.
Oh well ...
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.
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
-
Dan Kegel -
Jeff Latimer -
Jeremy White -
Marcus Meissner -
Michael Stefaniuc -
Mike Hearn -
Robert Shearman