[PATCH 2/2] Add transport message for up-to-date references

[PATCH 2/2] Add transport message for up-to-date references

[Christopher Lindee]

If the `--send-up-to-date` option in the previous commit is used, the
"Everything up-to-date!" message will never appear, even if all of the
refs are up to date.  Moreover, the output `deadbeef..deadbeef` appears
suspicious, almost as if a collision occurred.  To clarify that the hash
is, in fact, identical & to allow grepping for the phrase "up-to-date",
add a message to the output when the ref is transmitted, but no change
occurred.

Signed-off-by: Christopher Lindee <christopher.lindee@webpros.com>
---
 transport.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/transport.c b/transport.c
index 84deadd2b6..89802452ea 100644
--- a/transport.c
+++ b/transport.c
@@ -670,6 +670,8 @@ static void print_ok_ref_status(struct ref *ref,
 			strbuf_addstr(&quickref, "..");
 			type = ' ';
 			msg = NULL;
+			if (oideq(old_oid, new_oid))
+				msg = "up-to-date";
 		}
 		strbuf_add_unique_abbrev(&quickref, new_oid,
 					 DEFAULT_ABBREV);
-- 
2.38.1

Re: [PATCH 2/2] Add transport message for up-to-date references

[Junio C Hamano]

Christopher Lindee <christopher.lindee@webpros.com> writes:

> Subject: Re: [PATCH 2/2] Add transport message for up-to-date references

Same comment as [1/2].  Perhaps

    push: mark forced no-op pushes differently in the report

or something?

> If the `--send-up-to-date` option in the previous commit is used, the
> "Everything up-to-date!" message will never appear, even if all of the
> refs are up to date.  Moreover, the output `deadbeef..deadbeef` appears
> suspicious, almost as if a collision occurred.  To clarify that the hash
> is, in fact, identical & to allow grepping for the phrase "up-to-date",
> add a message to the output when the ref is transmitted, but no change
> occurred.
>
> Signed-off-by: Christopher Lindee <christopher.lindee@webpros.com>
> ---
>  transport.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/transport.c b/transport.c
> index 84deadd2b6..89802452ea 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -670,6 +670,8 @@ static void print_ok_ref_status(struct ref *ref,
>  			strbuf_addstr(&quickref, "..");
>  			type = ' ';
>  			msg = NULL;
> +			if (oideq(old_oid, new_oid))
> +				msg = "up-to-date";
>  		}
>  		strbuf_add_unique_abbrev(&quickref, new_oid,
>  					 DEFAULT_ABBREV);

This code is in an if/else cascade of this shape:

	if we are deleting
		print [deleted]
	else if they did not have any
		print [new]
	else {
		if we forced
		then
			prepare to say forced
		else
			prepare to say an unforced update
		say "updated" in a certain way
	}

The above addition looks somewhat out of place.  I would understand
if the addition happened like so instead:

diff --git i/transport.c w/transport.c
index df518ead70..bacef94b33 100644
--- i/transport.c
+++ w/transport.c
@@ -666,6 +666,8 @@ static void print_ok_ref_status(struct ref *ref,
 			strbuf_addstr(&quickref, "...");
 			type = '+';
 			msg = "forced update";
+		} else if (oideq(old_oid, new_oid)) {
+			... prepare to say "same but forced no-op" ...
 		} else {
 			strbuf_addstr(&quickref, "..");
 			type = ' ';


to make the new logic flow more like so:

		if we forced
		then
			prepare to say forced
		else if we were forced to tell no-op push
			prepare to say we did no-op
		else
			prepare to say an unforced update
		say "updated" in a certain way

Re: [PATCH 2/2] Add transport message for up-to-date references

[Christopher Lindee]

Junio C Hamano writes:

> Christopher Lindee <christopher.lindee@webpros.com> writes:
> 
> > Subject: Re: [PATCH 2/2] Add transport message for up-to-date references
> 
> Same comment as [1/2].  Perhaps
> 
>     push: mark forced no-op pushes differently in the report
> 
> or something?

Thanks!  I will correct this.

> > If the `--send-up-to-date` option in the previous commit is used, the
> > "Everything up-to-date!" message will never appear, even if all of the
> > refs are up to date.  Moreover, the output `deadbeef..deadbeef` appears
> > suspicious, almost as if a collision occurred.  To clarify that the hash
> > is, in fact, identical & to allow grepping for the phrase "up-to-date",
> > add a message to the output when the ref is transmitted, but no change
> > occurred.
> >
> > Signed-off-by: Christopher Lindee <christopher.lindee@webpros.com>
> > ---
> >  transport.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/transport.c b/transport.c
> > index 84deadd2b6..89802452ea 100644
> > --- a/transport.c
> > +++ b/transport.c
> > @@ -670,6 +670,8 @@ static void print_ok_ref_status(struct ref *ref,
> >                       strbuf_addstr(&quickref, "..");
> >                       type = ' ';
> >                       msg = NULL;
> > +                     if (oideq(old_oid, new_oid))
> > +                             msg = "up-to-date";
> >               }
> >               strbuf_add_unique_abbrev(&quickref, new_oid,
> >                                        DEFAULT_ABBREV);
> 
> This code is in an if/else cascade of this shape:
> 
>         if we are deleting
>                 print [deleted]
>         else if they did not have any
>                 print [new]
>         else {
>                 if we forced
>                 then
>                         prepare to say forced
>                 else
>                         prepare to say an unforced update
>                 say "updated" in a certain way
>         }
> 
> The above addition looks somewhat out of place.  I would understand
> if the addition happened like so instead:
> 
> diff --git i/transport.c w/transport.c
> index df518ead70..bacef94b33 100644
> --- i/transport.c
> +++ w/transport.c
> @@ -666,6 +666,8 @@ static void print_ok_ref_status(struct ref *ref,
>                         strbuf_addstr(&quickref, "...");
>                         type = '+';
>                         msg = "forced update";
> +               } else if (oideq(old_oid, new_oid)) {
> +                       ... prepare to say "same but forced no-op" ...
>                 } else {
>                         strbuf_addstr(&quickref, "..");
>                         type = ' ';
> 
> 
> to make the new logic flow more like so:
> 
>                 if we forced
>                 then
>                         prepare to say forced
>                 else if we were forced to tell no-op push
>                         prepare to say we did no-op
>                 else
>                         prepare to say an unforced update
>                 say "updated" in a certain way

The shoehorned `if` was to avoid duplicating the `strbuf_addstr` and
`type` statements.  It sounds like code duplication is not a concern,
so I can make that change.  However, with this new logic flow, maybe
it would be better to have wholly unique values for the display, for
example:

   deadbeef...deadbeef  main -> main
  -deadbeef..deadbeef   main -> main
  =deadbeef..deadbeef   main -> main
  =deadbeef             main -> main
   deadbeef^!           main -> main
  ^deadbeef deadbeef    main -> main
   deadbeef==deadbeef   main -> main
   deadbeef..deadbeef   main == main

There's a fair amount of room for creativity here.  Of course, using
revisions is useful, but the existing output contains `+` for forced
updates, which is not valid in a revision, so there is clearly space
for novelty.

We may also want to consider what happens when both --force and this
new option are used at the same time.  When testing, the message was
always "up-to-date", but I realize now that a server might report it
as a forced update - it would be odd, but would it be impossible?  I
don't know enough about the push certificate records discussion from
the cover page to say that we wouldn't force an update on a noop.

Regards,
Chris.

Re: [PATCH 2/2] Add transport message for up-to-date references

[Christopher Lindee]

Christopher Lindee writes:

> Junio C Hamano writes:
> 
> > Christopher Lindee <christopher.lindee@webpros.com> writes:
> > 
> > > Subject: Re: [PATCH 2/2] Add transport message for up-to-date references
> > >
> > > If the `--send-up-to-date` option in the previous commit is used, the
> > > "Everything up-to-date!" message will never appear, even if all of the
> > > refs are up to date.  Moreover, the output `deadbeef..deadbeef` appears
> > > suspicious, almost as if a collision occurred.  To clarify that the hash
> > > is, in fact, identical & to allow grepping for the phrase "up-to-date",
> > > add a message to the output when the ref is transmitted, but no change
> > > occurred.
> > >
> > > Signed-off-by: Christopher Lindee <christopher.lindee@webpros.com>
> > > ---
> > >  transport.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/transport.c b/transport.c
> > > index 84deadd2b6..89802452ea 100644
> > > --- a/transport.c
> > > +++ b/transport.c
> > > @@ -670,6 +670,8 @@ static void print_ok_ref_status(struct ref *ref,
> > >                       strbuf_addstr(&quickref, "..");
> > >                       type = ' ';
> > >                       msg = NULL;
> > > +                     if (oideq(old_oid, new_oid))
> > > +                             msg = "up-to-date";
> > >               }
> > >               strbuf_add_unique_abbrev(&quickref, new_oid,
> > >                                        DEFAULT_ABBREV);
> > 
> > This code is in an if/else cascade of this shape:
> > 
> >         if we are deleting
> >                 print [deleted]
> >         else if they did not have any
> >                 print [new]
> >         else {
> >                 if we forced
> >                 then
> >                         prepare to say forced
> >                 else
> >                         prepare to say an unforced update
> >                 say "updated" in a certain way
> >         }
> > 
> > The above addition looks somewhat out of place.  I would understand
> > if the addition happened like so instead:
> > 
> > diff --git i/transport.c w/transport.c
> > index df518ead70..bacef94b33 100644
> > --- i/transport.c
> > +++ w/transport.c
> > @@ -666,6 +666,8 @@ static void print_ok_ref_status(struct ref *ref,
> >                         strbuf_addstr(&quickref, "...");
> >                         type = '+';
> >                         msg = "forced update";
> > +               } else if (oideq(old_oid, new_oid)) {
> > +                       ... prepare to say "same but forced no-op" ...
> >                 } else {
> >                         strbuf_addstr(&quickref, "..");
> >                         type = ' ';
> > 
> > 
> > to make the new logic flow more like so:
> > 
> >                 if we forced
> >                 then
> >                         prepare to say forced
> >                 else if we were forced to tell no-op push
> >                         prepare to say we did no-op
> >                 else
> >                         prepare to say an unforced update
> >                 say "updated" in a certain way
> 
> The shoehorned `if` was to avoid duplicating the `strbuf_addstr` and
> `type` statements.  It sounds like code duplication is not a concern,
> so I can make that change.  However, with this new logic flow, maybe
> it would be better to have wholly unique values for the display, for
> example:
> 
>    deadbeef...deadbeef  main -> main
>   -deadbeef..deadbeef   main -> main
>   =deadbeef..deadbeef   main -> main
>   =deadbeef             main -> main
>    deadbeef^!           main -> main
>   ^deadbeef deadbeef    main -> main
>    deadbeef==deadbeef   main -> main
>    deadbeef..deadbeef   main == main
> 
> There's a fair amount of room for creativity here.  Of course, using
> revisions is useful, but the existing output contains `+` for forced
> updates, which is not valid in a revision, so there is clearly space
> for novelty.

It seems I just needed to look one function below to find precedent:

  static int print_one_push_report(struct ref *ref, const char *dest, int count,
                                   struct ref_push_report *report,
                                   int porcelain, int summary_width)
  {       
          ...
          case REF_STATUS_UPTODATE:
                  print_ref_status('=', "[up to date]", ref,
                                   ref->peer_ref, NULL,
                                   report, porcelain, summary_width);
                  break;

Is this a precedent we should follow, or is print_one_push_report()
special in some way?

Thanks,
Chris.

Re: [PATCH 2/2] Add transport message for up-to-date references

[Junio C Hamano]

Christopher Lindee <christopher.lindee@webpros.com> writes:

> It seems I just needed to look one function below to find precedent:
>
>   static int print_one_push_report(struct ref *ref, const char *dest, int count,
>                                    struct ref_push_report *report,
>                                    int porcelain, int summary_width)

It is "static int" meaning it is a file-local function.  You should
be able to find out how it is used without running around all over
the codebase but just the single file it appears in.

>   {       
>           ...
>           case REF_STATUS_UPTODATE:
>                   print_ref_status('=', "[up to date]", ref,
>                                    ref->peer_ref, NULL,
>                                    report, porcelain, summary_width);
>                   break;
>
> Is this a precedent we should follow, or is print_one_push_report()
> special in some way?

The code path this function is called is triggerd when you go
verbose:

    $ git push  ../victim-00 v2.43.0-rc0~56:master
    Everything up-to-date
    $ git push -v ../victim-00 v2.43.0-rc0~56:master
    Pushing to ../victim-00
    To ../victim-00
     = [up to date]		v2.43.0-rc0~56 -> master

Do we want to make it possible to differentiate between the forced
no-op and omitted no-op from "git push -v" output, or should users
refrain from using "-v" when they want to be able to tell?

Re: [PATCH 2/2] Add transport message for up-to-date references

[Junio C Hamano]

Christopher Lindee <christopher.lindee@webpros.com> writes:

> The shoehorned `if` was to avoid duplicating the `strbuf_addstr` and
> `type` statements.  It sounds like code duplication is not a concern,
> so I can make that change.  However, with this new logic flow, maybe
> it would be better to have wholly unique values for the display,...

I wasn't avoiding duplication at all.

20% of the reason why I pointed it out was because the third member
"forced no-op update" that is added to the existing two, "forced
update" and "non-forced fast-forwarding update", looked as if it
were made a part of the "non-forced update", where the three at
least to me looked more like equals.  And the rest 80% is exactly
because the "three equals" arrangement gives us a more freedom to
express how we show the update.

>    deadbeef==deadbeef   main -> main
>    deadbeef..deadbeef   main == main
>
> There's a fair amount of room for creativity here.  Of course, using
> revisions is useful, but the existing output contains `+` for forced
> updates, which is not valid in a revision, so there is clearly space
> for novelty.

Sorry, but I do not understand the remark about '+' at all.  In the
existing output, the flag char like '+' comes at the beginning and
followed by a whitespace before <from> and <to> ref correspondence
is reported, no?

I can buy the idea of using "summary" that is different from the
existing A..B or A...B form to make it stand out, but the "->"
between the two "main" in your example must stay as is.  That part
of the output shows the correspondence between our ref and their
ref, and has nothing to do with what object their ref originally was
pointing at and what object their ref points at now.  There is no
choice of the sign there, but even if there were a choice [*], it
should not be influenced by how the pair of <old,new> objects
involved in the update are related.

	Side note: we could imagine using a different sign other
	than "->" if you update a branch from a non-ref
	(e.g. pushing the freshly made commit on detached HEAD state
	to update a branch over there), or perhaps updating a ref
	with a ref from different hierarchies (e.g. push the tip of
	the current branch to update their refs/tags/v1.2.3).

Perhaps use "%" as the type and show just a single object name in
summary?  I.e. something like the first one in this example:

 % 4f9b731bde		   master -> main
   1203cff8ae..6e790dbe36  next -> next
 + b7485789d7...3e580ca942 seen -> seen

> We may also want to consider what happens when both --force and this
> new option are used at the same time.  When testing, the message was
> always "up-to-date", but I realize now that a server might report it
> as a forced update - it would be odd, but would it be impossible?

If I recall correctly what happens at the protocol level (without
looking at the code---look for comment "Finally.*tell the other end"
to find it out where it is), I do not think the receiving end can
even tell, because the only thing they see for each ref is the old
and the new object name and the refname.  There are intricate
mechanism among the sender (push/send-pack), the receiver
(receive-pack), and the transport helpers, to carry necessary info
around to produce a report that says "this ref update went OK" and
"this ref update was NG, due to such and such reason", but I do not
think the receiving end does not compute the forcedness for
reporting.  It only runs in_merge_bases() between old and new
objects to decide if it is a non-fast-forward, when configured to
reject such updates, and it may report the failure was due to
non-fast-forward condition, but I do not think there is more than
one kind of successful updates reported (they just say "ok").

Speaking of what happens on the receiving end, we may have to
consider what, if anything, we need to do to the hooks that run
there, which gets "the ref X was updated from object A to object B".
They never saw "object A to object A" update and may get confused.

Re: [PATCH 2/2] Add transport message for up-to-date references

[Martin Ågren]

On Tue, 12 Mar 2024 at 22:55, Christopher Lindee
<christopher.lindee@webpros.com> wrote:
>
> If the `--send-up-to-date` option in the previous commit is used, the
> "Everything up-to-date!" message will never appear, even if all of the
> refs are up to date.  Moreover, the output `deadbeef..deadbeef` appears
> suspicious, almost as if a collision occurred.  To clarify that the hash
> is, in fact, identical & to allow grepping for the phrase "up-to-date",
> add a message to the output when the ref is transmitted, but no change
> occurred.

> +                       if (oideq(old_oid, new_oid))
> +                               msg = "up-to-date";

From a grammar point of view, I think this should be "up to date". (A
branch can be up to date, in which case it is an up-to-date branch.)

There is quite some history exactly around this phrase, though, see,
e.g., 80bdaba894 ("messages: mark some strings with "up-to-date" not to
touch", 2024-01-12). If we really want "up-to-date" here, I think we
should add a comment similar to 80bdaba894, although it does feel
awkward to knowingly introduce a new instance. So maybe better, go for
"up-to-date ref"?

If we worry about how "Everything up-to-date" disappeared in the
previous commit, maybe that commit should instead detect that all refs
were such no-ops and emit that "Everything up-to-date"?

(Part of me wonders what kind of existing scripts [1] would be helped by
us sticking to the dashed form. If they go "grep '^Everything
up-to-date$", they won't notice this new output. If they use a more
relaxed "grep up-to-date", they might get confused, possibly much more
often than they could already be by a branch called "up-to-date".)

Martin

[1] They don't even provide this new option, but let's assume we
eventually grow a config knob.

Re: [PATCH 2/2] Add transport message for up-to-date references

[Christopher Lindee]

Martin Ågren <martin.agren@gmail.com> writes:
> On Tue, 12 Mar 2024 at 22:55, Christopher Lindee
> <christopher.lindee@webpros.com> wrote:
> >
> > If the `--send-up-to-date` option in the previous commit is used, the
> > "Everything up-to-date!" message will never appear, even if all of the
> > refs are up to date.  Moreover, the output `deadbeef..deadbeef` appears
> > suspicious, almost as if a collision occurred.  To clarify that the hash
> > is, in fact, identical & to allow grepping for the phrase "up-to-date",
> > add a message to the output when the ref is transmitted, but no change
> > occurred.
>
> > +                       if (oideq(old_oid, new_oid))
> > +                               msg = "up-to-date";
>
> From a grammar point of view, I think this should be "up to date". (A
> branch can be up to date, in which case it is an up-to-date branch.)

I wondered about that; I will fix.

> There is quite some history exactly around this phrase, though, see,
> e.g., 80bdaba894 ("messages: mark some strings with "up-to-date" not to
> touch", 2024-01-12). If we really want "up-to-date" here, I think we
> should add a comment similar to 80bdaba894, although it does feel
> awkward to knowingly introduce a new instance. So maybe better, go for
> "up-to-date ref"?
>
> If we worry about how "Everything up-to-date" disappeared in the
> previous commit, maybe that commit should instead detect that all refs
> were such no-ops and emit that "Everything up-to-date"?
>
> (Part of me wonders what kind of existing scripts [1] would be helped by
> us sticking to the dashed form. If they go "grep '^Everything
> up-to-date$", they won't notice this new output. If they use a more
> relaxed "grep up-to-date", they might get confused, possibly much more
> often than they could already be by a branch called "up-to-date".)

This raises a good point: if we default to the old behavior and only
send up-to-date refs when the new option is present (as is currently 
the case with this patchset), then existing scripts will continue to
work.  Moreover, scripts using the new option will consistently have
"up to date", so they can change the grep to use that (since it will 
never show "Everything up-to-date!").

Thanks,
Chris.

Re: [PATCH 2/2] Add transport message for up-to-date references

[Junio C Hamano]

Christopher Lindee <christopher.lindee@webpros.com> writes:

> This raises a good point: if we default to the old behavior and only
> send up-to-date refs when the new option is present (as is currently 
> the case with this patchset), then existing scripts will continue to
> work.  Moreover, scripts using the new option will consistently have
> "up to date", so they can change the grep to use that (since it will 
> never show "Everything up-to-date!").

Scripts should never be parsing the output meant for humans.  You
should worry about "git push --porcelain" output first.

I think we report "= srcref:dstref [up to date]" there and that is
what the scripts are expecting for an up-to-date case.  If you want
to allow the scripts to react to a forced no-op update differently
from the normal "we didn't even tell them about this ref" case, then
we'd need a different type letter or "[up to date]" string (or
both).