On Thu, 16 Nov 2006, Linus Torvalds wrote: > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html