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