* 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
* 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
* 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
* 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] 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
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: 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
* 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] 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] 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] 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: 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] 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
* [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: FYI: git-am allows creation of empty commits.
From: Junio C Hamano @ 2006-02-24 12:04 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m18xs1dmp3.fsf@ebiederm.dsl.xmission.com>
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.
If you want to do it, however, you need to be a bit careful
about merges. In a multi-parented commit, it is legitimate if
the merge result exactly match one of the parents (in fact
"git-merge -s ours" can be used to create a merge that matches
its first parent).
The commit-tree program is one of the oldest part of the system,
and as a mechanism, does not set nor enforce policies like this.
It has been more liberal than the best current practice, such as
(1) don't do single-parent empty commit; (2) don't list the same
parent twice. The second one was introduced in mid-June last
year, which is "long after it was invented" in git timescale.
On the other hand, it is more anal than it could be. It does
not take a tag that points to a commit to its -p parameter.
That's because we did not have tag objects in the beginning, and
by the time tags were introduced, nobody ran commit-tree by hand
anymore.
-- >8 --
[PATCH] commit-tree: disallow an empty single-parent commit.
Also allow "git-commit-tree -p v2.6.16-rc2", instead of having
to say "git-commit-tree -p v2.6.16-rc2^0".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/commit-tree.c b/commit-tree.c
index 88871b0..14a7552 100644
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -45,12 +45,14 @@ static void check_valid(unsigned char *s
{
void *buf;
char type[20];
+ unsigned char real_sha1[20];
unsigned long size;
- buf = read_sha1_file(sha1, type, &size);
- if (!buf || strcmp(type, expect))
+ buf = read_object_with_reference(sha1, expect, &size, real_sha1);
+ if (!buf)
die("%s is not a valid '%s' object", sha1_to_hex(sha1), expect);
free(buf);
+ memcpy(sha1, real_sha1, 20);
}
/*
@@ -75,6 +77,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;
@@ -105,6 +120,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));
^ permalink raw reply related
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Eric Wong @ 2006-02-24 12:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: Sam Vilain, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <81b0412b0602220835p4c4243edm145ee827eb706121@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> On 2/21/06, Sam Vilain <sam@vilain.net> wrote:
> > Alex Riesen wrote:
> > >>>Does not work here (ActiveState Build 811, Perl 5.8.6):
> > >>>$ perl -e 'open(F, "-|")'
> > >>>'-' is not recognized as an internal or external command,
> > >>>operable program or batch file.
> > >>Portability, Ease of Coding, Few CPAN Module Dependencies. Pick any two.
> > > Sometimes an upgrade is just out of question. Besides, that'd mean an
> > > upgrade to another operating system, because very important scripts
> > > over here a just not portable to anything else but
> > > "ActiveState Perl on Windows (TM)"
> > > I just have no choice.
> >
> > Sure, but perhaps IPC::Open2 or some other CPAN module has solved this
> > problem already.
>
> IPC::Open2 works! Well "kind of": there are still strange segfaults regarding
> stack sometimes. And I don't know yet whether and how the arguments are escaped
> (Windows has no argument array. It has that bloody stupid one-line command line)
It seems that ActiveState has more problems with pipes than it does with fork.
If it supports redirects reasonably well, this avoids pipes entirely and
may be more stable as a result (but possibly slower):
# IO::File is standard in Perl 5.x, new_tmpfile
# returns an open filehandle to an already unlinked file
use IO::File;
my $out = IO::File->new_tmpfile;
file
my $pid = fork;
defined $pid or die $!;
if (!$pid) {
# redirects STDOUT to $out file
open STDOUT, '>&', $out or die $!;
exec('foo','bar');
}
waitpid $pid, 0;
seek $out, 0, 0;
while (<$out>) {
...
}
Writing and reading from a tempfile are very fast for me in Linux, and probably
not much slower than pipes. Of course I'm still assuming file descriptors stay
shared after a 'fork', which may be asking too much on Windows. Using something
from File::Temp to get a temp filename would still work.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] New git-seek command with documentation and test.
From: Junio C Hamano @ 2006-02-24 11:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Carl Worth, git, Linus Torvalds
In-Reply-To: <43FED93D.1000601@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> 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>" (although it would be nice to have '-o' for 'overwrite
> existing branch' as an argument to git checkout)
True, but assembly provides more flexibility than higher level
languages and you need to strike a balance between power and
usability.
The real question is if the structure the tool enforces to your
workflow is simply being a straight-jacket or helping an average
user to avoid common mistakes.
One occasion I've felt the need for "seek" like feature was when
starting to bisect. You usually notice breakage, so you can
start with "git bisect bad HEAD", but then what next? You
usually are not absolutely sure which one _was_ working the last
time.
If I had a seek, then I could go back to some randomly chosen
version to try it out, going back until I find a good one.
Maybe "git bisect try $committish" would be a good addition. We
could live without it (we can just say "git reset --hard
$committish"), but it can be a bit more than just that. If
given committish is known to be good or bad, we could remind the
user what she said the last time, and offer a chance to take it
back. That is, (1) if the given $committish is an ancestor of
existing good one, list those good ones and ask "do you mean you
are not sure if they are good anymore, and retry the
bisection?" If yes, delete those good-* refs; (2) if the given
$committish is a descendant of a bad one, show it and ask "do
you mean you are not sure if they are good anymore, and retry
the bisection?" If yes, remove the existing bad ref. In any
case, "reset --hard" to it after user responds.
Other than that, I haven't felt a need for seek-like feature;
instead, I make liberal use of throw-away branches.
^ permalink raw reply
* Re: FYI: git-am allows creation of empty commits.
From: Eric W. Biederman @ 2006-02-24 11:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wxtgv02.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> After fixing it up and doing all of my edits I occasionally forget
>> the git-update-index step, before calling git-am --resolved. This
>> proceeds along it's merry way and creates an empty commit.
>
> Certainly a safty measure is missing here. Thanks for
> noticing. How about something like this?
Just tested it the patch works, at least in my simple contrived
example :)
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.
Eric
^ permalink raw reply
* Re: gitview: Use monospace font to draw the branch and tag name
From: Junio C Hamano @ 2006-02-24 11:17 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <43FC8BF2.60205@gmail.com>
"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.
^ permalink raw reply
* Some more pack-objects tweaks
From: Junio C Hamano @ 2006-02-24 10:38 UTC (permalink / raw)
To: git
I've been working more pack-objects improvements. There will be
two tweaks in the "next" branch I'll be pushing out tonight.
* rev-list reports full pathnames not just basenames for
contained trees and blobs. pack-objects hashes the incoming
names (and names obtained from "negative" trees when
--objects-edge aka "thin pack" is used) taking into account
the dirname and basename part.
Earlier, I had a patch that hashes the whole pathname, and
found it perform worse than the original "hash just the
basename" approach, so I never published it. The idea in
this round is to give "Makefile" and "t/Makefile" a different
but close hash values. Type-size sort groups "Makefile"s
from different revs together, and another group of bunch of
"t/Makefile"s are found close by.
* when creating "thin" pack, disable the code to avoid too
long a delta chain to be made due to reused delta (see
15b4d57 and ab7cd7b commit log for details).
This is because limiting delta chain is more costly than let
it grow by using preexisting delta, and "thin" pack is usable
by first exploding it, so at that point delta depth does not
matter.
In Linux 2.6 repository, I've created a thin pack between
v2.6.14..v2.6.15-rc1 (36k objects). Here are the results:
[without either patch]
15463034 bytes
Total 36248, written 36248 (delta 29046), reused 28306 (delta 22512)
real 1m38.157s user 1m32.520s sys 0m5.440s
[with full names]
11138621 bytes
Total 36248, written 36248 (delta 30368), reused 27918 (delta 22512)
real 1m36.254s user 1m28.650s sys 0m5.470s
[with full names, and allowing deeper delta]
9971223 bytes
Total 36248, written 36248 (delta 30868), reused 27429 (delta 22512)
real 1m36.923s user 1m29.770s sys 0m5.470s
All of these tests were done with the last patch in Nico's delta
enhancement series reverted, because the dataset used in this
test triggers a corner case performance disaster in it (I've
sent a message separately).
^ permalink raw reply
* Re: [PATCH] New git-seek command with documentation and test.
From: Andreas Ericsson @ 2006-02-24 10:11 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux, cworth, git
In-Reply-To: <43FEAD62.6050302@zytor.com>
H. Peter Anvin wrote:
> linux@horizon.com wrote:
>
>> The annoying thing about temporary branch names like "bisect" and "seek"
>> is that:
>> a) They clutter up the nae space available to the repository user.
>> Users have to know that those are reserved names.
>> b) If a repository is cloned while they're in use, they might get
>> into a "remotes" file, with even more confusing results.
>>
>> This is somewhat heretical, but how about making a truly unnamed
>> branch by
>> having .git/HEAD *not* be a symlink, but rather hold a commit ID
>> directly?
>> It's already well established that files in the .git directory directly
>> are strictly local to this working directory, so it seems a much better
>> home for such temporary state.
>>
>
> It might be easier to just reserve part of the namespace, e.g. ".bisect"
> and ".seek" instead.
>
Ach, no. Not specific names. ^\.-.* would be acceptable, but I sometimes
use '.name' or '-name' to mark a temporary branch. Making .- or some
such reserved would perhaps make sense, but not with specific names.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] New git-seek command with documentation and test.
From: Andreas Ericsson @ 2006-02-24 10:00 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <87zmkhrf4y.wl%cworth@cworth.org>
Carl Worth wrote:
> Add git-seek which allows for temporary excursions through the
> revision history. With "git seek <revision>" one gets a working tree
> corresponding to <revision>. When done with the excursion "git seek"
> returns back to the original branch from where the first seek began.
>
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>" (although it would be nice to have '-o' for 'overwrite
existing branch' as an argument to git checkout)
> Signed-off-by: Carl Worth <cworth@cworth.org>
>
> ---
>
> I had planned to just let this drop as my original need was some
> historical exploration that I've already finished. But now I've found
> a common use case in my everyday workflow that could benefit from
> git-seek. Here it is:
>
> I receive a bug-fix patch that updates a test case to demonstrate the
> bug. I can apply both the fix and the test case and see it succeed.
> But what I really want to do is first commit the test case, see it
> fail, and only then commit the fix and see the test now succeed. I'd
> also like the history to reflect that order. So what I do is:
>
> $ git-am
> $ git update-index test.c ; git commit -m "Update test"
> $ git update-index buggy.c ; git commit -m "Fix bug"
>
> At that point, without git-seek I can get by with:
>
> $ git checkout -b tmp HEAD^
> $ make check # to see failure
> $ git checkout <branch_I_was_on_to_begin_with>
> $ git branch -d tmp # easy to forget, but breaks the next time otherwise
> $ make check # to see success
>
> But what I'd really like to do, (and can with the attached patch), is:
>
> $ git seek HEAD^
> $ make check # to see failure
> $ git seek
> $ make check # to see success
>
> This avoids me having 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).
> 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.
> 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, or want to
keep the point so you can show the author some problem or other with the
patch. With git-seek you'll then have to remember the hard-to-learn
SHA1, or how far below HEAD or some other easily remembered point in
history it is. 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.
If I had a vote, I'd say no to this patch, and to this tool entirely.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] diff-delta: produce optimal pack data
From: Junio C Hamano @ 2006-02-24 8:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602212043260.5606@localhost.localdomain>
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?
^ permalink raw reply
* gitview: Bump the rev
From: Aneesh Kumar @ 2006-02-24 8:38 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: 0003-gitview-Bump-the-rev.txt --]
[-- Type: text/plain, Size: 610 bytes --]
Subject: gitview: Bump the rev
Make the 0.7 release
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
32e92e4586a4b48c2d4776bcb7ba885f5c710935
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 4a6b448..02e2445 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -422,7 +422,7 @@ class DiffWindow:
class GitView:
""" This is the main class
"""
- version = "0.6"
+ version = "0.7"
def __init__(self, with_diff=0):
self.with_diff = with_diff
--
1.2.3.g2cf3-dirty
^ permalink raw reply related
* gitview: Fix DeprecationWarning
From: Aneesh Kumar @ 2006-02-24 8:32 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: 0002-gitview-Fix-DeprecationWarning.txt --]
[-- Type: text/plain, Size: 743 bytes --]
Subject: gitview: Fix DeprecationWarning
DeprecationWarning: integer argument expected, got float
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
1d34275e275b7450721033bf261ea29219934982
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index b04df74..4a6b448 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -154,7 +154,7 @@ class CellRendererGraph(gtk.GenericCellR
cols = self.node[0]
for start, end, colour in self.in_lines + self.out_lines:
- cols = max(cols, start, end)
+ cols = int(max(cols, start, end))
(column, colour, names) = self.node
names_len = 0
--
1.2.3.g2cf3-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