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

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Apr 18, 2013, 09:53 UTC
Message-ID
<CAMP44s1RpgM5U0ySsof_sgEHNS1p-seQ=ciVCth9gOJMG0cpHw@mail.gmail.com>
In-Reply-To
<CALkWK0nji4m0zJPf_s0G5jfWaAN_RTGFZ6dSxfahq2OcRsu5xQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 4:19 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 18 quoted lines
> Felipe Contreras wrote:
>> I think the commit message is fine, you don't. So YOU go ahead and
>> write the proper one. If you don't, all you are doing is being an
>> impediment to progress.
>
> Hey Felipe.  Let's get a few things straightened out first:
>
> - We all act in our selfish interests, and write code to scratch our
> personal itches.  I don't write code or commit messages for anyone
> else, and neither should you.
>
> - However, we're not working in isolation.  We have this giant mailing
> list where we all post our patches.  It's like a bazaar where we
> compete against other patches for developer attention and potential
> reviewers.  In other words, it's a free market, and we're selling our
> product: if it fails to sell, will you blame the market or your
> product?  I write clear code and beautiful commit messages exactly for
> this reason: I'm fighting for attention!

Except the customers are not git developers, it's git users. Git developers rejecting patches because of the commit message is akin to distributors rejecting products because they don't like the transportation packages; they are only hurting themselves, by hurting their customers.

Show 7 quoted lines
> - We have to learn to interoperate with others' code and conventions,
> if we want to be part of the community.  That doesn't mean that we
> drown out our individuality, but it means that a our patch series has
> to conform to some minimal, loose, and evolving standard.  Now, you
> can argue that many of the existing conventions are outdated (I do it
> all the time), but it cannot change overnight.  Your influence on the
> community will show up over an extended period of time.
And the only way it can change is by discussing.

The only one that gets bitten by fixes not getting merged are git users, not me. So if a discussion of a commit message impedes the merging of the commit, I don't get affected, but when we have agreed to disagree on what constitutes a good message, and the patch is still on hold, then there's a problem.

Show 7 quoted lines
> - We are not an old enterprise who blame breakages on a few
> individuals, and fire them.  We're a community where all of us are
> equally responsible for all parts of the code.  I am as responsible
> for the remote-hg code in master as you are, as I had every
> opportunity to review it when the patch series came up on the list.  I
> might have chosen not to, but that doesn't relieve me of
> responsibility.
I don't think so. Unless you added your Signed-off-by, you are not.
Show 6 quoted lines
> -  We don't practice division of labour.  There are no managers,
> "testing people", "documentation people", "code-writing people",
> "commit-message writing people" etc.  Everyone has to do some portion
> of all these tasks, although we try to keep the boring work/ technical
> debt to a minimum.  Don't ask other people to write commit messages
> for your code.

I am not. Neither should they ask me to write the commit messages they want. They can make *suggestions*, and I can reject them.

When two persons have different ideas, often times both are wrong, and the middle-ground is best, but sometimes a person reaches the middle-ground, and sometimes one person was right from the start.

But when everyone shares the *assumption* that there is never a commit message that is too long, you know the wrestling mat of ideas is rigged. I wonder if I should write a commit message as long as a book chapter for a one-liner, only to prove a point, but I'm honestly afraid that it would be committed as is.

And remember what started the conversation; do you think a patch with a possibly incomplete commit message should not be merged to pu (proposed updates), shouldn't even be mentioned in the "what's cooking" mail, and thus shouldn't even be considered "cooking"?

Cheers.
-- 
Felipe Contreras
Previous: Ramkumar RamachandraNext: Ramkumar Ramachandra
Message 21 of 85 in “What's cooking in git.git (Apr 2013, #05; Mon, 15)”
  1. Junio C HamanoApr 15, 2013
  2. Felipe ContrerasApr 15, 2013
  3. Junio C HamanoApr 15, 2013
  4. Felipe ContrerasApr 15, 2013
  5. Junio C HamanoApr 16, 2013
  6. Felipe ContrerasApr 16, 2013
  7. Thomas RastApr 16, 2013
  8. Felipe ContrerasApr 16, 2013
  9. Junio C HamanoApr 16, 2013
  10. Felipe ContrerasApr 16, 2013
  11. Phil HordApr 16, 2013
  12. Felipe ContrerasApr 16, 2013
  13. Phil HordApr 16, 2013
  14. Junio C HamanoApr 17, 2013
  15. Felipe ContrerasApr 17, 2013
  16. Junio C HamanoApr 17, 2013
  17. Felipe ContrerasApr 18, 2013
  18. Matthieu MoyApr 18, 2013
  19. Felipe ContrerasApr 18, 2013
  20. Ramkumar RamachandraApr 18, 2013
  21. Felipe ContrerasApr 18, 2013
  22. Ramkumar RamachandraApr 18, 2013
  23. Felipe ContrerasApr 18, 2013
  24. Ramkumar RamachandraApr 18, 2013
  25. Felipe ContrerasApr 18, 2013
  26. Ramkumar RamachandraApr 18, 2013
  27. Felipe ContrerasApr 18, 2013
  28. Ramkumar RamachandraApr 23, 2013
  29. Felipe ContrerasApr 23, 2013
  30. Phil HordApr 18, 2013
  31. Felipe ContrerasApr 18, 2013
  32. Phil HordApr 19, 2013
  33. Felipe ContrerasApr 20, 2013
  34. Jeff KingApr 15, 2013
  35. Øyvind A. HolmApr 15, 2013
  36. Jeff KingApr 16, 2013
  37. Jeff KingApr 16, 2013
  38. Eric SunshineApr 16, 2013
  39. Junio C HamanoApr 16, 2013
  40. Drew NorthupApr 16, 2013
  41. "What's cooking" between #05 and #06Junio C Hamano, Apr 16, 2013
  42. John KeepingApr 17, 2013
  43. Junio C HamanoApr 17, 2013
  44. Jens LehmannApr 17, 2013
  45. John KeepingApr 18, 2013
  46. Lukas FleischerApr 17, 2013
  47. Junio C HamanoApr 17, 2013
  48. Thomas RastApr 17, 2013
  49. Junio C HamanoApr 17, 2013
  50. Thomas RastApr 17, 2013
  51. Junio C HamanoApr 17, 2013
  52. Junio C HamanoApr 17, 2013
  53. Jeff KingApr 17, 2013
  54. Junio C HamanoApr 18, 2013
  55. git add <pathspec>... defaults to "-A"Junio C Hamano, Apr 18, 2013
  56. Jeff KingApr 18, 2013
  57. Junio C HamanoApr 18, 2013
  58. Jeff KingApr 18, 2013
  59. Junio C HamanoApr 18, 2013
  60. Jeff KingApr 18, 2013
  61. Junio C HamanoApr 18, 2013
  62. Jeff KingApr 18, 2013
  63. Junio C HamanoApr 18, 2013
  64. Jeff KingApr 19, 2013
  65. Jonathan NiederApr 19, 2013
  66. Junio C HamanoApr 19, 2013
  67. Jeff KingApr 19, 2013
  68. Junio C HamanoApr 19, 2013
  69. jc/add-2.0-delete-default (Re: What's cooking in git.git (Apr 2013, #05; Mon, 15))Jonathan Nieder, Apr 21, 2013
  70. Junio C HamanoApr 22, 2013
  71. Junio C HamanoApr 22, 2013
  72. 0/2 "git add -A/--no-all" finishing touchesJunio C Hamano, Apr 22, 2013
  73. 1/2 git add: --ignore-removal is a better named --no-allJunio C Hamano, Apr 22, 2013
  74. 2/2 git add: rephrase -A/--no-all warningJunio C Hamano, Apr 22, 2013
  75. 3/2 git add <pathspec>... defaults to "-A"Junio C Hamano, Apr 22, 2013
  76. Eric SunshineApr 23, 2013
  77. Junio C HamanoApr 25, 2013
  78. Junio C HamanoApr 25, 2013
  79. Jonathan NiederApr 25, 2013
  80. Junio C HamanoApr 25, 2013
  81. Junio C HamanoApr 25, 2013
  82. Jonathan NiederApr 25, 2013
  83. Junio C HamanoApr 26, 2013
  84. Junio C HamanoApr 26, 2013
  85. Jonathan NiederApr 26, 2013

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.