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

Re: [PATCH 1/9] remote-bzr: trivial cleanups

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Apr 25, 2013, 22:58 UTC
Message-ID
<CAMP44s1CTzO6J+QTDw_tmbkf-jfVxBzpfqY08_6RXrMuPr+CFw@mail.gmail.com>
In-Reply-To
<7vsj2e1d83.fsf@alter.siamese.dyndns.org>
On Thu, Apr 25, 2013 at 5:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Having said that, I am more worried about wasting everybody's time
> (and this includes your time) with the impedance mismatch between
> you and the rest of us.
>
> Our standard for explaining the change (either in the log or in the
> comment) is to err on the descriptive side to be helpful even to
> people new to the codebase.  We do not require or encourage to state
> the obvious. The issue is the definition of "obviousness" varies
> even among the rest of us and even for a single person depending on
> how familiar that person is with the area of the code in question.
> But the divide between you (alone) and the rest of us seems to be
> far more vast than differences among the people other than you.

You are missing my point, this is *ONE INSTANCE*. Show me another instance where a reviewer complained about the lack of a descriptive commit messages on *remote-helpers*.

> Especially the criteria I used in the above example for "bmarks"
> need to be used carefully.  If a reviewer needs to follow a very
> deep callchain to convince himself why a change does not break
> things, it is no longer obvious and deserves to be explained.

So if I'm not willing to describe every little trivial cleanup change I do, what should I do then? Avoid those trivial changes?

If your true purpose of having descriptive commit messages is to improve maintainability, then actually doing these cleanups should have priority over a descriptive commit message, because doing the cleanups improves the maintainability even without a detailed description.

Clearly, your reasoning is incomplete.
> So I dunno.  If you are not willing to change your ways and try to
> be more descriptive to help others to understand what you are doing,
> there is nothing I can do to help you.

I'm willing to change my ways when there's reason to change my ways, and so far, nobody has provided any evidence that my commit messages are indeed lacking, only *opinions*.

Other people are perfectly fine with them: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=felipe.contreras

And the only reason we are wasting time, is that *you* make us waste time. Any sensible reviewer would be context aware, notice that this is a contrib patch, and focus on behavioral changes, notice the mistake I made, and point that *one* of the changes was changing the behavior, at which point I would agree and reroll either without that change, or with the change in a separate commit (which I don't want to do right now). The maintainer (you), wouldn't even have to reply at all.

But the reviewer failed to do so, and other contributors went even further, so the ball is in now in your court. IMO a sensible maintainer would simply say "Guys, stay on topic, what do we do with this patch?", but no, you allow people to suggest that not only the whole series, but the whole sub-project be dropped, and to do so with totally unrelated facts, and generalizing from *ONE INSTANCE* in the actual sub-project, and generally from ad hominem arguments.

This doesn't help anybody.

Show me a systemic problem with the commit messages *in remote-helpers*, and then perhaps it would be worth to start *a new thread* to discuss them, but nobody has done so. We are still talking about a *single patch*.

And if you really really don't like the patch, say "do X, or I drop the patch", or the series, and there would be no need for other reviewers to waste their time (if their comments were truly valid and correct, which they are not). There's no need to say anything more. And even if the reviewers were correct in their comments, allowing suggestions such as that the whole sub-project should be dropped because of one patch is going to waste people's times, no matter what.

Cheers.
-- 
Felipe Contreras
Previous: Junio C HamanoNext: Junio C Hamano
Message 12 of 49 in “remote-helpers: fixes and cleanups”
  1. 0/9 remote-helpers: fixes and cleanupsFelipe Contreras, Apr 25, 2013
  2. 1/9 remote-bzr: trivial cleanupsFelipe Contreras, Apr 25, 2013
  3. Ramkumar RamachandraApr 25, 2013
  4. Felipe ContrerasApr 25, 2013
  5. Thomas RastApr 25, 2013
  6. Felipe ContrerasApr 25, 2013
  7. Junio C HamanoApr 25, 2013
  8. Felipe ContrerasApr 25, 2013
  9. Junio C HamanoApr 25, 2013
  10. Felipe ContrerasApr 25, 2013
  11. Junio C HamanoApr 25, 2013
  12. Felipe ContrerasApr 25, 2013
  13. Junio C HamanoApr 25, 2013
  14. Felipe ContrerasApr 26, 2013
  15. Ramkumar RamachandraApr 26, 2013
  16. Felipe ContrerasApr 26, 2013
  17. Ramkumar RamachandraApr 26, 2013
  18. Felipe ContrerasApr 26, 2013
  19. Ramkumar RamachandraApr 26, 2013
  20. Felipe ContrerasApr 26, 2013
  21. Junio C HamanoApr 26, 2013
  22. Felipe ContrerasApr 26, 2013
  23. Ramkumar RamachandraApr 26, 2013
  24. Ramkumar RamachandraApr 26, 2013
  25. Felipe ContrerasApr 26, 2013
  26. Ramkumar RamachandraApr 26, 2013
  27. Ramkumar RamachandraApr 26, 2013
  28. Felipe ContrerasApr 26, 2013
  29. Ramkumar RamachandraApr 26, 2013
  30. Felipe ContrerasApr 26, 2013
  31. Ramkumar RamachandraApr 26, 2013
  32. Felipe ContrerasApr 26, 2013
  33. Felipe ContrerasApr 26, 2013
  34. Ramkumar RamachandraApr 26, 2013
  35. Felipe ContrerasApr 26, 2013
  36. Stefano LattariniApr 25, 2013
  37. Felipe ContrerasApr 25, 2013
  38. 2/9 remote-hg: remove extra checkFelipe Contreras, Apr 25, 2013
  39. Ramkumar RamachandraApr 25, 2013
  40. Felipe ContrerasApr 25, 2013
  41. 3/9 remote-bzr: fix bad state issueFelipe Contreras, Apr 25, 2013
  42. 4/9 remote-bzr: add support to push URLsFelipe Contreras, Apr 25, 2013
  43. 5/9 remote-hg: use hashlib instead of hg sha1 utilFelipe Contreras, Apr 25, 2013
  44. Ramkumar RamachandraApr 25, 2013
  45. Felipe ContrerasApr 25, 2013
  46. 6/9 remote-bzr: store converted URLFelipe Contreras, Apr 25, 2013
  47. 7/9 remote-hg: use python urlparseFelipe Contreras, Apr 25, 2013
  48. 8/9 remote-bzr: tell bazaar to be quietFelipe Contreras, Apr 25, 2013
  49. 9/9 remote-bzr: strip extra newlineFelipe Contreras, Apr 25, 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.