git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4] fast-(import|export): improve on commit signature output format

From
Christian Couder <christian.couder@gmail.com>
Date
Jul 8, 2025, 10:17 UTC
Message-ID
<CAP8UFD3ZitsRz3ccAjmB_k+DhdYw+AJgf-2vPCGUaRAgWd9SEA@mail.gmail.com>
In-Reply-To
<xmqqwm8jxoj3.fsf@gitster.g>
On Tue, Jul 8, 2025 at 7:03 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > On Tue, Jul 8, 2025 at 12:58 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> >> We haven't heard much after a few comments were posted on this
> >> latest round, since Elijah's
> >> <20250619133630.727274-1-christian.couder@gmail.com>; I understand
> >> that it would be the author's turn to respond (the response does not
> >> necessarily have to be with an updated iteration).  If so, let me
> >> mark the topic as Stalled in the draft of the latest issue of the
> >> "What's cooking" report.
> >
> > I will hopefully send a v5 later today.
I just sent it and replied to the pending reviews about v4.
Show 5 quoted lines
> Thanks.
>
> By the way, I noticed that you often do not respond to reviews until
> the last minute, at the same time as when you send your next
> iteration, or even soon after doing so.
Yeah, right.
Show 17 quoted lines
> That is quite different from how other contributors operate, i.e.
> respond and engage in discussions triggered by the reviews, and
> after people involved in discussion got an (even rough) idea of what
> the right next step would be, if not a total consensus, send the
> next iteration.
>
> I do not know which style is more efficient form of cooperation, but
> it somewhat makes my job harder, if I do not hear much _heartbeats_
> after I see review comments on the list.  I do not mind waiting for
> seeing the next round for quite a while---after all, any substantial
> (re)work takes time.  And responding to reviews may need thinking
> things through carefully, which may take some time, so I would not
> demand an immediate response, either.  But it would be nearly
> impossible to feel the current status of such a topic---a few review
> comments are seen, the author goes silent for a while, we cannot
> tell if the author is working on a new iteration or where the author
> and reviewers agree and disagree.
Sorry if it makes your job harder.

When I work on a number of different things, I alternate between topics. Just after I send a new version of some series to the mailing list, I usually start working on a different topic. These days for example I alternate between this topic and the promisor-remote capability topic. So it seems to me that if I were to respond to reviews right away, I could be switching topics all the time if there are discussions happening on several topics I work on.

I know I still have to switch often anyway between topics because I might be pinged internally at GitLab about some issues or because someone I mentor asks me a question privately, etc. And maybe for you or others switching topics often is not an issue, but when topics are quite complex I feel it makes it much harder for me to focus on what I am doing. I don't think I am the only one in this case by the way.

> Also a review response that comes at the same time or immediately
> after a new iteration is already sent out makes it look like the
> author is refusing to continue discussion and reviewers are not
> welcome to make follow-up suggestions during such a discussion.

Sorry if it looks like this. I am not refusing any discussion or follow up suggestions. As you say above, responding to reviews may need thinking and often working to try things out, and often it seems to me that I cannot really reply properly if I haven't worked enough to try some ideas.

Let me take for example the v5 I just sent. It's only by researching and trying different ideas without knowing if they would work that I found (after a long time) a way to write a proper test with both a SHA-1 and a SHA-256 signature on the same commit. It was the same for using "$GIT_DEFAULT_HASH" instead of "sha(1|256)" in the tests.

So yeah, I could have replied early with "I will do it in v5." or "I will try to do it in v5." or "Ok" or "I will think about it." to most suggestions I got, but what would have really been the value of a response with mostly those kinds of sentences in it?

> Instead, the next iteration comes as a fait accompli,

Even if I had replied with mostly "I will do it in v5." or "I will try to do it in v5.", etc, to many suggestions, I could still have found or decided for some reasons to actually implement something else and use those reasons to justify it. Would it have been less of a fait accompli?

> and makes it
> less useful to continue the review discussion on the previous round
> by responding to such a late response.

In my opinion the discussion can continue with more useful and higher quality information, as I have worked significantly to think through and try to implement the suggestions that were made or to research and then often implement other solutions. Yeah, it doesn't continue on the previous round, but hopefully the new round is better, so ...

Previous: Junio C HamanoNext: Christian Couder
Message 53 of 65 in “fast-(import|export): improve on the signature algorithm name”
  1. fast-(import|export): improve on the signature algorithm nameChristian Couder, Apr 24, 2025
  2. Junio C HamanoApr 24, 2025
  3. Elijah NewrenApr 24, 2025
  4. Junio C HamanoApr 24, 2025
  5. Christian CouderMay 26, 2025
  6. Junio C HamanoMay 27, 2025
  7. Junio C HamanoMay 28, 2025
  8. Elijah NewrenMay 28, 2025
  9. Junio C HamanoMay 28, 2025
  10. Elijah NewrenMay 28, 2025
  11. Junio C HamanoMay 29, 2025
  12. Christian CouderJun 2, 2025
  13. Christian CouderJun 2, 2025
  14. Junio C HamanoJun 2, 2025
  15. Christian CouderMay 26, 2025
  16. Elijah NewrenApr 24, 2025
  17. Christian CouderMay 26, 2025
  18. brian m. carlsonApr 24, 2025
  19. Christian CouderMay 26, 2025
  20. Junio C HamanoApr 24, 2025
  21. 0/6 extract algo information from signaturesChristian Couder, May 26, 2025
  22. 1/6 gpg-interface: simplify ssh fingerprint parsingChristian Couder, May 26, 2025
  23. 2/6 gpg-interface: use left shift to define GPG_VERIFY_*Christian Couder, May 26, 2025
  24. 3/6 doc/verify-commit: update and improve the whole docChristian Couder, May 26, 2025
  25. 4/6 gpg-interface: extract hash algorithm from signature status outputChristian Couder, May 26, 2025
  26. 5/6 gpg-interface: extract SSH key type from signature status outputChristian Couder, May 26, 2025
  27. 6/6 verify-commit: add a --summary flagChristian Couder, May 26, 2025
  28. Elijah NewrenMay 26, 2025
  29. Christian CouderJun 19, 2025
  30. brian m. carlsonJun 2, 2025
  31. Christian CouderJun 19, 2025
  32. fast-(import|export): improve on commit signature output formatChristian Couder, Jun 18, 2025
  33. fast-(import|export): improve on commit signature output formatChristian Couder, Jun 19, 2025
  34. Junio C HamanoJun 19, 2025
  35. Christian CouderJul 8, 2025
  36. Elijah NewrenJun 19, 2025
  37. Christian CouderJun 20, 2025
  38. Junio C HamanoJun 20, 2025
  39. Christian CouderJul 8, 2025
  40. Elijah NewrenJun 26, 2025
  41. Christian CouderJul 8, 2025
  42. Junio C HamanoJul 7, 2025
  43. Christian CouderJul 8, 2025
  44. Junio C HamanoJul 8, 2025
  45. Patrick SteinhardtJul 8, 2025
  46. Christian CouderJul 8, 2025
  47. Junio C HamanoJul 8, 2025
  48. Christian CouderJul 9, 2025
  49. Junio C HamanoJul 9, 2025
  50. Patrick SteinhardtJul 10, 2025
  51. Christian CouderJul 10, 2025
  52. Junio C HamanoJul 10, 2025
  53. Christian CouderJul 8, 2025
  54. fast-(import|export): improve on commit signature output formatChristian Couder, Jul 8, 2025
  55. Junio C HamanoJul 8, 2025
  56. Elijah NewrenJul 8, 2025
  57. Junio C HamanoJul 9, 2025
  58. Elijah NewrenJul 9, 2025
  59. Christian CouderJul 9, 2025
  60. Christian CouderJul 9, 2025
  61. fast-(import|export): improve on commit signature output formatChristian Couder, Jul 9, 2025
  62. Junio C HamanoJul 9, 2025
  63. Elijah NewrenJul 14, 2025
  64. Junio C HamanoJul 14, 2025
  65. Christian CouderJul 25, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.