Re: git annoyances

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 9, 2008, 19:21 UTC
Message-ID: <alpine.LNX.1.00.0804091442190.19665@iabervon.org>
In-Reply-To: <20080409101428.GA2637@elte.hu>

On Wed, 9 Apr 2008, Ingo Molnar wrote:

Show 24 quoted lines

> 
> i just had a rather annoying session with git - here's the dump and 
> commentary, in case anyone is interested in usability fineprint.
> 
> it was with git-core-1.5.4.3-2.fc8 - so if it's all fixed/improved in 
> 1.5.5, or if this is blatant user error for which i deserve to be 
> punished then my apologies!
> 
> usually i just have a single git repo that tracks everything 
> interesting, but this time i did something i rarely do: i tried to merge 
> one local tree of mine into another local tree of mine. So i had no 
> commands (or even concepts) cached in my short-term memory that would 
> achieve this goal, i just tried the commands that i thought to be 
> 'obvious', without applying much (or any) IQ to those commands:
> 
>  $ cd linux-2.6-sched-devel.git
> 
>  $ git-remote add ~/linux-2.6-x86.git
> 
>  $ git-remote show x86
>   * remote x86
>     URL: /home/mingo/linux-2.6-x86.git
>   New remote branches (next fetch will store in remotes/x86)
>   base for-akpm for-linus latest master testing

Good so far.

>  $ git-merge x86/latest
>  x86/latest - not something we can merge

Git is missing the fact that, while refs/remotes/x86/latest doesn't exist, there is a fetch rule that would create it. It should suggest "git fetch x86" or "git fetch x86 latest". This is a bit tricky, because you've used a shorthand for something that doesn't exist, so there isn't a unique answer for which full name you're looking for, but there is a unique solution (in this case) for which one could be created by a pattern you have.

Show 9 quoted lines

>  #
>  # ho hum. Not something 'we' can merge. Do i care? :-) There's no 
>  # actionable reference given to the user about how to resolve this 
>  # problem. So i kept on trying:
>  #
> 
>  $ git-fetch x86/latest
>  fatal: 'x86/latest': unable to chdir or not a git archive
>  fatal: The remote end hung up unexpectedly

The right error message here would probably be:

/home/mingo/linux-2.6-sched-devel.git/x86/latest: No such file or directory

That should at least tell you what git thinks, incorrectly, that you want it to do, and why it doesn't work.

Show 44 quoted lines

> what got me going after experimenting around some more was this exact 
> command:
> 
>  $ git-pull x86 latest
> 
> (that fetch+merge went problem-free.)
> 
> but it was a PITA and all of git's messages about the problem were not 
> only unhelpful, they confused me into looking for problems where there 
> were none IMO. I was starting to wonder whether i have to have some git 
> daemon running on that box for example. But in retrospect IMO it was 
> rather clear from the outset what i wanted git to do (merge the tip of 
> my other tree into the tip of this tree, on the local box, no frills), i 
> just didnt figure out the exact command to do it.
> 
> another (minor) usability annoyance: one of the first things i tried was 
> to verify the remote setup, via:
> 
> $ git-remote show
> 
> which gave me this answer:
> 
>  Usage: git remote show <remote>
> 
> then i tried git-remote show -a (to list all repositories, etc.) - what 
> i didnt figure out was to show all repositories is to do a simple 
> "git-remote". I think "git-remote show" should output all repositories, 
> or at least indicate it in its help line what to do to get such a list. 
> (for us poor sobs forgetting commandline details ;)
> 
> also, the first natural thing i did was to just type:
> 
>  $ git-merge ~/linux-2.6-x86.git/
> 
> which i naively assumed would sort things out for me and provide some 
> reasonable default behavior - but instead it just gave an annoyingly 
> unhelpful error message:
> 
>  /home/mingo/linux-2.6-x86.git/ - not something we can merge
> 
> there should really be a consciously established "route of failure 
> resolution" - directing people towards relevant sources of information 
> or commands when the git command-line utilities return some error due to 
> user incompetence. Otherwise users just guess around and get frustrated.

I'm not sure we can figure out what the user actually meant in this case; there's just too much overlap in namespaces to determine reliably that you were giving it a remote repository on the local filesystem rather than anything else.

	-Daniel
*This .sig left intentionally blank*