On Tue, Aug 20, 2013 at 03:57:45PM -0700, Jonathan Nieder wrote:

> Jeff King wrote:
> > I kind of hate the name "--ulong". I wanted to call it "--size" or
> > something and abstract away the actual platform representation, and just
> > make it "big enough for file sizes".
> Yes, something like --size would be more pleasant.
> It could still use unsigned long internally.  My only worry about
> --size is that it does not make it clear we are talking about file
> sizes and not in-memory sizes (size_t), and I'm not too worried about
> that.

I almost sent it as "--size" with unsigned long internally. But try
writing the documentation for it. You want to say something like "it's
big enough to handle file sizes". Except that on 32-bit, it's _not_.
It's only 4G.

You really want something that uses off_t internally, so 32-bit systems
with largefile support do the sane thing. But now you have no way of
emulating the way that git parses stuff internally. You cannot say "git
config --size core.bigFileThreshold" and get the same results that git
will have internally when it looks at that file (because it uses
"unsigned long" internally").

I think there is an argument to be made that git should be using off_t
internally for such things. But it is a lot of code to change and check,
and I'm not sure that anybody even really cares that much.

> Style: uncuddled "else", stray blank line.  (The former was already
> there, but it still stands out.)  I think

Yes, I was trying to follow the existing style (but obviously the extra
line was just a typo).

>               if (types == TYPE_INT) {
>                       ...
>               } else if (types == TYPE_ULONG) {
>                       ...
>               } else if (types == TYPE_BOOL) {
>                       ...
>               } else if (types == TYPE_BOOL_OR_INT) {
>                       ...
>               } else {
>                       ...
>               }
> would be easiest to read.

But that is adding brackets for one-liner conditional bodies that do not
need it. Which is more evil?

My usual method is to do what looks the most readable to me, but I admit
I have a hard time using my intuition with the cuddled-elses, as I think
they look terrible (yes, I'm aware they are in our style guide and I am
not arguing to take them out, only that my personal sense of "looks
good" is helpless with them).

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