* Re: On Tabs and Spaces
From: David Kastrup @ 2007-10-17 19:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0710171337330.19446@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 17 Oct 2007, David Kastrup wrote:
>
>> Luke Lu <git@vicaya.com> writes:
>>
>> > But I still haven't seen any compelling arguments against the "all
>> > space" case, other than "people will screw it up into mixed spaces",
>> > which is really a straw man, as many multi-platform projects
>> > enforced the all-space policy easily by using a pre-commit hook in
>> > maintainers' repository.
>>
>> All-space indentation renders the binary delta algorithm git uses for
>> compression of packs slow and partly inoperative (all sequences of 16
>> spaces share the same finger print, and the number of identical finger
>> prints for which the file information is kept is reduced to 64).
>
> But sequences of 16 spaces are unlikely to land on 16-byte boundaries
> all the time in the file so adjacent data to those 16-space blocks will
> still provide good hashing.
Half of the three-tab equivalents and all of the four-tab equivalents
contain a 16-byte space sequence on the tested boundary.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 19:53 UTC (permalink / raw)
To: Tom Tobin; +Cc: git
In-Reply-To: <1192649598.6640.44.camel@athena>
On Wed, 17 Oct 2007, Tom Tobin wrote:
>
> And, of course, this still comes up against the *benefits* of
> all-spaces. Benefits which have been mentioned by several people;
> benefits which you refuse to *acknowledge*, even if they don't sway you.
I notice how you didn't even list them. Why? Because they don't exist?
So here's the deal: I claim that "use hard-tabs, and accept that they are
8 characters wide" is a provably working situation. For lots of *large*
projects. I'm not some odd-ball person here, I bet that if you go and look
at any sourceforge entry that is written in C (which is the language we're
debating here), you'll find that the ones that use hard-tabs (even if they
use spaces for smaller indents) are the vast majority.
So what's your point? You're pushing something that is provably odd-ball,
since almost nobody uses it, and you cannot even state what the huge
advantages are, and you claim that I'm the one that ignores them, when it
is *you* who have refused to acknowledge that there are reasons to *not*
do it (one big reason being that there are current existing and
productive developers that definitely do *not* want to change - and no,
it wasn't just me, either).
Your arguments make no sense. So *of*course* they don't sway me.
And you know what? I don't much care if you aren't swayed by mine. It's to
some degree a matter of taste, and the fact is, if you don't like the
current git model, you can go away and play with your own model. It *is*
open source, after all.
Put another way: if you cannot respect the wishes of the people who have
done the work, then I damn well have no reason what-so-ever to respect
*yours*.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Josh England @ 2007-10-17 19:52 UTC (permalink / raw)
To: Tom Tobin; +Cc: Linus Torvalds, git
In-Reply-To: <1192649598.6640.44.camel@athena>
On Wed, 2007-10-17 at 14:33 -0500, Tom Tobin wrote:
> That disk space translates into memory usage exactly *how*? Compiled
> code? Or the in-memory text while you're editing? The former can't be
> the issue, and the latter is trivial.
Think compression. Worse yet in my opinion is the bandwidth spike that
the larger tarball would create. Estimates earlier in the thread put
the difference at upwards of 40MB. Disk space may be cheap, but highly
available redundant mirrored disk space is not, and neither is
bandwidth.
> And, of course, this still comes up against the *benefits* of
> all-spaces. Benefits which have been mentioned by several people;
> benefits which you refuse to *acknowledge*, even if they don't sway you.
I think what Linus is trying to say here is this: THE "BENEFITS" DO
*NOT* OUTWEIGH THE DRAWBACKS. Accept it and move on.
> You've essentially demonstrated that git's "benevolent" dictator is an
> asshole, and even worse, an irrational asshole. It's one thing to deal
> with a community member like that; when it's the BD, I think I'll move
> along elsewhere. Congratulations.
Lovely. Personal attacks are such an effective way to get your point
across. You, sir, are a tool. Good riddance.
-JE
^ permalink raw reply
* Re: On Tabs and Spaces
From: Nicolas Pitre @ 2007-10-17 19:48 UTC (permalink / raw)
To: Tom Tobin; +Cc: Linus Torvalds, git
In-Reply-To: <1192649598.6640.44.camel@athena>
On Wed, 17 Oct 2007, Tom Tobin wrote:
> On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote:
> > In contrast, your argument seems to be "I've not actually done anything,
> > but I want to paint the bikeshed pink".
>
> Because, once again, being new makes one incorrect, doesn't it?
>
> You've essentially demonstrated that git's "benevolent" dictator is an
> asshole, and even worse, an irrational asshole. It's one thing to deal
> with a community member like that; when it's the BD, I think I'll move
> along elsewhere. Congratulations.
If you can't overcome your dislike for tabs and accept that this is the
coding style for the Git project then please go away.
Can this discussion, rational or not, just stop now?
Nicolas
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jan Wielemaker @ 2007-10-17 19:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710171147190.26902@woody.linux-foundation.org>
On Wednesday 17 October 2007 20:54, Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Tom Tobin wrote:
> > Or is "unix developers" code for "my sample size of one"?
>
> Well, let's put it this way: that "sample" is the one that started the
> project.
>
> I got to pick the license. Are you going to argue about that too? I got to
> pick the way I wrote the code. Are you going to continue arguing about
> that?
>
> The fact is, I don't see the people arguing for spaces having actually
> *done* anything for git. So why are you arguing?
Possibly because they do not want to cooperate :-) Anyway, it is mostly
a Unix <-> the rest issue. In the Unix world all tools by default use
8-spaces per tab and although most of them can be told otherwise, nobody
bothers. That way at least all code looks the same, regardless of spaces
or tabs. Many editors are smart enough to create sequences
N<TAB>+M<SPACE> for initial indentation to get consistent usage, but even
if it isn't consistent patch and diff can be told to handle it.
Outside the Unix world there appears to be little standard, so you receive
files with any combination of tab distance, using tabs vs. spaces, etc.
Most often I have to re-indent them before reading :-(
I guess the most ideal situation is to use only tabs for initial indentation
and spaces elsewhere, so changing the tab distance gets consistent layout.
The drawback is that there is no room for `half indentation', so style
conventions have to take care of that.
Still, the main developers take the decision. If you don't like it, don't
cooperate or fork.
--- Jan
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 19:44 UTC (permalink / raw)
To: Tom Tobin; +Cc: git
In-Reply-To: <1192649598.6640.44.camel@athena>
On Wed, 17 Oct 2007, Tom Tobin wrote:
> >
> > Well, let's put it this way: that "sample" is the one that started the
> > project.
>
> And therefore your choices become magically reasonable?
They sure as hell automatically become a lot more relevant than YOUR
choices, don't they?
> Every single damn editor out there can handle spaces.
Yes, and they'll start mixing spaces and tabs when they auto-indent.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Tom Tobin @ 2007-10-17 19:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710171147190.26902@woody.linux-foundation.org>
On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote:
>
> On Wed, 17 Oct 2007, Tom Tobin wrote:
> >
> > Or is "unix developers" code for "my sample size of one"?
>
> Well, let's put it this way: that "sample" is the one that started the
> project.
And therefore your choices become magically reasonable?
> I got to pick the license. Are you going to argue about that too? I got to
> pick the way I wrote the code. Are you going to continue arguing about
> that?
The way you *wrote* the code is different from deciding how the code
*should* be written — or is your code set in stone? (Funny, considering
that we're talking about a revision control system here.)
As for the license bit — yes, you certainly *did* get to pick the
license. What's your point? We wouldn't even be having this discussion
if it wasn't open source.
> The fact is, I don't see the people arguing for spaces having actually
> *done* anything for git. So why are you arguing?
Oh, here you pull out the big stick: if you haven't already done
anything for git, your ideas (as for what to, hmm, do for git) are
worthless! Err, yeah, great perspective there.
> > Interesting how you waver between "certain developers" and "me". I'm
> > convinced at this point that your argument comes down to "I can't use my
> > favorite text editor with all-spaces, therefore all-spaces sucks".
>
> Umm. And I've *told* you that.
>
> The whole point is:
> - every single damn editor out there can handle tabs.
> - it's the default
> - end of story.
>
> What's so hard to understand?
Every single damn editor out there can handle spaces.
The "default" is project-by-project.
Since you're BD in git-land, yes, your say-so is ultimately
end-of-story. It doesn't make your argument reasonable.
> > As for *disk space*? When we can measure cheap drives in sizable
> > fractions of *terabytes*, this simply isn't a serious argument.
>
> That disk-space translates into memory usage too, and into just being
> technically the *inferior* choice.
>
> How hard is that to accept? If you have a choice between a technically
> better solution, and a technically worse one, why are you arguing for the
> worse one?
That disk space translates into memory usage exactly *how*? Compiled
code? Or the in-memory text while you're editing? The former can't be
the issue, and the latter is trivial.
And, of course, this still comes up against the *benefits* of
all-spaces. Benefits which have been mentioned by several people;
benefits which you refuse to *acknowledge*, even if they don't sway you.
> > Yeah, can you believe some projects actually *survive* with an
> > all-spaces indentation rule? And ::gasp:: even *thrive*?
>
> Hey, Ḯ'm not saying that others shouldn't use spaces. I'm saying that
> *git* should not, the same way the Linux kernel does not and will not.
>
> Why? Because tabs are better. You (or anybody else) have simply never
> given any argument against that very simple argument. You try to push an
> inferior solution.
Uh huh.
> > Problems have been outlined, but since everything for you comes down to
> > "anything that comes between me and microemacs sucks", rational
> > discussion breaks down.
>
> Don't talk about "rational discussion", since you don't even *have* any.
>
> The starting point for any rational decision would be to explain why
> changing tabs to spaces would actually improve anything at all. And you
> have yet to show *any* such argument, while I've shown arguments to the
> reverse.
You're being willfully blind here.
> One big one being: the person who started the project and still actually
> *does* something for it actually cares.
Because, once again, this makes your arguments correct, doesn't it?
> In contrast, your argument seems to be "I've not actually done anything,
> but I want to paint the bikeshed pink".
Because, once again, being new makes one incorrect, doesn't it?
You've essentially demonstrated that git's "benevolent" dictator is an
asshole, and even worse, an irrational asshole. It's one thing to deal
with a community member like that; when it's the BD, I think I'll move
along elsewhere. Congratulations.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Robin Rosenberg @ 2007-10-17 19:33 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Git Mailing List, Johannes Schindelin, Eli Zaretskii,
Daniel Barkalow, Alex Riesen, tsuna, Andreas Ericsson
In-Reply-To: <4D822762-D344-465E-B77D-90A64D61F5A9@zib.de>
tisdag 16 oktober 2007 skrev Steffen Prohaska:
>
> On Oct 16, 2007, at 2:33 PM, Johannes Schindelin wrote:
>
> >> Maybe we need a configuration similar to core.autocrlf (which
> >> controls
> >> newline conversion) to control filename comparison and normalization?
> >>
> >> Most obviously for the case (in-)sensitivity on Windows, but I also
> >> remember the unicode normalization happening on Mac's HFS filesystem
> >> that caused trouble in the past.
> >
> > Robin Rosenberg has some preliminary code for that. The idea is to
> > wrap
> > all filesystem operations in cache.h, and do a filename normalisation
> > first.
>
> At that point we could add a safety check. Paths that differ only by
> case, or whitespace, or ... (add general and project specific rules
> here)
> should be denied. This would guarantee that tree objects can always be
> checked out. Even if the filesystem capabilities are limited.
>
> Robin, what do you think?
My code only normalizes filenames to UTF-8 inside git, which isn't the same
thing. I think that can be extended to handling MacOSX normalized UTF-8 and
Windows UTF-16 so, when you check out a thing from git there will be no
surprises. Case insensitivity is another dimension. I have no idea as to the
performance of the code, it's more like a proof-that-it-can-be-done.
The code cannot "fail", it always does something reasonable, like not
converting when that is not possible. Something else has to be done for
validation.
The UTF-16 that windows use is not a current issue because git only does
local code page. Jgit, but it isn't very smart either because git doesn't say
anything about filename encoding, while Windows/MacOSX/CIFS and other
filesystems does.
The fact that git uses eigth bit file names may also be a reason performance
is slower on Windows, because the eight-bit Win32API transforms all strings
and filenames to the native UTF-16 encoding on *every* system call, in and
out; that's a lot of work when you do it thousands of times. If git itself
did the transform it might be made smarter and more suited to git's purposes,
and most importantly faster. I have no idea about the performance hit. One
has to measure something.
I notice a number of SCM's out there, including one with a \$\d{4} pricetag
gets you into trouble if you rename a file from Foo to FOO on Windows.
-- robin
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Lars Hjemli @ 2007-10-17 19:27 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Morten Welinder, git, spearce
In-Reply-To: <8B2F7666-DCEB-4D58-ACFE-F40587CD415D@silverinsanity.com>
On 10/17/07, Brian Gernhardt <benji@silverinsanity.com> wrote:
> I wish I got this much attention the first time I tried to get this
> problem fixed. ;-)
>
> On Oct 17, 2007, at 11:39 AM, Lars Hjemli wrote:
>
> > This makes me wonder: what about all the other instances of die() in
> > git-cvsserver? Or in any of the other perl scripts, for that matter?
> > Should they all be fixed, or is it this particular test that is wrong?
>
> The reason this comes up is because t/test-lib.sh:test_expect_failure
> () thinks codes > 128 (or negative values if you want to look at it
> that way) are bad tests. I believe this is because many shells use
> these codes to indicate things like "command not found" or other
> probably unexpected failures.
>
> Other than that, does it matter what die() returns, as long as it's
> non-zero?
My point exactly ;-)
If the test is changed to use 'test_expect_success' in the same way as
'req_Root failure (relative pathname)' does it, the test no longer
depends on the exact exit-code returned by die().
IMHO this is much better future-proofing than replacing die() with
print()/exit 1 whenever one of these tests fails.
--
larsh
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Karl Hasselström @ 2007-10-17 19:23 UTC (permalink / raw)
To: Robin Rosenberg
Cc: David Kastrup, David Symonds, Geert Bosch, Wincent Colaiuta,
Johan Herland, git, Marius Storm-Olsen, Christian Couder,
René Scharfe, Junio Hamano, Johannes Schindelin
In-Reply-To: <20071017161749.GA17985@diana.vm.bytemark.co.uk>
On 2007-10-17 18:17:49 +0200, Karl Hasselström wrote:
> On 2007-10-17 18:10:55 +0200, Robin Rosenberg wrote:
>
> > Yet another very short word: void.
>
> My vote is for "supercalifragilisticexpialidocious". It's clearly
> superior to the 1500 other suggestions in this thread.
(Not intended as an attack on this particular suggestion, by the way.
Sorry if it sounded a bit harsh.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-17 19:15 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, spearce
In-Reply-To: <20071017190646.GC9041@planck.djpig.de>
On Oct 17, 2007, at 3:06 PM, Frank Lichtenheld wrote:
> I have this in my repo and will submit this with the other git-
> cvsserver
> changes. I was just waiting for either Junio to return or someone else
> stepping up.
Ah. I had missed that. I just dug up the patch when switching to
Shawn's repo gave me those old testing errors. Had thought it had
gotten lost in the shuffle.
Never mind me then,
~~ Brian
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Frank Lichtenheld @ 2007-10-17 19:08 UTC (permalink / raw)
To: Morten Welinder; +Cc: Brian Gernhardt, git, spearce
In-Reply-To: <118833cc0710170739i179e7389k1e44f70086ca88be@mail.gmail.com>
On Wed, Oct 17, 2007 at 10:39:52AM -0400, Morten Welinder wrote:
> > made it into your repo. It fixes test failures on my machine that have
> > been plauging me for months.
>
> That sounds more like a reason to fix the test. "die" is the perl
> standard way of
> reporting an error. It will print the error message on stderr, not on
> stdout like
> your version does.
Please note that git-cvsserver is special in that its output will never
be displayed directly to the user but is always interpreted first by
the client. So print "E something" is acutally in some cases more
correct than print STDERR something.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Frank Lichtenheld @ 2007-10-17 19:06 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git, spearce
In-Reply-To: <20071017140547.GA21691@Hermes.cust.hotspot.t-mobile.com>
On Wed, Oct 17, 2007 at 10:05:47AM -0400, Brian Gernhardt wrote:
> This was causing test failures because die was exiting 255.
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> ---
>
> Shawn, I sent this in a couple weeks ago but it looks like it never
> made it into your repo. It fixes test failures on my machine that have
> been plauging me for months.
I have this in my repo and will submit this with the other git-cvsserver
changes. I was just waiting for either Junio to return or someone else
stepping up.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 04/25] Rework make_usage to print the usage message immediately
From: Alex Riesen @ 2007-10-17 19:06 UTC (permalink / raw)
To: Pierre Habouzit, git, Shawn O. Pearce
In-Reply-To: <20071016221555.GB31695@olympe.madism.org>
Pierre Habouzit, Wed, Oct 17, 2007 00:15:55 +0200:
> > Why stderr, BTW? For instance, the output from "git help" is on
> > stdout. To be fair, I don't know why it is stdout there either.
> because it's what usage() does already ?
fair enough.
^ permalink raw reply
* Re: git-gc --prune interferes cogito?
From: Michael Dressel @ 2007-10-17 18:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20071017153841.GL18279@machine.or.cz>
Hi,
On Wed, 17 Oct 2007, Petr Baudis wrote:
> Hi,
>
> On Wed, Oct 17, 2007 at 04:43:27PM +0200, MichaelTiloDressel@t-online.de wrote:
> > I'm using git-1.5.3.2 and cogito-0.18.1.
> >
> > After I did a git-gc --prune cg-status didn't show my branches anymore.
> > git-branch -a still showed the branches.
> > I think that git-gc removed all files from .git/refs/heads/ except for
> > origin. Git seams to be fine with the branches in
> > .git/logs/refs/heads/.
> >
> > So should git-gc not be used together with cogito?
>
> Cogito doesn't support packed heads - I guess setting gc.packrefs to
> false should fix the issue. Cogito should support packed tags, I guess;
> I don't know if there's a way to make git-gc pack only tags.
>
Thank you. I tried it at home too where I had an older version of git.
With the older git version git-gc --prune didn't disturbe cogito.
I upgradet to git version 1.5.3.4 and tried gc.packrefs=false and it
seams to be ok forr cogito.
Cheers,
Michael
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 18:54 UTC (permalink / raw)
To: Tom Tobin; +Cc: git
In-Reply-To: <1192645509.6640.21.camel@athena>
On Wed, 17 Oct 2007, Tom Tobin wrote:
>
> Or is "unix developers" code for "my sample size of one"?
Well, let's put it this way: that "sample" is the one that started the
project.
I got to pick the license. Are you going to argue about that too? I got to
pick the way I wrote the code. Are you going to continue arguing about
that?
The fact is, I don't see the people arguing for spaces having actually
*done* anything for git. So why are you arguing?
> Interesting how you waver between "certain developers" and "me". I'm
> convinced at this point that your argument comes down to "I can't use my
> favorite text editor with all-spaces, therefore all-spaces sucks".
Umm. And I've *told* you that.
The whole point is:
- every single damn editor out there can handle tabs.
- it's the default
- end of story.
What's so hard to understand?
> As for *disk space*? When we can measure cheap drives in sizable
> fractions of *terabytes*, this simply isn't a serious argument.
That disk-space translates into memory usage too, and into just being
technically the *inferior* choice.
How hard is that to accept? If you have a choice between a technically
better solution, and a technically worse one, why are you arguing for the
worse one?
> Yeah, can you believe some projects actually *survive* with an
> all-spaces indentation rule? And ::gasp:: even *thrive*?
Hey, Ḯ'm not saying that others shouldn't use spaces. I'm saying that
*git* should not, the same way the Linux kernel does not and will not.
Why? Because tabs are better. You (or anybody else) have simply never
given any argument against that very simple argument. You try to push an
inferior solution.
> Problems have been outlined, but since everything for you comes down to
> "anything that comes between me and microemacs sucks", rational
> discussion breaks down.
Don't talk about "rational discussion", since you don't even *have* any.
The starting point for any rational decision would be to explain why
changing tabs to spaces would actually improve anything at all. And you
have yet to show *any* such argument, while I've shown arguments to the
reverse.
One big one being: the person who started the project and still actually
*does* something for it actually cares.
In contrast, your argument seems to be "I've not actually done anything,
but I want to paint the bikeshed pink".
Linus
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-17 18:40 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Morten Welinder, git, spearce
In-Reply-To: <8c5c35580710170839l4b31a4fao5b41efafc5a83883@mail.gmail.com>
I wish I got this much attention the first time I tried to get this
problem fixed. ;-)
On Oct 17, 2007, at 11:39 AM, Lars Hjemli wrote:
> This makes me wonder: what about all the other instances of die() in
> git-cvsserver? Or in any of the other perl scripts, for that matter?
> Should they all be fixed, or is it this particular test that is wrong?
The reason this comes up is because t/test-lib.sh:test_expect_failure
() thinks codes > 128 (or negative values if you want to look at it
that way) are bad tests. I believe this is because many shells use
these codes to indicate things like "command not found" or other
probably unexpected failures.
Other than that, does it matter what die() returns, as long as it's
non-zero?
~~Brian
^ permalink raw reply
* Re: On Tabs and Spaces
From: Tom Tobin @ 2007-10-17 18:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710170849590.26902@woody.linux-foundation.org>
On Wed, 2007-10-17 at 08:53 -0700, Linus Torvalds wrote:
>
> On Wed, 17 Oct 2007, Luke Lu wrote:
> >
> > Well, we just established that all-space is perfect, look-wise.
>
> But we also established that an all-space model is not stable, because any
> unix developers will start adding tabs instead of spaces.
Damn unix developers! They just can't be controlled!
... seriously now. You're trying on one hand to enforce a particular
indentation rule (use tabs for indentations, assume tabs are 8
characters wide, use spaces for partial indentation) — which assumes
unix developers *can* follow a project's rules for coding style — and
yet you're arguing *against* all-spaces because unix developers *can't*
follow rules.
Or is "unix developers" code for "my sample size of one"?
> > As I mentioned, an all-space policy is trivial to enforce.
>
> Hell no, it's not.
>
> More importantly, I can guarantee that certain developers will refuse to
> be part of such a project with such an idiotic design that eats disk-space
> for no gain, and makes it impossible for me to use my normal editor.
Interesting how you waver between "certain developers" and "me". I'm
convinced at this point that your argument comes down to "I can't use my
favorite text editor with all-spaces, therefore all-spaces sucks".
As for *disk space*? When we can measure cheap drives in sizable
fractions of *terabytes*, this simply isn't a serious argument.
> > But I still haven't seen any compelling arguments against the "all space"
> > case, other than "people will screw it up into mixed spaces", which is really
> > a straw man, as many multi-platform projects enforced the all-space policy
> > easily by using a pre-commit hook in maintainers' repository.
>
> Hey, you start your own projct, and you can enforce whatever idiotic rules
> you want to.
Yeah, can you believe some projects actually *survive* with an
all-spaces indentation rule? And ::gasp:: even *thrive*?
> But in the meantime, all-tab indentations are equally good, and are the
> defacto rule. So *you* are the one who should show compelling arguments
> for changing, and so far you haven't shown any.
>
> Really: what is the problem with hardtabs? Absolutely none.
Problems have been outlined, but since everything for you comes down to
"anything that comes between me and microemacs sucks", rational
discussion breaks down.
Thank goodness the git community (not to mention the Linux community!)
is larger than you; they exist in no small part due to your programming
skill and initial open-sourcing, but certainly in *spite* of your
personality otherwise.
^ permalink raw reply
* [QGIT4 PATCH] Add --no-color option to several calls to git
From: Yaacov Akiba Slama @ 2007-10-17 17:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: Marco Costalba, Yaacov Akiba Slama
Setting "diff.color = true" in the configuration makes
the output of several git commands use color codes.
The color codes aren't parsed by qgit, so adds the --no-color" option
to the calls of these git commmands.
Signed-off-by: Yaacov Akiba Slama <ya@slamail.org>
---
src/git.cpp | 18 +++++++++---------
src/git_startup.cpp | 6 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/git.cpp b/src/git.cpp
index 6cb9c7d..ef7d736 100644
--- a/src/git.cpp
+++ b/src/git.cpp
@@ -776,18 +776,18 @@ MyProcess* Git::getDiff(SCRef sha, QObject* receiver, SCRef diffToSha, bool comb
QString runCmd;
if (sha != ZERO_SHA) {
- runCmd = "git diff-tree -r --patch-with-stat ";
+ runCmd = "git diff-tree --no-color -r --patch-with-stat ";
runCmd.append(combined ? "-c " : "-C -m "); // TODO rename for combined
runCmd.append(diffToSha + " " + sha); // diffToSha could be empty
} else
- runCmd = "git diff-index -r -m --patch-with-stat HEAD";
+ runCmd = "git diff-index --no-color -r -m --patch-with-stat HEAD";
return runAsync(runCmd, receiver);
}
const QString Git::getWorkDirDiff(SCRef fileName) {
- QString runCmd("git diff-index -r -z -m -p --full-index --no-commit-id HEAD"), runOutput;
+ QString runCmd("git diff-index --no-color -r -z -m -p --full-index --no-commit-id HEAD"), runOutput;
if (!fileName.isEmpty())
runCmd.append(" -- " + quote(fileName));
@@ -998,7 +998,7 @@ bool Git::isSameFiles(SCRef tree1Sha, SCRef tree2Sha) {
if (isParentOf(tree2Sha, tree1Sha))
return !isTreeModified(tree1Sha);
- const QString runCmd("git diff-tree -r " + tree1Sha + " " + tree2Sha);
+ const QString runCmd("git diff-tree --no-color -r " + tree1Sha + " " + tree2Sha);
QString runOutput;
if (!run(runCmd, &runOutput))
return false;
@@ -1209,7 +1209,7 @@ const RevFile* Git::getAllMergeFiles(const Rev* r) {
if (revsFiles.contains(mySha))
return revsFiles[mySha];
- QString runCmd("git diff-tree -r -m -C " + r->sha()), runOutput;
+ QString runCmd("git diff-tree --no-color -r -m -C " + r->sha()), runOutput;
if (!run(runCmd, &runOutput))
return NULL;
@@ -1230,7 +1230,7 @@ const RevFile* Git::getFiles(SCRef sha, SCRef diffToSha, bool allFiles, SCRef pa
if (!diffToSha.isEmpty() && (sha != ZERO_SHA)) {
- QString runCmd("git diff-tree -r -m -C ");
+ QString runCmd("git diff-tree --no-color -r -m -C ");
runCmd.append(diffToSha + " " + sha);
if (!path.isEmpty())
runCmd.append(" " + path);
@@ -1250,7 +1250,7 @@ const RevFile* Git::getFiles(SCRef sha, SCRef diffToSha, bool allFiles, SCRef pa
dbs("ASSERT in Git::getFiles, ZERO_SHA not found");
return NULL;
}
- QString runCmd("git diff-tree -r -c -C " + sha), runOutput;
+ QString runCmd("git diff-tree --no-color -r -c -C " + sha), runOutput;
if (!run(runCmd, &runOutput))
return NULL;
@@ -1337,7 +1337,7 @@ bool Git::getPatchFilter(SCRef exp, bool isRegExp, ShaSet& shaSet) {
if (buf.isEmpty())
return true;
- QString runCmd("git diff-tree -r -s --stdin "), runOutput;
+ QString runCmd("git diff-tree --no-color -r -s --stdin "), runOutput;
if (isRegExp)
runCmd.append("--pickaxe-regex ");
@@ -1386,7 +1386,7 @@ bool Git::formatPatch(SCList shaList, SCRef dirPath, SCRef remoteDir) {
QSettings settings;
const QString FPArgs(settings.value(PATCH_ARGS_KEY).toString());
- QString runCmd("git format-patch");
+ QString runCmd("git format-patch --no-color");
if (testFlag(NUMBERS_F) && !remote)
runCmd.append(" -n");
diff --git a/src/git_startup.cpp b/src/git_startup.cpp
index 95a9474..a281173 100644
--- a/src/git_startup.cpp
+++ b/src/git_startup.cpp
@@ -480,7 +480,7 @@ bool Git::startParseProc(SCList initCmd, FileHistory* fh, SCRef buf) {
bool Git::startRevList(SCList args, FileHistory* fh) {
- const QString baseCmd("git log --log-size --parents --boundary --pretty=raw -z");
+ const QString baseCmd("git log --no-color --log-size --parents --boundary --pretty=raw -z");
QStringList initCmd(baseCmd.split(' '));
if (!isMainHistory(fh))
/*
@@ -505,7 +505,7 @@ bool Git::startUnappliedList() {
// WARNING: with this command 'git log' could send spurious
// revs so we need some filter out logic during loading
- QStringList cmd(QString("git log --parents --pretty=raw -z ^HEAD").split(' '));
+ QStringList cmd(QString("git log --no-color --parents --pretty=raw -z ^HEAD").split(' '));
cmd << unAppliedShaList;
return startParseProc(cmd, revData, QString());
}
@@ -835,7 +835,7 @@ void Git::loadFileNames() {
}
if (!diffTreeBuf.isEmpty()) {
filesLoadingPending = filesLoadingCurSha = "";
- const QString runCmd("git diff-tree -r -C --stdin");
+ const QString runCmd("git diff-tree --no-color -r -C --stdin");
runAsync(runCmd, this, diffTreeBuf);
}
indexTree();
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 0/7] Bisect dunno
From: Johannes Schindelin @ 2007-10-17 18:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Christian Couder, Junio Hamano, git
In-Reply-To: <20071017073538.GB13801@spearce.org>
Hi,
On Wed, 17 Oct 2007, Shawn O. Pearce wrote:
> Christian Couder <chriscool@tuxfamily.org> wrote:
> > Here is my bisect dunno patch series again.
> > The changes since last time are the following:
>
> I now have this series queued in my pu branch. It passes the tests
> it comes with, and doesn't appear to break anything, but apparently
> there is also still some debate about what a dunno should be called
> ("unknown", "void", "ugly", "dunno", "skip" ...).
AFAICT these are all bikeshed painting arguments, not technical arguments.
I was initially opposed to having --bisect-all, wanting to have
--bisect-dunno <ref>...
But in the end, the people doing the work decide, and therefore I am fine
with --bisect-all, especially since it seems clean enough for me.
As for all those "dunno is no English"... I'd first merge the technical
part (i.e. what you have now in pu), and then let the discussion about
which synonyms to choose continue, until a consensus is formed about other
names (if there is a consensus at all!).
IMHO there is no reason to hold of the fine work of Christian, just
because there are non-technical arguments still in the air.
I want bisect dunno. Even if there is another name later.
Ciao,
Dscho
^ permalink raw reply
* Re: On Tabs and Spaces
From: Johannes Schindelin @ 2007-10-17 18:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710170849590.26902@woody.linux-foundation.org>
Hi,
On Wed, 17 Oct 2007, Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Luke Lu wrote:
>
> > As I mentioned, an all-space policy is trivial to enforce.
>
> Hell no, it's not.
>
> More importantly, I can guarantee that certain developers will refuse to
> be part of such a project with such an idiotic design that eats
> disk-space for no gain, and makes it impossible for me to use my normal
> editor.
Yes. Me, for one.
But heck, _everyone_ is free to fork. That is one of the missions of git:
"fork!". You can maintain you tab-less fork, until people flock to you,
deciding to use your repo instead of Junio's, or Shawn's. If enough
people decide, you will have more followers than the others.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Johannes Schindelin @ 2007-10-17 18:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, René Scharfe, git, Nicolas Pitre
In-Reply-To: <20071017044405.GV13801@spearce.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1102 bytes --]
Hi,
On Wed, 17 Oct 2007, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> > On Tue, Oct 16, 2007 at 04:38:36PM +0000, René Scharfe wrote:
> > > Pierre Habouzit schrieb:
> > > > This bit is to allow to aggregate options with arguments together when
> > > > the argument is numeric.
> > > >
> > > > +#if 0
> > > > + /* can be used to understand -A1B1 like -A1 -B1 */
> > > > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > > > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > > > + return 0;
> > > > + }
> > > > +#endif
> > >
> > > I don't like it, it complicates number options with unit suffixes (e.g.
> > > --windows-memory of git-pack-objects).
> ...
> > This is a very strong argument _against_ this chunk IMO.
>
> Since everyone (including myself)
... except for me ...
> is apparently strongly against this hunk I removed it when I
> cherry-picked this series from Pierre into my tree. The series will be
> in my pu tonight, but minus this hunk.
I can live without this hunk.
Ciao,
Dscho
^ permalink raw reply
* [QGIT4 PATCH] Add --no-color option to several calls to git
From: Yaacov Akiba Slama @ 2007-10-17 17:54 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, Yaacov Akiba Slama
Setting "diff.color = true" in the configuration makes
the output of several git commands use color codes.
The color codes aren't parsed by qgit, so adds the --no-color" option
to the calls of these git commmands.
Signed-off-by: Yaacov Akiba Slama <ya@slamail.org>
---
src/git.cpp | 18 +++++++++---------
src/git_startup.cpp | 6 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/git.cpp b/src/git.cpp
index 6cb9c7d..ef7d736 100644
--- a/src/git.cpp
+++ b/src/git.cpp
@@ -776,18 +776,18 @@ MyProcess* Git::getDiff(SCRef sha, QObject* receiver, SCRef diffToSha, bool comb
QString runCmd;
if (sha != ZERO_SHA) {
- runCmd = "git diff-tree -r --patch-with-stat ";
+ runCmd = "git diff-tree --no-color -r --patch-with-stat ";
runCmd.append(combined ? "-c " : "-C -m "); // TODO rename for combined
runCmd.append(diffToSha + " " + sha); // diffToSha could be empty
} else
- runCmd = "git diff-index -r -m --patch-with-stat HEAD";
+ runCmd = "git diff-index --no-color -r -m --patch-with-stat HEAD";
return runAsync(runCmd, receiver);
}
const QString Git::getWorkDirDiff(SCRef fileName) {
- QString runCmd("git diff-index -r -z -m -p --full-index --no-commit-id HEAD"), runOutput;
+ QString runCmd("git diff-index --no-color -r -z -m -p --full-index --no-commit-id HEAD"), runOutput;
if (!fileName.isEmpty())
runCmd.append(" -- " + quote(fileName));
@@ -998,7 +998,7 @@ bool Git::isSameFiles(SCRef tree1Sha, SCRef tree2Sha) {
if (isParentOf(tree2Sha, tree1Sha))
return !isTreeModified(tree1Sha);
- const QString runCmd("git diff-tree -r " + tree1Sha + " " + tree2Sha);
+ const QString runCmd("git diff-tree --no-color -r " + tree1Sha + " " + tree2Sha);
QString runOutput;
if (!run(runCmd, &runOutput))
return false;
@@ -1209,7 +1209,7 @@ const RevFile* Git::getAllMergeFiles(const Rev* r) {
if (revsFiles.contains(mySha))
return revsFiles[mySha];
- QString runCmd("git diff-tree -r -m -C " + r->sha()), runOutput;
+ QString runCmd("git diff-tree --no-color -r -m -C " + r->sha()), runOutput;
if (!run(runCmd, &runOutput))
return NULL;
@@ -1230,7 +1230,7 @@ const RevFile* Git::getFiles(SCRef sha, SCRef diffToSha, bool allFiles, SCRef pa
if (!diffToSha.isEmpty() && (sha != ZERO_SHA)) {
- QString runCmd("git diff-tree -r -m -C ");
+ QString runCmd("git diff-tree --no-color -r -m -C ");
runCmd.append(diffToSha + " " + sha);
if (!path.isEmpty())
runCmd.append(" " + path);
@@ -1250,7 +1250,7 @@ const RevFile* Git::getFiles(SCRef sha, SCRef diffToSha, bool allFiles, SCRef pa
dbs("ASSERT in Git::getFiles, ZERO_SHA not found");
return NULL;
}
- QString runCmd("git diff-tree -r -c -C " + sha), runOutput;
+ QString runCmd("git diff-tree --no-color -r -c -C " + sha), runOutput;
if (!run(runCmd, &runOutput))
return NULL;
@@ -1337,7 +1337,7 @@ bool Git::getPatchFilter(SCRef exp, bool isRegExp, ShaSet& shaSet) {
if (buf.isEmpty())
return true;
- QString runCmd("git diff-tree -r -s --stdin "), runOutput;
+ QString runCmd("git diff-tree --no-color -r -s --stdin "), runOutput;
if (isRegExp)
runCmd.append("--pickaxe-regex ");
@@ -1386,7 +1386,7 @@ bool Git::formatPatch(SCList shaList, SCRef dirPath, SCRef remoteDir) {
QSettings settings;
const QString FPArgs(settings.value(PATCH_ARGS_KEY).toString());
- QString runCmd("git format-patch");
+ QString runCmd("git format-patch --no-color");
if (testFlag(NUMBERS_F) && !remote)
runCmd.append(" -n");
diff --git a/src/git_startup.cpp b/src/git_startup.cpp
index 95a9474..a281173 100644
--- a/src/git_startup.cpp
+++ b/src/git_startup.cpp
@@ -480,7 +480,7 @@ bool Git::startParseProc(SCList initCmd, FileHistory* fh, SCRef buf) {
bool Git::startRevList(SCList args, FileHistory* fh) {
- const QString baseCmd("git log --log-size --parents --boundary --pretty=raw -z");
+ const QString baseCmd("git log --no-color --log-size --parents --boundary --pretty=raw -z");
QStringList initCmd(baseCmd.split(' '));
if (!isMainHistory(fh))
/*
@@ -505,7 +505,7 @@ bool Git::startUnappliedList() {
// WARNING: with this command 'git log' could send spurious
// revs so we need some filter out logic during loading
- QStringList cmd(QString("git log --parents --pretty=raw -z ^HEAD").split(' '));
+ QStringList cmd(QString("git log --no-color --parents --pretty=raw -z ^HEAD").split(' '));
cmd << unAppliedShaList;
return startParseProc(cmd, revData, QString());
}
@@ -835,7 +835,7 @@ void Git::loadFileNames() {
}
if (!diffTreeBuf.isEmpty()) {
filesLoadingPending = filesLoadingCurSha = "";
- const QString runCmd("git diff-tree -r -C --stdin");
+ const QString runCmd("git diff-tree --no-color -r -C --stdin");
runAsync(runCmd, this, diffTreeBuf);
}
indexTree();
--
1.5.3.4
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Sean @ 2007-10-17 17:51 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl49g1w1.fsf@lola.quinscape.zz>
On Wed, October 17, 2007 12:08 pm, David Kastrup said:
>
> All-space indentation renders the binary delta algorithm git uses for
> compression of packs slow and partly inoperative (all sequences of 16
> spaces share the same finger print, and the number of identical finger
> prints for which the file information is kept is reduced to 64).
You seem to have identified a weakness in Git's design rather than
an argument against using all-space indentation. Personally I find it
counter-productive and annoying to work in space-indented source code.
But let's be honest, this "issue" is mostly about familiarity and
comfort rather than some deep objective truth.
Sean
^ permalink raw reply
* Re: On Tabs and Spaces
From: Nicolas Pitre @ 2007-10-17 17:44 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl49g1w1.fsf@lola.quinscape.zz>
On Wed, 17 Oct 2007, David Kastrup wrote:
> Luke Lu <git@vicaya.com> writes:
>
> > But I still haven't seen any compelling arguments against the "all
> > space" case, other than "people will screw it up into mixed spaces",
> > which is really a straw man, as many multi-platform projects
> > enforced the all-space policy easily by using a pre-commit hook in
> > maintainers' repository.
>
> All-space indentation renders the binary delta algorithm git uses for
> compression of packs slow and partly inoperative (all sequences of 16
> spaces share the same finger print, and the number of identical finger
> prints for which the file information is kept is reduced to 64).
But sequences of 16 spaces are unlikely to land on 16-byte boundaries
all the time in the file so adjacent data to those 16-space blocks will
still provide good hashing.
> > The only downside of all-space is a moderate space bloat in source,
> > which is insignificant, all things considered.
>
> It will also slow down git's packing and make it produce worse
> results.
If that was effectively the case then it is Git that had to be fixed and
not the way people write code. Git should cope with the data it is fed
and not the other way around.
And this is completely orthogonal to the policy of using hard tabs or
spaces in source code, so I'm clearly _not_ providing any argument to
that discussion one way or the other here.
Nicolas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox