* Re: Git-commits mailing list feed.
From: David Woodhouse @ 2005-04-21 12:23 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: git, linux-kernel, torvalds
In-Reply-To: <1114079347.6277.29.camel@laptopd505.fenrus.org>
On Thu, 2005-04-21 at 12:29 +0200, Arjan van de Ven wrote:
> with BK this was not possible, but could we please have -p added to the
> diff parameters with git ? It makes diffs a LOT more reasable!
With BK this was not possible, but could you please provide your
criticism in 'diff -up' form?
I've done 'perl -pi -e s/-u/-up/ gitdiff-do' as a quick hack to provide
what you want, but a saner fix to make gitdiff-do obey the same
GIT_DIFF_CMD and GIT_DIFF_OPTS environment variables as show-diff.c
would be a more useful answer.
--
dwmw2
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [ANNOUNCEMENT] /Arch/ embraces `git'
From: duchier @ 2005-04-21 11:46 UTC (permalink / raw)
To: Tomas Mraz; +Cc: gnu-arch-dev, talli, git
In-Reply-To: <1114078877.5886.37.camel@perun.redhat.usu>
Tomas Mraz <t8m@centrum.cz> writes:
>> Btw, if, as you indicate above, you do believe that a 1 level indexing should
>> use [0:2], then it doesn't make much sense to me to also suggest that a 2 level
>> indexing should use [0:1] as primary subkey :-)
>
> Why do you think so? IMHO we should always target a similar number of
> files/subdirectories in a directories of the blob archive. So If I
> always suppose that the archive would contain at most 16 millions of
> files then the possible indexing schemes are either 1 level with key
> length 3 (each directory would contain ~4096 files) or 2 level with key
> length 2 (each directory would contain ~256 files).
> Which one is better could be of course filesystem and hardware
> dependent.
First off, I have been using python slice notation, so when I write [0:2] I mean
a key of length 2 (the second index is not included). I now realize that when
you wrote the same you meant to include the second index.
I believe that our disagreement comes from the fact that we are asking different
questions. You consider the question of how to best index a fixed database and
I consider the question of how to best index an ever increasing database.
Now consider why we even want multiple indexing levels: presumably this is
because certain operations become too costly when the size of a directory
becomes too large. If that's not the case, then we might as well just have one
big flat directory - perhaps that's even a viable option for some
filesystems.[1]
[1] there is the additional consideration that a hierarchical system
implements a form of key compression by sharing key prefixes. I don't know at
what point such an effect becomes beneficial, if ever.
Now suppose we need at least one level of indexing. Under an assumption of
uniform distribution of bits in keys, as more objects are added to the database,
the lower levels are going to fill up uniformly. Therefore at those levels we
are again faced with exactly the same indexing problem and thus should come up
with exactly the same answer.
This is why I believe that the scheme I proposed is best: when a bottom level
directory fills up past a certain size, introduce under it an additional level,
and reindex the keys. Since the "certain size" is fixed, this is a constant
time operation.
One could also entertain the idea of reindexing not just a bottom level
directory but an entire subtree of the database (this would be closer to your
idea of finding an optimal reindexing of just this part of the database).
However this has the disadvantage that the operation's cost grows exponentially
with the depth of the tree.
Cheers,
--Denys
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Olivier Andrieu @ 2005-04-21 11:31 UTC (permalink / raw)
To: mingo; +Cc: pasky, git
In-Reply-To: <20050421092120.GA20626@elte.hu>
> Ingo Molnar [Thu, 21 Apr 2005]:
>
> * Olivier Andrieu <oandrieu@nerim.net> wrote:
>
> > There, here's a tarball :
> > http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz
>
> i'm trying to build it under Fedora Core 4 (devel), and there are two
> problems:
>
> - the build scripts seem to assume that "." is in PATH (or that the
> needed viz_style.ml/etc. scripts are in the PATH).
I'm not sure what's wrong here. It works fine for me when I run make
in the source directory and I don't have "." in PATH.
> adding "." to the PATH worked around this issue, a number of files built
> fine, but then it hit the next problem:
>
> ocamlopt.opt -I /usr/lib/ocaml/lablgtk2 -I glib -I crypto -pp -c viz_style.ml
> sh: - : invalid option
> Usage: sh [GNU long option] [option] ...
> sh [GNU long option] [option] script-file ...
> GNU long options:
> [...]
> Preprocessor error
> make: *** [viz_style.cmx] Error 2
That's probably because the configure script didn't find
camlp4. Camlp4 is a preprocessor for ocaml, it's needed for compiling
this file (viz_style.ml). Camlp4 is built with the ocaml compilers but
some package it separately. Try to find and install some ocaml-camlp4
(or camlp4) package and then re-run configure.
The configure script should signal an error when it doesn't find
camlp4, I'll change that.
--
Olivier
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Remi Vanicat @ 2005-04-21 10:47 UTC (permalink / raw)
To: git
In-Reply-To: <20050421092120.GA20626@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * Olivier Andrieu <oandrieu@nerim.net> wrote:
>
>> There, here's a tarball :
>> http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz
>
> i'm trying to build it under Fedora Core 4 (devel), and there are two
> problems:
>
> - the build scripts seem to assume that "." is in PATH (or that the
> needed viz_style.ml/etc. scripts are in the PATH).
>
> adding "." to the PATH worked around this issue, a number of files built
> fine, but then it hit the next problem:
>
> ocamlopt.opt -I /usr/lib/ocaml/lablgtk2 -I glib -I crypto -pp -c viz_style.ml
There should be the command name of the preprocessor after the -pp
option. ocamlopt assume that it should use a preprocessor whose name
is -c, and fail. The problem must be in the configure script or the
makefile. A kick hack may be to launch make with the option
CAMLP4O=camlp4o (well, as it work here, I'm not sure of the exact
problem).
--
Rémi Vanicat
^ permalink raw reply
* Re: Possible problem with git-pasky-0.6.2 (patch: **** Only garbage was found in the patch input.)I
From: Steven Cole @ 2005-04-21 10:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050421071104.GC31910@pasky.ji.cz>
On Thursday 21 April 2005 01:11 am, Petr Baudis wrote:
> Dear diary, on Thu, Apr 21, 2005 at 02:20:27AM CEST, I got a letter
> where Steven Cole <elenstev@mesatop.com> told me that...
> > Actually, I meant "patch -p1 <stuff_from_above".
>
> So, how did it end up?
The file listed in the diff was already patched, so applying that
output does the expected:
[steven@spc git-pasky-0.6.2-damaged]$ patch -p1 <xyzzy.diff
patching file gitcancel.sh
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file gitcancel.sh.rej
>
> Actually, never mind. I forgot that I bring the local changes forward as
> patches instead. So this is Harmless (tm). It means the patch containing
> your local changes has just that kind of git diff output containing
> filename: hash. I will probably just chain grep -v '^[^+-@ ]' in front
> of patch. (Someone starting his filename with a space _deserves_ the
> trouble. ;-)
>
> > But before doing that, I did a fsck-cache as follows, with these results.
> > This seems damaged.
> >
> > [steven@spc git-pasky-0.6.2]$ fsck-cache --unreachable $(cat .git/HEAD)
>
> You can't do just this. In Cogito repository, you may have multiple
> branches, each with different HEAD of course. So you need to
>
> fsck-cache --unreachable $(cat .git/heads/*)
>
[steven@spc git-pasky-0.6.2]$ fsck-cache $(cat .git/heads/*)
root 1bf00e46973f7f1c40bc898f1346a1273f0a347f
dangling commit 2c1a8048d56cfbe0ff8a3d04c12d06f3832e7edc
dangling commit a387546d148df5718a9c53bbe0cbea441e793d98
dangling blob d6ff9de73fc920cf1f27afac82571c4c58526b80
[steven@spc git-pasky-0.6.2]$ ./git-prune-script
Ah, yes. Prune juice.
[steven@spc git-pasky-0.6.2]$ fsck-cache --unreachable $(cat .git/heads/*)
root 1bf00e46973f7f1c40bc898f1346a1273f0a347f
Now, all is well. Sorry for the noise.
Steven
^ permalink raw reply
* HOWTO: PATCH: don't hardcode path-to-bash, use sys/limits.h
From: Klaus Robert Suetterlin @ 2005-04-21 10:23 UTC (permalink / raw)
To: Mike Taht; +Cc: git
In-Reply-To: <4267387A.6040602@timesys.com>
Hi,
I supply a patch that dehardcodes the path to bash (which is not /bin on all computers) and adds sys/limits.h to provide ULONG_MAX.
If this is not the right way to supply patches, or if this email misses some crucial point please tell me so, and supply explanation.
--
Robert Suetterlin (robert@mpe.mpg.de)
phone: (+49)89 / 30000-3546 fax: (+49)89 / 30000-3950
commit 5f6caff82b1f3b5931d92aaff99be6d8dbad10ca
tree d7ea8aeefbbc2ab63cb5acd41b647b1b5f11fb83
parent cd1c034369b73da7503da365fa556aab27004814
author Klaus Robert Suetterlin <krs@xdt04.mpe-garching.mpg.de> 1114078431 +0200
committer Klaus Robert Suetterlin <krs@xdt04.mpe-garching.mpg.de> 1114078431 +0200
Don't hardcode the path-to-bash please.
Index: commit.c
===================================================================
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/commit.c (mode:100644 sha1:eda45d7e15358ed6f2cd0502de2a08987307fc98)
+++ d7ea8aeefbbc2ab63cb5acd41b647b1b5f11fb83/commit.c (mode:100644 sha1:cfe9a8ddf6ee2702e3923cb22240f9f9ed1bd04c)
@@ -1,3 +1,4 @@
+#include <sys/limits.h>
#include "commit.h"
#include "cache.h"
#include <string.h>
Index: gitdiff-do
===================================================================
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/gitdiff-do (mode:100755 sha1:afed4e40b259a61b0f12979ba7326f26743bc553)
+++ d7ea8aeefbbc2ab63cb5acd41b647b1b5f11fb83/gitdiff-do (mode:100755 sha1:218dfabeb4a5dcbd2cf58bd6f672f385690ec397)
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/usr/bin/env bash
#
# Make a diff between two GIT trees.
# Copyright (c) Petr Baudis, 2005
Index: gitlog.sh
===================================================================
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/gitlog.sh (mode:100755 sha1:a496a864f9586e47a4d7bd3ae0af0b3e07b7deb8)
+++ d7ea8aeefbbc2ab63cb5acd41b647b1b5f11fb83/gitlog.sh (mode:100755 sha1:7b3aa8a89bc64273c648920ccd1686859754803e)
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/usr/bin/env bash
#
# Make a log of changes in a GIT branch.
#
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Tomas Mraz @ 2005-04-21 10:21 UTC (permalink / raw)
To: Denys Duchier; +Cc: gnu-arch-dev, talli, git
In-Reply-To: <86d5soa42h.fsf@speedy.lifl.fr>
On Thu, 2005-04-21 at 11:09 +0200, Denys Duchier wrote:
> Tomas Mraz <t8m@centrum.cz> writes:
>
> > If we suppose the maximum number of stored blobs in the order of milions
> > probably the optimal indexing would be 1 level [0:2] indexing or 2
> > levels [0:1] [2:3]. However it would be necessary to do some
> > benchmarking first before setting this to stone.
>
> As I have suggested in a previous message, it is trivial to implement adaptive
> indexing: there is no need to hardwire a specific indexing scheme. Furthermore,
> I suspect that the optimal size of subkeys may well depend on the filesystem.
> My experiments seem to indicate that subkeys of length 2 achieve an excellent
> compromise between discriminatory power and disk footprint on ext2.
>
> Btw, if, as you indicate above, you do believe that a 1 level indexing should
> use [0:2], then it doesn't make much sense to me to also suggest that a 2 level
> indexing should use [0:1] as primary subkey :-)
Why do you think so? IMHO we should always target a similar number of
files/subdirectories in a directories of the blob archive. So If I
always suppose that the archive would contain at most 16 millions of
files then the possible indexing schemes are either 1 level with key
length 3 (each directory would contain ~4096 files) or 2 level with key
length 2 (each directory would contain ~256 files).
Which one is better could be of course filesystem and hardware
dependent.
Of course it might be best to allow adaptive indexing but I think that
first some benchmarking should be made and it's possible that some fixed
scheme could be chosen as optimal.
--
Tomas Mraz <t8m@centrum.cz>
^ permalink raw reply
* Re: [PATCH] Add help details to git help command. (This time with Perl)
From: David Greaves @ 2005-04-21 9:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: Steven Cole, git
In-Reply-To: <20050420233453.GC12962@pasky.ji.cz>
> We've decided to go for the individual scripts directly. :-)
Just to clarify - individual scripts or $0 name handling?
I kinda like one big script - also means we don't need to 'install' it
to get access to Cogito.pm...
>
> Unfortunately, you didn't send the attachments inline, so I can't
> comment on them sensibly.
I'm not sure what you want here; last time you said:
> Thanks. Could you please send the patches signed off and either with
> content-disposition: inline or in the mail body?
So I dug around Thunderbird's config and, this time, from my email on
the git list:
--------------050206040606040908050407
Content-Type: application/x-perl;
name="gitadd.pl"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="gitadd.pl"
> Perhaps my main problem is now style. I'd prefer you do format it alike
> the C sources of git, with 8-chars indentation and such. Also make sure
> you use spaces around (or after) operators. Also, for just few short
> functions I prefer putting the functions before the code itself.
will do
David
^ permalink raw reply
* Searching the changelog in wit
From: Christian Meder @ 2005-04-21 9:24 UTC (permalink / raw)
To: git
Hi,
I didn't release a new version yet but I updated
http://grmso.net:8090 with support for changelog searches.
Philosophy is as mentioned before to use the URI as API to wit.
You can do things like
http://grmso.net:8090/changelog/10d/search/Signed-off-by:%20Andrew%20Morton
(search for change sets in the last 10 days which are signed off by
Andrew Morton)
or
http://grmso.net:8090/changelog/20/search/G..f
(search the last 20 change sets for 4 letter words starting with G and
ending with f)
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: git-viz tool for visualising commit trees
From: Ingo Molnar @ 2005-04-21 9:21 UTC (permalink / raw)
To: Olivier Andrieu; +Cc: pasky, git
In-Reply-To: <20050421.034227.104037433.oandrieu@nerim.net>
* Olivier Andrieu <oandrieu@nerim.net> wrote:
> There, here's a tarball :
> http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz
i'm trying to build it under Fedora Core 4 (devel), and there are two
problems:
- the build scripts seem to assume that "." is in PATH (or that the
needed viz_style.ml/etc. scripts are in the PATH).
adding "." to the PATH worked around this issue, a number of files built
fine, but then it hit the next problem:
ocamlopt.opt -I /usr/lib/ocaml/lablgtk2 -I glib -I crypto -pp -c viz_style.ml
sh: - : invalid option
Usage: sh [GNU long option] [option] ...
sh [GNU long option] [option] script-file ...
GNU long options:
[...]
Preprocessor error
make: *** [viz_style.cmx] Error 2
i've straced the build, and the bug comes from ocamlopt.opt executing:
sh -c "-c 'viz_style.ml'"
which confuses the shell.
i've got ocaml-3.08.3-1, lablgtk-2.4.0-2 installed.
Ingo
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Denys Duchier @ 2005-04-21 9:09 UTC (permalink / raw)
To: Tomas Mraz; +Cc: duchier, gnu-arch-dev, talli, git, torvalds
In-Reply-To: <1114036849.5880.61.camel@perun.redhat.usu>
Tomas Mraz <t8m@centrum.cz> writes:
> If we suppose the maximum number of stored blobs in the order of milions
> probably the optimal indexing would be 1 level [0:2] indexing or 2
> levels [0:1] [2:3]. However it would be necessary to do some
> benchmarking first before setting this to stone.
As I have suggested in a previous message, it is trivial to implement adaptive
indexing: there is no need to hardwire a specific indexing scheme. Furthermore,
I suspect that the optimal size of subkeys may well depend on the filesystem.
My experiments seem to indicate that subkeys of length 2 achieve an excellent
compromise between discriminatory power and disk footprint on ext2.
Btw, if, as you indicate above, you do believe that a 1 level indexing should
use [0:2], then it doesn't make much sense to me to also suggest that a 2 level
indexing should use [0:1] as primary subkey :-)
Cheers,
--
Dr. Denys Duchier - IRI & LIFL - CNRS, Lille, France
AIM: duchierdenys
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Ingo Molnar @ 2005-04-21 7:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Greg KH, git
In-Reply-To: <Pine.LNX.4.58.0504201503050.6467@ppc970.osdl.org>
* Linus Torvalds <torvalds@osdl.org> wrote:
> Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't
> it be cool to just write "cg-<tab><tab>" and see the command choices?
> Or "cg-up<tab>" and get cg-update done for you..
add this line to your ~/.bashrc:
complete -W "add addremote apply cancel ci commit diff export fork help init log ls lsobj lsremote merge pull rm seek status tag track version" git
and you'll get all the argument completions, after "git " (it works on
arguments, after the space). (you can even customize it to list only the
ones you typically use, to make the completion faster) This first showed
up in zsh but now bash knows it too. (see 'Programmable Completions' in
man bash)
Ingo
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [ANNOUNCEMENT] /Arch/ embraces `git'
From: Tomas Mraz @ 2005-04-21 7:49 UTC (permalink / raw)
To: Tom Lord; +Cc: gnu-arch-users, gnu-arch-dev, git
In-Reply-To: <200504202304.QAA17069@emf.net>
On Wed, 2005-04-20 at 16:04 -0700, Tom Lord wrote:
> I think that to a large extent you are seeing artifacts
> of the questionable trade-offs that (reports tell me) the
> ext* filesystems make. With a different filesystem, the
> results would be very different.
Tom, please stop this ext* filesystem bashing ;-) Even with filesystem
which compresses the tails of files into one filesystem block it
wouldn't make a difference that there are potentially (and very probably
even with blob numbers in order of 100000) 65536 directories on the
first level. This doesn't help much in fast reading the first level.
> I'm imagining a blob database containing may revisions of the linux
> kernel. It will contain millions of blobs.
>
> It's fine that some filesystems and some blob operations work fine
> on a directory with millions of files but what about other operations
> on the database? I pity the poor program that has to `readdir' through
> millions of files.
Even with milions of files this key structure doesn't make much sense -
the keys on the first and second levels are too long. However you're
right that the original structure proposed by Linus is too flat.
--
Tomas Mraz <t8m@centrum.cz>
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Petr Baudis @ 2005-04-21 7:36 UTC (permalink / raw)
To: Bryan Donlan; +Cc: git
In-Reply-To: <u6hjj2-jl9.ln1@bd-home-comp.no-ip.org>
Dear diary, on Thu, Apr 21, 2005 at 04:53:33AM CEST, I got a letter
where Bryan Donlan <bdonlan@bd.beginyourfear.com> told me that...
> 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.
Harmless, and fixed in latest.
Thanks for the report,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: wit 0.0.3 - a web interface for git available
From: Greg KH @ 2005-04-21 7:33 UTC (permalink / raw)
To: Kay Sievers; +Cc: Christoph Hellwig, Christian Meder, git
In-Reply-To: <20050421012827.GA13795@vrfy.org>
On Thu, Apr 21, 2005 at 03:28:27AM +0200, Kay Sievers wrote:
> 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.
Very nice, this looks great. And hey, we have a git logo now :)
greg k-h
^ permalink raw reply
* [PATCH] Set AUTHOR_DATE in git-tools
From: David Woodhouse @ 2005-04-21 7:32 UTC (permalink / raw)
To: torvalds; +Cc: git
Entirely untested.
Makefile: eca3a5d5256cca06d86ebb85ec9d3218752ffcd2
applypatch: 397e4a0e506f1c5765767057dfe506154b743b83
--- a/applypatch
+++ b/applypatch
@@ -26,6 +26,7 @@ EDIT=${EDIT:-vi}
export AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' .dotest/info)"
export AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' .dotest/info)"
+export AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' .dotest/info)"
export SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' .dotest/info)"
if [ -n "$signoff" -a -f "$signoff" ]; then
dotest: a3e3d35ae0afa358f01b49eecb358d64c616c3e4
mailinfo.c: c1dcac130530174ec5335d2c752d76403ad1d3ad
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -13,6 +13,7 @@ static char line[1000];
static char name[1000];
static char email[1000];
static char subject[1000];
+static char date[1000];
static char *sanity_check(char *name, char *email)
{
@@ -83,6 +84,11 @@ static void handle_subject(char *line)
strcpy(subject, line);
}
+static void handle_date(char *line)
+{
+ strcpy(date, line);
+}
+
static void add_subject_line(char *line)
{
while (isspace(*line))
@@ -99,6 +105,11 @@ static void check_line(char *line, int l
cont = 0;
return;
}
+ if (!memcmp(line, "Date:", 5) && isspace(line[5])) {
+ handle_date(line+6);
+ cont = 0;
+ return;
+ }
if (!memcmp(line, "Subject:", 8) && isspace(line[8])) {
handle_subject(line+9);
cont = 1;
@@ -107,7 +118,7 @@ static void check_line(char *line, int l
if (isspace(*line)) {
switch (cont) {
case 0:
- fprintf(stderr, "I don't do 'From:' line continuations\n");
+ fprintf(stderr, "I don't do 'From:' or 'Date:' header continuations\n");
break;
case 1:
add_subject_line(line);
@@ -215,7 +226,8 @@ static void handle_rest(void)
cleanup_space(name);
cleanup_space(email);
cleanup_space(sub);
- printf("Author: %s\nEmail: %s\nSubject: %s\n\n", name, email, sub);
+ cleanup_space(date);
+ printf("Author: %s\nEmail: %s\nSubject: %s\nDate: %s\n", name, email, sub, date);
FILE *out = cmitmsg;
do {
mailsplit.c: 9379fbc5e84983e5ea0754a6587cc3490c696c69
--
dwmw2
^ permalink raw reply
* Re: Switching between branches
From: Petr Baudis @ 2005-04-21 7:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1114047759.20044.22.camel@dv>
Dear diary, on Thu, Apr 21, 2005 at 03:42:39AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Hello!
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.
you can't. There was 'git update' (and intermediate never-committed 'git
switch'), but I decided not to support it for now, since I don't have
any compelling usage case for it. Do
git fork my-linus ~/my-linus linus
and you will get a local clone of Linus' branch in ~/my-linus, tracking
and everything.
> 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.
Since git merge's purpose is to _merge_, not _switch_, so it picks the
common ancestor by default; another disadvantage is that this happens on
top of your local tree, but your history will record it as a merge which
shares both linus and my history, which isn't quite right. What is
peculiar, though, is that it didn't remove the files specific to
git-pasky.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Possible problem with git-pasky-0.6.2 (patch: **** Only garbage was found in the patch input.)I
From: Petr Baudis @ 2005-04-21 7:11 UTC (permalink / raw)
To: Steven Cole; +Cc: git
In-Reply-To: <200504201820.27497.elenstev@mesatop.com>
Dear diary, on Thu, Apr 21, 2005 at 02:20:27AM CEST, I got a letter
where Steven Cole <elenstev@mesatop.com> told me that...
> Actually, I meant "patch -p1 <stuff_from_above".
So, how did it end up?
Actually, never mind. I forgot that I bring the local changes forward as
patches instead. So this is Harmless (tm). It means the patch containing
your local changes has just that kind of git diff output containing
filename: hash. I will probably just chain grep -v '^[^+-@ ]' in front
of patch. (Someone starting his filename with a space _deserves_ the
trouble. ;-)
> But before doing that, I did a fsck-cache as follows, with these results.
> This seems damaged.
>
> [steven@spc git-pasky-0.6.2]$ fsck-cache --unreachable $(cat .git/HEAD)
You can't do just this. In Cogito repository, you may have multiple
branches, each with different HEAD of course. So you need to
fsck-cache --unreachable $(cat .git/heads/*)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Petr Baudis @ 2005-04-21 6:49 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Linus Torvalds, Greg KH, git
In-Reply-To: <20050421042833.GA10934@nevyn.them.org>
Dear diary, on Thu, Apr 21, 2005 at 06:28:34AM CEST, I got a letter
where Daniel Jacobowitz <dan@debian.org> told me that...
> 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.
... Plan9. But I guess you won't even have a pager there. ;-)
A little off-topic, anyone knows how to turn off that damn alternate
screen thing on the xterm level? (Or any other level which makes _all_
programs not to use it.)
More seriously, I think Linus' patch is fine; the usage in scripts is
not affected, and alternatives were suggested. When we have cg-admin, I
might even let you set per-repository git-specific PAGER (which you
could set to be even some fancy script which would parse the stuff, open
a cute window and display stuff graphically, or whatever).
Linus, ahem, could you please sign off your patch? :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Mailing list feed.
From: David Woodhouse @ 2005-04-21 6:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 225 bytes --]
If we just strip out the setting of $FROM and $MLIST, the script I use
to feed bk-commits-head@vger.kernel.org is perfectly generic. Petr, can
you include it in the tree so it gets updated as things change please?
--
dwmw2
[-- Attachment #2: gitfeedmaillist.sh --]
[-- Type: application/x-shellscript, Size: 3344 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Greg KH @ 2005-04-21 5:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, 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:
>
>
> 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.
Yeah!
I've gotten tired of counting how many times I forgot to pipe 'git log'
to less already. Doesn't seem to want to be canceled either...
thanks for doing this.
greg k-h
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Sean @ 2005-04-21 4:27 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Linus Torvalds, dan, pasky, greg, git
In-Reply-To: <20050420221451.36c98f62.rddunlap@osdl.org>
On Thu, April 21, 2005 1:14 am, Randy.Dunlap said:
>> 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?
>
This conversation is getting a bit silly, but to answer your question a
pager has a search feature which would let you bypass the first 900,000
lines to find the ones you're interested in.
Cheers,
Sean
^ permalink raw reply
* [PATCH] experimental - Performance of various compressors
From: Mike Taht @ 2005-04-21 5:22 UTC (permalink / raw)
To: Mike Taht; +Cc: git
In-Reply-To: <426736AF.7000900@timesys.com>
Don't apply this patch and change GIT_COMPRESSION unless you know what
you are doing and why you are doing it. You will break an older version
of git. You may break a newer version of git. You have been warned.
I also note that there's a bzlib out there.
cache.h: 828d660ab82bb35a1ca632a2ba4620dc483889bd
--- a/cache.h
+++ b/cache.h
@@ -16,6 +16,8 @@
#include <openssl/sha.h>
#include <zlib.h>
+#define GIT_COMPRESSION Z_BEST_COMPRESSION
+
/*
* Basic data structures for the directory cache
*
sha1_file.c: 754e8b4e9ea8104df48152f875d6b874304e2a62
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -199,7 +199,7 @@ int write_sha1_file(char *buf, unsigned
/* Set it up */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
+ deflateInit(&stream, GIT_COMPRESSION);
size = deflateBound(&stream, len);
compressed = malloc(size);
update-cache.c: a09883541c745c76413c62109a80f40df4b7a7fb
--- a/update-cache.c
+++ b/update-cache.c
@@ -40,7 +40,7 @@ static int index_fd(unsigned char *sha1,
SHA1_Final(sha1, &c);
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
+ deflateInit(&stream, GIT_COMPRESSION);
/*
* ASCII size + nul byte
Mike Taht wrote:
> Just to clarify this was a git add of the linux-2.6.11.7 sources (sorry,
> untimed) , and timing the git commit.
>
> Mo betta data latah.
>
> Mike Taht wrote:
>
>> 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
""His mind is like a steel trap -- full of mice."
-- Foghorn Leghorn"
^ permalink raw reply
* Re: Performance of various compressors
From: Mike Taht @ 2005-04-21 5:14 UTC (permalink / raw)
To: git
In-Reply-To: <426734DE.3040606@timesys.com>
Just to clarify this was a git add of the linux-2.6.11.7 sources (sorry,
untimed) , and timing the git commit.
Mo betta data latah.
Mike Taht wrote:
> 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
"The chief contribution of Protestantism to human thought is its
massive proof
that God is a bore.
-- H.L. Mencken, "The Aesthetic Recoil," American Mercury, July, 1931."
^ permalink raw reply
* 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
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