On 2016-05-26 03:31 PM, Junio C Hamano wrote:
Marc Branchaud <marcn...@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
