* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Randy.Dunlap @ 2005-04-21 5:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: dan, pasky, greg, git
In-Reply-To: <Pine.LNX.4.58.0504202056310.2344@ppc970.osdl.org>
On Wed, 20 Apr 2005 21:00:44 -0700 (PDT) Linus Torvalds wrote:
|
|
| On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
| >
| > My logic: it's a lot more intuitive to say "cg-log | less" to get
| > paginated output than it is to say "cg-log | cat" to get unpaginated
| > output.
|
| I disagree.
|
| There is _never_ any valid situation where you do "cg-log" with
| unpaginated output to a tty.
|
| In _any_ real system you'll be getting thousands of lines of output.
| Possibly millions. unpaginated? What the hell are you talking about?
Who in the world would look at thousands or millions of lines on a
tty using a pager?
| And as I pointed out, if the output is not a tty, then both less and more
| automatically turn into cat, so there's no difference. This change _only_
| triggers for a tty, and I dare you to show a single relevant project where
| it's ok to scroll thousands of lines.
|
| Even git-pasky, which is just a two-week-old project right now outputs
| 4338 lines of output to "git log".
|
| Unpaginated? You must be kidding.
|
| (But if you are _that_ fast a reader, then hey, use "PAGER=cat", and
| you'll find yourself happy).
---
~Randy
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Junio C Hamano @ 2005-04-21 5:08 UTC (permalink / raw)
To: Dave Jones; +Cc: Linus Torvalds, Daniel Jacobowitz, Petr Baudis, Greg KH, git
In-Reply-To: <20050421042248.GA16002@redhat.com>
>>>>> "DJ" == Dave Jones <davej@redhat.com> writes:
DJ> I used to do 'bk changes | grep \[AGPGART\] -C3 | head' on a
DJ> regular basis, just to be able to answer 'hey, did cset x
DJ> get into tree y?' questions from users. which is the
DJ> probably the closest I came to non-paginated usage.
I am bk untainted so I may be misunderstanding what your example
is, but I take that "bk changes" in your example corresponds to
"git log", correct?
Then please read what Linus wrote again. Your example is
exactly the point Linus is making. The output from that command
is not going to a tty---it is going to a _pipe_ and more or less
will do exactly (not more or less ;-) the right thing.
^ permalink raw reply
* Performance of various compressors
From: Mike Taht @ 2005-04-21 5:06 UTC (permalink / raw)
To: git
I started rolling a tool to measure various aspects of git performance.
I will start looking at merge next, and at workloads different from the
kernel (gcc4 anyone?) ...
The only data points worth sharing a this point are:
That doing the compression at a level of 3, rather than the max of 9,
cuts the cpu time required for a big git commit by over half, and that
that actually translates into a win on the I/O to disk. (these tests
were performed on a dual opteron 842)
The benefits of compression aren't very much for git right now.
And: A big git commit is I/O bound. But we knew that. Maybe it's
possible to make it less I/O bound.
Git branch: 7a4c67965de68ae7bc7aa1fde33f8eb9d8114697
Tree: 2.6.11.7 source tree
Branch: N/a
Merge File: N/a
HW: dual opteron 242
Mem: 1GB
Disk: seagate barracuda
Filesystem: Reiser3
Git add: N/a
Cache: Hot
Git Commit: 44.97user 5.94system 1:45.24elapsed 48%CPU
Git Merge:
Options:
Feature: Test of compression=9 (std git)
du -s .git/objects 110106 # du is probably not the right thing
du -s --apparent-size .git/objects 58979
Git branch: 9e272677621c91784cf2533123a41745178f0701
Tree: 2.6.11.7 source tree
Branch: N/a
Merge File: N/a
HW: dual opteron 242
Mem: 1GB
Disk: seagate barracuda
Disk mode: udma5
Filesystem: Reiser3
Git add: N/a
Cache: Hot
Git Commit: 16.79user 6.15system 1:21.92elapsed 28%CPU
Git Merge:
Options:
Feature: Test of compression=3 (std git)
du -s .git/objects 115218
du -s --apparent-size .git/objects 64274
There's some variety in the best/worst case timings for I/O for the
compressor=3 case...
16.79user 6.15system 1:21.92elapsed 28%CPU
16.68user 5.71system 1:13.19elapsed 30%CPU
--
Mike Taht
lastly -
Timings of git commit with tmpfs (note, these were done with an ancient,
5 hour old version of git and the script)
Hot cache, tmpfs .git compression=9
44.97user 2.76system 0:47.72elapsed 100%CPU
Hot cache, tmpfs .git, compression=6
Wed Apr 20 20:18:11 PDT 2005
23.55user 2.83system 0:26.36elapsed 100%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (0major+568680minor)pagefaults 0swaps
109620 .git/objects
58618 .git/objects
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Matthias Urlichs @ 2005-04-21 2:48 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0504201503050.6467@ppc970.osdl.org>
Linus Torvalds wrote:
> I realize that there is probably a law that there has to be a space, but I
> actually personally use tab-completion all the time
You can actually teach bash3 to do that (yes, with space).
In general, though, I tend to agree -- dashes work with more shells and
avoid namespace collisions.
--
Matthias Urlichs
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Daniel Jacobowitz @ 2005-04-21 4:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Greg KH, git
In-Reply-To: <Pine.LNX.4.58.0504202056310.2344@ppc970.osdl.org>
On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
> >
> > My logic: it's a lot more intuitive to say "cg-log | less" to get
> > paginated output than it is to say "cg-log | cat" to get unpaginated
> > output.
>
> I disagree.
>
> There is _never_ any valid situation where you do "cg-log" with
> unpaginated output to a tty.
>
> In _any_ real system you'll be getting thousands of lines of output.
> Possibly millions. unpaginated? What the hell are you talking about?
OK, so I'm crazy. I must have hallucinated doing this sort of thing on
a regular basis... :-) Examples: terminals with good scrollback,
screen, script. Small repositories. Irritation at less's habit of
using the alternate xterm buffer, whatever the technical term for that
is.
But hey, you'll use it more often than I will by far.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Daniel Barkalow @ 2005-04-21 4:28 UTC (permalink / raw)
To: Brad Roberts; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.44.0504202026180.2625-100000@bellevue.puremagic.com>
On Wed, 20 Apr 2005, Brad Roberts wrote:
> How about fetching in the inverse order. Ie, deepest parents up towards
> current. With that method the repository is always self consistent, even
> if not yet current.
You don't know the deepest parents to fetch until you've read everything
more recent, since the history you'd have to walk is the history you're
downloading.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Dave Jones @ 2005-04-21 4:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Jacobowitz, Petr Baudis, Greg KH, git
In-Reply-To: <Pine.LNX.4.58.0504202056310.2344@ppc970.osdl.org>
On Wed, Apr 20, 2005 at 09:00:44PM -0700, Linus Torvalds wrote:
> > My logic: it's a lot more intuitive to say "cg-log | less" to get
> > paginated output than it is to say "cg-log | cat" to get unpaginated
> > output.
> I disagree.
>
> There is _never_ any valid situation where you do "cg-log" with
> unpaginated output to a tty.
>
> In _any_ real system you'll be getting thousands of lines of output.
> Possibly millions. unpaginated? What the hell are you talking about?
>
> And as I pointed out, if the output is not a tty, then both less and more
> automatically turn into cat, so there's no difference. This change _only_
> triggers for a tty, and I dare you to show a single relevant project where
> it's ok to scroll thousands of lines.
>
> Even git-pasky, which is just a two-week-old project right now outputs
> 4338 lines of output to "git log".
>
> Unpaginated? You must be kidding.
>
> (But if you are _that_ fast a reader, then hey, use "PAGER=cat", and
> you'll find yourself happy).
I used to do 'bk changes | grep \[AGPGART\] -C3 | head' on a regular basis,
just to be able to answer 'hey, did cset x get into tree y?' questions from users.
which is the probably the closest I came to non-paginated usage.
(though, ok 'head' is technically a pager too..)
Dave
^ permalink raw reply
* Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.
From: Junio C Hamano @ 2005-04-21 4:04 UTC (permalink / raw)
To: Linus Torvalds, Petr Baudis; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504192102140.6467@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> And as you can see, the output matches "diff-tree -r" output (we always do
LT> "-r", since the index is always fully populated). All the same rules: "+"
LT> means added file, "-" means removed file, and "*" means changed file. You
LT> can trivially see that the above is a rename.
I do not know if Pasky tools already have something like this
already, or not; but just FIY, here is what I use to extract a
"patch" out of a working tree.
Usage:
$ diff-tree -z [-r] ... | jit-diff-tree-helper [ | less ]
$ diff-cache -z ... | jit-diff-tree-helper [ | less ]
This would be useful for the merge I described in my initial
message in this thread to take a snapshot of what the user has
done since the last commit, to be applied on the result of the
merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
--- jit-diff-tree-helper 2005-03-19 15:28:25.000000000 -0800
+++ jit-diff-tree-helper 2005-04-20 19:15:32.000000000 -0700
@@ -0,0 +1,63 @@
+#!/usr/bin/perl -w
+
+use strict;
+use File::Temp qw(mkstemp);
+
+sub cat_file {
+ my ($sha1, $file) = @_;
+ unless (defined $sha1) { return "/dev/null"; }
+ if ($sha1 =~ /^0{40}$/) {
+ open I, '<', $file;
+ } else {
+ local $/; # slurp mode
+ open I, "-|", "cat-file", "blob", $sha1
+ or die "$0: cannot read $sha1";
+ }
+ my ($o, $filename) = mkstemp(",,jit-diff-tree-helperXXXXXX");
+ print $o join("",<I>);
+ close I
+ or die "$0: closing cat-file pipe from $sha1";
+ close $o
+ or die "$0: closing write fd to $filename";
+ return $filename;
+}
+$/ = "\0";
+my $rM = "[0-7]+";
+my $rI = "[0-9a-f]{40}";
+while (<STDIN>) {
+ my ($old, $new, $file);
+ chomp;
+ if (/^\+$rM\tblob\t($rI)\t(.*)$/os) {
+ ($old, $new, $file) = (undef, $1, $2);
+ }
+ elsif (/^-$rM\tblob\t($rI)\t(.*)$/os) {
+ ($old, $new, $file) = ($1, undef, $2);
+ }
+ elsif (/^\*$rM->$rM\tblob\t($rI)->($rI)\t(.*)$/os) {
+ ($old, $new, $file) = ($1, $2, $3);
+ }
+ else {
+ chomp;
+ print STDERR "warning: $0: ignoring $_\n";
+ next;
+ }
+ if (@ARGV) {
+ my $matches = 0;
+ for (@ARGV) {
+ my $l = length($_);
+ if ($file eq $_ ||
+ (substr($file, 0, $l) eq $_ &&
+ substr($file, $l, 1) eq "/")) {
+ $matches = 1;
+ last;
+ }
+ }
+ next unless $matches;
+ }
+ $old = cat_file $old, $file;
+ $new = cat_file $new, $file;
+ system "diff", "-L", "l/$file", "-L", "k/$file", "-pu", $old, $new;
+ for ($old, $new) {
+ unlink $_ if $_ ne '/dev/null';
+ }
+}
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Linus Torvalds @ 2005-04-21 4:00 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Petr Baudis, Greg KH, git
In-Reply-To: <20050421033526.GA9404@nevyn.them.org>
On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
>
> My logic: it's a lot more intuitive to say "cg-log | less" to get
> paginated output than it is to say "cg-log | cat" to get unpaginated
> output.
I disagree.
There is _never_ any valid situation where you do "cg-log" with
unpaginated output to a tty.
In _any_ real system you'll be getting thousands of lines of output.
Possibly millions. unpaginated? What the hell are you talking about?
And as I pointed out, if the output is not a tty, then both less and more
automatically turn into cat, so there's no difference. This change _only_
triggers for a tty, and I dare you to show a single relevant project where
it's ok to scroll thousands of lines.
Even git-pasky, which is just a two-week-old project right now outputs
4338 lines of output to "git log".
Unpaginated? You must be kidding.
(But if you are _that_ fast a reader, then hey, use "PAGER=cat", and
you'll find yourself happy).
Linus
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Sean @ 2005-04-21 2:45 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Linus Torvalds, Petr Baudis, Greg KH, git
In-Reply-To: <20050421033526.GA9404@nevyn.them.org>
On Wed, April 20, 2005 11:35 pm, Daniel Jacobowitz said:
> My logic: it's a lot more intuitive to say "cg-log | less" to get
paginated output than it is to say "cg-log | cat" to get unpaginated
output.
>
Daniel,
All you'd have to do is:
$ export PAGER=cat
to get the behavior you want.
Sean
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Daniel Jacobowitz @ 2005-04-21 3:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Greg KH, git
In-Reply-To: <Pine.LNX.4.58.0504201809170.2344@ppc970.osdl.org>
On Wed, Apr 20, 2005 at 06:12:34PM -0700, Linus Torvalds wrote:
> Here's a slightly updated version.
>
> It's identical to the previous one, except that it also feeds the result
> through "| ${PAGER:-less}" which makes it a lot more useful, in my
> opinion.
>
> If you redirect the output to a non-tty, both "less" and "more" do the
> right thing and just feed the output straight through. But if the output
> is a tty, this makes "git log" a lot more friendly than a quickly
> scrolling mess..
Personally, I'd rather it didn't do this; bk help does the same thing,
and it drives me crazy. I guess you have /usr/bin/man for a precedent,
though :-)
My logic: it's a lot more intuitive to say "cg-log | less" to get
paginated output than it is to say "cg-log | cat" to get unpaginated
output.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply
* Similarities with Vesta
From: Kenneth C. Schalk @ 2005-04-21 3:33 UTC (permalink / raw)
To: git
When I first read about git a few days ago, I was pretty surprised by
how similar it seemed to the project I've been working on for several
years. (Coming off BK, I would have expected a more Darcs/Codeville
kind of change-merging-centric approach.)
Since I don't see any mention of Vesta on this list or lkml, I thought
I should at least join the list and say a few words. Some of the
similarities which jumped out at me:
- The Vesta repository is a filesystem. It was written by a
"filesystem person" at a systems research lab. It has a versioning
system (and a build system) built on top of it.
- The Vesta repository's backing store is indexed by a hash of file
contents (though this is a detail mostly hidden from users).
- The Vesta repository stores complete copies of every source file,
but only one copy of each (thanks to the hash-based indexing).
- The Vesta repository's directory structure makes it possible to
quickly determine what files and directories have changed between
two versions. (Actually, I normally just use "diff -r", but I
hacked up something similar to git's diff-tree in about an hour
using the Python binding for the repository's API.)
Since this isn't entirely on topic, I'll refrain from going into too
much detail, but I'd be happy to answer any questions. (There's also
lots of information on http://www.vestasys.org/, multiple published
papers, and a book from Springer-Verlag coming out sometime later this
year.) I'm hoping that there's some opportunities for the kernel
developers to get some benefit from the considerable research and
development that's gone into Vesta.
A very brief history of Vesta:
- The project started in the early '90s at DEC's Systems Research
Center. In the mid '90s, a from-scratch re-write was done based on
the research group's experiences with the first prototype.
- In 1998, the Alpha microprocessor group started using it for chip
design. When the Alpha group was acquired by Intel in 2001, Compaq
(which had acquired DEC) agreed to release Vesta as free software.
- The former Alpha group continues to use Vesta at Intel, and
employs two developers to work on maintaining and improving it.
Lastly, since I know git's development has been focused on
performance, here's a quick example of checking in, patching, and
diffing the kernel source in Vesta:
# Create a branch to use for the 2.6.0 sources.
% vbranch -O /vesta/ktest1.xorian.net/kernel/2.6.0
Creating branch /vesta/ktest1.xorian.net/kernel/2.6.0
% vcheckout /vesta/ktest1.xorian.net/kernel/2.6.0
Reserving version /vesta/ktest1.xorian.net/kernel/2.6.0/1
Creating session /vesta/ktest1.xorian.net/kernel/2.6.0/checkout/1
Making working directory /vesta-work/ken/kernel
# Unpack the 2.6.0 source into the working directory.
% cd /vesta-work/ken/kernel
% tar -jxf /tmp/kernel/linux-2.6.0.tar.bz2
31.90s user 7.98s system 46% cpu 1:24.92 total
# Move everything up out of the directory with the version name just
# to simplify the rest of the example.
% mv linux-2.6.0/* .
% rmdir linux-2.6.0
# Take an immutable snapshot of the working copy. This is basically
# hashing the file contents and taking a snapshot of the directory
# structure. (The real work happens inside the repository server,
# which is running in the background.)
% vadvance
Advancing to /vesta/ktest1.xorian.net/kernel/2.6.0/checkout/1/1
0.75s user 1.08s system 4% cpu 39.371 total
# Check in the snapshot. (This is a very fast operation, because all
# it's really doing is giving a new name to the snapshot taken in the
# previous step.)
% cd ..
% vcheckin kernel
Checking in /vesta/ktest1.xorian.net/kernel/2.6.0/1
Deleting /vesta-work/ken/kernel
0.10s user 0.07s system 33% cpu 0.510 total
# Make a new branch for 2.6.1 based on the 2.6.0 version just checked
# in. (Again, no real work here.)
% vbranch -o /vesta/ktest1.xorian.net/kernel/2.6.0/1 \
/vesta/ktest1.xorian.net/kernel/2.6.1
Creating branch /vesta/ktest1.xorian.net/kernel/2.6.1
0.01s user 0.01s system 27% cpu 0.073 total
# Apply the 2.6.1 patch.
% cd /vesta-work/ken/kernel
% bzcat /tmp/kernel/patch-2.6.1.bz2 | patch -p1
[...]
bzcat 0.70s user 0.03s system 91% cpu 0.796 total
patch 0.74s user 1.52s system 22% cpu 10.216 total
# Take a snapshot of the changes and check them in.
% vadvance
Advancing to /vesta/ktest1.xorian.net/kernel/2.6.1/checkout/1/1
0.33s user 0.38s system 22% cpu 3.092 total
% cd ..
% vcheckin kernel
Checking in /vesta/ktest1.xorian.net/kernel/2.6.1/1
Deleting /vesta-work/ken/kernel
0.05s user 0.03s system 41% cpu 0.193 total
# Repeat just for some more timing numbers.
% vbranch -o /vesta/ktest1.xorian.net/kernel/2.6.1/1 \
/vesta/ktest1.xorian.net/kernel/2.6.2
Creating branch /vesta/ktest1.xorian.net/kernel/2.6.2
0.01s user 0.01s system 167% cpu 0.012 total
% vcheckout /vesta/ktest1.xorian.net/kernel/2.6.2
Reserving version /vesta/ktest1.xorian.net/kernel/2.6.2/1
Creating session /vesta/ktest1.xorian.net/kernel/2.6.2/checkout/1
Making working directory /vesta-work/ken/kernel
0.01s user 0.00s system 62% cpu 0.016 total
% cd /vesta-work/ken/kernel
% bzcat /tmp/kernel/patch-2.6.2.bz2 | patch -p1
[...]
bzcat 1.89s user 0.06s system 92% cpu 2.107 total
patch 1.67s user 3.21s system 19% cpu 24.807 total
% vadvance
Advancing to /vesta/ktest1.xorian.net/kernel/2.6.2/checkout/1/1
0.38s user 0.47s system 18% cpu 4.559 total
% cd ..
% vcheckin kernel
Checking in /vesta/ktest1.xorian.net/kernel/2.6.2/1
Deleting /vesta-work/ken/kernel
0.07s user 0.03s system 38% cpu 0.260 total
# Let's see how fast my quick diff-tree clone is.
% cd /vesta/ktest1.xorian.net/kernel
% diff-tree.py 2.6.0/1 2.6.1/1
< 2.6.0/1/CREDITS
> 2.6.1/1/CREDITS
< 2.6.0/1/Documentation/DocBook/kernel-locking.tmpl
> 2.6.1/1/Documentation/DocBook/kernel-locking.tmpl
[...]
< 2.6.0/1/sound/sound_core.c
> 2.6.1/1/sound/sound_core.c
< 2.6.0/1/usr/gen_init_cpio.c
> 2.6.1/1/usr/gen_init_cpio.c
1.50s user 0.44s system 50% cpu 3.871 total
% diff-tree.py 2.6.1/1 2.6.2/1
[...]
1.70s user 0.47s system 47% cpu 4.526 total
% diff-tree.py 2.6.0/1 2.6.2/1
[...]
1.85s user 0.56s system 48% cpu 4.935 total
# /vesta is a mount point for a virtual filesystem provided by the
# repository server. All the versions created above can be accessed
# directly, so you can use normal diff to generate patches.
% diff -Nru 2.6.0/1 2.6.1/1 > /tmp/kernel/patch-2.6.1-recreated
0.79s user 2.00s system 39% cpu 7.149 total
% diff -Nru 2.6.1/1 2.6.2/1 > /tmp/kernel/patch-2.6.2-recreated
1.40s user 2.51s system 38% cpu 10.070 total
Just a couple final notes on this demonstration:
- The repository server and all client programs were running on a
1.7GHz AthlonXP
- The Vesta tools came from the latest pre-release version
(12.pre13/5)
Thanks for your time.
--Ken Schalk
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Brad Roberts @ 2005-04-21 3:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, git
In-Reply-To: <20050417195900.GH1461@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Date: Sun, 17 Apr 2005 21:59:00 +0200
> From: Petr Baudis <pasky@ucw.cz>
> To: Daniel Barkalow <barkalow@iabervon.org>
> Cc: git@vger.kernel.org
> Subject: Re: [3/5] Add http-pull
>
> Dear diary, on Sun, Apr 17, 2005 at 09:24:27PM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > On Sun, 17 Apr 2005, Petr Baudis wrote:
> >
> > > Dear diary, on Sun, Apr 17, 2005 at 08:49:11PM CEST, I got a letter
> > > where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > > > There's some trickiness for the history of commits thing for stopping at
> > > > the point where you have everything, but also behaving appropriately if
> > > > you try once, fail partway through, and then try again. It's on my queue
> > > > of things to think about.
> > >
> > > Can't you just stop the recursion when you hit a commit you already
> > > have?
> >
> > The problem is that, if you've fetched the final commit already, and then
> > the server dies, and you try again later, you already have the last one,
> > and so you think you've got everything.
>
> Hmm, some kind of journaling? ;-)
How about fetching in the inverse order. Ie, deepest parents up towards
current. With that method the repository is always self consistent, even
if not yet current.
Later,
Brad
^ permalink raw reply
* wit 0.0.4 uploaded
From: Christian Meder @ 2005-04-21 3:05 UTC (permalink / raw)
To: git
Hi,
I uploaded a new snapshot to http://www.absolutegiganten.org/wit
The changes are
0.0.4:
* c2html usage is configurable now
* add flexible /changelog/<number of entries>, <number of days> and all
* improve display of dates
* implement all the nice ideas from Kay Sievers gitweb.pl
* try to validate most of the dynamic URIs
* sanitize logging and move host and port configuration to config.py
* add copyright headers to source files
* add a simple start script
* change default web serving mode of wit to multithreading
If I weren't so tired I'd write something cool and nifty for sure
The demo site is at
http://grmso.net:8090
Greetings,
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Bryan Donlan @ 2005-04-21 2:53 UTC (permalink / raw)
To: git
In-Reply-To: <20050420205633.GC19112@pasky.ji.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Petr Baudis wrote:
| Hello,
|
| so I've "released" git-pasky-0.6.2 (my SCMish layer on top of Linus
| Torvalds' git tree history storage system), find it at the usual
|
| http://pasky.or.cz/~pasky/dev/git/
When I run `git pull', I get:
Tree change:
55f9d5042603fff4ddfaf4e5f004d2995286d6d3:7a4c67965de68ae7bc7aa1fde33f8eb9d8114697
+100644 blob 8186a561108d3c62625614272bd5e2f7d5826b4b README.reference
*100755->100755 blob
5f23301eb97a0fadd505a6e9cc851e98741a512a->bf277135908ee7c6b7d6ad330d1ce183b9bb411f
git
*100755->100755 blob
a78cf8ccab98861ef7aecb4cb5a79e47d3a84b67->74b4083d67eda87d88a6f92c6c66877bba8bda8a
gitcancel.sh
Tracked branch, applying changes...
Fast-forwarding 55f9d5042603fff4ddfaf4e5f004d2995286d6d3 ->
7a4c67965de68ae7bc7aa1fde33f8eb9d8114697
on top of 55f9d5042603fff4ddfaf4e5f004d2995286d6d3...
patch: **** Only garbage was found in the patch input.
I'm on debian testing, patch 2.5.9. It seems to apply the changes
despite this error.
Thanks,
Bryan Donlan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQmcVqXhF4rlE0/81AQPNdA//fmL+O3amch3WUfYLZroSNarto/jcQ8WE
NAwthoT+nPkvUcrgoPVPvuJKmKlemBLGqJhz5raOgL8Cu09ttnHh9zi9fz/XD2uR
FFJ603xJDBqHGAG3FVS9EHaTdIFq7kSgVKn90BGdR/gxYR5oCt9DHbOzpI9S0DC5
o580CvtMHRfN1mUwhmxt8oU1E5obRvHlwQ2R4kVl90DBmPNRNXMiWziKjaVyKVng
IXR2ERfCb1HurZfoOlcmhw0Aod7sJpjubf/tm9CDdRIkMdKkeuKBqWbanzHJTlJG
2GOH2Q0CNp1HscFO+DKsCPBMa8zLAPuN0AF//o8URzXElwFiAfQNMjK8hOFVBI2y
6OR/WUvwlXUs47+9QJX7mLTjTJIgcHsxZF9amX37jXKiL5iZyDUJD9wxcFL6A1ut
eVntC36Fp6yx8zROAex0hNx68LHTILUh5bDi3N9gTnpplWpCn02GNkQi18GQLk4Z
Y34WipxwGImbJooGveHh8nH6v/6V4fOy1SaxaV5q4EL563wGrRlIZ9/POgWeJoas
D5S7aJgXCw0GLTJFZCEDORUTCv73HgxR7zSlyqup2qR0Tjqv/JWTCfqCSRLJ8Ktc
PVKf2Alx6ycVFbh9XhQUKWT4tLm1KywpTUvZe+K0DMfw28dbRREnRyFVqbId8JmX
LJgbHTVxRCs=
=Fx+f
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] Usage-string fixes.
From: Junio C Hamano @ 2005-04-21 2:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Usage string fixes to make maintenance easier (only one instance
of a string to update not multiple copies). I've spotted and
corrected inconsistent usage text in diff-tree while doing this.
Also diff-cache and read-tree usage text have been corrected to
match their up-to-date features. Earlier, neither "--cached"
form of diff-cache nor "-m single-merge" form of read-tree were
described.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
commit-tree.c | 14 ++++++--------
diff-cache.c | 6 ++++--
diff-tree.c | 6 ++++--
read-tree.c | 10 ++++++----
4 files changed, 20 insertions(+), 16 deletions(-)
--- ../git.linus/commit-tree.c 2005-04-20 19:00:38.000000000 -0700
+++ ../git.junio/commit-tree.c 2005-04-20 11:41:45.000000000 -0700
@@ -268,15 +268,13 @@
}
/*
- * Having more than two parents may be strange, but hey, there's
- * no conceptual reason why the file format couldn't accept multi-way
- * merges. It might be the "union" of several packages, for example.
- *
- * I don't really expect that to happen, but this is here to make
- * it clear that _conceptually_ it's ok..
+ * Having more than two parents is not strange at all, and this is
+ * how multi-way merges are represented.
*/
#define MAXPARENT (16)
+static char *commit_tree_usage = "commit-tree <sha1> [-p <sha1>]* < changelog";
+
int main(int argc, char **argv)
{
int i, len;
@@ -296,14 +294,14 @@
unsigned int size;
if (argc < 2 || get_sha1_hex(argv[1], tree_sha1) < 0)
- usage("commit-tree <sha1> [-p <sha1>]* < changelog");
+ usage(commit_tree_usage);
check_valid(tree_sha1, "tree");
for (i = 2; i < argc; i += 2) {
char *a, *b;
a = argv[i]; b = argv[i+1];
if (!b || strcmp(a, "-p") || get_sha1_hex(b, parent_sha1[parents]))
- usage("commit-tree <sha1> [-p <sha1>]* < changelog");
+ usage(commit_tree_usage);
check_valid(parent_sha1[parents], "commit");
parents++;
}
--- ../git.linus/diff-cache.c 2005-04-20 19:00:38.000000000 -0700
+++ ../git.junio/diff-cache.c 2005-04-20 19:14:25.000000000 -0700
@@ -215,6 +215,8 @@
return 0;
}
+static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
+
int main(int argc, char **argv)
{
unsigned char tree_sha1[20];
@@ -238,11 +240,11 @@
cached_only = 1;
continue;
}
- usage("diff-cache [-r] [-z] <tree sha1>");
+ usage(diff_cache_usage);
}
if (argc != 2 || get_sha1_hex(argv[1], tree_sha1))
- usage("diff-cache [-r] [-z] <tree sha1>");
+ usage(diff_cache_usage);
tree = read_tree_with_tree_or_commit_sha1(tree_sha1, &size, 0);
if (!tree)
--- ../git.linus/diff-tree.c 2005-04-20 19:00:38.000000000 -0700
+++ ../git.junio/diff-tree.c 2005-04-20 19:14:55.000000000 -0700
@@ -178,6 +178,8 @@
return retval;
}
+static char *diff_tree_usage = "diff-tree [-r] [-z] <tree sha1> <tree sha1>";
+
int main(int argc, char **argv)
{
unsigned char old[20], new[20];
@@ -194,10 +196,10 @@
line_termination = '\0';
continue;
}
- usage("diff-tree [-r] [-z] <tree sha1> <tree sha1>");
+ usage(diff_tree_usage);
}
if (argc != 3 || get_sha1_hex(argv[1], old) || get_sha1_hex(argv[2], new))
- usage("diff-tree <tree sha1> <tree sha1>");
+ usage(diff_tree_usage);
return diff_tree_sha1(old, new, "");
}
--- ../git.linus/read-tree.c 2005-04-20 19:00:38.000000000 -0700
+++ ../git.junio/read-tree.c 2005-04-20 19:15:33.000000000 -0700
@@ -217,6 +217,8 @@
}
}
+static char *read_tree_usage = "read-tree (<sha> | -m <sha1> [<sha2> <sha3>])";
+
int main(int argc, char **argv)
{
int i, newfd, merge;
@@ -236,20 +238,20 @@
if (!strcmp(arg, "-m")) {
int i;
if (stage)
- usage("-m needs to come first");
+ die("-m needs to come first");
read_cache();
for (i = 0; i < active_nr; i++) {
if (ce_stage(active_cache[i]))
- usage("you need to resolve your current index first");
+ die("you need to resolve your current index first");
}
stage = 1;
merge = 1;
continue;
}
if (get_sha1_hex(arg, sha1) < 0)
- usage("read-tree [-m] <sha1>");
+ usage(read_tree_usage);
if (stage > 3)
- usage("can't merge more than two trees");
+ usage(read_tree_usage);
if (read_tree(sha1, "", 0) < 0)
die("failed to unpack tree object %s", arg);
stage++;
^ permalink raw reply
* Re: (rework) [PATCH 3/4] Accept commit in some places when tree is needed.
From: Junio C Hamano @ 2005-04-21 2:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504201807320.2344@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Wed, 20 Apr 2005, Junio C Hamano wrote:
>>
>> Sorry, but the numbering is wrong this should have been [4/5]
>> not [3/4]. The contents should be fine, though.
LT> Applied and pushed out.
Thanks. I have alreay a bugfix and a half X-<.
----------------------------------------------------------------
[PATCH] Fix read-tree-with-tree-or-commit-sha1 function.
Instead of NULL to signal an error, it was returning a garbage.
Also the compiler complains about a type mismatch between signed
and unsigned character array. Both are my bad. Sorry.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
--- l/sha1_file.c 2005-04-20 19:00:38.000000000 -0700
+++ k/sha1_file.c 2005-04-20 18:14:34.000000000 -0700
@@ -174,7 +174,7 @@
void *buffer;
unsigned long isize;
int was_commit = 0;
- char tree_sha1[20];
+ unsigned char tree_sha1[20];
buffer = read_sha1_file(sha1, type, &isize);
@@ -197,7 +197,7 @@
*/
if (!buffer || strcmp(type, "tree")) {
free(buffer);
- return;
+ return NULL;
}
*size = isize;
^ permalink raw reply
* Switching between branches
From: Pavel Roskin @ 2005-04-21 1:42 UTC (permalink / raw)
To: git
Hello!
Perhaps it's a naive question, but how do I switch between branches? I
mean an equivalent of "svn switch" or "cvs update -r branch" that would
reuse the existing working directory.
I tried to switch a git-pasky working directory to the linus branch.
Here's what I tried:
git track linus
git cancel
git pull
git cancel
git merge linus
git cancel
After all that I found that README is still from the pasky branch.
Then I tried "git merge -b pasky linus" - this actually changed the
files to the linus branch, but it didn't remove files specific to
git-pasky. Also, I'm surprised that I had to specify "-b pasky", as if
the currently checked out branch is unknown.
I'm using git-pasky 0.6.2.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Olivier Andrieu @ 2005-04-21 1:42 UTC (permalink / raw)
To: mingo; +Cc: pasky, git
In-Reply-To: <20050420100824.GB25477@elte.hu>
> Ingo Molnar <mingo@elte.hu> [Wed, 20 Apr 2005]:
>
> * Petr Baudis <pasky@ucw.cz> wrote:
>
> > Hi,
> >
> > just FYI, Olivier Andrieu was kind enough to port his monotone-viz
> > tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one
> > from the monotone repository). The tool visualizes the history flow
> > nicely; see
> >
> > http://rover.dkm.cz/~pasky/gitviz1.png
> > http://rover.dkm.cz/~pasky/gitviz2.png
> > http://rover.dkm.cz/~pasky/gitviz3.png
> > http://rover.dkm.cz/~pasky/gitviz4.png
> > http://rover.dkm.cz/~pasky/gitviz5.png
> > http://rover.dkm.cz/~pasky/gitviz6.png
> > http://rover.dkm.cz/~pasky/gitviz7.png
> >
> > for some screenshots.
>
> really nice stuff! Any plans to include it in git-pasky, via 'git gui'
> option or so? Also, which particular version has this included - the
> freshest tarball on the monotone-viz download site doesnt seem to
> include it.
There, here's a tarball :
http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz
and a binary, compiled on Fedora Core 3 :
http://oandrieu.nerim.net/monotone-viz/git-viz.exe
http://oandrieu.nerim.net/monotone-viz/README.git-viz
Please, bear in mind that this is really a hack. Since monotone and
git has very similar concepts, I merely replaced the code that was
accessing monotone's database (sqlite) by some code using git
tools. But the UI still has references to monotone all over the place,
a couple of things won't work, etc.
--
Olivier
^ permalink raw reply
* Re: [PATCH] gittrack.sh accepts invalid branch names
From: Pavel Roskin @ 2005-04-21 1:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050420232110.GA12962@pasky.ji.cz>
Hi, Petr!
On Thu, 2005-04-21 at 01:21 +0200, Petr Baudis wrote:
> Dear diary, on Wed, Apr 20, 2005 at 09:48:30PM CEST, I got a letter
> where Pavel Roskin <proski@gnu.org> told me that...
> > --- a/gittrack.sh
> > +++ b/gittrack.sh
> > @@ -35,7 +35,7 @@ die () {
> > mkdir -p .git/heads
> >
> > if [ "$name" ]; then
> > - grep -q $(echo -e "^$name\t" | sed 's/\./\\./g') .git/remotes || \
> > + sed -ne "/^$name\t/p" .git/remotes | grep -q . || \
> > [ -s ".git/heads/$name" ] || \
> > die "unknown branch \"$name\""
>
> This fixes the acceptance, but not the choice.
>
> What does the grep -q . exactly do? Just sets error code based on
> whether the sed output is non-empty?
Yes.
> What about [] instead?
You'll need another pair of quotes for that:
[ "$(sed -ne "/^$name\t/p" .git/remotes)" ]; echo $?
If I remember correctly from my Autoconf hacking experience, not all
shells like mixing quotes and command substitution, and even bash
treated this differently in different versions. I can do more research,
but it seems just too fragile to me.
Another thing I remember is that "case" would not need quotes. For some
historic reasons, the expression between "case" and "in" is subjected to
command substitution, but not word expansion.
So the patch becomes:
--- a/gittrack.sh
+++ b/gittrack.sh
@@ -35,9 +35,11 @@ die () {
mkdir -p .git/heads
if [ "$name" ]; then
- grep -q $(echo -e "^$name\t" | sed 's/\./\\./g') .git/remotes || \
+ case x$(sed -ne "/^$name\t/p" .git/remotes) in
+ x)
[ -s ".git/heads/$name" ] || \
- die "unknown branch \"$name\""
+ die "unknown branch \"$name\"" ;;
+ esac
echo $name >.git/tracking
Looks rather ugly for my taste, but just in case:
Signed-off-by: Pavel Roskin <proski@gnu.org>
By the way, please check all references to .git/remotes - this bug is
not specific to gittrack.sh.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: wit 0.0.3 - a web interface for git available
From: Kay Sievers @ 2005-04-21 1:28 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Greg KH, Christian Meder, git
In-Reply-To: <20050420094253.GB29910@infradead.org>
On Wed, Apr 20, 2005 at 10:42:53AM +0100, Christoph Hellwig wrote:
> On Tue, Apr 19, 2005 at 09:18:29PM -0700, Greg KH wrote:
> > On Wed, Apr 20, 2005 at 02:29:11AM +0200, Christian Meder wrote:
> > > Hi,
> > >
> > > ok it's starting to look like spam ;-)
> > >
> > > I uploaded a new version of wit to http://www.absolutegiganten.org/wit
> >
> > Why not work together with Kay's tool:
> > http://ehlo.org/~kay/gitweb.pl?project=linux-2.6&action=show_log
>
> That one looks really nice. One major feature I'd love to see would
> be a show all diffs link for a changeset.
It's working now:
http://ehlo.org/~kay/gitweb.pl
Many thanks to Christian Gierke for all the interface work, the nice
layout and the git logo. Thanks for the colored diff to Ken Brush.
The script itself is available on the same box by ftp.
Thanks,
Kay
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Linus Torvalds @ 2005-04-21 1:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Greg KH, git
In-Reply-To: <Pine.LNX.4.58.0504201710500.2344@ppc970.osdl.org>
On Wed, 20 Apr 2005, Linus Torvalds wrote:
>
> Pasky,
> what do you think about this change to "git log"?
Here's a slightly updated version.
It's identical to the previous one, except that it also feeds the result
through "| ${PAGER:-less}" which makes it a lot more useful, in my
opinion.
If you redirect the output to a non-tty, both "less" and "more" do the
right thing and just feed the output straight through. But if the output
is a tty, this makes "git log" a lot more friendly than a quickly
scrolling mess..
Linus
----
gitlog.sh: a496a864f9586e47a4d7bd3ae0af0b3e07b7deb8
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -28,7 +28,7 @@ rev-tree $base | sort -rn | while read t
fi
;;
"")
- echo; cat
+ echo; sed 's/^/ /'
;;
*)
echo $key $rest
@@ -36,5 +36,5 @@ rev-tree $base | sort -rn | while read t
esac
done
- echo -e "\n--------------------------"
-done
+ echo
+done | ${PAGER:-less}
^ permalink raw reply
* Re: (rework) [PATCH 3/4] Accept commit in some places when tree is needed.
From: Linus Torvalds @ 2005-04-21 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6mxgds8.fsf@assigned-by-dhcp.cox.net>
On Wed, 20 Apr 2005, Junio C Hamano wrote:
>
> Sorry, but the numbering is wrong this should have been [4/5]
> not [3/4]. The contents should be fine, though.
Applied and pushed out.
Btw, I edited your subject lines to make them be more specific
to one particular patch.
Linus
^ permalink raw reply
* Re: (rework) [PATCH 3/4] Accept commit in some places when tree is needed.
From: Junio C Hamano @ 2005-04-21 0:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vvf6hgeqj.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
JCH> Updates ls-tree.c to use read_tree_with_tree_or_commit_sha1()
JCH> function. The command can take either tree or commit IDs with
JCH> this patch.
Sorry, but the numbering is wrong this should have been [4/5]
not [3/4]. The contents should be fine, though.
^ permalink raw reply
* (rework) [PATCH 5/5] Accept commit in some places when tree is needed.
From: Junio C Hamano @ 2005-04-21 0:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Updates read-tree to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with
this patch.
The change involves a slight modification of how it recurses down
the tree. Earlier the caller only supplied SHA1 and the recurser
read the object using it, but now it is the caller's responsibility
to read the object and give it to the recurser. This matches the
way recursive behaviour is done in other tree- related commands.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
read-tree.c | 34 ++++++++++++++++++++++++----------
1 files changed, 24 insertions(+), 10 deletions(-)
read-tree.c: 46747b5e99b102ed547e87f55a8ee734c9ddb074
--- a/read-tree.c
+++ b/read-tree.c
@@ -23,16 +23,11 @@ static int read_one_entry(unsigned char
return add_cache_entry(ce, 1);
}
-static int read_tree(unsigned char *sha1, const char *base, int baselen)
+static int read_tree_recursive(void *buffer, const char *type,
+ unsigned long size,
+ const char *base, int baselen)
{
- void *buffer;
- unsigned long size;
- char type[20];
-
- buffer = read_sha1_file(sha1, type, &size);
- if (!buffer)
- return -1;
- if (strcmp(type, "tree"))
+ if (!buffer || strcmp(type, "tree"))
return -1;
while (size) {
int len = strlen(buffer)+1;
@@ -50,10 +45,20 @@ static int read_tree(unsigned char *sha1
int retval;
int pathlen = strlen(path);
char *newbase = malloc(baselen + 1 + pathlen);
+ void *eltbuf;
+ char elttype[20];
+ unsigned long eltsize;
+
+ eltbuf = read_sha1_file(sha1, elttype, &eltsize);
+ if (!eltbuf)
+ return -1;
memcpy(newbase, base, baselen);
memcpy(newbase + baselen, path, pathlen);
newbase[baselen + pathlen] = '/';
- retval = read_tree(sha1, newbase, baselen + pathlen + 1);
+ retval = read_tree_recursive(eltbuf, elttype, eltsize,
+ newbase,
+ baselen + pathlen + 1);
+ free(eltbuf);
free(newbase);
if (retval)
return -1;
@@ -65,6 +70,15 @@ static int read_tree(unsigned char *sha1
return 0;
}
+static int read_tree(unsigned char *sha1, const char *base, int baselen)
+{
+ void *buffer;
+ unsigned long size;
+
+ buffer = read_tree_with_tree_or_commit_sha1(sha1, &size, 0);
+ return read_tree_recursive(buffer, "tree", size, base, baselen);
+}
+
static int remove_lock = 0;
static void remove_lock_file(void)
^ 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