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

Re: [PATCH] builtin-remote: better handling of multiple remote HEADs

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 14, 2009, 19:48 UTC
Message-ID
<7vy6w8sstp.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20090214185411.GA13121@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Which made me think of something else, with all of this talk about
> reviewers that has been going on. Junio is actually in a little bit of a
> special position with small changes (like style issues) to say "I'll
> apply this, but tweak these changes".
It is not that I am special.

What is special is an otherwise obviously good patch with a few trivial mistakes that I can fix locally without worrying the fix-up may be wrong. It is not even per author, it is per patch, and it is a rare exception.

Often, I notice these things *after* I applied and reviewed the results, so it already is in my work area. I then judge the tradeoff between an extra round (which as you stated needs another fresh review, patch application and testing here) and the possibility that I may make a silly mistake myself while attempting a fix-up (such a mistake by me will not be seen on the list and others do not have chance to catch them).

For this reason, I try to keep these "will fix up no need for resend" to the minimum and only to the most trivial cases.

Show 11 quoted lines
> ... But the rest of us are stuck
> saying "I would change this one line" to the list; then either:
>
>   - the original submitter re-rolls the patch, which takes their time
>     and everyone else's time to look at the new patch, see that it is
>     trivially changed, etc
>
>     or
>
>   - Junio has to read the followup comments, then go back and find the
>     spot in the original patch to mark it up.
A third option is:
	"I would change this and that" review comment message, followed by
	a separate message "Here is how I would have done it", addressed
	To: the original submitter (with in-body From: line), Cc: to the
	list and me.

The original submitter can verify the latter one, and either agree to or disagree with it. If the reroll is good, then I can just pick it up. I think you have done that in the past yourself, and the process made my life a lot easier.

Previous: Jeff KingNext: Daniel Barkalow
Message 21 of 41 in “remote HEAD improvements take 2”
  1. 0/4 remote HEAD improvements take 2Jay Soffian, Feb 13, 2009
  2. 1/4 builtin-clone: move locate_head() to remote.c so it can be re-usedJay Soffian, Feb 13, 2009
  3. 2/4 builtin-remote: move duplicated cleanup code its own functionJay Soffian, Feb 13, 2009
  4. 3/4 builtin-remote: teach show to display remote HEADJay Soffian, Feb 13, 2009
  5. 4/4 builtin-remote: add set-head verbJay Soffian, Feb 13, 2009
  6. Junio C HamanoFeb 13, 2009
  7. Jay SoffianFeb 13, 2009
  8. 4/4 builtin-remote: add set-head subcommandJay Soffian, Feb 13, 2009
  9. Junio C HamanoFeb 13, 2009
  10. Jay SoffianFeb 13, 2009
  11. Jeff KingFeb 14, 2009
  12. Junio C HamanoFeb 14, 2009
  13. Jeff KingFeb 14, 2009
  14. Jay SoffianFeb 14, 2009
  15. Jay SoffianFeb 14, 2009
  16. Jeff KingFeb 14, 2009
  17. builtin-remote: better handling of multiple remote HEADsJay Soffian, Feb 14, 2009
  18. Jeff KingFeb 14, 2009
  19. Jay SoffianFeb 14, 2009
  20. Jeff KingFeb 14, 2009
  21. Junio C HamanoFeb 14, 2009
  22. Daniel BarkalowFeb 14, 2009
  23. Jeff KingFeb 14, 2009
  24. Jeff KingFeb 15, 2009
  25. 1/5 test scripts: refactor start_httpd helperJeff King, Feb 15, 2009
  26. 2/5 add basic http clone/fetch testsJeff King, Feb 15, 2009
  27. Junio C HamanoFeb 15, 2009
  28. 3/5 refactor find_refs_by_name to accept const listJeff King, Feb 15, 2009
  29. 4/5 remote: refactor guess_remote_headJeff King, Feb 15, 2009
  30. 5/5 remote: use exact HEAD lookup if it is availableJeff King, Feb 15, 2009
  31. Jay SoffianFeb 15, 2009
  32. Jeff KingFeb 15, 2009
  33. 1/2 transport: cleanup duplicated ref fetching codeJeff King, Feb 15, 2009
  34. 2/2 transport: unambiguously determine local HEADJeff King, Feb 15, 2009
  35. Jeff KingFeb 15, 2009
  36. Jeff KingFeb 15, 2009
  37. Jay SoffianFeb 15, 2009
  38. Jeff KingFeb 15, 2009
  39. Junio C HamanoFeb 16, 2009
  40. Jay SoffianFeb 16, 2009
  41. Jay SoffianFeb 13, 2009

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.