On Thu, 16 Nov 2006, Linus Torvalds wrote:
quoted text
>
> 	git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD

Btw, I'd like to claim that this is a _great_ user interface.

Yeah, it's different from other SCM's. I don't think you'd really want to 
script a merge like this in CVS, especially not using standard UNIX 
pipelines etc. But it's an example of how a lot of git operations - even 
the "high level ones" are pretty scriptable, using very basic and very 
simple standard UNIX shell scripting.

So even though I'd not actually _do_ the above one-liner, I think it's a 
great example of how git really works, and how scriptable it can be, 
without a lot of huge problems.

So considering that "FETCH_HEAD" works pretty much everywhere, and that 
you can also use the totally non-scripting approach of doing "standard" 
SCM things like

	git diff ..FETCH_HEAD

or 

	gitk HEAD...FETCH_HEAD

to look at what got fetched (and in the latter case look at both the 
current HEAD _and_ FETCH_HEAD, and what was in one but not the other), I 
really think it's unfair to say that "git fetch" does not have a nice UI.

It's just that "git fetch" can be used two totally different ways:

 - "git fetch" to get something temporary: use FETCH_HEAD, and do _not_ 
   specify a destination branch

 - "git fetch" as a way to update the branches you already have, by either 
   using explicit branch specifiers (which would be unusual, but works), 
   or by just having the branch relationships listed in your .git/remotes/ 
   file or .git/config file.

both are actually very natural things to do.

What is probably _not_ that natural is to do the explicit branch 
specifier, ie

	git fetch somerepo remotebranch:localbranch

which obviously works, but you wouldn't want to actually do this very 
often. Either you do something once (and use FETCH_HEAD, which is actually 
nicer than a real branch in some respects: it also tells you were you 
fetched _from_, and it can contain data on merging from _multiple_ 
branches), or you set up a "real translation" in your configuration files.

So I would say that the natural thing to do is:

 - "git pull somerepo"

   This will _also_ fetch all the branches you've said you want to track, 
   of course.

 - "git fetch somerepo somebranch"

   Look at FETCH_HEAD, and be happy

 - "git fetch somerepo"

   This is kind of strange, but it can be useful if you are basically just 
   mirroring another repo, and want to fetch all the branches you've said 
   you want to track, but don't actually want to check them out.

while the "complicated" scenario like the following is something you 
should generally _avoid_, because it's just confusing and complex:

 - "git fetch somerepo branch1:mybranch1 branch2:mybranch2"

   This works, and I'm sure it's useful, and I've even used it (usually 
   with just one branch, though), but let's face it - it's too damn 
   complicated to be anything you want to do _normally_.

So git is definitely powerful, but I think some people have looked at the 
_complicated_ cases more than the simple cases (ie maybe people have 
looked too much at that last case, not realizing that there really isn't 
much reason to use it - and FETCH_HEAD is one big reason why you seldom 
need the complicated format).

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html