Comments for Paolo Capriotti

Comment on Some thoughts on git by Rick

Rick — Thu, 03 Jul 2008 12:44:09 +0000

@Quintesse: If you want Mercurial support for Eclipse try http://www.vectrace.com/mercurialeclipse/

It has advanced A LOT in very short time, sure you will find it quite feature complete.

Comment on Some thoughts on git by Dustin

Dustin — Thu, 03 Jul 2008 04:21:31 +0000

I don’t see the problem with the source code. I had the opposite experience, really.

I wanted to add a feature to git. I found it fairly easy to figure out where to put it and how to write it. I did make a couple of mistakes in my initial version (which were pointed out to me early). Making git do what I wanted it to do was easy. The hard part was getting it accepted.

Junio has got to be one of the busiest software volunteers on the planet, but he meticulously reviewed my code for both style and function. I had to send it through several times and wrote *way* more unit tests than code. In the end, it made my confidence *really* high.

Comment on Some thoughts on git by pcapriotti

pcapriotti — Wed, 18 Jun 2008 00:50:03 +0000

@David
Of course browsing through the code of a large and complex system is always somewhat painful. I was just reporting that my experience with it has been particularly unpleasant if I compare it with the effort needed to understand other (also big and complex) code bases that I worked with.
About the exit on failure thing, it’s not about spawning a subprocess. Exiting from a subprocess is ok. The point is that if you call exit in a library, the calling process will terminate, and that’s almost never what you want.

Comment on Some thoughts on git by David

David — Tue, 17 Jun 2008 23:42:32 +0000

With reference to your comments about Git’s source code, I do not believe your arguments are valid. Unix philosophy is about many things, one of them is isolating functionality into small programs so that errors in one program do not corrupt the others. Git does this. Another is emphasizing the importance of data structures in system design. Git does this.

Large functions are not correlated with higher defect rates (http://www.informationweek.com/news/software/open_source/showArticle.jhtml?articleID=207801458). You can watch Steve McConnell wrestle with this in CC/2e if you care to read about it. He suggests giving up at around 150 lines (and I tend to agree), but I think this has more to do with wearing out your page up/page down keys than with code quality.

Why are you trying to understand the source code without a serious investment of time and energy? There are two possibilities: A) (most likely) have an axe to grind and are trying very hard to find problems with Git or B) (less likely but possible) you have very serious misconceptions about software design. Large software systems are inherently complex, and you have to make a major investement of time and energy in order to understand them. You say browsing the source files is painful…of course it is painful! It is painful because you are not familiar with the rules of the Git project, and that pain is your mind stretching to fathom the
vastness of the new mental terrain.

You say the API is lacking in part because some of the programs call exit() on failure. You should learn how to open a pipe to a subprocess. Try this:
$ python
>>> import subprocess
>>> help(subprocess)

Git is not perfect, but your criticisms are very weak.

Comment on Some thoughts on git by Jim Keller

Jim Keller — Wed, 28 May 2008 20:38:15 +0000

>Who cares about windows?

You have to understand that companies have a variety of people of varying skillsets who all need to use the repository. It’s not reasonable to ask a graphic designer or an HTML/CSS coder to move from Windows to UNIX and use a command line tool to do their commits.

A lot of times, the programmer ego comes into play and people say “if so and so can’t figure it out, they’re just dumb/ bad at their job/etc”, but it doesn’t make sense to spend significant time and money training people to use an immature system just because it’s theoretically the latest and greatest.

Comment on Rewriting from scratch by Riccardo Iaconelli

Riccardo Iaconelli — Thu, 08 May 2008 20:39:14 +0000

oh yeah!

Comment on Rewriting from scratch by Corno

Corno — Mon, 28 Apr 2008 12:50:20 +0000

I’m missing my favorite one: “It’s not meta enough”

Comment on skema 0.1 by Dot

Dot — Wed, 16 Jan 2008 19:11:53 +0000

This rocks! Do you plan to make a 0.2 release?

Comment on skema 0.1 by The return of “Top English WP Blogs” « conduong.co.cc

The return of “Top English WP Blogs” « conduong.co.cc — Sun, 16 Dec 2007 10:47:29 +0000

[...] skema 0.1 I have just released skema, a very simple tool I wrote to automate some repetitive coding tasks. Nothing fancy, just a […] [...]

Comment on A smart logger by WoundedLion

WoundedLion — Fri, 14 Dec 2007 23:39:53 +0000

Good point. Return value optimization is not guaranteed, but merely allowed, by the standard and implemented in most compilers worth their salt.

To make it foolproof, however, you could add an “active” flag to the LogHelper which is set by LogHelper::operator<<(). The destructor would not forward the log message unless this flag was set.

Then, at least you would still avoid the complexity of implementing the full ownership transfer logic and also the cost all of those intermediate LogHelper constructor calls.