* 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: 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: 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: 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: 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: 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
* 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 4:17 UTC (permalink / raw)
To: Jeff King; +Cc: david, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <alpine.LFD.0.999.0710172017020.26902@woody.linux-foundation.org>
On Wed, 17 Oct 2007, Linus Torvalds wrote:
>
> [..] and if you're a vi user, you can do a ':set tabstop=4'
btw, don't get me wrong. I think 8-char tabstops are much better, and
would much prefer to really teach people not to indent too deeply (because
six-deep indents really look ugly as hell with 8-char indents).
So setting tabstops to smaller values is not something I think is good
practice, but at least that way you can keep your dirty perversions to
yourself, and don't have to admit to the world that you molest dogs and
small children and use an inferior tab-stop.
The rest of the world might notice occsionally when you don't hide your
non-indentation tab-uses well enough, of course, but keep to block
comments and spaces for non-indentation, and you'll be reasonably safe.
However, if I see people actually having indentations six+ deep, I'll know
that (a) you're likely a small-tab-misusing-deviant and (b) a horrible
programmer. And then the tab-deviancy is the smaller problem.
(Yes, we do have some cases of six+ deep indentations in the kernel. I'm
happy to say that they are fairly rare, and yes, I'm personally convinced
that the 8-wide indent level is part of it. It really *does* end up
encouraging people to split things up and write nested cases as separate
functions etc, because it simply becomes so obvious when things are going
south..)
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-18 4:22 UTC (permalink / raw)
To: Paul Wankadia; +Cc: git
In-Reply-To: <loom.20071018T032910-500@post.gmane.org>
On Thu, 18 Oct 2007, Paul Wankadia wrote:
>
> I hope and pray that you are parodied on "South Park" someday.
Isn't that what every person aspires to in the end?
Maybe I should start a kooky religion, then I'd be a shoo-in.
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: Dmitry Torokhov @ 2007-10-18 4:31 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <ejftl3c2.fsf@blue.sea.net>
On Wednesday 17 October 2007, Jari Aalto wrote:
> - 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.
>
How about this - I like tabs because when you removing it you
need to hit Backspace just once and don't have to strain your
eyes figuring out "Did I delete enough? Does it line up now?"
--
Dmitry
^ permalink raw reply
* Re: On Tabs and Spaces
From: Dmitry Potapov @ 2007-10-18 4:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jari Aalto, git
In-Reply-To: <alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org>
On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote:
> The answer is *also* not "tabs are just for initial code
> indents",
Unfortunately, it leads to some problems. For example, you can type:
git blame alloc.c
2c1cbec1 (Linus Torvalds 2007-04-16 22:10:19 -0700 21) #define DEFINE_ALLOCATOR(name, type) \
855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 22) static unsigned int name##_allocs; \
100c5f3b (Linus Torvalds 2007-04-16 22:11:43 -0700 23) void *alloc_##name##_node(void) \
855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 24) { \
855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 25) static int nr; \
and see that the end of line 23 does not look right. Because of that,
I prefer tabs for initial code indents and spaces in other places. Of
course, my preferences are irrelevant when it comes to someone else's
project, and I can easily use whatever style it takes to get things
done. It is just that "use tabs elsewhere and everything will be fine
as long as you have the standard tab setting" is not exactly correct.
The rest is people's preferences and habits...
Dmitry
^ permalink raw reply
* [PATCH] Add a message explaining that automatic GC is about to start
From: koreth @ 2007-10-18 4:41 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <20071018032307.GA7313@coredump.intra.peff.net>
---
On Wed, Oct 17, 2007 at 11:23:07PM -0400, Jeff King wrote:
> 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.
And as an added bonus, we can tell people how to turn off automatic GC
and how to invoke it by hand.
builtin-gc.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 23ad2b6..b1159d6 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -211,6 +211,10 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
prune = 0;
if (!need_to_gc())
return 0;
+ fprintf(stderr, "Packing your repository for optimum "
+ "performance. If you would rather run\n"
+ "\"git gc\" by hand, run \"git config gc.auto 0\" "
+ "to disable automatic cleanup.\n");
}
if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
--
1.5.3.rc2.4.g726f9
^ permalink raw reply related
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Steven Grimm @ 2007-10-18 4:44 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <20071018044143.GA24043@midwinter.com>
Sigh... Forgot to add:
Signed-off-by: Steven Grimm <koreth@midwinter.com>
^ permalink raw reply
* Re: pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Shawn O. Pearce @ 2007-10-18 4:50 UTC (permalink / raw)
To: Mike Galbraith; +Cc: git
In-Reply-To: <1192678865.20353.14.camel@Homer.simpson.net>
Mike Galbraith <efault@gmx.de> wrote:
> 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: Total 48507 (delta 38878), reused 44654 (delta 35166)
Well, Linus and crew are pretty busy beavers. Its shocking how
fast they can make a dam^H^H^Hoperating system better. :-)
...
> 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>
The problem here is you aren't on a branch, you are on a detached
HEAD. So we must have setup the wrong thing in .git/FETCH_HEAD
and we didn't actually merge.
What version of git is this, exactly (`git version`)?
I'd suggest making your life a little bit easier. Consider creating
a remote that points to Linus:
$ git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ git checkout -b master ; # or any other branch
$ git config branch.master.remote linus
$ git config branch.master.merge refs/heads/master
Now you can update from Linus with just:
$ git pull
Provided you are on branch "master", or whatever other branches
you setup those branch.*.remote and branch.*.merge configuration
options for.
--
Shawn.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Nicolas Pitre @ 2007-10-18 4:52 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:
> 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).
Well, you actually touched every files in the tree, and there are about
22K of them. this, plus the tree objects leading to them, your commit
certainly did create an unusual amount of loose objects. Repacking them
will inevitably take a wile.
Nicolas
^ permalink raw reply
* Re: bug: origin refs updated too soon locally
From: Shawn O. Pearce @ 2007-10-18 4:53 UTC (permalink / raw)
To: Perry Wagle; +Cc: git
In-Reply-To: <8CEF6150-4BE7-4B4D-B58C-12CE4671007E@cs.indiana.edu>
Perry Wagle <wagle@cs.indiana.edu> 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.
Heh. Yes, that's a known bug. Someone should really fix it.
The problem is we are updating the local tracking ref before we
actually get confirmation from the remote side that the remote side
has accepted (or rejected) that update request.
This is probably easier to do after the db/fetch-pack topic is
merged as the improvements there might make this easier. But I
could be wrong. Be nice if someone proved me wrong by writing up
a patch for git-send-pack.
For the time being the best way to recover from this is to use
git-fetch rather than git-pull. Recall that git-pull is defined as
"fetch then merge". You really just need to refetch the tracking
branches again, so your tracking branches have the same value as
the remote side.
--
Shawn.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jeff King @ 2007-10-18 4:54 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <alpine.LFD.0.9999.0710180049450.19446@xanadu.home>
On Thu, Oct 18, 2007 at 12:52:59AM -0400, Nicolas Pitre wrote:
> Well, you actually touched every files in the tree, and there are about
> 22K of them. this, plus the tree objects leading to them, your commit
> certainly did create an unusual amount of loose objects. Repacking them
> will inevitably take a wile.
Yes, I know. I wasn't complaining so much about the speed, but rather
the behavior of "git-gc" running while I was in the middle of trying to
accomplish something else (I hadn't seen it before, because I generally
keep my repos fairly packed).
-Peff
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jeff King @ 2007-10-18 4:55 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <20071018045453.GA10825@coredump.intra.peff.net>
On Thu, Oct 18, 2007 at 12:54:53AM -0400, Jeff King wrote:
> > Well, you actually touched every files in the tree, and there are about
> > 22K of them. this, plus the tree objects leading to them, your commit
> > certainly did create an unusual amount of loose objects. Repacking them
> > will inevitably take a wile.
>
> Yes, I know. I wasn't complaining so much about the speed, but rather
> the behavior of "git-gc" running while I was in the middle of trying to
> accomplish something else (I hadn't seen it before, because I generally
> keep my repos fairly packed).
But if you are trying to say that my case is pathological, then yes.
-Peff
^ permalink raw reply
* Re: [PATCH 1/6] more compact progress display
From: Shawn O. Pearce @ 2007-10-18 4:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Karl Hasselström, git
In-Reply-To: <alpine.LFD.0.9999.0710171653500.19446@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> 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.
Agreed. I've already merged Nico's change into my next branch.
I'll update git-gui soon to understand both formats, and that's that.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Jeff King @ 2007-10-18 5:01 UTC (permalink / raw)
To: koreth; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git
In-Reply-To: <20071018044143.GA24043@midwinter.com>
On Wed, Oct 17, 2007 at 09:41:43PM -0700, koreth@midwinter.com wrote:
> And as an added bonus, we can tell people how to turn off automatic GC
> and how to invoke it by hand.
I like it, especially with the new progress patches.
-Peff
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Shawn O. Pearce @ 2007-10-18 5:04 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Frank Lichtenheld, git
In-Reply-To: <98FA3712-B4E5-499A-B3E5-818FC33833DA@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> wrote:
> 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.
It did. I have your resubmit that started this thread in my INQ and
will try to get to it today. But if Frank has a queue of stuff I've
missed I'd like a pointer to it so I can also try to start working
through it. I know I also have some other topics that Lars Hjemli
accumlated in his tree that I still need to cherry-pick over into
mine, but I don't see the one we are talking about in there.
--
Shawn.
^ permalink raw reply
* Re: pulling Already up-to-date linux-2.6 repo takes ~8 minutes?
From: Mike Galbraith @ 2007-10-18 5:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071018045001.GA14735@spearce.org>
On Thu, 2007-10-18 at 00:50 -0400, Shawn O. Pearce wrote:
> The problem here is you aren't on a branch, you are on a detached
> HEAD. So we must have setup the wrong thing in .git/FETCH_HEAD
> and we didn't actually merge.
Aha. (I didn't setup anything that I can recall, followed a howto I
found)
> What version of git is this, exactly (`git version`)?
git version 1.5.3.4.203.gcc61a
> I'd suggest making your life a little bit easier. Consider creating
> a remote that points to Linus:
>
> $ git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> $ git checkout -b master ; # or any other branch
> $ git config branch.master.remote linus
> $ git config branch.master.merge refs/heads/master
>
> Now you can update from Linus with just:
>
> $ git pull
>
> Provided you are on branch "master", or whatever other branches
> you setup those branch.*.remote and branch.*.merge configuration
> options for.
Thanks, I appreciate it, kernel.org likely does too.
-Mike
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Shawn O. Pearce @ 2007-10-18 5:11 UTC (permalink / raw)
To: Jeff King
Cc: koreth, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin,
git
In-Reply-To: <20071018050158.GA11903@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Oct 17, 2007 at 09:41:43PM -0700, koreth@midwinter.com wrote:
>
> > And as an added bonus, we can tell people how to turn off automatic GC
> > and how to invoke it by hand.
>
> I like it, especially with the new progress patches.
Me too. Its in my tree now. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Bisect: fix a removed variable that is still used.
From: Shawn O. Pearce @ 2007-10-18 5:13 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, Johannes Schindelin, git
In-Reply-To: <20071018005256.280dfaab.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> wrote:
> This is fix for something I forgot in the patch named:
>
> [PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}"
> into "bisect_state".
>
> I can send an updated version of the above patch if
> needed.
Thanks. Squashed into 6/7.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2 v3] mergetool: use path to mergetool in config var mergetool.<tool>.path
From: Shawn O. Pearce @ 2007-10-18 5:27 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11926413723666-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> This commit adds a mechanism to provide absolute paths to the
> external programs called by 'git mergetool'. ...
...
> @@ -297,17 +297,38 @@ do
> shift
> done
>
> +valid_tool() {
> + case "$1" in
> + kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
> + ;; # happy
> + *)
> + return 1
> + ;;
> + esac
> +}
...
> + test -n "$merge_tool" || valid_tool "$merge_tool" || {
Wouldn't an empty $merge_tool string be caught above in the
valid_tool function where it falls through and returns 1?
So isn't test -n here redundant?
--
Shawn.
^ 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