On Thu, Apr 18, 2013 at 2:44 AM, Matthieu Moy
> Felipe Contreras <felipe.contre...@gmail.com> 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
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
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
> 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.
>> * 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:
Author: Sverre Rabbelier <srabbel...@gmail.com>
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(-)
Author: Alex Sydell <a...@dropbox.com>
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html