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

[Junio C Hamano <gitster@pobox.com>]

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.