* [PATCH] commit-tree: disallow an empty single-parent commit.
From: Junio C Hamano @ 2006-02-24 12:20 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <7vy8019d44.fsf@assigned-by-dhcp.cox.net>
Allow "git-commit-tree v2.6.15^{tree} -p HEAD", instead of
requiring "git-commit-tree `git rev-parse v2.6.15^{tree}` -p
HEAD". The parent parameter that follows -p uses get_sha1() to
understand the extended notation, and there is little reason not
to allow it for the tree object name parameter.
Also make the check_valid() function simpler. This function
which predates sha1_object_info() so it had to do things by hand
but there is no reason to read the data just to discard anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Replacement patch. Very lightly tested.
commit-tree.c | 27 ++++++++++++++++++++-------
1 files changed, 20 insertions(+), 7 deletions(-)
8f97300b2580b43905ce11eef21e77c5e8e809a6
diff --git a/commit-tree.c b/commit-tree.c
index 88871b0..b1d816c 100644
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -43,14 +43,11 @@ static void add_buffer(char **bufp, unsi
static void check_valid(unsigned char *sha1, const char *expect)
{
- void *buf;
char type[20];
- unsigned long size;
- buf = read_sha1_file(sha1, type, &size);
- if (!buf || strcmp(type, expect))
- die("%s is not a valid '%s' object", sha1_to_hex(sha1), expect);
- free(buf);
+ if (sha1_object_info(sha1, type, NULL) || strcmp(type, expect))
+ die("%s is not a valid '%s' object",
+ sha1_to_hex(sha1), expect);
}
/*
@@ -75,6 +72,19 @@ static int new_parent(int idx)
return 1;
}
+static int check_empty_commit(const unsigned char *tree_sha1,
+ const unsigned char *parent_sha1)
+{
+ unsigned char sha1[20];
+ char refit[50];
+ sprintf(refit, "%s^{tree}", sha1_to_hex(parent_sha1));
+ if (get_sha1(refit, sha1))
+ die("cannot determine tree in parent commit.");
+ if (!memcmp(sha1, tree_sha1, 20))
+ return error ("empty commit? aborting.");
+ return 0;
+}
+
int main(int argc, char **argv)
{
int i;
@@ -90,7 +100,7 @@ int main(int argc, char **argv)
git_config(git_default_config);
- if (argc < 2 || get_sha1_hex(argv[1], tree_sha1) < 0)
+ if (argc < 2 || get_sha1(argv[1], tree_sha1) < 0)
usage(commit_tree_usage);
check_valid(tree_sha1, "tree");
@@ -105,6 +115,9 @@ int main(int argc, char **argv)
}
if (!parents)
fprintf(stderr, "Committing initial tree %s\n", argv[1]);
+ if (parents == 1)
+ if (check_empty_commit(tree_sha1, parent_sha1[0]))
+ exit(1);
init_buffer(&buffer, &size);
add_buffer(&buffer, &size, "tree %s\n", sha1_to_hex(tree_sha1));
--
1.2.3.g7465
^ permalink raw reply related
* Re: [PATCH] commit-tree: disallow an empty single-parent commit.
From: Eric W. Biederman @ 2006-02-24 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric W. Biederman, git
In-Reply-To: <7vslq99cd5.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Allow "git-commit-tree v2.6.15^{tree} -p HEAD", instead of
> requiring "git-commit-tree `git rev-parse v2.6.15^{tree}` -p
> HEAD". The parent parameter that follows -p uses get_sha1() to
> understand the extended notation, and there is little reason not
> to allow it for the tree object name parameter.
>
> Also make the check_valid() function simpler. This function
> which predates sha1_object_info() so it had to do things by hand
> but there is no reason to read the data just to discard anymore.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Looks good to me. The logic at least looks complete.
Eric
^ permalink raw reply
* Re: FYI: git-am allows creation of empty commits.
From: Eric Wong @ 2006-02-24 13:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric W. Biederman, git, Martin Langhoff, Matthias Urlichs
In-Reply-To: <7vy8019d44.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> > Is this something that we always want to test for in the porcelain
> > or do we want to move a check into git-commit-tree?
> >
> > For getting a reasonable error message where you have the test
> > seems to be the only sane place, but having the check deeper
> > down would be more likely to catch this kind of thing.
>
> I think 99.9% of the time it is a mistake if a single-parented
> commit has the same tree as its parent commit has, so having a
> check in commit-tree may not be a bad idea.
This would break importers, more than 0.1% I think... Arch definitely allows
empty commits for getting log messages in. SVN forbids them from their POV, but
they also have things that we can't see when we import (properties like: mime,
externals, eol-style) causing us to write the same tree twice. Not sure about
CVS...
Maybe a flag such as --force could be added.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-rm: Fix to properly handle files with spaces, tabs, newlines, etc.
From: Alex Riesen @ 2006-02-24 13:23 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Krzysiek Pawlik, git
In-Reply-To: <8764n7rl6s.wl%cworth@cworth.org>
On 2/23/06, Carl Worth <cworth@cworth.org> wrote:
> +# Setup some files to be removed, some with funny characters
> +touch -- foo bar baz 'space embedded' 'tab embedded' 'newline
> +embedded' -q
> +git-add -- foo bar baz 'space embedded' 'tab embedded' 'newline
> +embedded' -q
> +git-commit -m "add files"
This doesn't work on some exotic filesystems (ntfs and fat):
*** t3600-rm.sh ***
touch: cannot touch `tab\tembedded': No such file or directory
touch: cannot touch `newline\nembedded': No such file or directory
error: pathspec 'tab embedded' did not match any.
error: pathspec 'newline
embedded' did not match any.
Maybe you misspelled it?
Nothing to commit
* FAIL 1: Pre-check that foo exists and is in index before git-rm foo
[ -f foo ] && git-ls-files --error-unmatch foo
* FAIL 2: Test that git-rm foo succeeds
git-rm foo
* FAIL 4: Pre-check that bar exists and is in index before "git-rm -f bar"
[ -f bar ] && git-ls-files --error-unmatch bar
* FAIL 5: Test that "git-rm -f bar" succeeds
git-rm -f bar
* FAIL 6: Post-check that bar does not exist and is not in index after
"git-rm -f bar"
! [ -f bar ] && ! git-ls-files --error-unmatch bar
* FAIL 7: Test that "git-rm -- -q" succeeds (remove a file that looks
like an option)
git-rm -- -q
* FAIL 8: Test that "git-rm -f" succeeds with embedded space, tab, or
newline characters.
git-rm -f 'space embedded' 'tab embedded' 'newline
embedded'
* FAIL 10: When the rm in "git-rm -f" fails, it should not remove the
file from the index
git-ls-files --error-unmatch baz
* failed 8 among 10 test(s)
^ permalink raw reply
* Re: [PATCH] Convert open("-|") to qx{} calls
From: Alex Riesen @ 2006-02-24 13:27 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <43FE9771.4030206@dawes.za.net>
On 2/24/06, Rogan Dawes <discard@dawes.za.net> wrote:
> Alex Riesen wrote:
> > Randal L. Schwartz, Thu, Feb 23, 2006 21:41:44 +0100:
> >> Johannes> Now that our local Perl guru joined the discussion, may I ask what
> >> Johannes> is, and what is not quoted when put inside qx{}?
> >>
> >> Nothing is quoted. Your string acts as if it was XXX in:
> >>
> >> sh -c 'XXX'
> >>
> >
> > Not so for ActiveState. It'll just run the first non-whitespace word
> > passing the rest of the line in its command-line.
> > It's not even worse then to pass it all to cmd/command :)
> >
>
> Not true.
>
> > type t
> #!perl -w
>
> print qx{echo joe & echo joe}."\n";
> > perl t
> joe
> joe
>
Does not seem to be the case here (and yes, I check build 815 too):
$ perl -v
This is perl, v5.8.6 built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)
Copyright 1987-2004, Larry Wall
Binary build 811 provided by ActiveState Corp. http://www.ActiveState.com
ActiveState is a division of Sophos.
Built Dec 13 2004 09:52:01
...
$ perl -e 'print qx{echo joe & echo joe}."\n";'
joe & echo joe
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Johannes Schindelin @ 2006-02-24 13:44 UTC (permalink / raw)
To: Eric Wong; +Cc: Alex Riesen, Sam Vilain, Junio C Hamano, git
In-Reply-To: <20060224120225.GE12309@localdomain>
Hi,
On Fri, 24 Feb 2006, Eric Wong wrote:
> Writing and reading from a tempfile are very fast for me in Linux, and
> probably not much slower than pipes.
Sorry, but no. Really no. Pipes have several advantages over temporary
files:
- The second program can already work on the data before the first
finishes.
- Most simple temp file handling has security issues.
- You need write access.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] New git-seek command with documentation and test.
From: Carl Worth @ 2006-02-24 14:23 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <43FED93D.1000601@op5.se>
[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]
On Fri, 24 Feb 2006 11:00:29 +0100, Andreas Ericsson wrote:
>
> I've said it before, and I'll say it again. This tool provides less
> flexibility and much less power than "git checkout -b branch
> <commit-ish>"
Yes, that's by design. It's not intended to be a replacement for git
checkout -b. It's intended to be easier to use than that when its
purpose fits what you want to to.
> > 1) invent a throwaway name,
>
> All programmers have at least five throwaway names that are only ever
> used as such (mine are, in order of precedence, foo, bar, tmp, fnurg,
> sdf and asd).
Sure, and when I use "git checkout -b" I have to keep trying these
linearly until I found one that is available. That's what I've been
doing, and it's painful enough that I wrote this. (Though yes,
something like checkout -o would help here).
> > 2) remember the branch I started on,
>
> With topic branches, you need to pick more careful topic names. Without
> topic branches you're always on "master". Surely you know what the
> patches touch, so you know what branch they should be in.
I almost put "remember" in quotation marks. Obviously I know what I'm
working on. It's more a matter of just having to type the name, (I do
use very careful topic names so they tend to be longish). Having
tab-completion for git-checkout would help here.
So (1) and (2) have potential workarounds, but neither exists, and
even then they would still be harder to use than git-seek.
> > 3) remember to actually throwaway the temporary branch.
>
> This isn't always a bad thing, since you after applying some patch or
> other decide you want to go back to this point in history,
That assumes that I've made any change though. If you're going back in
the past to make changes, then "git checkout -b" is the right thing to
use. It's when you're not planning to make changes, but just exploring
the past that "git seek" is helpful.
So (3) is just extra pain when using git-seek for what its designed to
be good for, (exploring history when not planning on writing to it).
But note that the git-seek I've implemented *does* provide a writable
branch, so if you discover that you do want to commit something, then
that's always available. Linus gave compelling arguments for this.
> In that case, you need to remember to add the
> branch/tag/whatever to where you seeked rather than just go on with the
> work. Removing a branch later is simple. Finding the right spot to
> create it later can be trouble-some.
Yes. And that's why git-seek stops and warns you before it leaves
dangling commits by moving the branch. (Though it might make sense to
add a -f option to force it to seek regardless of the things it
currently balks at.)
> If I had a vote, I'd say no to this patch, and to this tool entirely.
One argument in favor is that seeking already exists in git privately
within git-bisect. Exposing git-seek makes it easier to code new
operations along the lines of git-bisect. It's certainly consistent
with git's current implementation strategy to have the more primitive
pieces of complex operations exported and available.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Convert open("-|") to qx{} calls
From: Rogan Dawes @ 2006-02-24 14:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <81b0412b0602240527v5d617111sc33e627ff3e1641c@mail.gmail.com>
Alex Riesen wrote:
> On 2/24/06, Rogan Dawes <discard@dawes.za.net> wrote:
> > Not true.
>>
>> > type t
>> #!perl -w
>>
>> print qx{echo joe & echo joe}."\n";
>> > perl t
>> joe
>> joe
>>
>
> Does not seem to be the case here (and yes, I check build 815 too):
>
> $ perl -v
>
> This is perl, v5.8.6 built for MSWin32-x86-multi-thread
> (with 3 registered patches, see perl -V for more detail)
>
> Copyright 1987-2004, Larry Wall
>
> Binary build 811 provided by ActiveState Corp. http://www.ActiveState.com
> ActiveState is a division of Sophos.
> Built Dec 13 2004 09:52:01
> ...
>
> $ perl -e 'print qx{echo joe & echo joe}."\n";'
> joe & echo joe
Interesting. I tried to do that one-liner at a DOS prompt (not cygwin,
which I assume you are using), and I was unable to do so. CMD was seeing
the "&" first, and splitting the command in 2, namely
perl -e 'print qx joe
and
echo joe}."\n";'
which obviously didn't work.
Do you get the same results if you run it from a DOS prompt? and via a file?
Rogan
^ permalink raw reply
* git-annotate
From: Morten Welinder @ 2006-02-24 15:21 UTC (permalink / raw)
To: GIT Mailing List
git-annotate ought to call usage() if it doesn't get its file.
M.
> git annotate
Use of uninitialized value in open at
/scratch/welinder/git/git-annotate line 40.
Failed to open filename: No such file or directory at
/scratch/welinder/git/git-annotate line 40.
^ permalink raw reply
* Re: [PATCH] Convert open("-|") to qx{} calls
From: Alex Riesen @ 2006-02-24 15:25 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <43FF185C.1080909@dawes.za.net>
On 2/24/06, Rogan Dawes <discard@dawes.za.net> wrote:
> Interesting. I tried to do that one-liner at a DOS prompt (not cygwin,
> which I assume you are using), and I was unable to do so.
Yes, it was from cygwin's bash.
> Do you get the same results if you run it from a DOS prompt? and via a file?
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\>perl -e 'print qx{echo joe & echo joe}'
Can't find string terminator "'" anywhere before EOF at -e line 1.
joe}'
C:\>perl -e "print qx{echo joe & echo joe}"
joe & echo joe
C:\>perl x.pl
joe & echo joe
C:\>
^ permalink raw reply
* git-annotate efficiency
From: Morten Welinder @ 2006-02-24 15:37 UTC (permalink / raw)
To: GIT Mailing List
So I wanted to give git-annotate a spin and typed...
git annotate Makefile
Bad idea. It's been ten minutes and no output yet. While the script only
appears to use ~20% of cpu according to top, an strace shows that it
spins off a huge number of very short-lived subprocesses.
Morten
...
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
waitpid(1539, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 1539
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
pipe([3, 4]) = 0
pipe([5, 6]) = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x401db708) = 1540
close(6) = 0
close(4) = 0
read(5, "", 4) = 0
close(5) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfffc718) = -1 EINVAL
(Invalid argument)
_llseek(3, 0, 0xbfffc760, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
read(3, "diff --git a/Makefile b/Makefile"..., 4096) = 63
read(3, "--- a/Makefile\n+++ b/Makefile\n@@"..., 4096) = 203
--- SIGCHLD (Child exited) @ 0 (0) ---
read(3, "", 4096) = 0
close(3) = 0
rt_sigaction(SIGHUP, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
...
^ permalink raw reply
* Re: [PATCH] diff-delta: produce optimal pack data
From: Nicolas Pitre @ 2006-02-24 15:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q2pf8fq.fsf@assigned-by-dhcp.cox.net>
On Fri, 24 Feb 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Indexing based on adler32 has a match precision based on the block size
> > (currently 16). Lowering the block size would produce smaller deltas
> > but the indexing memory and computing cost increases significantly.
>
> Indeed.
>
> I had this patch in my personal tree for a while. I was
> wondring why sometimes progress indication during "Deltifying"
> stage stops for literally several seconds, or more.
Note that above I'm saying that _keeping_ adler32 for small blocks is
even longer. In other words, for small blocks, the version not using
adler32 is about 3 times faster.
I also noticed the significant slowdown after I made the
improved progress patch. The idea now has to do with detecting
patological cases and breaking out of them early.
> In Linux 2.6 repository, these object pairs take forever to
> delta.
>
> blob 9af06ba723df75fed49f7ccae5b6c9c34bc5115f ->
> blob dfc9cd58dc065d17030d875d3fea6e7862ede143
> size (491102 -> 496045)
> 58 seconds
>
> blob 4917ec509720a42846d513addc11cbd25e0e3c4f ->
> blob dfc9cd58dc065d17030d875d3fea6e7862ede143
> size (495831 -> 496045)
> 64 seconds
Thanks for this. I'll see what I can do to tweak the code to better
cope with those. Just keep my fourth delta patch in the pu branch for
now.
Nicolas
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Linus Torvalds @ 2006-02-24 16:14 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Eric Wong, Alex Riesen, Sam Vilain, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0602241440330.9461@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 24 Feb 2006, Johannes Schindelin wrote:
>
> Sorry, but no. Really no. Pipes have several advantages over temporary
> files:
>
> - The second program can already work on the data before the first
> finishes.
This really is a _huge_ issue in general, although probably not a very
big one in this case.
This is what I talked about when I said "streaming" data. Look at the
difference between
git whatchanged -s drivers/usb
and
git log drivers/usb
in the kernel repo. They give almost the same output, but...
Notice how one starts _immediately_, while the other starts after a few
seconds (or, if you have a slow machine, and an unpacked archive, after
tens of seconds or longer).
And the reason is that "git log" uses "git-rev-list" with a path limiter,
and currently that ends up having to walk basically the whole history in
order to generate a minimal graph.
In contrast, "git-whatchanged" uses "git-diff-tree" to limit the output,
and git-diff-tree doesn't care about "minimal graph" or crud like that: it
just cares about discarding any local commits that aren't interesting. It
doesn't need to worry about updating parent chains etc, so it can do it
all incrementally - and can thus start output as soon as it gets anything
at all.
Now, maybe you think that "a few seconds" isn't a big deal. Sure, it's
actually fast as hell, considering what it is doing, and anybody should be
really really impressed that we can do that at all.
But (a) it _is_ a huge deal. Responsiveness is really important. And
worse: (b) it scales badly with repository size. Creating the whole
data-set before starting to output it really doesn't scale.
Now, I have ways to make "git-rev-list" better. It doesn't really need to
walk the _whole_ history for its path limiting before it can start
outputting stuff: it really _could_ do things more incrementally. However,
it's a real bitch sometimes to work with incremental data when you don't
know everything, so it gets a lot more complicated.
So my point isn't that "git log drivers/usb" will get less and less
responsive over time. I can fix that - eventually. My point is that in
order to make it more responsive, I need to make it less synchronous. More
"streaming".
And that is where a pipe is so much better than a file. It's very
fundamentally a streaming interface.
However, I suspect some of these issues are non-issues for the perl
programs that work with a few entries at a time.
Linus
^ permalink raw reply
* gitview: Code cleanup
From: Aneesh Kumar K.V @ 2006-02-24 16:19 UTC (permalink / raw)
To: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0004-gitview-Code-cleanup.txt --]
[-- Type: text/plain, Size: 3109 bytes --]
Subject: gitview: Code cleanup
Rearrange the code little bit so that it is easier to read
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 50 +++++++++++++++++++++--------------------------
1 files changed, 22 insertions(+), 28 deletions(-)
1dd075c97bae172d0c1b6f31897fec962217aab2
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 02e2445..2cde71e 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -870,21 +870,22 @@ class GitView:
# Reset nodepostion
if (last_nodepos > 5):
- last_nodepos = 0
+ last_nodepos = -1
# Add the incomplete lines of the last cell in this
try:
colour = self.colours[commit.commit_sha1]
except KeyError:
- last_colour +=1
- self.colours[commit.commit_sha1] = last_colour
- colour = last_colour
+ self.colours[commit.commit_sha1] = last_colour+1
+ last_colour = self.colours[commit.commit_sha1]
+ colour = self.colours[commit.commit_sha1]
+
try:
node_pos = self.nodepos[commit.commit_sha1]
except KeyError:
- last_nodepos +=1
- self.nodepos[commit.commit_sha1] = last_nodepos
- node_pos = last_nodepos
+ self.nodepos[commit.commit_sha1] = last_nodepos+1
+ last_nodepos = self.nodepos[commit.commit_sha1]
+ node_pos = self.nodepos[commit.commit_sha1]
#The first parent always continue on the same line
try:
@@ -895,32 +896,25 @@ class GitView:
self.nodepos[commit.parent_sha1[0]] = node_pos
for sha1 in self.incomplete_line.keys():
- if ( sha1 != commit.commit_sha1):
+ if (sha1 != commit.commit_sha1):
self.draw_incomplete_line(sha1, node_pos,
out_line, in_line, index)
else:
del self.incomplete_line[sha1]
- in_line.append((node_pos, self.nodepos[commit.parent_sha1[0]],
- self.colours[commit.parent_sha1[0]]))
-
- self.add_incomplete_line(commit.parent_sha1[0], index+1)
-
- if (len(commit.parent_sha1) > 1):
- for parent_id in commit.parent_sha1[1:]:
- try:
- tmp_node_pos = self.nodepos[parent_id]
- except KeyError:
- last_colour += 1;
- self.colours[parent_id] = last_colour
- last_nodepos +=1
- self.nodepos[parent_id] = last_nodepos
-
- in_line.append((node_pos, self.nodepos[parent_id],
- self.colours[parent_id]))
- self.add_incomplete_line(parent_id, index+1)
-
+ for parent_id in commit.parent_sha1:
+ try:
+ tmp_node_pos = self.nodepos[parent_id]
+ except KeyError:
+ self.colours[parent_id] = last_colour+1
+ last_colour = self.colours[parent_id]
+ self.nodepos[parent_id] = last_nodepos+1
+ last_nodepos = self.nodepos[parent_id]
+
+ in_line.append((node_pos, self.nodepos[parent_id],
+ self.colours[parent_id]))
+ self.add_incomplete_line(parent_id)
try:
branch_tag = self.bt_sha1[commit.commit_sha1]
@@ -935,7 +929,7 @@ class GitView:
return (in_line, last_colour, last_nodepos)
- def add_incomplete_line(self, sha1, index):
+ def add_incomplete_line(self, sha1):
try:
self.incomplete_line[sha1].append(self.nodepos[sha1])
except KeyError:
--
1.2.3.g2cf3-dirty
^ permalink raw reply related
* gitview: Fix the graph display
From: Aneesh Kumar K.V @ 2006-02-24 16:27 UTC (permalink / raw)
To: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0005-gitview-Fix-the-graph-display.txt --]
[-- Type: text/plain, Size: 1574 bytes --]
Subject: gitview: Fix the graph display .
This fix all the known issue with the graph display
The bug need to be explained graphically
|
a
This line need not be there ---->| \
b |
| /
c
c is parent of a and all a,b and c are placed on the same line and b is child of c
With my last checkin I added a seperate line to indicate that a is
connected to c. But then we had the line connecting a and b which should
not be ther. This changes fixes the same bug
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
d4da5f1243c47322ede9dae2a65098cbc7e9ecb5
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 2cde71e..4e3847d 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -938,8 +938,10 @@ class GitView:
def draw_incomplete_line(self, sha1, node_pos, out_line, in_line, index):
for idx, pos in enumerate(self.incomplete_line[sha1]):
if(pos == node_pos):
- out_line.append((pos,
- pos+0.5, self.colours[sha1]))
+ #remove the straight line and add a slash
+ if ((pos, pos, self.colours[sha1]) in out_line):
+ out_line.remove((pos, pos, self.colours[sha1]))
+ out_line.append((pos, pos+0.5, self.colours[sha1]))
self.incomplete_line[sha1][idx] = pos = pos+0.5
try:
next_commit = self.commits[index+1]
--
1.2.3.g2cf3-dirty
^ permalink raw reply related
* Re: gitview: Use monospace font to draw the branch and tag name
From: Aneesh Kumar @ 2006-02-24 16:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr75tc8gj.fsf@assigned-by-dhcp.cox.net>
On 2/24/06, Junio C Hamano <junkio@cox.net> wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@gmail.com> writes:
>
> > This patch address the below:
> > Use monospace font to draw branch and tag name
> > set the font size to 13.
>
> I have an impression that hardcoding UI policy like this is
> generally frowned upon.
But with that changes branch and the tag name looks neat.
May be down the line we can add a prefernce tag that will allow the
user to change all these hardcoded values.
-aneesh
^ permalink raw reply
* Removal of "--merge-order"?
From: Linus Torvalds @ 2006-02-24 16:32 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
I just tested it again, and
git-rev-list --merge-order HEAD
takes an inordinate amount of time:
real 5m1.139s
user 4m59.504s
sys 0m1.220s
and that's on a reasonably fast machine (not my fastest, but no slouch by
any measure - my fastest machine I'm not allowed to really benchmark
publicly ;)
It may be a cool algorithm, but it's essentially useless on any bigger
tree. And nobody uses it, since "--topo-order" gives the guarantees that
people really care about, and finishes in 0.537 seconds on the same
machine with the same tree.
It also depends on the openssh "bignum" stuff, which means that any
machine where we just rely on our own SHA1 implementation and don't use
openssh doesn't have the flag anyway.
In other words, I'd really prefer if it was gone. Some of the things I
might do to git-rev-list would be much simpler if I didn't have to worry
about merge-order, and the way it interfaces with the rest of
git-rev-list.
Comments?
Linus
^ permalink raw reply
* Re: Removal of "--merge-order"?
From: Randy.Dunlap @ 2006-02-24 16:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602240824110.3771@g5.osdl.org>
On Fri, 24 Feb 2006, Linus Torvalds wrote:
>
> I just tested it again, and
>
> git-rev-list --merge-order HEAD
>
> takes an inordinate amount of time:
>
> real 5m1.139s
> user 4m59.504s
> sys 0m1.220s
That's too bad.
> and that's on a reasonably fast machine (not my fastest, but no slouch by
> any measure - my fastest machine I'm not allowed to really benchmark
> publicly ;)
>
> It may be a cool algorithm, but it's essentially useless on any bigger
> tree. And nobody uses it, since "--topo-order" gives the guarantees that
> people really care about, and finishes in 0.537 seconds on the same
> machine with the same tree.
>
> It also depends on the openssh "bignum" stuff, which means that any
> machine where we just rely on our own SHA1 implementation and don't use
> openssh doesn't have the flag anyway.
>
> In other words, I'd really prefer if it was gone. Some of the things I
> might do to git-rev-list would be much simpler if I didn't have to worry
> about merge-order, and the way it interfaces with the rest of
> git-rev-list.
>
> Comments?
I'm just a lowly user, but I see people trying to export git
trees to other SCMs, and they seem to prefer merge-order.
This is your chance to correct me about:
(a) how I am wrong; (b) how they are wrong. 8;)
I've heard/seen you say that merge-order is not interesting,
but I still believe that *your* merge order of the Linux kernel
tree is almost all that people really care about.
Apparently I needed to go to LCA to hear you discuss git.
--
~Randy
^ permalink raw reply
* Re: Removal of "--merge-order"?
From: Linus Torvalds @ 2006-02-24 17:23 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0602240840520.7894@shark.he.net>
On Fri, 24 Feb 2006, Randy.Dunlap wrote:
>
> I'm just a lowly user, but I see people trying to export git
> trees to other SCMs, and they seem to prefer merge-order.
> This is your chance to correct me about:
> (a) how I am wrong; (b) how they are wrong. 8;)
Well, I didn't even realize anybody at all was using it. I've never seen
any mention of it, and considering how ungodly slow it is, I would have
expected somebody to pipe up about it..
I did a google search for "git" and "merge-order", and the only actual use
(as opposed to mention in a man-page) I found in the 20 hits google showed
was an old version of gitk.
> I've heard/seen you say that merge-order is not interesting,
> but I still believe that *your* merge order of the Linux kernel
> tree is almost all that people really care about.
Could you actually point to somebody using it? They're hiding it well.
> Apparently I needed to go to LCA to hear you discuss git.
I certainly never delved into any of that..
Linus
^ permalink raw reply
* Re: Removal of "--merge-order"?
From: Ryan Anderson @ 2006-02-24 17:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randy.Dunlap, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602240918030.3771@g5.osdl.org>
On Fri, Feb 24, 2006 at 09:23:24AM -0800, Linus Torvalds wrote:
> On Fri, 24 Feb 2006, Randy.Dunlap wrote:
> >
> > I'm just a lowly user, but I see people trying to export git
> > trees to other SCMs, and they seem to prefer merge-order.
> > This is your chance to correct me about:
> > (a) how I am wrong; (b) how they are wrong. 8;)
>
> Well, I didn't even realize anybody at all was using it. I've never seen
> any mention of it, and considering how ungodly slow it is, I would have
> expected somebody to pipe up about it..
>
> I did a google search for "git" and "merge-order", and the only actual use
> (as opposed to mention in a man-page) I found in the 20 hits google showed
> was an old version of gitk.
http://www.gelato.unsw.edu.au/archives/git/0511/12965.html
But topo-order would probably work as well, the default ordering just
didn't work correctly in my tests.
Certainly not a case that votes *against* removal, just noting an actual
user at one point.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] diff-delta: produce optimal pack data
From: Carl Baldwin @ 2006-02-24 17:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7v4q2pf8fq.fsf@assigned-by-dhcp.cox.net>
Junio,
This message came to me at exactly the right time. Yesterday I was
exploring using git as the content storage back-end for some binary
files. Up until now I've only used it for software projects.
I found the largest RCS file that we had in our current back-end. It
contained twelve versions of a binary file. Each version averaged about
20 MB. The ,v file from RCS was about 250MB. I did some experiments on
these binary files.
First, gzip consistantly is able to compress these files to about 10%
their original size. So, they are quite inflated. Second, xdelta would
produce a delta between two neighboring revisions of about 2.5MB in size
that would compress down to about 2MB. (about the same size as the next
revision compressed without deltification so packing is ineffective
here).
I added these 12 revisions to several version control back-ends
including subversion and git. Git produced a much smaller repository
size than the others simply due to the compression that it applies to
objects. It also was at least as fast as the others.
The problem came when I tried to clone this repository.
git-pack-objects chewed on these 12 revisions for over an hour before I
finally interrupted it. As far as I could tell, it hadn't made much
progress.
My other complaint was that git prune ran slow (~8 seconds on my very
fast machine with fast disk access) on a repository with only these
twelve revisions in it (37 total objects in the object store). This is
because 'git prune' actually ends up running fsck on all of the objects
which verifies the sha1 of each object. This seems like a lot of work
just to prune unwanted objects. What would you say to a --fast option
to git-prune that would avoid most of what fsck does including verifying
sha1 for each object?
Anyway, that was a tangent. I looked into to overriding the --depth
option to git-pack-objects and set it to 0. However, this isn't
trivial. git-pack-objects is never called directly by the user. It is
only called through things like 'git clone', 'git push' and 'git
repack'. What do you think about this? Could we add a configuration
option that could be set for the repository? Something smarter like
what you suggest where git would pack small text files but give up on
large binaries would be optimal.
I've already determined that packing a repository with this type of
largish binary file doesn't do any good but there doesn't seem to be a
way to avoid packing when doing network operations.
Thoughts?
Carl
On Fri, Feb 24, 2006 at 12:49:13AM -0800, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Indexing based on adler32 has a match precision based on the block size
> > (currently 16). Lowering the block size would produce smaller deltas
> > but the indexing memory and computing cost increases significantly.
>
> Indeed.
>
> I had this patch in my personal tree for a while. I was
> wondring why sometimes progress indication during "Deltifying"
> stage stops for literally several seconds, or more.
>
> In Linux 2.6 repository, these object pairs take forever to
> delta.
>
> blob 9af06ba723df75fed49f7ccae5b6c9c34bc5115f ->
> blob dfc9cd58dc065d17030d875d3fea6e7862ede143
> size (491102 -> 496045)
> 58 seconds
>
> blob 4917ec509720a42846d513addc11cbd25e0e3c4f ->
> blob dfc9cd58dc065d17030d875d3fea6e7862ede143
> size (495831 -> 496045)
> 64 seconds
>
> Admittedly, these are *BAD* input samples (a binary firmware
> blob with many similar looking ", 0x" sequences). I can see
> that trying to reuse source materials really hard would take
> significant computation.
>
> However, this is simply unacceptable.
>
> The new algoritm takes 58 seconds to produce 136000 bytes of
> delta, while the old takes 0.25 seconds to produce 248899 (I am
> using the test-delta program in git.git distribution). The
> compression ratio is significantly better, but this is unusable
> even for offline archival use (remember, pack delta selection
> needs to do window=10 such deltification trials to come up with
> the best delta, so you are spending 10 minutes to save 100k from
> one oddball blob), let alone on-the-fly pack generation for
> network transfer.
>
> Maybe we would want two implementation next to each other, and
> internally see if it is taking too much cycles compared to the
> input size then switch to cheaper version?
>
> -
> 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
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin RADCAD (R&D CAD)
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: Removal of "--merge-order"?
From: Randy.Dunlap @ 2006-02-24 17:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randy.Dunlap, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602240918030.3771@g5.osdl.org>
On Fri, 24 Feb 2006, Linus Torvalds wrote:
>
>
> On Fri, 24 Feb 2006, Randy.Dunlap wrote:
> >
> > I'm just a lowly user, but I see people trying to export git
> > trees to other SCMs, and they seem to prefer merge-order.
> > This is your chance to correct me about:
> > (a) how I am wrong; (b) how they are wrong. 8;)
>
> Well, I didn't even realize anybody at all was using it. I've never seen
> any mention of it, and considering how ungodly slow it is, I would have
> expected somebody to pipe up about it..
>
> I did a google search for "git" and "merge-order", and the only actual use
> (as opposed to mention in a man-page) I found in the 20 hits google showed
> was an old version of gitk.
>
> > I've heard/seen you say that merge-order is not interesting,
> > but I still believe that *your* merge order of the Linux kernel
> > tree is almost all that people really care about.
>
> Could you actually point to somebody using it? They're hiding it well.
Other than Ryan's reply, I found 2 users in a quick search,
but they have already stated that they are willing to change, so I
don't see objections unless someone else comes forward.
(Martin Langhoff, archimport)
http://marc.theaimsgroup.com/?l=git&m=112682069025547&w=2
Jon Seymour:
http://marc.theaimsgroup.com/?l=git&m=112998877717814&w=2
> > Apparently I needed to go to LCA to hear you discuss git.
>
> I certainly never delved into any of that..
Darn.
--
~Randy
^ permalink raw reply
* Re: [PATCH] diff-delta: produce optimal pack data
From: Nicolas Pitre @ 2006-02-24 17:56 UTC (permalink / raw)
To: Carl Baldwin; +Cc: Junio C Hamano, git
In-Reply-To: <20060224174422.GA13367@hpsvcnb.fc.hp.com>
On Fri, 24 Feb 2006, Carl Baldwin wrote:
> Junio,
>
> This message came to me at exactly the right time. Yesterday I was
> exploring using git as the content storage back-end for some binary
> files. Up until now I've only used it for software projects.
>
> I found the largest RCS file that we had in our current back-end. It
> contained twelve versions of a binary file. Each version averaged about
> 20 MB. The ,v file from RCS was about 250MB. I did some experiments on
> these binary files.
>
> First, gzip consistantly is able to compress these files to about 10%
> their original size. So, they are quite inflated. Second, xdelta would
> produce a delta between two neighboring revisions of about 2.5MB in size
> that would compress down to about 2MB. (about the same size as the next
> revision compressed without deltification so packing is ineffective
> here).
>
> I added these 12 revisions to several version control back-ends
> including subversion and git. Git produced a much smaller repository
> size than the others simply due to the compression that it applies to
> objects. It also was at least as fast as the others.
>
> The problem came when I tried to clone this repository.
> git-pack-objects chewed on these 12 revisions for over an hour before I
> finally interrupted it. As far as I could tell, it hadn't made much
> progress.
I must ask if you had applied my latest delta patches?
Also did you use a recent version of git that implements pack data
reuse?
Nicolas
^ permalink raw reply
* Re: git-annotate efficiency
From: Morten Welinder @ 2006-02-24 18:00 UTC (permalink / raw)
To: GIT Mailing List
In-Reply-To: <118833cc0602240737i42acdc90sb8f93dde1a1bc035@mail.gmail.com>
It looks like handle_rev is seeing the same revisions over and over again.
I don't know why that would be, but the following patch just skips dups.
I have no idea if it is right, though.
Morten
diff --git a/git-annotate.perl b/git-annotate.perl
index 3800c46..a5e2d86 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -117,7 +117,10 @@ sub init_claim {
sub handle_rev {
my $i = 0;
+ my %seen = ();
while (my $rev = shift @revqueue) {
+ next if $seen{$rev};
+ $seen{$rev} = 1;
my %revinfo = git_commit_info($rev);
^ permalink raw reply related
* Re: Removal of "--merge-order"?
From: Linus Torvalds @ 2006-02-24 18:07 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0602240942520.7894@shark.he.net>
On Fri, 24 Feb 2006, Randy.Dunlap wrote:
>
> Other than Ryan's reply, I found 2 users in a quick search,
> but they have already stated that they are willing to change, so I
> don't see objections unless someone else comes forward.
One thing we could do - and might be simpler - is to make the merge-order
thing be a post-processing phase of git-rev-list.
IOW, instead of
git-rev-list --merge-order
we could perhaps do
git-rev-list --parents [--topo-order?] | git-merge-order
so that the merge-order code wouldn't impact git-rev-list itself.
As it is, the merge-order code ends up hooking into the "process_commit"
thing (and thus to "filter_commit" which does the parent rewriting, and
then show_commit), which makes it harder to work with.
Now, rev-list.c is not the biggest file (apply.c is about twice the size),
but in many ways it's the most complex one by far. It's also the most
performance-critical one, and the one that it would be really nice if we
were to be able to libify it.
For example, instead of the horrid scriping language, I _think_ I could
almost libify it by just hooking into "show_commit", and using a callback
function for that (and then the stand-alone program would just make the
callback function be one that prints out the commit).
With some care, we might be able to make things like "git diff" be small C
programs (or, more likely, to save space and not replicate the binaries
many times - make the "git" binary able to do all the simple things on its
own: "git-diff" would be just a link to "git").
That would possibly be a simpler way to get away from using nonportable
scripts. Plain C really does remain one of the most portable things out
there.
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