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

From: Marc Branchaud <marcnarc@xiplink.com>
Date: May 26, 2016, 18:13 UTC
Message-ID: <57473CDA.5000408@xiplink.com>
In-Reply-To: <xmqq8tywwwab.fsf@gitster.mtv.corp.google.com>

On 2016-05-26 01:42 PM, Junio C Hamano wrote:

Show 10 quoted lines

>
> True.  One of the entries in Marc's example is easily misread as
> "pclouds/2nd-index branch at its refs/heads/pclouds/2nd-index was
> fetched to its usual place", when Marc wanted to say "they had
> 2nd-index branch at refs/heads/2nd-index, and it was copied to our
> refs/remotes/pclouds/2nd-index".
>
> So even though we might be able to make sure it is unambiguous
> without "this -> that" ("->" is pronounced as 'became'), it is
> easily misread.

Actually, I tend to just think of it as "this is a local name you can use to refer to the new thing that was just fetched." The left-hand side describes the thing being fetched (new or updated branch/tag/ref), and the right hand side shows how to locally refer to that thing.

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.

 > $ git fetch origin refs/pull/77/head refs/pull/78/head

Ah, now this is an odd case. Maybe there should be a different output format altogether for this one. The problem is that the remote refs being fetched are stored without any kind of local ref. (Commands like "git log FETCH_HEAD" only work with the last ref fetched, even though all the SHAs get added to the .git/FETCH_HEAD file. Maybe if git supported a "FETCH_HEAD@{x}" syntax...)

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. Maybe something like:

	From ...
	 * origin:refs/pull/77/head  abcd0123
	 * origin:refs/pull/78/head  453def00

(Not 100% sure about the "origin:" prefix...)

M.