Felipe Contreras [off-list ref] writes:
* How many times have you tracked regressions in transport helper's
import/export functionality?
Hint: zero.
The real question to make the situation non-hypothetical would actually
be "how many times did you track a regression that bisected down to
*this particular commit*". Any regression that ends up on another commit
is irrelevant.
I guess you realize how stupid my argument is. But how is yours
different? You do realize that your claim that nobody is ever going to
bisect down to your commit is as hypothetical as other people's claim
(if you think it is not, then try to point us a proof that nobody is
ever going to need a good message in the future to understand what I
mean).
We're trying to make all the code and all the commits clean. It seems to
be a consensus here that review is good. I see no reason to purposely
make some commits less good than others based on the fact that they may
not be used in the future.
Search your favorite search engine for "broken window principle" to get
more arguments in this direction.
* How many times has *anybody* done so?
Hint: other than me, quite possibly zero.
If you want to be the only developer, and avoid being disturbed by
others, then why are you pushing your changes to git.git? Why are you
even discussing on this list?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Thu, Apr 18, 2013 at 2:44 AM, Matthieu Moy
[off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
* How many times have you tracked regressions in transport helper's
import/export functionality?
Hint: zero.
The real question to make the situation non-hypothetical would actually
be "how many times did you track a regression that bisected down to
*this particular commit*". Any regression that ends up on another commit
is irrelevant.
I guess you realize how stupid my argument is. But how is yours
different?
I did not make any argument (stupid or otherwise), I made I claim; I
won't waste my time with hypotheticals.
You do realize that your claim that nobody is ever going to
bisect down to your commit is as hypothetical as other people's claim
(if you think it is not, then try to point us a proof that nobody is
ever going to need a good message in the future to understand what I
mean).
Yeah, they are both hypotheticals, the only difference is that your
claim is very easy to prove; all you need is *ONE* example.
But I'm very happy to withdraw my claim, as long as you withdraw your
claim as well, and we go back to the default position: we don't know
if anybody will every look at these commit messages again.
We're trying to make all the code and all the commits clean. It seems to
be a consensus here that review is good. I see no reason to purposely
make some commits less good than others based on the fact that they may
not be used in the future.
You have to prove first that they are "less good", and the best way to
do that is provide commit messages of your own, if you do that, they
can be used instead, but if you don't, what do you propose to do? Drop
the patches?
Search your favorite search engine for "broken window principle" to get
more arguments in this direction.
More like broken windows hypothesis, which is not without its critics.
quoted
* How many times has *anybody* done so?
Hint: other than me, quite possibly zero.
If you want to be the only developer, and avoid being disturbed by
others, then why are you pushing your changes to git.git? Why are you
even discussing on this list?
Doesn't matter, it's still *HYPOTHETICAL* that anybody will every hit
this in a bisect.
Now, if you agree it's all hypothetical, the next rational thing to do
is risk analysis: how likely is it to happen, and what would be the
impact if it does? The answer to both questions is: close to *ZERO*.
So, considering the nature of these patches (a remote-helper in the
contrib area that is relatively new), and the active developers (me),
I'd say it's much more important to get the fixes in, than to document
every little quirk, detail and reasoning behind them. It's the balance
I think it's best at this point, and it is my time, and it is my
decision what I do with it.
It might also help to compare oranges with oranges, and with regards
to remote-hg transport helpers, I do believe the one in
contrib/remote-helpers has the best commit messages:
msysgit's remote-hg:
---
commit 6bbd5365988d63780acc2ab407878eef8c19b47c
Author: Sverre Rabbelier [off-list ref]
Date: Sun Aug 22 01:22:14 2010 -0500
git_remote_helpers: add fastimport library
git_remote_helpers/fastimport/__init__.py | 0
git_remote_helpers/fastimport/commands.py | 469
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
git_remote_helpers/fastimport/dates.py | 79 +++++++++++
git_remote_helpers/fastimport/errors.py | 182 +++++++++++++++++++++++++
git_remote_helpers/fastimport/head_tracker.py | 47 +++++++
git_remote_helpers/fastimport/helpers.py | 88 +++++++++++++
git_remote_helpers/fastimport/idmapfile.py | 65 +++++++++
git_remote_helpers/fastimport/parser.py | 621
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
git_remote_helpers/fastimport/processor.py | 222
+++++++++++++++++++++++++++++++
git_remote_helpers/setup.py | 3 +-
10 files changed, 1775 insertions(+), 1 deletion(-)
---
gitifyhg:
--
commit 4b364563cd705dc5e69082e6b80d304fe50b9c9c
Author: Alex Sydell [off-list ref]
Date: Sat Mar 23 23:46:33 2013 -0700
Report correct (instead of unknown) hashes when importing refs into git
gitifyhg/gitifyhg.py | 27 +++++++++++++++++++++------
gitifyhg/hgimporter.py | 20 ++------------------
gitifyhg/util.py | 44 ++++++++++++++++++++++++++++++++++++++++++++
test/test_push.py | 31 +++++++++++++++++++++++++++----
4 files changed, 94 insertions(+), 28 deletions(-)
---
And of course, the best place to discuss the lack of good commit
messages, is in the patches themselves, which are after all, sent to
the mailing list for everyone to review.
Cheers.
--
Felipe Contreras