threads / patch / 28655

patch, 20 partsRe: [PATCH 00/20] [GIT PULL][v3.2] tracing: queued updates

Subject: Re: [PATCH 00/20] [GIT PULL][v3.2] tracing: queued updates

## tl;dr

3 messages between Oct 12, 2011 and Oct 12, 2011. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Ingo Molnar· Oct 12, 2011, 08:07 UTC · lore

* Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:

Show 8 quoted lines

> On Tue, 11 Oct 2011 07:50:17 +0200, Ingo Molnar said:
> 
> >  $ git pull git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git tip/perf/core
> >  fatal: The remote end hung up unexpectedly
> 
> Is it possible to get 'git' to say something more informative than 
> "hung up unexpectedly"? "Tree not found, check URL" or similar 
> would be nice...

I've Cc:-ed the Git development list which has lots of very responsive gents on it eager to improve Git.

I see this message dozens of times per year and i am always confused about the message.

Firstly, arguably, typoing something is not 'fatal' really - it's just a resource that was not found on the server.

Secondly, and more importantly, the reason for the failed pull is indeed important to know, if you want to resolve the problem with a minimum fuss:

 - Was it the tree that didnt exist?
 - Or the branch?
 - Or was there some other problem [such as a truly unexpectedly 
                                    closed transport socket]?

It's really useful for a painless UI flow to disambiguate failure messages into clearly actionable variants.

Thanks,

	Ingo

Jeff King· Oct 12, 2011, 14:19 UTC · re: Ingo Molnar · lore

On Wed, Oct 12, 2011 at 10:07:14AM +0200, Ingo Molnar wrote:

Show 8 quoted lines

> > On Tue, 11 Oct 2011 07:50:17 +0200, Ingo Molnar said:
> > 
> > >  $ git pull git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git tip/perf/core
> > >  fatal: The remote end hung up unexpectedly
> > 
> > Is it possible to get 'git' to say something more informative than 
> > "hung up unexpectedly"? "Tree not found, check URL" or similar 
> > would be nice...

It's not possible for the client to say anything more. The server sees that the request isn't valid and hangs up without saying anything. So the server needs to be changed to output better responses.

Show 14 quoted lines

> Firstly, arguably, typoing something is not 'fatal' really - it's 
> just a resource that was not found on the server.
> 
> Secondly, and more importantly, the reason for the failed pull is 
> indeed important to know, if you want to resolve the problem with a 
> minimum fuss:
> 
>  - Was it the tree that didnt exist?
>  - Or the branch?
>  - Or was there some other problem [such as a truly unexpectedly 
>                                     closed transport socket]?
> 
> It's really useful for a painless UI flow to disambiguate failure 
> messages into clearly actionable variants.

I agree. I think some people are concerned with leaking information about which repos exist and how they are configured. That is probably not a big problem for a public site like kernel.org, though.

You might find this thread interesting:

  http://thread.gmane.org/gmane.comp.version-control.git/182529/focus=182642

It seems to have resulted in a patch that will at least say "access denied" for every error. Which is a step up from "the remote end hung up unexpectedly", but I do think most users would appreciate it being more specific.

Perhaps we just need a config option to turn on more verbose messages, if the site decides that there's no security implications to doing so.

-Peff

Ingo Molnar· Oct 12, 2011, 16:29 UTC · re: Jeff King · lore

* Jeff King <peff@peff.net> wrote:

Show 7 quoted lines

> > It's really useful for a painless UI flow to disambiguate failure 
> > messages into clearly actionable variants.
> 
> I agree. I think some people are concerned with leaking information 
> about which repos exist and how they are configured. That is 
> probably not a big problem for a public site like kernel.org, 
> though.

Well, a gitconfig option could be provided to not leak that small amount of info - but it would otherwise be weird for an OSS SCM to default to a behavior that only makes sense with closed source, right? :-)

Thanks,

	Ingo