Christopher Lindee <christopher.lindee@xxxxxxxxxxx> 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.
