Re: [PATCH 1/2] fetch: better alignment in ref summary

[Marc Branchaud <marcnarc@xiplink.com>]

On 2016-05-26 03:31 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> The fact that something is buried in some odd part of the ref tree is
>> less relevant, IMO.  If I'm using custom fetch refspecs or other
>> oddities, I'll have that in the back of my head.  But what I really
>> care about is what ref I can use with commands like log and checkout.
>>
>> So, regarding Peff's examples:
>>
>>> $ git fetch origin refs/pull/*/head:refs/remotes/pr/*
>>
>> Just show me the "pr/foo" refs.  I know where things are coming
>> from. Even if I configured that fetch refspec a long time ago, I don't
>> need to see the exact mapping every time I fetch.
>
> That is only because you are used to seeing them.  You cannot claim
> "I'll remember forever without seeing them" without actually
> experiencing not seeing them for a long time.

I don't expect (or even want) to forever remember the mapping.  It's a 
matter of context.

When fetching, I'm interested in shiny new refs and I want to work with 
them.

When configuring a remote repository, I'm interested in how to bring 
that repo's refs into my own repository.

These are two distinct modes of thought, and I don't think fetch's 
output always needs to display the latter.  Perhaps the --verbose switch 
could turn on showing how the remote refs get mapped.  I can see how 
that would occasionally be useful for debugging fetch refspecs.

>> I think the output should show the plain SHA values, since those are
>> the only things the user can use to work with those refs.
>
> When they tell others how to reproduce what they did (or record what
> they did so that they can reproduce it later), they need what it is
> called at the remote end.

Which is why I included the refnames in my proposal to Peff's second 
example.  Really, the SHA and the remote's name for the SHA are the only 
meaningful things in this case.

> I would hesitate to go in the approach based on discarding
> information, as if it is the only way to shorten and clarify the
> output.  Let's not do so before thinking things through to achieve
> the same while keeping the information we give to the users.

I agree, this is not something to undertake lightly.  But I've yet to be 
convinced of the utility of always showing the ref mapping during a fetch.

I actually found fetch's output quite confusing when I first started 
using git.  It's really not obvious that the thing on the left of the 
"->" is the remote's local name, especially since to see what was 
fetched one has to use the thing on the right-hand side -- which is 
obviously in a remote-specific namespace.  (Admittedly, this was before 
checkout learned to search refs/remotes/ for things to check out.)

		M.