* Re: [RFC/PATCH] Add a --nosort option to pack-objects
From: Junio C Hamano @ 2007-12-07 21:25 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1197061832-8489-1-git-send-email-mh@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> The --nosort option disabled the internal sorting used by pack-objects,
> and runs the sliding window along the object list litterally as given on
> stdin.
I think this is a good way to give people an easier way to experiment.
But it makes me wonder if this is disabling too much, and if the list
should be sorted at least by type, as we won't delta different types of
objects against each other.
At the beginning of try_delta(), when we see that the next candidate is
of a different type, we return -1 telling the caller that "No object in
the window will ever be a good delta base for the current object, please
abort". This relies on the fact that we sort by type first, so I think
one of the following is necessary:
(1) you weaken this check (return 0, saying "This did not delta well but
do not give up yet"),
(2) you document this well so that --nosort user will know, or
(3) you sort --nosort input by type.
> I would obviously add the appropriate documentation for this flag if this
> is accepted. I'll also try to send another documentation patch for
> pack-objects with some information compiled from Linus's explanation to my
> last message about pack-objects.
I need to rant here a bit.
Sometimes people say "Here is my patch. If this is accepted, I'll add
documentation and tests". My reaction is, "Don't you, as the person who
proposes that change, believe in your patch deeply enough yourself to be
willing to perfect it, to make it suitable for consumption by the
general public, whether it is included in my tree or not? A change that
even you do not believe in deeply enough probably to perfect would not
benefit the general public, so thanks but no thanks, I'll pass."
Fortunately we haven't had this problem too many times on this list.
I would not have minded at all if you said:
Obviously, appropriate documentation and tests are needed before
inclusion, but I am sending this out primarily to seek opinions
from the list to make sure this is going in the right direction,
iow, this is an RFC.
What bugged me was the phrase "if this is accepted".
^ permalink raw reply
* Re: [RFC/PATCH] Add a --nosort option to pack-objects
From: Nicolas Pitre @ 2007-12-07 21:24 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <1197061832-8489-1-git-send-email-mh@glandium.org>
On Fri, 7 Dec 2007, Mike Hommey wrote:
> While most of the time the heuristics used by pack-objects to sort the
> given object list are satisfying enough, there are cases where it can be
> useful for the user to sort the list with heuristics that would be better
> suited.
Could you please elaborate on those cases where the current heuristic
would be unsatisfactory?
Nicolas
^ permalink raw reply
* Re: RAM consumption when working with the gcc repo
From: Jon Smirl @ 2007-12-07 21:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: david, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712071529580.555@xanadu.home>
On 12/7/07, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 7 Dec 2007, david@lang.hm wrote:
>
> > On Fri, 7 Dec 2007, Jon Smirl wrote:
> >
> > > I noticed two things when doing a repack of the gcc repo. First is
> > > that the git process is getting to be way too big. Turning off the
> > > delta caches had minimal impact. Why does the process still grow to
> > > 4.8GB?
> > >
> > > Putting this in perspective, this is a 4.8GB process constructing a
> > > 330MB file. Something isn't right. Memory leak or inefficient data
> > > structure?
> >
> > keep in mind that that 330MB file is _very_ heavily compressed. the simple
> > zlib compression is probably getting you 10:1 or 20:1 compression and the
> > delta compression is a significant multiplier on top of that.
>
> Doesn't matter. Something is indeed fishy.
>
> The bulk of pack-objects memory consumption can be estimated as follows:
>
> 1M objects * sizeof(struct object_entry) ~= 100MB
> 256 window entries with data (assuming a big 1MB per entry) = 256MB
> Delta result caching was disabled therefore 0MB
> read-side delta cache limited to 16MB
>
> So the purely ram allocation might get to roughly 400MB.
>
> Then add the pack and index map, which, depending on the original pack
> size,
> might be 2GB.
I'm repacking the heavily compress pack, so input pack and index are
about 360MB, not 2GB.
>
> So we're pessimistically talking of about 2.5GB of virtual space.
>
> The other 2.3GB is hard to explain.
More like 3.5MB that is hard to explain.
Is there a simple way to tell what percent is mmap vs anon allocation?
>
>
> Nicolas
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [RFC/PATCH] Add a --nosort option to pack-objects
From: Mike Hommey @ 2007-12-07 21:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
While most of the time the heuristics used by pack-objects to sort the
given object list are satisfying enough, there are cases where it can be
useful for the user to sort the list with heuristics that would be better
suited.
The --nosort option disabled the internal sorting used by pack-objects,
and runs the sliding window along the object list litterally as given on
stdin.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
I would obviously add the appropriate documentation for this flag if this
is accepted. I'll also try to send another documentation patch for
pack-objects with some information compiled from Linus's explanation to my
last message about pack-objects.
builtin-pack-objects.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 4f44658..8bc2d5f 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -21,7 +21,7 @@
static const char pack_usage[] = "\
git-pack-objects [{ -q | --progress | --all-progress }] \n\
- [--max-pack-size=N] [--local] [--incremental] \n\
+ [--max-pack-size=N] [--local] [--incremental] [--nosort]\n\
[--window=N] [--window-memory=N] [--depth=N] \n\
[--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n\
[--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n\
@@ -64,6 +64,7 @@ static int non_empty;
static int no_reuse_delta, no_reuse_object, keep_unreachable;
static int local;
static int incremental;
+static int nosort;
static int allow_ofs_delta;
static const char *base_name;
static int progress = 1;
@@ -1715,7 +1716,9 @@ static void prepare_pack(int window, int depth)
if (progress)
progress_state = start_progress("Compressing objects",
nr_deltas);
- qsort(delta_list, n, sizeof(*delta_list), type_size_sort);
+ if (! nosort)
+ qsort(delta_list, n, sizeof(*delta_list),
+ type_size_sort);
ll_find_deltas(delta_list, n, window+1, depth, &nr_done);
stop_progress(&progress_state);
if (nr_done != nr_deltas)
@@ -1988,6 +1991,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
incremental = 1;
continue;
}
+ if (!strcmp("--nosort", arg)) {
+ nosort = 1;
+ continue;
+ }
if (!prefixcmp(arg, "--compression=")) {
char *end;
int level = strtoul(arg+14, &end, 0);
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] quote_path: convert empty path to "./"
From: Jeff King @ 2007-12-07 20:49 UTC (permalink / raw)
To: Thomas Harning; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <4759996B.2000300@gmail.com>
On Fri, Dec 07, 2007 at 02:05:15PM -0500, Thomas Harning wrote:
> I concur. There is one case that this seems to dodge. What about the case
> where you are in:
>
> /test/test_2 where /test is not tracked...
>
> This should probably show "./../" not just "./" , right?
It already says "../", which is correct:
$ git init
$ mkdir test && cd test
$ touch file
$ mkdir test2 && cd test2
$ git status
...
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ../
There's no point in ever saying "./" _except_ in the case where the
output would be totally blank, since there is no way to tell that it is
an output line.
Personally, I don't like either the "../" or the "./", but I actually
think the relative paths are less readable than the full paths in
general.
-Peff
^ permalink raw reply
* Re: RAM consumption when working with the gcc repo
From: Nicolas Pitre @ 2007-12-07 20:46 UTC (permalink / raw)
To: david; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712071323260.12607@asgard.lang.hm>
On Fri, 7 Dec 2007, david@lang.hm wrote:
> On Fri, 7 Dec 2007, Jon Smirl wrote:
>
> > I noticed two things when doing a repack of the gcc repo. First is
> > that the git process is getting to be way too big. Turning off the
> > delta caches had minimal impact. Why does the process still grow to
> > 4.8GB?
> >
> > Putting this in perspective, this is a 4.8GB process constructing a
> > 330MB file. Something isn't right. Memory leak or inefficient data
> > structure?
>
> keep in mind that that 330MB file is _very_ heavily compressed. the simple
> zlib compression is probably getting you 10:1 or 20:1 compression and the
> delta compression is a significant multiplier on top of that.
Doesn't matter. Something is indeed fishy.
The bulk of pack-objects memory consumption can be estimated as follows:
1M objects * sizeof(struct object_entry) ~= 100MB
256 window entries with data (assuming a big 1MB per entry) = 256MB
Delta result caching was disabled therefore 0MB
read-side delta cache limited to 16MB
So the purely ram allocation might get to roughly 400MB.
Then add the pack and index map, which, depending on the original pack
size,
might be 2GB.
So we're pessimistically talking of about 2.5GB of virtual space.
The other 2.3GB is hard to explain.
Nicolas
^ permalink raw reply
* Re: RAM consumption when working with the gcc repo
From: Marco Costalba @ 2007-12-07 20:36 UTC (permalink / raw)
To: david; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712071323260.12607@asgard.lang.hm>
On Dec 7, 2007 10:24 PM, <david@lang.hm> wrote:
> On Fri, 7 Dec 2007, Jon Smirl wrote:
>
> keep in mind that that 330MB file is _very_ heavily compressed. the simple
> zlib compression is probably getting you 10:1 or 20:1 compression and the
> delta compression is a significant multiplier on top of that.
>
If the delta is good the zlib is poor and the contrary stands too.
It is very difficult to _guess_ in this cases.
Marco
^ permalink raw reply
* Re: Git and GCC
From: Giovanni Bajo @ 2007-12-07 20:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, jonsmirl, peff, nico, dberlin, harvey.harrison,
ismail, gcc, git
In-Reply-To: <alpine.LFD.0.9999.0712070919590.7274@woody.linux-foundation.org>
On 12/7/2007 6:23 PM, Linus Torvalds wrote:
>> Is SHA a significant portion of the compute during these repacks?
>> I should run oprofile...
>
> SHA1 is almost totally insignificant on x86. It hardly shows up. But we
> have a good optimized version there.
>
> zlib tends to be a lot more noticeable (especially the uncompression: it
> may be faster than compression, but it's done _so_ much more that it
> totally dominates).
Have you considered alternatives, like:
http://www.oberhumer.com/opensource/ucl/
--
Giovanni Bajo
^ permalink raw reply
* Re: RAM consumption when working with the gcc repo
From: david @ 2007-12-07 21:24 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910712071207p750c14f4h7abc5d637da3a478@mail.gmail.com>
On Fri, 7 Dec 2007, Jon Smirl wrote:
> I noticed two things when doing a repack of the gcc repo. First is
> that the git process is getting to be way too big. Turning off the
> delta caches had minimal impact. Why does the process still grow to
> 4.8GB?
>
> Putting this in perspective, this is a 4.8GB process constructing a
> 330MB file. Something isn't right. Memory leak or inefficient data
> structure?
keep in mind that that 330MB file is _very_ heavily compressed. the simple
zlib compression is probably getting you 10:1 or 20:1 compression and the
delta compression is a significant multiplier on top of that.
David Lang
> The second issue is that the repack process slows way down on the last
> 10% of the packing process. I don't believe this was caused by
> swapping since my disk light wasn't on. It takes a long to do the last
> 10% as it did for the first 70%. This seems to be correlated with the
> size of the process getting so large.
>
>
^ permalink raw reply
* Re: git guidance
From: david @ 2007-12-07 21:17 UTC (permalink / raw)
To: Al Boldi
Cc: Andreas Ericsson, Johannes Schindelin, Phillip Susi,
Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <200712071353.11654.a1426z@gawab.com>
On Fri, 7 Dec 2007, Al Boldi wrote:
> Andreas Ericsson wrote:
>> So, to get to the bottom of this, which of the following workflows is it
>> you want git to support?
>>
>> ### WORKFLOW A ###
>> edit, edit, edit
>> edit, edit, edit
>> edit, edit, edit
>> Oops I made a mistake and need to hop back to "current - 12".
>> edit, edit, edit
>> edit, edit, edit
>> publish everything, similar to just tarring up your workdir and sending
>> out ### END WORKFLOW A ###
>>
>> ### WORKFLOW B ###
>> edit, edit, edit
>> ok this looks good, I want to save a checkpoint here
>> edit, edit, edit
>> looks good again. next checkpoint
>> edit, edit, edit
>> oh crap, back to checkpoint 2
>> edit, edit, edit
>> ooh, that's better. save a checkpoint and publish those checkpoints
>> ### END WORKFLOW B ###
>
> ### WORKFLOW C ###
> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or
> publish (should be adjustable), on its privately created on-the-fly
> repository.
> ### END WORKFLOW C ###
>
> For example:
>
> echo "// last comment on this file" >> /gitfs.mounted/file
>
> should do an implied checkpoint, and make these checkpoints immediately
> visible under some checkpoint branch of the gitfs mounted dir.
>
> Note, this way the developer gets version control without even noticing, and
> works completely transparent to any kind of application.
so if you have a script that does
echo "mail header" >tmpfile
echo "subject: >>tmpfile
echo >>tmpfile
echo "body" >>tmpfile
you want to have four seperate commits
what if you have a perl script
open outfile ">tmpfile";
print outfile "mail header\n";
print outfile "subject:\n\n";
print outfile "body\n";
close ourfile;
how many seperate commits do you think should take place?
what if $|=1 (unbuffered output, so that each print statement becomes
visable to other programs immediatly)?
what if the file is changed via mmap? should each byte/word written to
memory be a commit? or when the mmap is closed? or when the kernel happens
to flush the page to disk?
'recording every change to a filesystem' is a very incomplete definition
of a goal.
David Lang
^ permalink raw reply
* RAM consumption when working with the gcc repo
From: Jon Smirl @ 2007-12-07 20:07 UTC (permalink / raw)
To: Git Mailing List
I noticed two things when doing a repack of the gcc repo. First is
that the git process is getting to be way too big. Turning off the
delta caches had minimal impact. Why does the process still grow to
4.8GB?
Putting this in perspective, this is a 4.8GB process constructing a
330MB file. Something isn't right. Memory leak or inefficient data
structure?
The second issue is that the repack process slows way down on the last
10% of the packing process. I don't believe this was caused by
swapping since my disk light wasn't on. It takes a long to do the last
10% as it did for the first 70%. This seems to be correlated with the
size of the process getting so large.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Ingo Molnar @ 2007-12-07 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmysm1eyz.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > ... One small detail though: i frequently ssh to testboxes that have
> > DISPLAY set but i want text output. So git-bisect view --text should be
> > a special-case perhaps?
>
> Yeah, but at that point, wouldn't "git bisect view log" be shorter to
> type?
it's also more intuitive. ok :-)
Ingo
^ permalink raw reply
* Re: git guidance
From: Valdis.Kletnieks @ 2007-12-07 19:36 UTC (permalink / raw)
To: Al Boldi
Cc: Jakub Narebski, Andreas Ericsson, Johannes Schindelin,
Phillip Susi, Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <200712072204.48410.a1426z@gawab.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
> Because WORKFLOW C is transparent, it won't affect other workflows. So you
> could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an
> additional level of version control detail at no extra cost other than the
> git-engine scratch repository overhead.
>
> BTW, is git efficient enough to handle WORKFLOW C?
Imagine the number of commits a 'make clean; make' will do in a kernel tree, as
it commits all those .o files... :)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: Git and GCC
From: Nicolas Pitre @ 2007-12-07 19:36 UTC (permalink / raw)
To: Jon Smirl
Cc: Linus Torvalds, Harvey Harrison, Daniel Berlin, David Miller,
ismail, gcc, git
In-Reply-To: <9e4733910712062308t22258c6anb685b18a663e0a31@mail.gmail.com>
On Fri, 7 Dec 2007, Jon Smirl wrote:
> On 12/7/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >
> > On Thu, 6 Dec 2007, Jon Smirl wrote:
> > > >
> > > > time git blame -C gcc/regclass.c > /dev/null
> > >
> > > jonsmirl@terra:/video/gcc$ time git blame -C gcc/regclass.c > /dev/null
> > >
> > > real 1m21.967s
> > > user 1m21.329s
> >
> > Well, I was also hoping for a "compared to not-so-aggressive packing"
> > number on the same machine.. IOW, what I was wondering is whether there is
> > a visible performance downside to the deeper delta chains in the 300MB
> > pack vs the (less aggressive) 500MB pack.
>
> Same machine with a default pack
>
> jonsmirl@terra:/video/gcc/.git/objects/pack$ ls -l
> total 2145716
> -r--r--r-- 1 jonsmirl jonsmirl 23667932 2007-12-07 02:03
> pack-bd163555ea9240a7fdd07d2708a293872665f48b.idx
> -r--r--r-- 1 jonsmirl jonsmirl 2171385413 2007-12-07 02:03
> pack-bd163555ea9240a7fdd07d2708a293872665f48b.pack
> jonsmirl@terra:/video/gcc/.git/objects/pack$
>
> Delta lengths have virtually no impact.
I can confirm this.
I just did a repack keeping the default depth of 50 but with window=100
instead of the default of 10, and the pack shrunk from 2171385413 bytes
down to 410607140 bytes.
So our default window size is definitely not adequate for the gcc repo.
OTOH, I recall tytso mentioning something about not having much return
on a bigger window size in his tests when he proposed to increase the
default delta depth to 50. So there is definitely some kind of threshold
at which point the increased window size stops being advantageous wrt
the number of cycles involved, and we should find a way to correlate it
to the data set to have a better default window size than the current
fixed default.
Nicolas
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-12-07 19:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3tzmuu57k.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> [On hold]
>>
>> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>> - Move all dashed-form commands to libexecdir
>>
>> I think this is a sane thing to do in the longer term. Will be in
>> 'next' after v1.5.4. I think "leave porcelain on PATH" might be also a
>> good thing as a transition measure.
>
> We would have to change the paragraph in INSTALL about git wrapper
> (which would be no longer optional, or at least no longer optional in
> the sense that you can just delete/not install this file), and its
> conflict with (old) GNU Interactive Tools (the other 'git').
Thanks for noticing. Please send in a proposed patch to do so; then
we can park it near the tip of this topic, and nobody will forget.
>> [Stalled]
>>
>> * ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
>> - git-checkout --push/--pop
>>
>> A reasonably cleanly written cute hack, and I do not see this breaking
>> the normal codepath, so I do not mind merging this as long as people
>> find it useful.
>
> That would be nice to have, although as somebody[*1*] said, you usualy
> know that you should have pushed branch into stack when you want to
> 'pop'. So it would be nice to have (if possible and easy to implement)
> also "git checkout --previous" or "git checkout -".
> ...
Perhaps. There are a few issues, though.
* When you were on 'master' and say "co -", you would want to come back
to the 'master' branch, whose tip may have advanced since you
switched away from (e.g. "git push . experiment:master"), and that is
a desired behaviour. When you switch away from a detached HEAD, what
would we record? The fact the head was detached and its commit, so
next "co -" would come back to that exact commit in a detached state?
Or "co -" is meant to say "I was distracted and was away but now
let's go back to my normal working state" and should refrain from
touching the previous branch information? I tend to think it would
be the latter.
* There are a few commands that are not "git checkout" but still
switches branches ("rebase that branch on this one" form of rebase
and "bisect"). Personally, I think bisect should stop using the
branch 'bisect' but instead work on detached HEAD in the longer run,
but what would we do about "rebase"?
> [*1*] I'm sorry for no attribution
I think this was Matthieu Moy, <vpqir3de8t6.fsf@bauges.imag.fr>,
http://article.gmane.org/gmane.comp.version-control.git/67133
>> * jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
>> . pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
>
> What is the status of this thingy, by the way?
As the topic group header says, it is [Stalled].
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Junio C Hamano @ 2007-12-07 19:28 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20071207112159.GA11035@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> ... One small detail though: i frequently ssh to testboxes that have
> DISPLAY set but i want text output. So git-bisect view --text should be
> a special-case perhaps?
Yeah, but at that point, wouldn't "git bisect view log" be shorter to
type?
^ permalink raw reply
* Re: [PATCH] Let git-help prefer man-pages installed with this version of git
From: Junio C Hamano @ 2007-12-07 19:29 UTC (permalink / raw)
To: Sergei Organov; +Cc: Johannes Schindelin, git, Christian Couder
In-Reply-To: <871w9y7mei.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> First, I don't think you need to clarify like this. It is just
> implementation detail of git-help that it uses 'man', and thus
> implicitly relies on MANPATH. The essential thing has been already
> stated above: git-help should show correct documentation.
Ok, this is a good argument for the patch. With Christian's
enhancements, we will handle -i(nfo) and -w(eb) and we will tell the
"info" and "html" browsers where the documentation we installed for the
running instance of git is, so we should do so consistently for
"manpage" browser (aka "man"). You are right.
^ permalink raw reply
* Re: Some git performance measurements..
From: Mike Ralphson @ 2007-12-07 19:15 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Junio C Hamano, Nicolas Pitre, Linus Torvalds,
Jakub Narebski, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712071816100.27959@racer.site>
On Dec 7, 2007 6:37 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 7 Dec 2007, Mike Ralphson wrote:
>
> > On Dec 7, 2007 1:49 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > On Fri, 7 Dec 2007, Mike Ralphson wrote:
> > >
> > > > I benchmarked 3 alternative qsorts, qsortG [2] was the fastest on my
> > > > system but has funky licensing, the NetBSD qsort was middle-range
> > > > and the glibc one the slowest of the three (but that could be due to
> > > > it being tuned for a "Sun 4/260"). All of them show over 100x speed
> > > > improvements on a git-status of my main repo (104s -> ~0.7s)
> > >
>
> Okay, sorry, I did not bother reading further when I read "You may use it
> in anything you like;".
>
> But if the author did not respond, it might be a better idea to just
> reimplement it.
>
I've just tried the mergesort implementation as used in msysgit and
that performs faster for me. It's simpler, and compatibly licensed. It
looks good.
Mike
^ permalink raw reply
* Re: [PATCH] quote_path: convert empty path to "./"
From: Thomas Harning @ 2007-12-07 19:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0712071853500.27959@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 7 Dec 2007, Jeff King wrote:
>
>> ...
>>
>
> Sounds reasonable.
>
> Ciao,
> Dscho
I concur. There is one case that this seems to dodge. What about the
case where you are in:
/test/test_2 where /test is not tracked...
This should probably show "./../" not just "./" , right?
^ permalink raw reply
* Re: git guidance
From: Al Boldi @ 2007-12-07 19:04 UTC (permalink / raw)
To: Jakub Narebski
Cc: Andreas Ericsson, Johannes Schindelin, Phillip Susi,
Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <m3prxiu3oo.fsf@roke.D-201>
Jakub Narebski wrote:
> Al Boldi <a1426z@gawab.com> writes:
> > For example:
> >
> > echo "// last comment on this file" >> /gitfs.mounted/file
> >
> > should do an implied checkpoint, and make these checkpoints immediately
> > visible under some checkpoint branch of the gitfs mounted dir.
> >
> > Note, this way the developer gets version control without even noticing,
> > and works completely transparent to any kind of application.
>
> Why not use versioning filesystem for that, for example ext3cow
> (which looks suprisingly git-like, when you take into account that
> for ext3cow history is linear and centralized, so one can use date
> or sequential number to name commits).
>
> See GitLinks page on Git Wiki, "Other links" section:
> http://www.ext3cow.com/
Sure, Linus mentioned the cow idea before in this thread, but you would still
need a few hacks to get some basic Version Control features.
> Version control system is all about WORKFLOW B, where programmer
> controls when it is time to commit (and in private repository he/she
> can then rewrite history to arrive at "Perfect patch series"[*1*]);
> something that for example CVS failed at, requiring programmer to do
> a merge if upstream has any changes when trying to commit.
Because WORKFLOW C is transparent, it won't affect other workflows. So you
could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an
additional level of version control detail at no extra cost other than the
git-engine scratch repository overhead.
BTW, is git efficient enough to handle WORKFLOW C?
Thanks!
--
Al
^ permalink raw reply
* Re: [PATCH] quote_path: convert empty path to "./"
From: Johannes Schindelin @ 2007-12-07 18:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071207165703.GA8889@sigill.intra.peff.net>
Hi,
On Fri, 7 Dec 2007, Jeff King wrote:
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # subdir/
>
> So far, so good.
>
> $ cd subdir
> $ git status
> ....
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> #
>
> Oops, that's a bit confusing.
>
> This patch prints './' to show that there is some output.
Sounds reasonable.
Ciao,
Dscho
^ permalink raw reply
* Re: Some git performance measurements..
From: Johannes Schindelin @ 2007-12-07 18:37 UTC (permalink / raw)
To: Mike Ralphson
Cc: Steffen Prohaska, Junio C Hamano, Nicolas Pitre, Linus Torvalds,
Jakub Narebski, Git Mailing List
In-Reply-To: <e2b179460712070809r4127dc0br8dc20f55b1076501@mail.gmail.com>
Hi,
On Fri, 7 Dec 2007, Mike Ralphson wrote:
> On Dec 7, 2007 1:49 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 7 Dec 2007, Mike Ralphson wrote:
> >
> > > I benchmarked 3 alternative qsorts, qsortG [2] was the fastest on my
> > > system but has funky licensing, the NetBSD qsort was middle-range
> > > and the glibc one the slowest of the three (but that could be due to
> > > it being tuned for a "Sun 4/260"). All of them show over 100x speed
> > > improvements on a git-status of my main repo (104s -> ~0.7s)
> >
> > How is "You may use it in anything you like;" funky licensing? It is
> > effectively public domain.
>
> I did ask what the git licensing policy was (GPL2 or GPL2-compatible)
> but got no response. The author's wishes state:
>
> * This code may be reproduced freely provided
> [long list]
Okay, sorry, I did not bother reading further when I read "You may use it
in anything you like;".
But if the author did not respond, it might be a better idea to just
reimplement it.
Ciao,
Dscho
^ permalink raw reply
* Re: Not a valid object name refs/heads/t20050127-arm during git-cvsimport
From: Michael Haggerty @ 2007-12-07 17:48 UTC (permalink / raw)
To: git; +Cc: Baurzhan Ismagulov
In-Reply-To: <m38x4auyga.fsf@roke.D-201>
Jakub Narebski wrote:
> Baurzhan Ismagulov <ibr@radix50.net> writes:
>
>> I want to import a CVS repo myrepo into git. I copied CVSHEAD and myrepo
>> dirs from the cvs server to /home/ibr/tmp and issued the following
>> command:
>>
>> git-cvsimport -p x -k -o cvshead -d/home/ibr/tmp -C zzz myrepo/drv
>>
>> It fails [...]
>
> You can try to use other CVS importers, for example parsecvs [...]
Or cvs2svn, which can now also output to git. See these threads for
more info:
http://marc.info/?l=git&m=118592701426175&w=4
http://cvs2svn.tigris.org/servlets/BrowseList?list=users&by=thread&from=624393
Michael
^ permalink raw reply
* Re: Git and GCC
From: Linus Torvalds @ 2007-12-07 17:23 UTC (permalink / raw)
To: David Miller
Cc: jonsmirl, peff, nico, dberlin, harvey.harrison, ismail, gcc, git
In-Reply-To: <20071207.045329.204650714.davem@davemloft.net>
On Fri, 7 Dec 2007, David Miller wrote:
>
> Also I could end up being performance limited by SHA, it's not very
> well tuned on Sparc. It's been on my TODO list to code up the crypto
> unit support for Niagara-2 in the kernel, then work with Herbert Xu on
> the userland interfaces to take advantage of that in things like
> libssl. Even a better C/asm version would probably improve GIT
> performance a bit.
I doubt yu can use the hardware support. Kernel-only hw support is
inherently broken for any sane user-space usage, the setup costs are just
way way too high. To be useful, crypto engines need to support direct user
space access (ie a regular instruction, with all state being held in
normal registers that get saved/restored by the kernel).
> Is SHA a significant portion of the compute during these repacks?
> I should run oprofile...
SHA1 is almost totally insignificant on x86. It hardly shows up. But we
have a good optimized version there.
zlib tends to be a lot more noticeable (especially the uncompression: it
may be faster than compression, but it's done _so_ much more that it
totally dominates).
Linus
^ permalink raw reply
* [PATCH] quote_path: convert empty path to "./"
From: Jeff King @ 2007-12-07 16:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
Now that we are correctly removing leading prefixes from files in git
status, there is a degenerate case: the directory matching the prefix.
Because we show only the directory name for a directory that contains
only untracked files, it gets collapsed to an empty string.
Example:
$ git init
$ mkdir subdir
$ touch subdir/file
$ git status
...
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# subdir/
So far, so good.
$ cd subdir
$ git status
....
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#
Oops, that's a bit confusing.
This patch prints './' to show that there is some output.
---
I think it looks a bit ugly because it is so small (though just '.' was
even worse). But I don't see what else would make sense.
wt-status.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 02dbb75..31d83bf 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -121,6 +121,9 @@ static char *quote_path(const char *in, int len,
}
}
+ if (!out->len)
+ strbuf_addstr(out, "./");
+
return out->buf;
}
--
1.5.3.7.2156.g3d791-dirty
^ permalink raw reply related
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