[PATCH] fetch: show reference pointed by new tags

[PATCH] fetch: show reference pointed by new tags

[Eric Engestrom]

Before, new tags had their names shown twice:
 * [new tag]         v4.5-rc6   -> v4.5-rc6

Instead, show the hash of the commit pointed to:
 * [new tag]         v4.5-rc6   -> fc77dbd

Signed-off-by: Eric Engestrom <eric@engestrom.ch>
---

This is my first dive into git's code, so it's likely I'm not doing things
right. The first candidate for that is the literal `7`, which should probably
be a variable, but I couldn't find what I should use instead.

I'd be happy to fix this for a v2 :]

Cheers,
  Eric


 builtin/fetch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index e4639d8..93b2145 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -515,6 +515,7 @@ static int update_local_ref(struct ref *ref,
 		if (starts_with(name, "refs/tags/")) {
 			msg = "storing tag";
 			what = _("[new tag]");
+			pretty_ref = find_unique_abbrev(ref->new_oid.hash, 7);
 		} else if (starts_with(name, "refs/heads/")) {
 			msg = "storing head";
 			what = _("[new branch]");
-- 
2.7.2

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

[Junio C Hamano]

Eric Engestrom <eric@engestrom.ch> writes:

> Before, new tags had their names shown twice:
>  * [new tag]         v4.5-rc6   -> v4.5-rc6
>
> Instead, show the hash of the commit pointed to:
>  * [new tag]         v4.5-rc6   -> fc77dbd
>
> Signed-off-by: Eric Engestrom <eric@engestrom.ch>

The report from update-local-refs is meant to show what "local"
names the updated ref has, i.e. what names you can refer the result
as.  If you fetched v4.5-rc6, the output tells you that you can
refer to it as v4.5-rc6 in your local repository.

Technically, you can also refer to the tag as fc77dbd, but I do not
see why a user would want to.

In addition, if I did:

    $ git fetch $his_repository 'refs/tags/*:refs/tags/his/*'

I'd see his 'v1.0' tag locally stored as 'his/v1.0', and that is
what is shown in the output as

  * [new tag] v1.0 -> his/v1.0

so that I know I can refer to his v1.0 as "his/v1.0", to
differenticate from the tag I happen to have created as v1.0 in my
local repository.

So, why is this change an improvement?

> ---
>
> This is my first dive into git's code, so it's likely I'm not doing things
> right. The first candidate for that is the literal `7`, which should probably
> be a variable, but I couldn't find what I should use instead.
>
> I'd be happy to fix this for a v2 :]
>
> Cheers,
>   Eric
>
>
>  builtin/fetch.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index e4639d8..93b2145 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -515,6 +515,7 @@ static int update_local_ref(struct ref *ref,
>  		if (starts_with(name, "refs/tags/")) {
>  			msg = "storing tag";
>  			what = _("[new tag]");
> +			pretty_ref = find_unique_abbrev(ref->new_oid.hash, 7);
>  		} else if (starts_with(name, "refs/heads/")) {
>  			msg = "storing head";
>  			what = _("[new branch]");

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>> This is my first dive into git's code, so it's likely I'm not doing things
>> right. The first candidate for that is the literal `7`,...

Actually, the first candidate is not related to any code, but that
you did not explain "why" in your log message.

I raised two issues with your change in my response, which are (1)
loss of convenience (i.e. why would a user want to type fc77dbd when
v4.5-rc6 is easier to remember) and (2) loss of information
(i.e. renaming fetch loses the assurance from the report that v1.0
did indeed copied to his/v1.0).  Both of these things tell us that
the change only makes the result worse.

But I am sure you didn't make this change to make the resulting
system worse.  That is why I asked "why is this an improvement?" and
that is _not_ a rhetorical question (i.e. I wasn't making a
statement: "this cannot possibly be an improvement").  You must have
thought that the user would benefit in some way if the report showed
a raw abbreviated object name there.  But you failed to say what
exactly that benefit is, and I couldn't guess, and that is why I
asked.

Because a raw abbreviated object name alone is a fairly useless
piece of information (i.e. to get anything meaningful, the user
needs to give it to some Git command like "git log", "git show",
etc.), and the resulting local tag name is equally usable as a raw
object name is if the user is going to use these Git commands to
learn more about the object anyway, the only semi-sensible
justification I can think of offhand for this change is that the
user somehow already has a list of raw object names for the refs
expected to be updated available and showing the raw object name in
the update-local report may serve as an assurance that the right
object was fetched.  Perhaps there was an announcement e-mail
message that said fc77dbd is the object name of the v4.5-rc6 tag,
and the user can see that object was fetched without having to run
extra Git command, or something like that.

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

Anyway, welcome to Git development community.

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

[Junio C Hamano]

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.

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

[Eric Engestrom]

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