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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2016-05-26 03:31 PM, Junio C Hamano wrote:
Marc Branchaud <marcnarc@xxxxxxxxxxx> 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.

--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]