Re: [PATCH 2/2] teach git-config to output large integers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]