On Thu, Oct 18, 2012 at 10:47 AM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Hi Felipe,
> On Wed, 17 Oct 2012, Felipe Contreras wrote:
>> On Wed, Oct 17, 2012 at 8:18 PM, Sverre Rabbelier <srabbel...@gmail.com> 
>> wrote:
>> > On Wed, Oct 17, 2012 at 11:12 AM, Felipe Contreras
>> > <felipe.contre...@gmail.com> wrote:
>> >> But fine, lets remove the tests out of the equation (150 lines), the
>> >> number of lines of code still exceeds 3000.
>> >
>> > I don't think it's fair to just look at LOC, git-remote-hg when it was
>> > just parsing was fairly simple. Most of the current code is our copy
>> > of the python fast-import library which is only used to support
>> > pushing to mercurial.
>> Well, as a rule of thumb more code means more places for bugs to hide.
> Everybody on this list knows that. But it is equally true that more
> functionality requires more code.

Not necessarily. There's projects with more code and less
functionality than their alternatives.

>> It is also quite frankly rather difficult to navigate; very
>> spaghetti-like. I have the feeling [...]
> Yours truly always welcomes constructive criticism. Other types of
> criticism, not so much.
> As to the functionality you seek: git-remote-hg found in
> git://github.com/msysgit/git works. It has the following advantages over
> every other solution, including the one proposed in this thread:
> - it works
> - no really, it works

Not for me.

> - it supports pushes, too

I don't care. When I need that I'll implement that with probably much less code.

> - it matured over a long time

So has CVS.

> - there are tests

Only a dozen of them. If I write the same tests for my solution would
you be happier? I didn't think so.

> - whenever we fixed bugs, we also added tests for the bug fixes

Like this one?

I don't see any tests for that.

> - it is in constant use

So you say, my impression is different.

> Without push support, remote-hg is useless to me.

Different people have different needs.

Without an easy way to setup, remote-hg is useless to me.

> If there are concerns about code style or unnecessary code (insofar it is
> really unnecessary, testgit for example is not, unless you want to avoid
> robust regression tests), I will discuss issues and collaborate. If the
> idea was not to collaborate, but to show off how much shorter code can be
> when it lacks functionality and proof of robustness I require for my
> everyday use of the program, dismissing existing code and concepts, less
> so.

So your idea of collaboration is accept that your code is awesome, and
my code sucks, and that I should fix your code, and throw my code to
the trash, while you do absolutely nothing but complain about the
whole situation. I have at least looked at your code. Have you even
looked at mine?

I've done my part in making my code easily available and ready for
review. I will not reply to you anymore until you show your
willingness to collaborate that you seem to demand for me, and:

1) Point to a remote-hg branch that is independent of msysgit stuff,
or any other irrelevant stuff
2) Is based on top of a recent version of git


Felipe Contreras
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

Reply via email to