Re: [PATCH] fetch: show reference pointed by new tags

From: Eric Engestrom <eric@engestrom.ch>
Date: Mar 13, 2016, 15:38 UTC
Message-ID: <20160313153802.GG30298@engestrom.ch>
In-Reply-To: <xmqqd1r5mw4p.fsf@gitster.mtv.corp.google.com>

Hi Junio,

Thanks for the warm welcome, but after your explanation on the purpose of the second field, it looks like my patch was just a plain bad idea.

I'm not that new to git (I've been using it actively for 6+ years), but as you guessed, I thought it was just redundant info as I had never seen a tag with a different remote name (unlike new branches, for which you always see the `remote/branch` name), and I thought I might as well replace it with an other info. As you mentioned though, a tag can be used everywhere its hash can, so there's no point showing that either.

I guess I'll just take that as a lesson :]
  “Make sure you actually understand what the code is doing
  before trying to modify it”

Cheers, Eric

On Mon, Mar 07, 2016 at 08:28:06PM -0800, Junio C Hamano wrote:

Show 51 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > But I am merely guessing from the your patch text what the reasoning
> > behind the change was and you are the one who had the original
> > reason why you needed this change, so your "why" may be a lot more
> > useful use case than the one I made up and called "semi-sensible"
> > here.  The proposed log message needs to explain your "why".
> >
> > And if you explained "why", you may have heard other people agreeing
> > with you that this new piece of information is nice to have.  They
> > may even have helped you by suggesting to add this extra information
> > somewhere in the output, instead of replacing existing information
> > in the output (which would lead to loss of convenience and
> > information).
> 
> I just thought of another possible explanation why you may have
> thought that it is a good idea to clobber the right hand side of the
> fetch report.  Perhaps you thought that LHS and RHS say the same
> thing and that is redundant?
> 
> Because "git fetch" is flexible and allows you to store what the
> remote side called X locally as Y, the fetch report in the most
> general form must say X on the remot side) was fetched and stored as
> Y in the local repository, i.e.
> 
> 	[new tag] X -> Y
> 
> but it is excusable that people new to Git who never saw such a
> renaming fetch to misunderstand that we are giving redundant
> information.
> 
> If that was the motivation, a possible way to change the behaviour
> would be to show
> 
> 	[new tag] X
> 
> if and only if the remote side and the local side uses exactly the
> sae name for the ref.  The lack of " -> " can clearly tell the user
> that the output is telling us that what they call X is fetched and
> stored as X (i.e. under the same name) locally.  A fetched ref that
> does not update any local ref (i.e. the ones that are recorded only
> in the FETCH_HEAD file) is shown as
> 
> 	tag X -> FETCH_HEAD
> 
> so there is no ambiguity there, either.
> 
> 
>