* Re: On Tabs and Spaces
From: Jari Aalto @ 2007-10-17 22:02 UTC (permalink / raw)
To: git
In-Reply-To: <E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu>
* Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU>
* Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu
> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:
>
>> But I still haven't seen any compelling arguments against the "all
>> space" case
>
> Overhead!
>
> If you use 8 spaces instead of one tab,
> that's using up 7x more space!
Software is the right place to worry about optimization. We should trust
SCM to make proper and efficient deltas. If not, algorithms need
improvemnts.
Any cross platform development or electronic exchange is guaranteed to
be interpreted correctly when policy enforces "only spaces"
As we have already seen in numerous times in this thread, using tabs
will - eventually - be interpreted in some editor, in some display, in
some encironment using some tools ... incorrectly or different than the
author intended. Simply because editors are configurable and we cannot
know what settings they may have when they load the file in.
There is no such problem with spaces.
The storage constraints are insignificant given the disk space vs. cost;
including possibly used compression algorithms in storage or transfers.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Pete/Piet Delaney @ 2007-10-17 21:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <e5bfff550710170014m395d5b8cld87a5c2c9f7d71a@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marco Costalba wrote:
> On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> 't' worked fine but still can see how to diff do of the list of
>> changes for a file. Viewing diffs of files based on change sets
>> worked fine but I think with BitKeeper I found it helpful to be
>> able to do a full 'kompare' type diff the file only; often I'm
>> not interested in which change set it went into.
>>
>
> Well, open tree view ('t'), select the file you are interested of,
> then click the magic wand button on the tool bar, now revisions you
> see are filtered by that file, if you browse the revisions the
> patch/diff you see will always point to your file (also if you can see
> the whole patch).
I take it the "magic wand button" is the check mark on the upper right
that says "Pin View (Alt-V)". When I pin the view the view of the file
in Qgit locks to the selected file but the External diff seems to stay
the same. The External diff appears to show my last change to the file;
changing the change-set selection doesn't seem to change anything with
the view pinned.
>
>> Something for a future version or am I lucky and you have
>> it covered already?
>>
>
> Don't know, depends on how you answer to the above point ;-)
How'd I do?
>
>> Good Idea, thought it's brought up a few questions:
>>
>> 1. When I do the <control-minis> to Decrease the font size
>> I can't undo it with the <control-plus>. Also <control-plus>
>> doesn't seem to do anything.
>>
>> 2. When displaying the "Lane info" why can't I see the
>> branch names?
>>
>
> Thanks for the reports, I will investigate as soon as I have a bit of
> spare time.
ok, I suspect that's an easy one.
>
>> I'll read it a few more times. I seem to sometimes get into a state
>> where I'm locked onto the current change set and can't get back to
>> the other change sets without starting another qgit.
>>
>
> Please, could you be so kind to better explain me the above point.
> Seems interesting, but I didn't get how to reproduce.
I'm not sure how I get into this state either, I'll try to recall
how I get into this state the next time it occurs.
>
>>> Yes it is. There are a lot of new featrures, is almost as stable as
>>> the previous and if you are interested in file history (annotations)
>>> in qgit-2.0 this feature has been greatly speeded up.
>> Do you know if it's a lot of work to install Qt4?
>>
>
> With Mandriva you are just at an uprmi away.
>
> Try something like
>
> urpmi libqt4-devel
/nethome/piet$ su
/nethome/piet$ /usr/sbin/urpmi libqt4-devel
no package named libqt4-devel
/nethome/piet$
/urpmi libqt4 also didn't work.
>
> It worked for me ;-)
I'm running 2005 Limited Edition; I wonder if QT4 even existed then.
Think it's worth messing with QT4 just to upgrade to you latest version?
Some of these graphics libs can be bear to install from src.
- -piet
>
> Marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFoLhJICwm/rv3hoRAt73AJ9kWv8EhuaAH/69HqG0+FZOAD8LlgCdH6uU
2PJDFOuZENrKJBA66MOdANc=
=yd6t
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: On Tabs and Spaces
From: Christer Weinigel @ 2007-10-17 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710171246500.26902@woody.linux-foundation.org>
This is bloody ridiculous, but...
On Wed, 17 Oct 2007 12:53:58 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 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).
>
> 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*.
I think you would get at lot less argument if you weren't so damn self
righteous about it. If you'd just said "it's a matter of taste and
hard tabs 8 spaces wide are the way we prefer to do it and that's the
way we want to keep doing it" I'd not have any problem with it.
But when you start claiming that there are no reasons to use all
spaces, and that it doesn't solve any problems (it definitely does),
and that all editors work with hard tabs at 8 (which they don't), at
least I get a bit frustrated with you. It's very non-respectful of you
to claim that everyone is stupid that doesn't agree with you and is
just asking for silly arguments. Yes, I know, you're an opinionated
bastard and proud of it, but maybe you should tone that down a bit.
(At least I got quite insulted by your Git talk at Google. People
are not stupid just because they don't agree with you, most of the time
they just have different preferences or different goals.)
/Christer (trying to escape from Lilliput)
^ permalink raw reply
* Re: On Tabs and Spaces
From: Johannes Schindelin @ 2007-10-17 21:08 UTC (permalink / raw)
To: Tom Tobin; +Cc: Linus Torvalds, git
In-Reply-To: <1192649598.6640.44.camel@athena>
Hi,
On Wed, 17 Oct 2007, Tom Tobin wrote:
> 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?
Tom, you have to contribute way more code than you did, in order to be
taken seriously with statements as these.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/6] more compact progress display
From: Nicolas Pitre @ 2007-10-17 20:56 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071017082003.GA10799@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 580 bytes --]
On Wed, 17 Oct 2007, Karl Hasselström wrote:
> On 2007-10-16 22:11:37 -0400, Shawn O. Pearce wrote:
>
> > Nicolas Pitre <nico@cam.org> wrote:
> >
> > > Each progress can be on a single line instead of two.
> >
> > Nice. Of course that screws with git-gui and now I have to match two
> > regexs and not one. But whatever.
>
> Maybe an env variable could cause the code to emit machine-friendly
> progress information instead?
That won't help with remotely generated progress unaware of local env
variable, and the remote server might still be generating old format.
Nicolas
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Daniel Barkalow @ 2007-10-17 20:45 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Jan Hudec, Frank Lichtenheld, Jakub Narebski, git,
Jonas Fonseca
In-Reply-To: <20071017002648.GH13801@spearce.org>
On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> Petr Baudis <pasky@suse.cz> wrote:
> > On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> > > On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
> > > > On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> > > > > Generic:
> > > > > # Dedicated domain name / site name, e.g. git.org or git.com
> ...
> > > > (And I guess something like git-scm.org wouldn't qualify as more
> > > > "official", would it?)
> > >
> ...
> > If someone trustworthy in the community has the resources to sponsor the
> > domain, I will only be happy and gladly set it up on my side (I can run
> > the nameservers myself too, if required). But I don't have the
> > resources for registering the domain myself, unfortunately.
>
> "git" is a three letter word. I don't think there have been *any*
> three letter .com/.org/.net domains available for years.
If anyone's in London, and could ask an Andy Ritchie nicely,
http://git.org/ doesn't seem to be doing much, and we might be able to get
a redirect.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: On Tabs and Spaces
From: David Kastrup @ 2007-10-17 20:31 UTC (permalink / raw)
To: Tom Tobin; +Cc: Linus Torvalds, git
In-Reply-To: <1192649598.6640.44.camel@athena>
Tom Tobin <korpios@korpios.com> writes:
> 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.
You are doing Junio a harsh injustice here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 2/2] Quoting paths in tests
From: David Kastrup @ 2007-10-17 20:03 UTC (permalink / raw)
To: git
In-Reply-To: <864pgpfyrd.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Jonathan del Strother <maillist@steelskies.com> writes:
>
>> For instance, git_editor in git-sh-setup expects the editor path to be
>> pre-quoted. So in t3404, you need to produce escaped double quotes &
>> dollar signs, resulting in unpleasantness like this :
>>
>> VISUAL="`pwd`/fake-editor.sh"
>> VISUAL=${VISUAL//\"/\\\"}
>> VISUAL=${VISUAL//$/\\\$}
>> VISUAL=\"$VISUAL\"
>> export VISUAL
>
> EDITORPWD="`pwd`"
> VISUAL='$EDITORPWD/fake-editor.sh'
> export EDITORPWD VISUAL
Pffffft.
VISUAL='"$EDITORPWD/fake-editor.sh"'
of course. Or we still have problems with spaces in pwd.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* 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
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