| Message ID | SA1PR14MB4691A8AC86E290A3539BE1398D2B2@SA1PR14MB4691.namprd14.prod.outlook.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Optionally support push options on up-to-date branches | expand |
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
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.
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.
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.
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.
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.
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?
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).
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);
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(+)