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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 18, 2013, 09:15 UTC
Message-ID: <CAMP44s2xH9yi+EvsVnV6JW0gPPistBbvg8Jj_62hXmZAAvC1cw@mail.gmail.com>
In-Reply-To: <vpq61zk8er7.fsf@grenoble-inp.fr>

On Thu, Apr 18, 2013 at 2:44 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 14 quoted lines

> Felipe Contreras <felipe.contreras@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
> different?

I did not make any argument (stupid or otherwise), I made I claim; I won't waste my time with hypotheticals.

Show 5 quoted lines

> 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.

Show 7 quoted lines

>> * 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 <srabbelier@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(-)
---

gitifyhg:
--
commit 4b364563cd705dc5e69082e6b80d304fe50b9c9c
Author: Alex Sydell <alex@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.

Cheers.

-- 
Felipe Contreras