Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jdavidb (1361)

jdavidb
  (email not shown publicly)
http://voiceofjohn.blogspot.com/

J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.

Journal of jdavidb (1361)

Tuesday April 08, 2008
10:48 AM

A git nit

[ #36101 ]

Yesterday I probably became a git convert. I've already got a long message composed that may become an email to some folks or a journal entry or both about what I think is great. But of course every software has stupidities, and here's one:

The --shared option to git-init has only three possible settings, but you can specify seven different values for it. One of the three settings (with two different names) simply says, "leave this default; don't set this option." This is silly.

It's not the end of the world, but it's silly. It probably didn't cost much to implement this "feature," but it probably doesn't gain anything. What's it supposed to do, make it possible to run the command without reading the documentation? Is that really a good idea? Are the semantics of some of those synonyms going to change some day?

I, on the other hand, got something out of writing this journal entry (which probably cost more than it did for some developer to implement that feature). I got to organize some of my thoughts about software design. I got to think about the TIMTOWTDI principle and muse on whether or not providing more than one name for things is related or not, and carries the same value or not. (I don't think it does; you don't often see Perl provide multiple special variables that do the same thing, do you? Or multiple command-line switches that do the same thing?) And the expected value of this journal entry is even greater to me because there's a chance I might get some insightful comment in reply which I could benefit from.

Speaking of costs, I think another cost of this feature is it makes the documentation more cluttered and harder to read. (Although again, it cost me more to write this journal entry than it did to read that manpage section.) But maybe one of the benefits is it forces people to slow down and read that documentation more carefully. But is that really necessary for this feature? Did somebody measure ahead of time and see they were getting a lot of time-consuming support emails about this?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I did some archeology, and found the mailing list thread where this feature is fleshed out. The discussion thread starts at http://thread.gmane.org/gmane.comp.version-control.git/21538/focus=21574 [gmane.org], but can be summarized as follows:

    The configuration item core.sharedrepository used to be a boolean, and backward compatibility is highly valued with the Git developers. So that explains the umask/false and group/true values.

    The everybody value is a suggestion by Linus, after which Junio anticipated a reques

    --
    All that is gold does not glitter...
    • Very cool. Thank you for the archaeology work.

      Having the possibility to specify an option, even if it is the default does not seem silly to me

      It doesn't to me, by itself. It starts to seem silly though when there's seven values you can specify with only three meanings, and two of those values simply specify the default.

      Having a little more context now, it still seems like a bad design decision to me that they "anticipated" world, and "threw in" all for good measure, because at the moment, if I'm understanding the docs correctly, those two options have exactly the same semantics as "everybody."

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • Premature optimization?
        Probably. But still, that particular piece of code hasn't changed since June 2006. Is it silly? Yes. Is it important? No. Also, not being able to have all and world mean something other for the core.sharedrepository configuration item doesn't seem like a big loss to me. How would all mean something different than world in the context of Unix file permissions?
        --
        All that is gold does not glitter...