* pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Mike Galbraith @ 2007-10-18 3:41 UTC (permalink / raw)
To: git
Greetings git gods,
I'm wondering if I'm not doing something wrong, and thereby putting
unneeded stress on kernel.org when I pull latest kernel tree.
git_pull_linus scriptlet:
#!/bin/sh
(cd linux-2.6; git pull
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git)
(cd linux-2.6; git pull -t
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git)
root@Homer: time ./git_pull_linus
remote: Generating pack...
remote: Counting objects: 17746
remote: Done counting 55975 objects.
remote: Result has 48507 objects.
remote: Deltifying 48507 objects...
remote: 100% (48507/48507) done
Indexing 48507 objects...
remote: Total 48507 (delta 38878), reused 44654 (delta 35166)
100% (48507/48507) done
Resolving 38878 deltas...
100% (38878/38878) done
3419 objects were added to complete this thin pack.
Already up-to-date.
You are not currently on a branch; you must explicitly
specify which branch you wish to merge:
git pull <remote> <branch>
real 7m57.429s
user 0m13.517s
sys 0m0.859s
8 minutes, truckloads of network traffic, and lord knows what all going
on at the other end just doesn't seem right. /me == dummy?
-Mike
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-18 3:32 UTC (permalink / raw)
To: Jeff King; +Cc: david, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <20071018030055.GA7218@coredump.intra.peff.net>
On Wed, 17 Oct 2007, Jeff King wrote:
>
> Yes, obviously. The people who advocate mixing really _are_ objectively
> wrong. But I was talking about all-spaces versus all-tabs.
If you really are all one-or-the-other, then everything is obviously fine,
and spaces have somewhat stronger guarantees (I say "somewhat", because
the line-up-guarantee of all-spaces is only guaranteed with fixed-width
fonts, and hard-tab indents often look nicer in printouts, and are
generally much more flexible in just how wide you make the indent *look*,
ie hard-tabs at least *allow* people to see the indents in different
ways, even if that will potentially mess up any alignment).
But some mixing is inevitable, and at least in UNIX, the tendency is for
tabs, not spaces, by default, so tabs have a much higher chance of
*staying* mostly tabs, while anybody who uses spaces pretty much *will*
get tabs inserted by just about any programming editor that isn't set up
for python.
So you always get _some_ amount of mixing, exactly because most editors
won't show you the difference, and what people aren't aware of, they don't
think about. There's no getting away from that, unless you actually
enforce it with hooks (and in a distributed environment, even that isn't
really going to fly, is it?).
And if you *do* decide to enforce it with hooks, you now have issues like
the fact that some files mustn't do it (autoconvert tabs to spaces in a
Makefile, and it just stops working!), and others have somewhat subtle
issues forcing your converter to be somewhat knowledgeable (trivial
example: strings that are spread across multiple lines in C..)
In general, if you do enforce it (which I personally think is not likely a
good idea, but hey, it's up to the project), I'd *still* suggest going the
way of enforcing hard-tabs, not spaces. As mentioned, space does matter,
but hardtabs really are "friendlier", and if you're a vi user, you can do
a :set tabstop=4 and if that's what you're used to, it will all look
better to you.
In contrast, all-spaces just sucks. It really has no redeeming values.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Paul Wankadia @ 2007-10-18 3:31 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org>
Linus Torvalds <torvalds <at> linux-foundation.org> writes:
> The only sane solution is the one the kernel and git have always used:
> tabs are 8 spaces wide, and anybody who disagrees can go screw themselves.
I hope and pray that you are parodied on "South Park" someday.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jeff King @ 2007-10-18 3:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710171955580.26902@woody.linux-foundation.org>
On Wed, Oct 17, 2007 at 08:13:23PM -0700, Linus Torvalds wrote:
> Yes.
>
> You're missing the fact that some people have problems with editors.
>
> So they add a line, and they add *that* line with the wrong kind of
> indentation. And it shows up among the other lines like this (here the
> whole patch is indented):
Oh. I thought you meant "if you have an all-spaces policy, your diffs
will not look good." But what you meant was "when people screw up your
policy by mixing tabs and spaces, your diffs will not look good." And
that applies equally, whether they are screwing up your all-tabs or
all-spaces setup (and I remain convinced that no matter what your
policy, people _will_ screw it up).
Thanks for the clarification.
> It's very seldom the case that you grow some problem space and performance
> stays the same.
Yes. I wondered whether the increased size would really matter here, or
if it would get lost in the noise of program startup and other
activities. But in this case, it really does matter.
> > Gah, I can't believe I've not only been sucked into a tab vs spaces
> > discussion, but now I've actually wasted time doing a performance
> > comparison on it.
> Well, performance analysis isn't exactly a "waste". That "git grep" was
No, it's not a waste. In the grand scheme of things, I don't actually
care that much about the result, but hey, I think I may be the only
person out of this gigantic thread to actually provide _numbers_. :)
> Yeah, I don't think it's wonderful, but it might even be a good thing as a
> "hey, at least you are aware of the notion of GC now" kind of introduction
> to people (who then hopefully realize that they don't actually want
> automatic GC, but rather do it once a week or something).
It would have been nicer if it said something like "Your repository
looks crufty. Running git-gc --auto..." using whatever terms users would
be comfortable with. Instead, it just started with "Counting objects"
and a long wait. I happen to know what that means, but I'm not sure how
a git newbie would react (though it looked _much_ nicer because of
Nico's recent terser progress patches).
-Peff
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-18 3:13 UTC (permalink / raw)
To: Jeff King; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <20071018024553.GA5186@coredump.intra.peff.net>
On Wed, 17 Oct 2007, Jeff King wrote:
>
> You have made this claim several times, and I really don't understand
> it. If I have 8 spaces, then a diff line will have either " ", "+", or
> "-" followed by 8 spaces. If I use a hard tab, then the tab will end up
> only taking up 7 spaces because of the nature of tabs.
>
> This might matter if I'm comparing non-diff code to diff code. But in a
> diff, _everything_ is indented by exactly one space, so it all lines up.
> Is there something I'm missing?
Yes.
You're missing the fact that some people have problems with editors.
So they add a line, and they add *that* line with the wrong kind of
indentation. And it shows up among the other lines like this (here the
whole patch is indented):
diff --git a/kernel/sched.c b/kernel/sched.c
index 92721d1..1ecb164 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -127,6 +127,7 @@ static inline u32 sg_div_cpu_power(const struct sched_group *sg, u32 load)
static inline void sg_inc_cpu_power(struct sched_group *sg, u32 val)
{
sg->__cpu_power += val;
+ wrong indentation here.
sg->reciprocal_cpu_power = reciprocal_value(sg->__cpu_power);
}
#endif
and so you see the fact that somebody messed up in the patch itself.
It actually more often goes the other way: somebody may have messed up
earlier, but did so *consistently* so it wasn't obvious when looking at
the patch. And then somebody fixes one line, and now that one fixed line
is indented correctly but differently.
When it gets *too* bad, we just reindent the whole file, but more
commonly when I notice it in a diff, I just edit that particular region
or even just the diff itself in-place.
Generally, it seldom comes to even that. Doing a
git grep ' ' -- '*.c'
(that's now eight spaces) returns quite a lot of lines, and it's generally
not worth worrying about (not all of them are indentation - people do use
spaces for lining things up etc - but a lot of it really is just indents
done against the coding style).
> I was about to tell you that you're full of it, but there really is a
> slowdown:
> [ ... ]
> It's actually about 16%.
I didn't even time it, and I called it at 20% without even counting any
tabs. Why? Because it's inevitable!
It so happens that "grep" has a lot of really clever heuristics, so that
it is actually better at passing over characters that it knows cannot
start the pattern you are searching for, so timing "grep" is actually
quite complex in the general case. So I bet that if you had grepped for
something that started with a space, you'd probably have found a bigger
slowdown.
But ignore all that complexity, and it really boils down to a really
simple principle: bigger data sets are more expensive, and "linear
slowdown" is actually almost the best possible case. Quite often, a bigger
data set causes *worse* than a linear slowdown.
It's very seldom the case that you grow some problem space and performance
stays the same.
> Gah, I can't believe I've not only been sucked into a tab vs spaces
> discussion, but now I've actually wasted time doing a performance
> comparison on it.
Well, performance analysis isn't exactly a "waste". That "git grep" was
something we spent some time trying to go fast (for example, doing the
whole external grep tool thing because that thing is usually optimized to
h*ll and back - so the execve() overhead is more than worth it).
And it's a real workload. Maybe others don't use "git grep" quite as much
as I do, but I do it *all* the time. Some other people probably use ctags
or something, I personally prefer just a fast git grep.
But the *exact* same issues will show up for "simple" things like "git
bisect". One of the biggest costs of git bisect is actually checking out
the source tree. If the source tree is on the order of 20% larger, what
does that mean?
So it doesn't matter if you have a terabyte disk. Source code size *still*
matters.
And 20% (or 16%) is more than a lot of other optimizations can help you
save!
> As an aside, that commit was enough to trigger a "git-gc --auto", which
> was my first experience with it. It's actually kind of annoying
> (especially since I was about to repack -a -d).
Yeah, I don't think it's wonderful, but it might even be a good thing as a
"hey, at least you are aware of the notion of GC now" kind of introduction
to people (who then hopefully realize that they don't actually want
automatic GC, but rather do it once a week or something).
Linus
^ permalink raw reply
* Re: A note from the interim Git maintainer
From: Eric Wong @ 2007-10-18 3:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Benoit Sigoure, Eygene Ryabinkin
In-Reply-To: <20071017071329.GY13801@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
> > Eygene Ryabinkin (2):
> > git-svn: respect Subversion's [auth] section configuration values
> > git-svn: use "no warnings 'once'" to disable false-positives
>
> I apparently already had that first one from Eygene ("[auth]
> section") in spearce/master; it went out last night. Perhaps you
> ran the shortlog above against Junio's tree and not mine?
Exactly, it was late :)
--
Eric Wong
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jeff King @ 2007-10-18 3:00 UTC (permalink / raw)
To: david; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <Pine.LNX.4.64.0710172002020.10276@asgard.lang.hm>
On Wed, Oct 17, 2007 at 08:03:51PM -0700, david@lang.hm wrote:
>> This might matter if I'm comparing non-diff code to diff code. But in a
>> diff, _everything_ is indented by exactly one space, so it all lines up.
>> Is there something I'm missing?
>
> if the code uses a tab and the patch uses 8 spaces the two will not line up
> in the diff becouse in the diff output the tab is 'only 7 spaces;
>
> useing one or the other isn't the problem, it's the mixing of the two.
Yes, obviously. The people who advocate mixing really _are_ objectively
wrong. But I was talking about all-spaces versus all-tabs.
-Peff
^ permalink raw reply
* Re: On Tabs and Spaces
From: david @ 2007-10-18 3:03 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <20071018024553.GA5186@coredump.intra.peff.net>
On Wed, 17 Oct 2007, Jeff King wrote:
> On Wed, Oct 17, 2007 at 05:59:27PM -0700, Linus Torvalds wrote:
>
>> It happens. We do de-spacification in the kernel occasionally when it is
>> an annoyance. Usually it shows up in patches, though - exactly because
>> code which adds spaces instead of tabs won't line up correctly in the
>> diff.
>
> You have made this claim several times, and I really don't understand
> it. If I have 8 spaces, then a diff line will have either " ", "+", or
> "-" followed by 8 spaces. If I use a hard tab, then the tab will end up
> only taking up 7 spaces because of the nature of tabs.
>
> This might matter if I'm comparing non-diff code to diff code. But in a
> diff, _everything_ is indented by exactly one space, so it all lines up.
> Is there something I'm missing?
if the code uses a tab and the patch uses 8 spaces the two will not line
up in the diff becouse in the diff output the tab is 'only 7 spaces;
useing one or the other isn't the problem, it's the mixing of the two.
David Lang
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jeff King @ 2007-10-18 2:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710171753020.26902@woody.linux-foundation.org>
On Wed, Oct 17, 2007 at 05:59:27PM -0700, Linus Torvalds wrote:
> It happens. We do de-spacification in the kernel occasionally when it is
> an annoyance. Usually it shows up in patches, though - exactly because
> code which adds spaces instead of tabs won't line up correctly in the
> diff.
You have made this claim several times, and I really don't understand
it. If I have 8 spaces, then a diff line will have either " ", "+", or
"-" followed by 8 spaces. If I use a hard tab, then the tab will end up
only taking up 7 spaces because of the nature of tabs.
This might matter if I'm comparing non-diff code to diff code. But in a
diff, _everything_ is indented by exactly one space, so it all lines up.
Is there something I'm missing?
> So it doesn't matter *which* one you use (all spaces or all tabs) in that
> sense.
Yes, I agree with that (even with an all-tabs policy, there are still
mangled and incorrect patches that come in -- and the maintainer rejects
or fixes them).
Which was what I was trying to point out with my question (though I was
also curious to hear your answer): all-space versus all-tab is largely a
matter of preference. And that means that people who want git to change
to _their_ preference are just being silly.
> And smaller *is* faster. Do something like this on the kernel:
>
> GIT_PAGER= time git grep sched_fair
>
> and then do the same thing with the kernel sources blown up by 20% by
> de-tabification. Guess which one is 20% slower?
I was about to tell you that you're full of it, but there really is a
slowdown:
$ cd linux-2.6
$ GIT_PAGER= time git grep sched_fair >/dev/null
0.34user 0.94system 0:01.30elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+7548minor)pagefaults 0swaps
$ find . -name .git -prune -o -type f | xargs perl -pi -e 's/\t/ /g'
$ git-commit -a -m de-tabify
$ git-repack -a -d
$ GIT_PAGER= time git grep sched_fair >/dev/null
0.42user 1.06system 0:01.54elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+7591minor)pagefaults 0swaps
It's actually about 16%.
Gah, I can't believe I've not only been sucked into a tab vs spaces
discussion, but now I've actually wasted time doing a performance
comparison on it.
As an aside, that commit was enough to trigger a "git-gc --auto", which
was my first experience with it. It's actually kind of annoying
(especially since I was about to repack -a -d).
-Peff
^ permalink raw reply
* Re: bug: origin refs updated too soon locally
From: Perry Wagle @ 2007-10-18 1:43 UTC (permalink / raw)
To: Perry Wagle; +Cc: git
In-Reply-To: <8CEF6150-4BE7-4B4D-B58C-12CE4671007E@cs.indiana.edu>
I take it back. A git-pull is not a workaround if the ref moved on
the remote end.
-- Perry
On Oct 17, 2007, at 6:35 PM, Perry Wagle wrote:
> If I clone a remote repository, make a few commits, push them to
> the remote repository, and the update hook on the remote repository
> rejects them (exit 1), the local origin refs are still updated as
> if the push had gone through. The workaround is to do a pull to
> set the origin refs back.
>
> -- Perry
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* bug: origin refs updated too soon locally
From: Perry Wagle @ 2007-10-18 1:35 UTC (permalink / raw)
To: git
If I clone a remote repository, make a few commits, push them to the
remote repository, and the update hook on the remote repository
rejects them (exit 1), the local origin refs are still updated as if
the push had gone through. The workaround is to do a pull to set the
origin refs back.
-- Perry
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Symonds @ 2007-10-18 1:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Geert Bosch, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, Ren? Scharfe, Junio Hamano
In-Reply-To: <Pine.LNX.4.64.0710180045160.25221@racer.site>
On 18/10/2007, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Oct 2007, Linus Torvalds wrote:
>
> > Well, this has been debated to death, but I actually think that "skip"
> > is a good choice, exactly because it's an action.
>
> Could we, _please_, first decide if the implementation has merits, and
> just apply it as is in that case? We can rename it whatever anybody likes
> later, and we can paint the bikeshed brown if you want to.
I figured with something like this, it'd be a lot easier to get the
colour right first, since command UI is harder to repaint if it gets
widely adopted. Anyway, I think the patch itself is a very good
feature.
Dave.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-18 0:59 UTC (permalink / raw)
To: Jeff King; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <20071018003256.GA5062@coredump.intra.peff.net>
On Wed, 17 Oct 2007, Jeff King wrote:
>
> In what way does an all-space model cause people to accidentally add
> tabs, but an all-tab model does not cause people to accidentally add
> spaces?
It happens. We do de-spacification in the kernel occasionally when it is
an annoyance. Usually it shows up in patches, though - exactly because
code which adds spaces instead of tabs won't line up correctly in the
diff.
So it doesn't matter *which* one you use (all spaces or all tabs) in that
sense. But clearly tabs are *way* more common at least in any UNIX
project, and tabs really do have the advantage of being smaller.
And smaller *is* faster. Do something like this on the kernel:
GIT_PAGER= time git grep sched_fair
and then do the same thing with the kernel sources blown up by 20% by
de-tabification. Guess which one is 20% slower?
And whoever said that disk space doesn't matter doesn't know what he is
talking about. Disk space most *definitely* matters. Do the above test
with a cold-cache case, and think what 20% more IO does to you (or 20%
less disk cache).
But no, the size issues are secondary, I'm not claiming anything else.
Although I do suspect that historically, they have been primary, and have
been the thing that has resulted in the fact that tabs are so commonly
used.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jeff King @ 2007-10-18 0:32 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>
On Wed, Oct 17, 2007 at 08:53:55AM -0700, Linus Torvalds 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.
In what way does an all-space model cause people to accidentally add
tabs, but an all-tab model does not cause people to accidentally add
spaces?
-Peff
^ permalink raw reply
* Re: On Tabs and Spaces
From: Christer Weinigel @ 2007-10-18 0:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Tom Tobin, git
In-Reply-To: <Pine.LNX.4.64.0710180040320.25221@racer.site>
On Thu, 18 Oct 2007 00:44:22 +0100 (BST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 18 Oct 2007, Christer Weinigel wrote:
>
> > I'm not that invisible am I?
> >
> > cd linux-2.6.22.7
> > find . -type f | xargs egrep -il "weinigel" | wc -l
> > 17
>
> File or directory not found.
>
> We are not Linux specific here. Besides, I was talking about _git_
> source code, just in case I did not make myself clear.
You do not have a sense of humor, do you? And you elided the paragraph
where I said that I haven't contributed anything to git so far. :-/
> > [...] and privately I use CVS just because I started using CVS ten
> > years ago and haven't bothered to change.
>
> I wonder why you have to leave your hideout and comment on the source
> code of _git_, then. I mean, why do _you_ care? (It should have
> become apparent to you that _we_ care, so it looks even more like you
> wanted to dictate a policy on git, which you have no business with.)
Where did I say that I'm not interested in git? If I weren't I
wouldn't have been reading this mailing list since it was first
created. The reason I don't use git is a lack of time. Professionally
I usually have no need to use git since my employer doesn't use it.
On my own time, I haven't even had time and energy to switch away from
CVS, even though I ought to have done that years ago. I dabble a bit
with git, mercurial, org bitkeeper (or did at least) when I need to
access something out on the net which is stored in such a repository,
but I haven't switched any of my projects over to using anything else.
I'm definitely interested in git, and it's interesting to read the
mailing list to see where git is going. And I'd definitely like git to
move in a direction where it's usable for me, or even better, where I
can recommend it to my (often Windows-only) colleagues.
And once again you cut out the part where I said that git is Junio's
baby, he decides what goes into the main git tree, and if he says 8
wide hard tabs, that it is. I haven't argued against that at all. So
I'm wondering why you are trying to project things I haven't
said on me.
/Christer (pissing contensts are silly, so why the hell am I getting
involved in one?)
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Linus Torvalds @ 2007-10-17 23:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Geert Bosch, David Symonds, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, Ren? Scharfe, Junio Hamano
In-Reply-To: <Pine.LNX.4.64.0710180045160.25221@racer.site>
On Thu, 18 Oct 2007, Johannes Schindelin wrote:
>
> Could we, _please_, first decide if the implementation has merits, and
> just apply it as is in that case? We can rename it whatever anybody likes
> later, and we can paint the bikeshed brown if you want to.
I thought everybody really agreed that being able to skip commits that you
cannot say good/bad about is a feature worth doing?
Right now we actually have some docs in the man-page about doing that
avoidance manually, so it's not like it's debatable whether this issue
comes up. It most definitely does come up.
Does anybody really think it's not a good feature? And I've not seen
negative comments about the implementation either apart from some small
details that I think got fixed up already (but maybe the complaints were
all hidden by the shed color discussions ;)
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 23:53 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Johannes Schindelin, Tom Tobin, git
In-Reply-To: <20071018011734.7b636141@localhost.localdomain>
On Thu, 18 Oct 2007, Christer Weinigel wrote:
>
> BTW, how serious is the problem with deltifying when there are a lot of
> spaces that David Kastrup mentioned?
I suspect it works quite well in practice.
But we've had to tweak the xdiff code before, and the hash calculations
for bucket size limits. If somebody actually points out a problem case, we
can probably tweak it again.
> Wouldn't it be a problem when people put ASCII graphics in comments or
> just have comments like /*********************************/ in their
> code?
In general, *any* situation where you have tons of character sequences
that are the same (and here it's not the characters *themselves* that have
to be the same - it's the *sequence* that has to be the same, so it's not
about repeating the same character over and over per se: it's about
repeating a certain block of characters many many times in the source
code) will be problematic for pretty much any similarity analysis.
Why? Because you just have a lot of the same sequence, and to get a good
delta you want to find common "sequences of these sequences" (call them
supersequences) in order to find the biggest common chunk.
So the badly performing cases for any delta algorithm (and I do want to
point out that this has nothing what-so-ever to do with the particular one
that git uses) tends to be exactly the ones where you have lots and lots
of smaller chunks that match in two files, and that then makes it costlier
to find the *bigger* chunks that are build up of those smaller chunks.
And generally you tend to have two situations: you either (a) take *much*
longer to find the common areas (they are often quadratic or worse
algorithms) or (b) you decide to ignore chunks that are so common that
they don't really add any real information when it comes to finding truly
common chunks. Where that second choice generally means that you can miss
some cases where you *could* have found a good match for deltification.
In fact, usually you have a combination of the above two effects: certain
deltas may be more expensive to find but there is also a limit that kicks
in and means that you never spend *too* much time on finding them if the
pattern space is not amenable to it.
Would lots of spaces be such a pattern? I personally doubt it would really
matter. In general, source code is easy to delta: the bulk of any common
sequences in most files will be found by the trivial "look for common
sequences in the beginning and the end". The really *bad* cases tend to be
rather odd, and often generated files.
So no, I don't think deltification is a huge deal for spaces. But it does
boil down to the same kind of issues: if you blow up the source base by
20%, you often slow down things by 20% or more, simply because there is
more data to process at all stages. It simply just slows down everything -
totally unnecessarily.
Linus
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Johannes Schindelin @ 2007-10-17 23:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Geert Bosch, David Symonds, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, Ren? Scharfe, Junio Hamano
In-Reply-To: <alpine.LFD.0.999.0710171553580.26902@woody.linux-foundation.org>
Hi,
On Wed, 17 Oct 2007, Linus Torvalds wrote:
> On Mon, 15 Oct 2007, David Kastrup wrote:
>
> > Geert Bosch <bosch@adacore.com> writes:
> >
> > > On Oct 15, 2007, at 13:53, David Symonds wrote:
> > >> That's also why I suggested "skip"; you might not be able to test a
> > >> particular commit, but you might also not *want* to test a
> > >> particular commit for some reason.
> > >
> > > Skip seems a great choice: it directly expresses the wish to not
> > > consider a certain commit. The reason is unimportant.
> >
> > But it is an _action_, while "good" and "bad" are properties.
>
> Well, this has been debated to death, but I actually think that "skip"
> is a good choice, exactly because it's an action.
Could we, _please_, first decide if the implementation has merits, and
just apply it as is in that case? We can rename it whatever anybody likes
later, and we can paint the bikeshed brown if you want to.
Ciao,
Dscho
^ permalink raw reply
* Re: On Tabs and Spaces
From: Johannes Schindelin @ 2007-10-17 23:44 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Linus Torvalds, Tom Tobin, git
In-Reply-To: <20071018011734.7b636141@localhost.localdomain>
Hi,
On Thu, 18 Oct 2007, Christer Weinigel wrote:
> On Wed, 17 Oct 2007 23:11:37 +0100 (BST)
> Johannes Schindelin <Johannes.w@gmx.de> wrote:
>
> > On Wed, 17 Oct 2007, Christer Weinigel wrote:
> >
> > > I think you would get at lot less argument if you weren't so damn
> > > self righteous about it.
> >
> > Why is it that in this thread, people whom I have heard _nothing_ of
> > before seem to think this would be a good time to let their opinion
> > be heard? Now, _that_ is what I call righteous. Show nothing but
> > opinion.
>
> I'm not that invisible am I?
>
> cd linux-2.6.22.7
> find . -type f | xargs egrep -il "weinigel" | wc -l
> 17
File or directory not found.
We are not Linux specific here. Besides, I was talking about _git_ source
code, just in case I did not make myself clear.
> [...] and privately I use CVS just because I started using CVS ten years
> ago and haven't bothered to change.
I wonder why you have to leave your hideout and comment on the source code
of _git_, then. I mean, why do _you_ care? (It should have become
apparent to you that _we_ care, so it looks even more like you wanted to
dictate a policy on git, which you have no business with.)
Puzzled, and a little unnerved,
Dscho
^ permalink raw reply
* Re: [QGIT4 PATCH] Add --no-color option to several calls to git
From: Marco Costalba @ 2007-10-17 23:38 UTC (permalink / raw)
To: Yaacov Akiba Slama; +Cc: git
In-Reply-To: <1192643649-18908-1-git-send-email-ya@slamail.org>
On 10/17/07, Yaacov Akiba Slama <ya@slamail.org> wrote:
> 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>
> ---
Thanks for the patch I will apply probably this week-end.
Probably a point release both for qgit-2.0 and qgit-1.5.7 will be
needed. This is a new feature of git that could break current qgit.
Could you please confirm me that with this patch qgit works flawless
for you when "diff.color = true", I' m worried to push a new point
release just to discover we need to fix some more.
Thanks
Marco
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jari Aalto @ 2007-10-17 23:38 UTC (permalink / raw)
To: git
In-Reply-To: <47168E70.4070305@op5.se>
* Thu 2007-10-18 Andreas Ericsson <ae@op5.se> gmane.comp.version-control.git
* Message-Id: 47168E70.4070305@op5.se
> And simply because nearly all (unix) editors still insert a hard tab
> when pressing the tab key, and *mixing* tabs and spaces makes the
> situation *really* unbearable, one really shouldn't use all spaces.
There was no assumption about a particular OS or editors.
The QA tools will take care of warning or making automatic formatting
before the code is put to SCM. In projects you cannot assume anything
about people, their tools or what OS they might use at hand.
>> There is no such problem with spaces.
>>
>
> I beg to differ, for reasons stated multiple times elsewhere in this
> thread.
Consider:
- Any editor will display the text written in "all spaces"
100 % the same. Regradless of any viewer or editor used.
But the same is not true with text that uses tabs (because you
really can't know what options the editor is preset / user set /
regarding the treatment of tabs).
The score is 1 - 0 for "all spaces" in this contest.
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Christian Couder @ 2007-10-17 23:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Junio Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710171906280.25221@racer.site>
Hi,
Le mercredi 17 octobre 2007, Johannes Schindelin a écrit :
> 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,
It's also the fine work of Junio as he wrote most of
the "rev-list --bisect-all" patch.
> just
> because there are non-technical arguments still in the air.
>
> I want bisect dunno. Even if there is another name later.
Thanks for your kind words,
Christian.
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.
From: Marco Costalba @ 2007-10-17 23:26 UTC (permalink / raw)
To: Robin Rosenberg
Cc: pete, piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <200710171800.37345.robin.rosenberg.lists@dewire.com>
On 10/17/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>
> You could avoid the temporary files if you just pipe the diff to kompare. That
> would require an option to tell qgit that the external viewer can read a git diff.
>
> At the time qgit 1.5 was written, kompare could not handle git diffs.
>
So does the other tools I have checked at that time.
But I don't know if this fixes the problem of slowness reported. A
little test Pete may do is just as I have written in the former email:
try to save the big files that cause troubles where he prefers and run
Kompare on them directly from the command line.
Is kompare faster? If no probably the 'pipe' technique will not solve
the problem and shrinks the applicability of the external diff
launcher to tools that handle diffs directly.
Marco
^ permalink raw reply
* Re: On Tabs and Spaces
From: Christer Weinigel @ 2007-10-17 23:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Tom Tobin, git
In-Reply-To: <Pine.LNX.4.64.0710172310270.25221@racer.site>
On Wed, 17 Oct 2007 23:11:37 +0100 (BST)
Johannes Schindelin <Johannes.w@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Oct 2007, Christer Weinigel wrote:
>
> > I think you would get at lot less argument if you weren't so damn
> > self righteous about it.
>
> Why is it that in this thread, people whom I have heard _nothing_ of
> before seem to think this would be a good time to let their opinion
> be heard? Now, _that_ is what I call righteous. Show nothing but
> opinion.
I'm not that invisible am I?
cd linux-2.6.22.7
find . -type f | xargs egrep -il "weinigel" | wc -l
17
Ahh, confirmation, I really do exist. The earliest LSM entry I can find
for myself is from 1995:
http://www.ibiblio.org/pub/linux/kernel/patches/scanners/hpscan-0.1.1.5.lsm
Mmm, nostalgia. :-)
But yes, I haven't contributed anything to git so far, I mostly lurk
on the mailing list and try to keep up with what's happening to git.
In the beginning I sent a few ideas to the list (which quite sadly were
ignored), but unfortunately I've been busy with paying work to do much
with git after that. And at work we use Perforce (yuk) or Subversion
(a lot nicer than Perforce) and privately I use CVS just because I
started using CVS ten years ago and haven't bothered to change. And
when I'm free I prefer to hack on hardware or device drivers instead.
The reason I wrote my first mail in this thread is that I work in a
different environment than Linus does and wanted to share that
experience. I usually work with embedded programming, where people use
lots of different editors and in mixed environments. Some people use
Visual Studio on Windows because that's what they use for host
programming, a lot of embedded development is done in the (almost
invariably sucky) IDE that comes with the compilers for the embedded
CPU, such as Microchips MPLAB or IAR Workbench, Eclipse is becoming
quite popular for C development, Slickedit is also popular on Windows,
a colleague prefers nedit for some strange reason, and so on. In such a
heterogeneous environment the easiest way to make sure that people see
the same indentation in all editors is to just tell them to use spaces
for indentation, and I think that every editor I just mentioned has a
setting to do that automatically. Microemacs is the odd one out in
that it doesn't support it. And my employers haven't really been
paying me to go on a crusade for the holy TAB is 8 spaces cause, they
just want things done, so I've had to settle for a "good enough"
solution which works most of the time.
So I just thought it was unfair of Linus to say that "use spaces"
doesn't solve any problems, in some environments it does. For the
Linux kernel and Git, it's easier for the maintainer to enforce
the coding standards and since Linus and Junio prefer to use hard tabs,
that are the rules that people who want to play with their toys
have to adhere to.
BTW, how serious is the problem with deltifying when there are a lot of
spaces that David Kastrup mentioned? It does sound like a quite
serious problem if it has a big impact on the performance of Git. Git
isn't only used for the Linux kernel, so there has to be some projects
that both use spaces for indentation and use Git out there. Wouldn't
it be a problem when people put ASCII graphics in comments or just have
comments like /*********************************/ in their code?
/Christer
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Linus Torvalds @ 2007-10-17 22:59 UTC (permalink / raw)
To: David Kastrup
Cc: Geert Bosch, David Symonds, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, Ren? Scharfe, Junio Hamano,
Johannes Schindelin
In-Reply-To: <85ve98gl57.fsf@lola.goethe.zz>
On Mon, 15 Oct 2007, David Kastrup wrote:
> Geert Bosch <bosch@adacore.com> writes:
>
> > On Oct 15, 2007, at 13:53, David Symonds wrote:
> >> That's also why I suggested "skip"; you might not be able to test a
> >> particular commit, but you might also not *want* to test a particular
> >> commit for some reason.
> >
> > Skip seems a great choice: it directly expresses the wish to
> > not consider a certain commit. The reason is unimportant.
>
> But it is an _action_, while "good" and "bad" are properties.
Well, this has been debated to death, but I actually think that "skip" is
a good choice, exactly because it's an action.
"good" and "bad" do indeed describe properties of the commit, and are used
to describe the state of the tree in question. In contrast, "git bisect
skip" says not somethign about the state of that tree - it talks about
what we should *do* with that tree.
IOW, I think "git bisect skip" in some sense has more to do with an action
like "git bisect start", than with "good" or "bad".
(Yes, "good" and "bad" have an action associated with them too - namely to
start the next bisection event - but they are not named according to the
action they cause, but because they describe the tree state)
Linus
^ 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