threads / patch / 41632

patchfetch: show reference pointed by new tags

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

## tl;dr

5 messages between Mar 6, 2016 and Mar 13, 2016. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

Eric Engestrom· Mar 6, 2016, 22:34 UTC · lore
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(+)
Show changes to builtin/fetch.c +1 −0
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
Junio C Hamano· Mar 7, 2016, 00:18 UTC · re: Eric Engestrom · lore

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

Eric Engestrom <eric@engestrom.ch> writes:
Show 7 quoted lines
> 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?
Show 27 quoted lines
> ---
>
> 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]");
Junio C Hamano· Mar 7, 2016, 01:05 UTC · re: Junio C Hamano · lore

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

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.
Junio C Hamano· Mar 8, 2016, 04:28 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 14 quoted lines
> 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.
Eric Engestrom· Mar 13, 2016, 15:38 UTC · re: Junio C Hamano · lore

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

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

← back to recent threads