git annoyances: git fetch does nothing; git pull works?

[Michael Stefaniuc]

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
-- 
Michael Stefaniuc               Tel.: +49-711-96437-199
Sr. Network Engineer            Fax.: +49-711-96437-111
Red Hat GmbH                    Email: mstefani at redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart