Mailing list feed.
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 gitfeedmaillist.sh Description: application/shellscript
Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes
Dear diary, on Thu, Apr 21, 2005 at 06:28:34AM CEST, I got a letter where Daniel Jacobowitz [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Set AUTHOR_DATE in git-tools
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
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes
Dear diary, on Thu, Apr 21, 2005 at 04:53:33AM CEST, I got a letter where Bryan Donlan [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes
* Linus Torvalds [EMAIL PROTECTED] wrote: Yeah, yeah, it looks different from cvs update, but dammit, wouldn't it be cool to just write cg-tabtab and see the command choices? Or cg-uptab 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
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 10) 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
Tomas Mraz [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Searching the changelog in wit
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: [EMAIL PROTECTED] The Way-Seeking Mind of a tenzo is actualized by rolling up your sleeves. (Eihei Dogen Zenji) - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add help details to git help command. (This time with Perl)
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
On Thu, 2005-04-21 at 11:09 +0200, Denys Duchier wrote: Tomas Mraz [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
HOWTO: PATCH: don't hardcode path-to-bash, use sys/limits.h
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 ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 commit 5f6caff82b1f3b5931d92aaff99be6d8dbad10ca tree d7ea8aeefbbc2ab63cb5acd41b647b1b5f11fb83 parent cd1c034369b73da7503da365fa556aab27004814 author Klaus Robert Suetterlin [EMAIL PROTECTED] 1114078431 +0200 committer Klaus Robert Suetterlin [EMAIL PROTECTED] 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. # - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible problem with git-pasky-0.6.2 (patch: **** Only garbage was found in the patch input.)I
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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. [EMAIL PROTECTED] 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/*) [EMAIL PROTECTED] git-pasky-0.6.2]$ fsck-cache $(cat .git/heads/*) root 1bf00e46973f7f1c40bc898f1346a1273f0a347f dangling commit 2c1a8048d56cfbe0ff8a3d04c12d06f3832e7edc dangling commit a387546d148df5718a9c53bbe0cbea441e793d98 dangling blob d6ff9de73fc920cf1f27afac82571c4c58526b80 [EMAIL PROTECTED] git-pasky-0.6.2]$ ./git-prune-script Ah, yes. Prune juice. [EMAIL PROTECTED] git-pasky-0.6.2]$ fsck-cache --unreachable $(cat .git/heads/*) root 1bf00e46973f7f1c40bc898f1346a1273f0a347f Now, all is well. Sorry for the noise. Steven - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-viz tool for visualising commit trees
Ingo Molnar [EMAIL PROTECTED] writes: * Olivier Andrieu [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-viz tool for visualising commit trees
Ingo Molnar [Thu, 21 Apr 2005]: * Olivier Andrieu [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
Tomas Mraz [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add DEST Makefile variable
This patch changes the Makefile to add a DEST variable (still defaulting to ~/bin/) so that people (or scripts) can trivially install git Somewhere Else. Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED] --- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/Makefile (mode:100644 sha1:1fef8e4ae93b2abae2ceb69c265c7c8176fe44c0) +++ 265515f9c4f089b1b61e9d2312c4b3babe189618/Makefile (mode:100644 sha1:af90bd4e1d53fa3b930c77a240b4681a0b2a886e) @@ -8,6 +8,7 @@ # break unless your underlying filesystem supports those sub-second times # (my ext3 doesn't). CFLAGS=-g -O3 -Wall +DEST=$(HOME)/bin CC=gcc AR=ar @@ -56,7 +57,7 @@ @chmod +x $@ install: $(PROG) $(GEN_SCRIPT) - install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(HOME)/bin/ + install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DEST)/ clean: rm -f *.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE) - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Missing linefeeds
This patch fixes die() and error() to print linefeeds after the message. Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED] --- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/usage.c (mode:100644 sha1:e774d2ef32726af0707d817cdb63fc8751ddc9d8) +++ 265515f9c4f089b1b61e9d2312c4b3babe189618/usage.c (mode:100644 sha1:21715d88b1a82aa06a3914e3f0e69fb1b61cc442) @@ -26,6 +26,7 @@ va_start(params, err); report(fatal: , err, params); va_end(params); + fputs(\n, stderr); exit(1); } @@ -36,5 +37,6 @@ va_start(params, err); report(error: , err, params); va_end(params); + fputs(\n, stderr); return -1; } - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Missing quotes
gitXnormid.sh should quote its cat-file calls so that nonexisting ssha1 IDs don't result in shell errors. Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED] --- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/gitXnormid.sh (mode:100755 sha1:c0d53afabe8662ebfc3c697faf08b0a2b43c93f7) +++ 265515f9c4f089b1b61e9d2312c4b3babe189618/gitXnormid.sh (mode:100644 sha1:94710a7a2ab945f1fbd5350cb0de15171ae3f582) @@ -41,11 +41,11 @@ exit 1 fi -if [ $type = tree ] [ $(cat-file -t $id) = commit ]; then +if [ $type = tree ] [ $(cat-file -t $id) = commit ]; then id=$(cat-file commit $id | egrep $TREE | cut -d ' ' -f 2) fi -if [ $(cat-file -t $id) != $type ]; then +if [ $(cat-file -t $id) != $type ]; then echo Invalid id: $id 2 exit 1 fi - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add git push
This patch adds the ability to git push, as the obvious converse of
git pull.
Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]
Index: git
===
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/git (mode:100755
sha1:557122dfb05580e4af2c55767f3d6f92b9110edd)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/git (mode:100644
sha1:c32ee037c4dd68f8fa6723cb115644d46810bc89)
@@ -42,6 +42,7 @@
merge [-c] [-b BASE_ID] FROM_ID
patch [COMMIT_ID]
pull[RNAME]
+ push[RNAME]
rm FILE...
seek[COMMIT_ID]
status
@@ -86,6 +87,7 @@
lsremote) gitlsremote.sh $@;;
merge) gitmerge.sh $@;;
pull) gitpull.sh $@;;
+push) gitpush.sh $@;;
patch) gitpatch.sh $@;;
rm) gitrm.sh $@;;
seek) gitseek.sh $@;;
--- /dev/null (tree:42a073eb6b5bb397a3e8768a032463a7fa02e6b9)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/gitpush.sh (mode:100644
sha1:0a658141991c602ca327edb9ab982d7660d7c665)
@@ -0,0 +1,59 @@
+#!/bin/sh
+#
+# Pushes changes from the local GIT repository to remote.
+# Copyright (c) Matthias Urlichs, 2005
+#
+# Takes the remote's name.
+
+name=$1
+
+die () {
+ echo gitpush.sh: $@ 2
+ exit 1
+}
+
+
+[ $name ] || name=$(cat .git/tracking 2/dev/null)
+[ $name ] || die where to push to?
+uri=$(grep $(echo -e ^$name\t | sed 's/\./\\./g') .git/remotes | cut -f 2)
+[ $uri ] || die unknown remote
+
+
+tracking=
+[ -s .git/tracking ] tracking=$(cat .git/tracking)
+
+orig_head=
+if [ $tracking = $name ]; then
+ [ -s .git/HEAD.tracked ] orig_head=$(cat .git/HEAD.tracked)
+else
+ [ -s .git/heads/$name ] orig_head=$(cat .git/heads/$name)
+fi
+
+rsync $RSYNC_FLAGS -Lr $uri/HEAD .git/HEAD_$name
+$id=$(cat .git/HEAD_$name)
+rm .git/HEAD_$name
+
+if [ -z $id ] ; then
+ echo The remote system doesn't have a HEAD file: Doing an initial
upload. 2
+ echo . 2
+elif [ $(cat-file -t $id) != commit ]; then
+ echo The remote system has stuff we don't have: pull first! 2
+ echo Commit ID: $id 2
+ exit 1
+fi
+
+# We already saw the MOTD, thank you very much.
+rsync $RSYNC_FLAGS --ignore-existing --whole-file \
+ -v -r .git/objects $uri | grep -v '^MOTD:'
+
+# FIXME: Warn about conflicting tag names?
+rsync $RSYNC_FLAGS --ignore-existing \
+ -v -r .git/tags $uri 2/dev/null | grep -v '^MOTD:'
+
+# Finally, update the remote HEAD
+rsync $RSYNC_FLAGS -Lr .git/HEAD $uri/HEAD \
+ 2/dev/null | grep -v '^MOTD:'
+
+echo Now up to date.
+exit
+
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Improve usage messages
This patch adds somewhat-improved usage messages to some of Linus' programs.
Specifically, they now handle -? / --help.
Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]
Index: check-files.c
===
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/check-files.c (mode:100644
sha1:7d16691aa9d51b5b4670d5837b3527ee7c7da79c)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/check-files.c (mode:100644
sha1:be904b13659a60eab31787b010a64f2274048a9f)
@@ -40,6 +40,8 @@
{
int i;
+ if(argc == 2 (!strcmp(argv[1],-?) || !strcmp(argv[1],--help)))
+ usage(check-files filename...);
read_cache();
for (i = 1; i argc ; i++)
check_file(argv[i]);
Index: diff-tree.c
===
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/diff-tree.c (mode:100644
sha1:b0122e42631410fa579115f025efc3cab777cde6)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/diff-tree.c (mode:100644
sha1:03fcc2fae2f0b06f3834f0b6e0d8762e70f49f51)
@@ -193,6 +193,11 @@
}
}
+static const char diff_tree_usage[] =
+ diff-tree [ -r (recurse) | -z (\\0-terminate) ]
+ \n\ttree sha1 tree sha1;
+
+
int main(int argc, char **argv)
{
unsigned char old[20], new[20];
@@ -209,11 +214,11 @@
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 [-r] [-z] tree sha1 tree sha1);
+ usage(diff_tree_usage);
commit_to_tree(old);
commit_to_tree(new);
return diff_tree_sha1(old, new, );
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/init-db.c (mode:100644
sha1:dad06351ca35d0d2f68cd9e719c49805386f96fa)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/init-db.c (mode:100644
sha1:4afd436e719b347cdf6b4420c9d926e453f1f95b)
@@ -26,6 +26,9 @@
char *sha1_dir, *path;
int len, i;
+ if(argc != 1)
+ usage(init-db);
+
safe_create_dir(.git);
sha1_dir = getenv(DB_ENVIRONMENT);
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/write-tree.c (mode:100644
sha1:827809dbddbff6dd8cf842641f6db5ad2f3ae07a)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/write-tree.c (mode:100644
sha1:55fe1c75c3065c8d5bef34f4f2e7af7aa147ea9d)
@@ -101,9 +101,13 @@
int main(int argc, char **argv)
{
int i, unmerged;
- int entries = read_cache();
+ int entries;
unsigned char sha1[20];
+ if(argc != 1)
+ usage(write-tree);
+
+ entries = read_cache();
if (entries = 0)
die(write-tree: no cache contents to write);
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-viz tool for visualising commit trees
* Olivier Andrieu [EMAIL PROTECTED] wrote: 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. ah, ok. I installed camlp4-3.08.3-1, and this also solved the other build problem as well that looked like to be a PATH problem. when i run git-viz in a git-controlled directory, it seems to start up fine, but i get an error message: Could not execute dot. Closing that window gives me the ability to do an 'Open', but git-viz does not seem to recognize any of my GIT repositories as such. (perhaps there's some GIT version dependency? I've got Linus' latest greatest installed.) The configure script should signal an error when it doesn't find camlp4, I'll change that. fyi, it also didnt check for ocaml and lablgtk. Ingo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Errors received during git pull from linux-2.6.git, but resulting kernel looks OK.
Executive summary: I received some alarming errors while doing a git pull of the latest kernel from kernel.org, but it appears that all is well. Continue reading for the gory details. I updated my git-pasky tools this morning, by doing git pasky pull, make, make install. Working from a repo converted yesterday using Linus'instructions and subsequently successfully updated once: [EMAIL PROTECTED] linux-2.6-origin]$ git lsremote origin rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git [EMAIL PROTECTED] linux-2.6-origin]$ time git pull origin MOTD: MOTD: Welcome to the Linux Kernel Archive. MOTD: MOTD: Due to U.S. Exports Regulations, all cryptographic software on this MOTD: site is subject to the following legal notice: MOTD: MOTD: This site includes publicly available encryption source code MOTD: which, together with object code resulting from the compiling of MOTD: publicly available source code, may be exported from the United MOTD: States under License Exception TSU pursuant to 15 C.F.R. Section MOTD: 740.13(e). MOTD: MOTD: This legal notice applies to cryptographic software only. MOTD: Please see the Bureau of Industry and Security, MOTD: http://www.bis.doc.gov/ for more information about current MOTD: U.S. regulations. MOTD: receiving file list ... done 18/13b464853cba4439b3c30412059ed6284114a0 8d/a3a306d0c0c070d87048d14a033df02f40a154 a2/755a80f40e5794ddc20e00f781af9d6320fafb sent 181 bytes received 952105 bytes 272081.71 bytes/sec total size is 63450766 speedup is 66.63 receiving file list ... done client: nothing to do: perhaps you need to specify some filenames or the --recursive option? Tree change: 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9:a2755a80f40e5794ddc20e00f781af9d6320fafb *100644-100644 blob 8e5f9bbdf4de94a1bc4b4da8cb06677ce0a57716-8da3a306d0c0c070d87048d14a033df02f40a154 Makefile Tracked branch, applying changes... Fast-forwarding 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 - a2755a80f40e5794ddc20e00f781af9d6320fafb on top of 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9... error: bad index version error: verify header failed read_cache: Invalid argument gitdiff.sh: no files matched error: bad index version error: verify header failed real6m4.771s user0m16.538s sys 0m12.952s [EMAIL PROTECTED] linux-2.6-origin]$ Maybe those errors are harmless. Checking out the new repo: [EMAIL PROTECTED] linux-2.6-origin]$ git export ../linux-2.6.12-rc3 [EMAIL PROTECTED] linux-2.6-origin]$ cd .. [EMAIL PROTECTED] GIT]$ diff -urN linux-2.6.11 linux-2.6.12-rc3 gitdiff-2.6.12-rc3 So, now I have patch-2.6.12-rc3 from kernel.org and gitdiff-2.6.12-rc3 made above. [EMAIL PROTECTED] GIT]$ diffstat gitdiff-2.6.12-rc3 | tail -n 2 sound/usb/usx2y/usbusx2yaudio.c |1 4622 files changed, 271839 insertions(+), 156792 deletions(-) [EMAIL PROTECTED] GIT]$ diffstat patch-2.6.12-rc3 | tail -n 2 sound/usb/usx2y/usbusx2yaudio.c |1 4622 files changed, 271839 insertions(+), 156792 deletions(-) Despite the errors from the git pull, the files look OK. Steven - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching between branches
Hi, Petr Baudis wrote: 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. I do -- I have a project which builds several slightly-customized versions, and I'd like to keep the generated objects around if possible. So I just build one version, then git cancel FOO to the next version, and let the make rules take care of rebuilding what needs to be rebuilt. (cancel already does most of the job anyway, i.e. cleanup stuff which the build process might have changed that it shouldn't have.) Cf. the last of the patches I've just mailed to the list. -- Matthias Urlichs - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes
Petr Baudis wrote: 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.) Change the terminfo entry. The relevant sequence is \E?47h and \E[?47l (save/restore screen) and often it is paired with \E7 and \E8 (save/restore cursor position) and \E[2J (clear screen). [1] Here it was put in the smcup/rmcup capabilities. infocmp term.src vi term.src # either remove the sequences or completely disable the # capabilities by adding a dot in front of them (.rmcup=...). tic term.src Done. Ciao, ET. [1] On strange terminals the escape sequences may be completely different but these are the common ones. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] multi item packed files
Hello,
There have been a few threads on making git more space efficient, and
eventually someone mentions tiny files and space fragmentation. Now that git
object names are decoupled from their compression, it's easier to consider a
a variety of compression algorithms. I whipped up a really silly pack files
together compression.
This would maintain the write once semantics but allow a simple mechanism
where objects are combined together. Choosing which objects to combine is
easy, things put together into update-cache go together. This gives us more
space efficiency and no seeks when reading that packed file off disk.
A natural extension to this is to make update-cache --commit-tree, which
includes the files produced by write-tree and commit-tree into the same
packed file. (I haven't coded this).
The layout works like this:
1) a new object type packed is added.
2) new objects are buffered into a packed object, until it gets to around 32k
in size. This is complete arbitrary but felt about right.
3) The packed object is writting to git storage and then hard links are made
to the packed object from the sha1 filename of each object inside.
4) read_sha1_file is changed to recognize the packed object and search inside.
I did a simple test on the 2.6.11 tree with my 100 patches applied. Without
packing, .git is 99MB. With packing it only needs 62MB:
read speeds don't suffer with this, time to read-tree ; checkout-cache -a -f
from a cold cache were the same. I could get the times lower with the patch
by caching the uncompressed data, since in theory I should be faster here.
Using this on data you care about would be a really bad idea right now. I'm
only posting the patch to get the basic idea across for benchmarking and
discussion.
-chris
diff -ur linus.back/cache.h linus/cache.h
--- linus.back/cache.h 2005-04-21 11:05:27.971607944 -0400
+++ linus/cache.h 2005-04-21 09:35:47.173613576 -0400
@@ -109,7 +109,7 @@
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern void * map_sha1_file(const unsigned char *sha1, unsigned long *size);
-extern void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size);
+extern void * unpack_sha1_file(const unsigned char *sha1, void *map, unsigned long mapsize, char *type, unsigned long *size);
extern void * read_sha1_file(const unsigned char *sha1, char *type, unsigned long *size);
extern int write_sha1_file(char *buf, unsigned len, unsigned char *return_sha1);
extern int check_sha1_signature(unsigned char *sha1, void *buf, unsigned long size, const char *type);
@@ -117,6 +117,10 @@
/* Convert to/from hex/sha1 representation */
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
+extern int pack_sha1_buffer(void *buf, unsigned long buf_len,
+ unsigned char *returnsha1, char **dest,
+ unsigned long *dest_size);
+int write_packed_buffer(void *buf, unsigned long len);
/* General helper functions */
extern void usage(const char *err);
diff -ur linus.back/cat-file.c linus/cat-file.c
--- linus.back/cat-file.c 2005-04-21 11:05:27.971607944 -0400
+++ linus/cat-file.c 2005-04-21 10:04:29.871723656 -0400
@@ -23,7 +23,7 @@
type[size] = '\n';
size++;
} else if (strcmp(type, argv[1])) {
- die(cat-file %s: bad tag, argv[2]);
+ die(cat-file %s: bad tag (%s: %s), argv[2], type, argv[1]);
}
while (size 0) {
diff -ur linus.back/fsck-cache.c linus/fsck-cache.c
--- linus.back/fsck-cache.c 2005-04-21 11:05:27.974607488 -0400
+++ linus/fsck-cache.c 2005-04-21 09:14:03.139856840 -0400
@@ -85,7 +85,7 @@
if (map) {
char type[100];
unsigned long size;
- void *buffer = unpack_sha1_file(map, mapsize, type, size);
+ void *buffer = unpack_sha1_file(sha1, map, mapsize, type, size);
if (!buffer)
return -1;
if (check_sha1_signature(sha1, buffer, size, type) 0)
diff -ur linus.back/sha1_file.c linus/sha1_file.c
--- linus.back/sha1_file.c 2005-04-21 11:05:27.978606880 -0400
+++ linus/sha1_file.c 2005-04-21 10:41:51.280977656 -0400
@@ -116,7 +116,8 @@
return map;
}
-void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size)
+void * unpack_sha1_file(const unsigned char *sha1, void *map,
+ unsigned long mapsize, char *type, unsigned long *size)
{
int ret, bytes;
z_stream stream;
@@ -134,12 +135,12 @@
ret = inflate(stream, 0);
if (sscanf(buffer, %10s %lu, type, size) != 2)
return NULL;
-
bytes = strlen(buffer) + 1;
buf = malloc(*size);
- if (!buf)
+ if (!buf) {
+ perror(malloc);
return NULL;
-
+ }
memcpy(buf, buffer + bytes, stream.total_out - bytes);
bytes = stream.total_out - bytes;
if (bytes *size ret == Z_OK) {
@@ -149,6 +150,36 @@
/* nothing */;
}
inflateEnd(stream);
+
+ /* we've found a packed object */
+ if (strcmp(type, packed) == 0) {
+ char *p = buf;
+ if (!sha1)
+ return NULL;
+
Re: [PATCH] multi item packed files
On Thu, 21 Apr 2005, Chris Mason wrote: There have been a few threads on making git more space efficient, and eventually someone mentions tiny files and space fragmentation. Now that git object names are decoupled from their compression, it's easier to consider a a variety of compression algorithms. I whipped up a really silly pack files together compression. Careful. This is something that needs history to tell whether it's effective. In particular, if one file changes and another one does not, your packed archive now ends up being a new blob, so while you saved space by having just one blob for the object, in reality you didn't save any space at all because with the x files changing, you just guaranteed that the packed blob changes x times more often. See? Your packing in space ends up also resulting in packing in time, and you didn't actually win anything. (If you did a good job of packing, you hopefully didn't _lose_ anything either - you needed 1:x number of objects that took 1:x the space if the packing ended up perfect - but since you needed x times more of these objects unless they all change together, you end up with exactly the same space usage). So the argument is: you can't lose with the method, and you _can_ win. Right? Wrong. You most definitely _can_ lose: you end up having to optimize for one particular filesystem blocking size, and you'll lose on any other filesystem. And you'll lose on the special filesystem of network traffic, which is byte-granular. I don't want to pee on peoples parades, and I'm all for gathering numbers, but the thing is, the current git isn't actually all that bad, and I guarantee that it's hard to make it better without using delta representation. And the current thing is really really simple. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Errors received during git pull from linux-2.6.git, but resulting kernel looks OK.
Dear diary, on Thu, Apr 21, 2005 at 03:55:26PM CEST, I got a letter where Steven Cole [EMAIL PROTECTED] told me that... Executive summary: I received some alarming errors while doing a git pull of the latest kernel from kernel.org, but it appears that all is well. Continue reading for the gory details. It seems that the directory cache format changed since you pulled the last time. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Pasky problem with 'git init URL'
Hi,
Just pulled linux-2.6.git, and got this:
New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320
Tracked branch, applying changes...
Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 -
3a6fd752a50af92765853879f4a11cc0cfcd0320
to a2755a80f40e5794ddc20e00f781af9d6320fafb...
Enter commit message, terminated by ctrl-D on a separate line:
Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320
Weird thing was that I made no changes.
Digging a bit deeper, I saw that .git/HEAD was a symlink
to .git/heads/master, and the tracked branch was 'origin'. Due to the
fact that Linus only have a .git/heads/master on his rsync, and this
thus updated to the new sha1, but the 'origin' (and tracked) head is
still pointing to an older sha1 caused this confusion.
I replicated the linux tree via:
git init URL
So I had a look at gitinit.sh, which first creates the .git/heads/master
and symlinks HEAD to it, then on seeing a URL was supplied, creates
a .git/heads/origin, track it, but do *not* change the .git/HEAD
symlink ... Is this intended? I see also that gittrack.sh do not update
the HEAD symlink ... Is this also intended?
I guess a solution is to either just use 'master', and do not do the
'origin' head, or to update the HEAD symlink. I however do not think
this is very generic, especially if the remote repo do not call their
main head 'master' - so it might be better to check what it have
in .git/heads, and if only one, use that as the main and tracked head,
else do nothing and tell the user to decide what head to track, etc.
The last option however brings a problem or two. First, how do you do
the multi-head thing? Maybe add a command 'git lsheads' (and while at
it, also add 'git lstags'?)? Secondly, if there was more than one head,
the local copy needs to be checked out ... don't know if 'git cancel' is
the logical thing the user will think to do ('git clone' perhaps?) ...
I think it might be a good time to start thinking and putting to text
what commands is really needed, what they should be called, and how
exactly they should behave before it gets much later in the game.
Anyhow, suggestions/comments welcome.
Thanks,
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] multi item packed files
On Thursday 21 April 2005 11:41, Linus Torvalds wrote: On Thu, 21 Apr 2005, Chris Mason wrote: There have been a few threads on making git more space efficient, and eventually someone mentions tiny files and space fragmentation. Now that git object names are decoupled from their compression, it's easier to consider a a variety of compression algorithms. I whipped up a really silly pack files together compression. Careful. This is something that needs history to tell whether it's effective. In particular, if one file changes and another one does not, your packed archive now ends up being a new blob, so while you saved space by having just one blob for the object, in reality you didn't save any space at all because with the x files changing, you just guaranteed that the packed blob changes x times more often. The packed blob lives in git but never makes it into a tree. Lets say that I have a packed blob with files a, b, c, and another packed blob with files x, y, z. Someone changes files, b and z and then runs update-cache b z. Now we have 2 unchanged packed blobs: a, b, c, x, y, z, and one new packed blob: b_new, z_new. This means that in order for the packing to help, we have to change more then one file at a time. That's why it would be good to have update-cache include the write-tree and commit-tree. See? Your packing in space ends up also resulting in packing in time, and you didn't actually win anything. (If you did a good job of packing, you hopefully didn't _lose_ anything either - you needed 1:x number of objects that took 1:x the space if the packing ended up perfect - but since you needed x times more of these objects unless they all change together, you end up with exactly the same space usage). So the argument is: you can't lose with the method, and you _can_ win. Right? Wrong. You most definitely _can_ lose: you end up having to optimize for one particular filesystem blocking size, and you'll lose on any other filesystem. And you'll lose on the special filesystem of network traffic, which is byte-granular. The patch does have one extra directory entry (for the packed blob), but from a network point of view roughly the same number of bytes should be copied. The hardlinks won't play nice with rsync though, soft links might be better. packing isn't just about filesystem block sizes, it's about locality. All the hashing means pretty much every access in git is random. With packing we can at least try to put a single changeset together on disk. Right now it doesn't matter much, but when the git tree is 6GB in two years we'll feel the pain. I don't want to pee on peoples parades, and I'm all for gathering numbers, but the thing is, the current git isn't actually all that bad, and I guarantee that it's hard to make it better without using delta representation. And the current thing is really really simple. Grin, if I thought you wanted the patch I might have tried to pretty it up a little. The point is that all the discussions about ways to make git use less space end up stuck in but wait, that'll make a bunch of tiny files and filesystems aren't good at that. So I believe some kind of packing is a required building block for any kind of delta storage. -chris - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Improve usage messages
Dear diary, on Thu, Apr 21, 2005 at 02:41:52PM CEST, I got a letter
where Matthias Urlichs [EMAIL PROTECTED] told me that...
This patch adds somewhat-improved usage messages to some of Linus' programs.
Specifically, they now handle -? / --help.
-? is pretty non-standard. Any problem with going for -h?
Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]
Index: check-files.c
===
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/check-files.c (mode:100644
sha1:7d16691aa9d51b5b4670d5837b3527ee7c7da79c)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/check-files.c (mode:100644
sha1:be904b13659a60eab31787b010a64f2274048a9f)
@@ -40,6 +40,8 @@
{
int i;
+ if(argc == 2 (!strcmp(argv[1],-?) || !strcmp(argv[1],--help)))
(style-education-hat
+ if (argc == 2 (!strcmp(argv[1], -?) || !strcmp(argv[1], --help)))
)
+ usage(check-files filename...);
Let's either do filename* or FILE..., this mixing doesn't look good.
read_cache();
for (i = 1; i argc ; i++)
check_file(argv[i]);
Index: diff-tree.c
===
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/diff-tree.c (mode:100644
sha1:b0122e42631410fa579115f025efc3cab777cde6)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/diff-tree.c (mode:100644
sha1:03fcc2fae2f0b06f3834f0b6e0d8762e70f49f51)
@@ -193,6 +193,11 @@
}
}
+static const char diff_tree_usage[] =
+ diff-tree [ -r (recurse) | -z (\\0-terminate) ]
+ \n\ttree sha1 tree sha1;
I'd say this is pretty confusnig. Just describe the parameters on
folowing lines in more detail, if you must.
+
+
int main(int argc, char **argv)
{
unsigned char old[20], new[20];
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching between branches
Dear diary, on Thu, Apr 21, 2005 at 04:12:49PM CEST, I got a letter where Matthias Urlichs [EMAIL PROTECTED] told me that... Hi, Petr Baudis wrote: 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. I do -- I have a project which builds several slightly-customized versions, and I'd like to keep the generated objects around if possible. So I just build one version, then git cancel FOO to the next version, and let the make rules take care of rebuilding what needs to be rebuilt. I suppose we could do with git switch then. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes
Dear diary, on Thu, Apr 21, 2005 at 04:21:00PM CEST, I got a letter where Edgar Toernig [EMAIL PROTECTED] told me that... Petr Baudis wrote: 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.) Change the terminfo entry. That's why I asked for how to do it on the xterm level. Some programs don't care about term(cap|info). And I may not be root. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Improve usage messages
Petr Baudis wrote: Dear diary, on Thu, Apr 21, 2005 at 02:41:52PM CEST, I got a letter where Matthias Urlichs [EMAIL PROTECTED] told me that... This patch adds somewhat-improved usage messages to some of Linus' programs. Specifically, they now handle -? / --help. just so you know, the intention of doing the README.reference was to get all the docs in one place and then go back to the c and update the usage() to be consistent. I started by doing grep usage *.c :) I'm actually working on diff-cache as we speak... David - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-viz tool for visualising commit trees
Dear diary, on Thu, Apr 21, 2005 at 04:47:16PM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] told me that... is the 'diff with ancestor' feature supposed to work at this early stage? (it just does nothing when i click on it. It correctly offers two ancestors for merge points, but does nothing there either.) Doesn't it require git diff? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
zlib version, list archives
I downloaded git-pasky 0.6.2. I cannot compile it because my zlib version is 1.1.4 and git-pasky relies on function deflateBound() which wasn't introduced until zlib version 1.2.x Is there a patch out there to work around this and maybe conditionally compile based on the zlib version? I apologize in advance if this has already been asked, I cannot find an archive of this list. Could somebody point me to one? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zlib version, list archives
On Thu, 21 Apr 2005 12:19:32 -0500 Joel Schopp wrote: | I downloaded git-pasky 0.6.2. I cannot compile it because my zlib | version is 1.1.4 and git-pasky relies on function deflateBound() which | wasn't introduced until zlib version 1.2.x Is there a patch out there | to work around this and maybe conditionally compile based on the zlib | version? | | I apologize in advance if this has already been asked, I cannot find an | archive of this list. Could somebody point me to one? http://marc.theaimsgroup.com/?l=git or http://dir.gmane.org/gmane.comp.version-control.git --- ~Randy - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
checkout-cache update
I just pushed out this very useful thing to checkout-cache, which is best just described by its commit log: Add the ability to prefix something to the pathname to checkout-cache.c This basically makes it trivial to use checkout-cache as a export as tree function. Just read the desired tree into the index, and do a checkout-cache --prefix=export-dir/ -a and checkout-cache will export the cache into the specified directory. NOTE! The final / is important. The exported name is literally just prefixed with the specified string, so you can also do something like checkout-cache --prefix=.merged- Makefile to check out the currently cached copy of Makefile into the file .merged-Makefile. Basically, I can do a a git-0.6 release with a simple checkout-cache --prefix=../git-0.6/ -a which basically says: check out all files, but use the prefix ../git-0.6/ before the filename when you do so. Then I just do cd .. tar czvf git-0.6.tar.gz git-0.6 and I'm done. Very cool, very simple, and _extremely_ fast. Doing the tree export (not the tar) for the whole kernel takes two minutes in the cold-cache case (not so wonderful, but acceptable), and 4.6 _seconds_ in the hot-cache case (pretty damn impressive, I say). (The compressng tar then takes about 20 seconds for me, and that's obviously all from the cache, since I just wrote it out). NOTE! The fact that the '/' at the end of the --prefix= thing is meaningful can be very confusing, I freely admit. But it does end up being potentially quite useful, and you're likely to script usage of this anyway into git export or something, so... Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
GIT_INDEX_FILE environment variable
This checkin goes along with the previous one, and makes it easier to use all the normal git operations on temporary index files: Add support for a GIT_INDEX_FILE environment variable. We use that to specify alternative index files, which can be useful if you want to (for example) generate a temporary index file to do some specific operation that you don't want to mess with your main one with. It defaults to the regular .git/index if it hasn't been specified. and it's particularly useful for doing things like read a tree into a temporary index file, and write the result out. For example, say that you wanted to know what the Makefile looked like in a particular release, you could do GIT_INDEX_FILE=.tmp-index read-tree $release GIT_INDEX_FILE=.tmp-index checkout-cache --prefix=old- Makefile rm .tmp-index and you're done. Your old Makefile version is now in old-Makefile (and this is also where it's nice that checkout-cache refuses to overwrite existing files by default: if you forgot or messed up the prefix, it's all good). You can also use it to test merges without screwing up your old index file in case something goes wrong. Did I already happen to mention that I think that the git model is the best model ever, and that I'm just not an incredibly good-looking hunk and becomingly modest, I'm smart too? Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT_INDEX_FILE environment variable
On Thu, 21 Apr 2005, Linus Torvalds wrote: Did I already happen to mention that I think that the git model is the best model ever, and that I'm just not an incredibly good-looking hunk and becomingly modest, I'm smart too? You forgot, *again*, to take your medications !! - Davide - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/19] summary of patch set
Tonight I did a bunch of tiny steps towards making the cache management code behave more like a library. There are no longer any global variables in read-cache.c. Nothing ever uses more than one cache yet, but I can see how it might simplify some of the merge code. They're also visible here: http://gameboy2.puremagic.com:8090/ [PATCH 01/19] write_cache api signature change, isolate active_cache and active_nr inside read-cache.c [PATCH 02/19] Add new api's to front the active_cache and active_nr cache internals [PATCH 03/19] convert show-diff.c to use new cache hiding api's [PATCH 04/19] Migrate update-cache.c to use the new cache api's [PATCH 05/19] migrate checkout-cache.c to the new cache api's [PATCH 06/19] migrate show-files.c to the new cache api's [PATCH 07/19] migrate merge-cache.c over to the new cache api's [PATCH 08/19] rename remove_entry_at to remove_cache_entry_at and expose as a public api [PATCH 09/19] migrate read-tree.c to the new cache api's [PATCH 10/19] migrate check-files.c to the new cache api's [PATCH 11/19] migrate write-tree.c to use the new cache api's [PATCH 12/19] fix up diff-cache.c to use new cache api's [PATCH 13/19] Remove active_cache, active_nr, and active_alloc from public view [PATCH 14/19] move cache_header out of the public view [PATCH 15/19] introduce a cache struct and move the various cache globals into it. [PATCH 16/19] change all call sites that use the return value of read_cache to get the # of cache entries. [PATCH 17/19] temporarily change add_cache_entry to create an empty cache on demand [PATCH 18/19] rename cache_match_stat to ce_match_stat to match other cache_entry related functions/macros [PATCH 19/19] the end goal of the last dozen or so commits, there's no longer a global cache variable [PATCH 01-19/19] All of the above combined - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/19] write_cache api signature change, isolate active_cache and active_nr inside read-cache.c
tree f45fd10b26bf98349b63427805a96bd0551cad74
parent 43fdf65356c50483233cb3d6e391b0849b2a2a50
parent cd1c034369b73da7503da365fa556aab27004814
author Brad Roberts [EMAIL PROTECTED] 1114072582 -0700
committer Brad Roberts [EMAIL PROTECTED] 1114072582 -0700
[PATCH] write_cache api signature change, isolate active_cache and active_nr
inside read-cache.c
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
cache.h|2 +-
read-cache.c |8
read-tree.c|2 +-
update-cache.c |2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
Index: cache.h
===
--- cd1c034369b73da7503da365fa556aab27004814:1/cache.h (mode:100644
sha1:828d660ab82bb35a1ca632a2ba4620dc483889bd)
+++ 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/cache.h (mode:100644
sha1:a101870e4a002a2548d88544a77bedad21668203)
@@ -88,7 +88,7 @@
/* Initialize and use the cache information */
extern int read_cache(void);
-extern int write_cache(int newfd, struct cache_entry **cache, int entries);
+extern int write_cache(int newfd);
extern int cache_name_pos(const char *name, int namelen);
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
Index: read-cache.c
===
--- cd1c034369b73da7503da365fa556aab27004814:1/read-cache.c (mode:100644
sha1:2f6a4aa18d48865db80459a3459ac4384b0b16c8)
+++ 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/read-cache.c (mode:100644
sha1:349ebd1f8a0a95bf462bb1dfd3d9dfb50628829c)
@@ -267,7 +267,7 @@
return 0;
}
-int write_cache(int newfd, struct cache_entry **cache, int entries)
+int write_cache(int newfd)
{
SHA_CTX c;
struct cache_header hdr;
@@ -275,14 +275,14 @@
hdr.hdr_signature = htonl(CACHE_SIGNATURE);
hdr.hdr_version = htonl(2);
- hdr.hdr_entries = htonl(entries);
+ hdr.hdr_entries = htonl(active_nr);
SHA1_Init(c);
if (ce_write(c, newfd, hdr, sizeof(hdr)) 0)
return -1;
- for (i = 0; i entries; i++) {
- struct cache_entry *ce = cache[i];
+ for (i = 0; i active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
if (ce_write(c, newfd, ce, ce_size(ce)) 0)
return -1;
}
Index: read-tree.c
===
--- cd1c034369b73da7503da365fa556aab27004814:1/read-tree.c (mode:100644
sha1:620f3f74eb56366fca8be4d28d7b04875c0fa90c)
+++ 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/read-tree.c (mode:100644
sha1:4ad48f5c409ead69407d2b5feab4466cdcb499f8)
@@ -261,7 +261,7 @@
die(just how do you expect me to merge %d trees?,
stage-1);
}
}
- if (write_cache(newfd, active_cache, active_nr) ||
+ if (write_cache(newfd) ||
rename(.git/index.lock, .git/index))
die(unable to write new index file);
remove_lock = 0;
Index: update-cache.c
===
--- cd1c034369b73da7503da365fa556aab27004814:1/update-cache.c (mode:100644
sha1:a09883541c745c76413c62109a80f40df4b7a7fb)
+++ 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/update-cache.c (mode:100644
sha1:585951108c57a64bb774114d289d81fd7fd22768)
@@ -341,7 +341,7 @@
if (add_file_to_cache(path))
die(Unable to add %s to database, path);
}
- if (write_cache(newfd, active_cache, active_nr) ||
+ if (write_cache(newfd) ||
rename(.git/index.lock, .git/index))
die(Unable to write new cachefile);
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/19] Add new api's to front the active_cache and active_nr cache internals
tree ebbf2c037e68116c4ff934f140ca12cdbe13311d
parent 77de9e0b7a81ddc22526c9415f0273171f631d3f
author Brad Roberts [EMAIL PROTECTED] 1114073146 -0700
committer Brad Roberts [EMAIL PROTECTED] 1114073146 -0700
[PATCH] Add new api's to front the active_cache and active_nr cache internals
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
cache.h |3 +++
read-cache.c | 15 +++
2 files changed, 18 insertions(+)
Index: cache.h
===
--- 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/cache.h (mode:100644
sha1:a101870e4a002a2548d88544a77bedad21668203)
+++ 27fc41dcd4aecafdaf583f3962697a2fa3fb6480:1/cache.h (mode:100644
sha1:9ad6e805eafcb213c6bb4b1f8ff4d4e053fa6067)
@@ -93,6 +93,9 @@
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
extern int cache_match_stat(struct cache_entry *ce, struct stat *st);
+extern int get_num_cache_entries();
+extern struct cache_entry * get_cache_entry(int pos);
+extern void set_cache_entry(struct cache_entry *ce, int pos);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
Index: read-cache.c
===
--- 77de9e0b7a81ddc22526c9415f0273171f631d3f:1/read-cache.c (mode:100644
sha1:349ebd1f8a0a95bf462bb1dfd3d9dfb50628829c)
+++ 27fc41dcd4aecafdaf583f3962697a2fa3fb6480:1/read-cache.c (mode:100644
sha1:6689df59d5a93e0503d7c80c114efbd16de826f3)
@@ -110,6 +110,21 @@
return ce_namelen(b) == len !memcmp(a-name, b-name, len);
}
+int get_num_cache_entries()
+{
+ return active_nr;
+}
+
+struct cache_entry * get_cache_entry(int pos)
+{
+ return active_cache[pos];
+}
+
+void set_cache_entry(struct cache_entry *ce, int pos)
+{
+ active_cache[pos] = ce;
+}
+
int add_cache_entry(struct cache_entry *ce, int ok_to_add)
{
int pos;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/19] migrate merge-cache.c over to the new cache api's
tree 8140acee0f9c57bfd87f40d1f99242c772afcdf2
parent 32efd81a3292a923ce5b5ae2e39ffefd0b08664d
author Brad Roberts [EMAIL PROTECTED] 1114074631 -0700
committer Brad Roberts [EMAIL PROTECTED] 1114074631 -0700
[PATCH] migrate merge-cache.c over to the new cache api's
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
merge-cache.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
Index: merge-cache.c
===
--- 32efd81a3292a923ce5b5ae2e39ffefd0b08664d:1/merge-cache.c (mode:100644
sha1:35a0d588178aa5371399458b1a15519cffd645b8)
+++ e2acfff5e544a8c6769a9e665927092b3edd7579:1/merge-cache.c (mode:100644
sha1:c2f96e7652a2aea9417c3790bfe9ab14ffcdb12f)
@@ -30,7 +30,7 @@
{
int found;
- if (pos = active_nr)
+ if (pos = get_num_cache_entries())
die(merge-cache: %s not in the cache, path);
arguments[0] = pgm;
arguments[1] = ;
@@ -40,7 +40,7 @@
found = 0;
do {
static char hexbuf[4][60];
- struct cache_entry *ce = active_cache[pos];
+ struct cache_entry *ce = get_cache_entry(pos);
int stage = ce_stage(ce);
if (strcmp(ce-name, path))
@@ -48,7 +48,7 @@
found++;
strcpy(hexbuf[stage], sha1_to_hex(ce-sha1));
arguments[stage] = hexbuf[stage];
- } while (++pos active_nr);
+ } while (++pos get_num_cache_entries());
if (!found)
die(merge-cache: %s not in the cache, path);
run_program();
@@ -70,8 +70,8 @@
static void merge_all(void)
{
int i;
- for (i = 0; i active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
+ for (i = 0; i get_num_cache_entries(); i++) {
+ struct cache_entry *ce = get_cache_entry(i);
if (!ce_stage(ce))
continue;
i += merge_entry(i, ce-name)-1;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/19] migrate read-tree.c to the new cache api's
tree 7a3cab4437a849857cc899017b97eea1787a6ce1
parent 099367f98cc063c33733d15c7a2d9737bea853d9
author Brad Roberts [EMAIL PROTECTED] 1114077044 -0700
committer Brad Roberts [EMAIL PROTECTED] 1114077044 -0700
[PATCH] migrate read-tree.c to the new cache api's
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
read-tree.c | 52 +++-
1 files changed, 31 insertions(+), 21 deletions(-)
Index: read-tree.c
===
--- 099367f98cc063c33733d15c7a2d9737bea853d9:1/read-tree.c (mode:100644
sha1:4ad48f5c409ead69407d2b5feab4466cdcb499f8)
+++ 50a6596bf7f51ecd598cd02d9c44379a9b92044a:1/read-tree.c (mode:100644
sha1:ad9128f26613a82361475516dd0f2b470f4ce4b3)
@@ -146,26 +146,30 @@
return NULL;
}
-static void trivially_merge_cache(struct cache_entry **src, int nr)
+/* rather than doing the 'right' thing of deleting entries as we merge,
+ * walk dst through the cache, overwriting entries as we go and at the
+ * end truncate the size of the cache */
+static void trivially_merge_cache()
{
static struct cache_entry null_entry;
- struct cache_entry **dst = src;
struct cache_entry *old = null_entry;
+ int src = 0, dst = 0, nr = get_num_cache_entries();
- while (nr) {
+ while (src nr) {
struct cache_entry *ce, *result;
- ce = src[0];
+ ce = get_cache_entry(src);
/* We throw away original cache entries except for the stat
information */
if (!ce_stage(ce)) {
old = ce;
src++;
- nr--;
- active_nr--;
continue;
}
- if (nr 2 (result = merge_entries(ce, src[1], src[2])) !=
NULL) {
+ if ((src (nr - 2))
+ (result = merge_entries(ce,
+ get_cache_entry(src + 1),
+ get_cache_entry(src + 2))) != NULL)
{
/*
* See if we can re-use the old CE directly?
* That way we get the uptodate stat info.
@@ -175,40 +179,46 @@
ce = result;
ce-ce_flags = ~htons(CE_STAGEMASK);
src += 2;
- nr -= 2;
- active_nr -= 2;
}
- *dst++ = ce;
+ set_cache_entry(ce, dst);
+ dst++;
src++;
+ }
+ /* this could be replaced by a truncate api */
+ while (nr dst) {
nr--;
+ remove_cache_entry_at(nr);
}
}
-static void merge_stat_info(struct cache_entry **src, int nr)
+static void merge_stat_info()
{
static struct cache_entry null_entry;
- struct cache_entry **dst = src;
struct cache_entry *old = null_entry;
+ int src = 0, dst = 0, nr = get_num_cache_entries();
- while (nr) {
+ while (src nr) {
struct cache_entry *ce;
- ce = src[0];
+ ce = get_cache_entry(src);
/* We throw away original cache entries except for the stat
information */
if (!ce_stage(ce)) {
old = ce;
src++;
- nr--;
- active_nr--;
continue;
}
if (path_matches(ce, old) same(ce, old))
*ce = *old;
ce-ce_flags = ~htons(CE_STAGEMASK);
- *dst++ = ce;
+ set_cache_entry(ce, dst);
+ dst++;
src++;
+ }
+ /* this could be replaced by a truncate api */
+ while (nr dst) {
nr--;
+ remove_cache_entry_at(nr);
}
}
@@ -233,8 +243,8 @@
if (stage)
usage(-m needs to come first);
read_cache();
- for (i = 0; i active_nr; i++) {
- if (ce_stage(active_cache[i]))
+ for (i = 0; i get_num_cache_entries(); i++) {
+ if (ce_stage(get_cache_entry(i)))
usage(you need to resolve your current
index first);
}
stage = 1;
@@ -252,10 +262,10 @@
if (merge) {
switch (stage) {
case 4: /* Three-way merge */
- trivially_merge_cache(active_cache, active_nr);
+ trivially_merge_cache();
break;
case 2: /* Just read a tree, merge with old cache contents */
- merge_stat_info(active_cache, active_nr);
+
[PATCH 10/19] migrate check-files.c to the new cache api's
tree 54aca1a1c5f41995c79fdf6b5f720574d0bfd8ef parent 50a6596bf7f51ecd598cd02d9c44379a9b92044a author Brad Roberts [EMAIL PROTECTED] 1114077105 -0700 committer Brad Roberts [EMAIL PROTECTED] 1114077105 -0700 [PATCH] migrate check-files.c to the new cache api's Signed-off-by: Brad Roberts [EMAIL PROTECTED] --- check-files.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: check-files.c === --- 50a6596bf7f51ecd598cd02d9c44379a9b92044a:1/check-files.c (mode:100644 sha1:7d16691aa9d51b5b4670d5837b3527ee7c7da79c) +++ a94803645fb68119be8835d466585c91e664a173:1/check-files.c (mode:100644 sha1:919e418b5f0f85220445c876a37bf4cf61d26525) @@ -26,7 +26,7 @@ pos = cache_name_pos(path, strlen(path)); if (pos 0) die(preparing to update existing file '%s' not in cache, path); - ce = active_cache[pos]; + ce = get_cache_entry(pos); if (fstat(fd, st) 0) die(fstat(%s): %s, path, strerror(errno)); - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/19] move cache_header out of the public view
tree a2c82ce3512904f82f78d87d86709a471f67ef9f
parent ff3667537379d5b0680e8c4f9a14d82dc9835430
author Brad Roberts [EMAIL PROTECTED] 1114083477 -0700
committer Brad Roberts [EMAIL PROTECTED] 1114083477 -0700
[PATCH] move cache_header out of the public view
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
cache.h | 15 ---
read-cache.c | 11 +++
2 files changed, 11 insertions(+), 15 deletions(-)
Index: cache.h
===
--- ff3667537379d5b0680e8c4f9a14d82dc9835430:1/cache.h (mode:100644
sha1:b29bb0ca5e7be15c0b423101f5cf381ee68f139e)
+++ b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1:1/cache.h (mode:100644
sha1:74d6c4d25c564e08eadc04aaef31a711d0645a43)
@@ -17,21 +17,6 @@
#include zlib.h
/*
- * Basic data structures for the directory cache
- *
- * NOTE NOTE NOTE! This is all in the native CPU byte format. It's
- * not even trying to be portable. It's trying to be efficient. It's
- * just a cache, after all.
- */
-
-#define CACHE_SIGNATURE 0x44495243 /* DIRC */
-struct cache_header {
- unsigned int hdr_signature;
- unsigned int hdr_version;
- unsigned int hdr_entries;
-};
-
-/*
* The cache_time is just the low 32 bits of the
* time. It doesn't matter if it overflows - we only
* check it for equality in the 32 bits we save.
Index: read-cache.c
===
--- ff3667537379d5b0680e8c4f9a14d82dc9835430:1/read-cache.c (mode:100644
sha1:0e972a80fa19eb77fd547fb579354af784be3ac4)
+++ b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1:1/read-cache.c (mode:100644
sha1:b16a72dc4e4525a7df060b3a43722217db7869c2)
@@ -6,6 +6,17 @@
#include stdarg.h
#include cache.h
+/*
+ * Basic data structures for the directory cache
+ */
+
+#define CACHE_SIGNATURE 0x44495243 /* DIRC */
+struct cache_header {
+ unsigned int hdr_signature;
+ unsigned int hdr_version;
+ unsigned int hdr_entries;
+};
+
static struct cache_entry **active_cache = NULL;
static unsigned int active_nr = 0, active_alloc = 0;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/19] introduce a cache struct and move the various cache globals into it.
tree c806c7328a6c9297df108ab00ebe1c4014496cb0
parent b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1
author Brad Roberts [EMAIL PROTECTED] 1114086327 -0700
committer Brad Roberts [EMAIL PROTECTED] 1114086327 -0700
[PATCH] introduce a cache struct and move the various cache globals into it.
New elements in the cache struct that previously were discarded:
- the cache headers
- the mmap info so we can cleanup later
For this stage, the cache itself is still a global variable. That will change.
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
cache.h |1
read-cache.c | 127 ++-
2 files changed, 76 insertions(+), 52 deletions(-)
Index: cache.h
===
--- b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1:1/cache.h (mode:100644
sha1:74d6c4d25c564e08eadc04aaef31a711d0645a43)
+++ f07f7073f45a7f81e5b6cf26f5181e14fd051d81:1/cache.h (mode:100644
sha1:a3018f9e12bfdd1a5273b20fcab5062667c6caec)
@@ -72,6 +72,7 @@
/* Initialize and use the cache information */
extern int read_cache(void);
extern int write_cache(int newfd);
+extern void free_cache();
extern int cache_name_pos(const char *name, int namelen);
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
Index: read-cache.c
===
--- b7d4fa53d4ee449b4b9b4f3c9dd40d6c99db4bc1:1/read-cache.c (mode:100644
sha1:b16a72dc4e4525a7df060b3a43722217db7869c2)
+++ f07f7073f45a7f81e5b6cf26f5181e14fd051d81:1/read-cache.c (mode:100644
sha1:c399f8e497441147afe630ca080558a8c6c79c78)
@@ -17,8 +17,20 @@
unsigned int hdr_entries;
};
-static struct cache_entry **active_cache = NULL;
-static unsigned int active_nr = 0, active_alloc = 0;
+struct mmap_holder {
+ void * ptr;
+ size_t size;
+};
+
+struct cache {
+ struct mmap_holder map;
+ struct cache_header *header;
+ struct cache_entry **entries;
+ unsigned int num_entries;
+ unsigned int allocated_entries;
+};
+
+static struct cache * cache = NULL;
int cache_match_stat(struct cache_entry *ce, struct stat *st)
{
@@ -81,10 +93,10 @@
int first, last;
first = 0;
- last = active_nr;
+ last = cache-num_entries;
while (last first) {
int next = (last + first) 1;
- struct cache_entry *ce = active_cache[next];
+ struct cache_entry *ce = cache-entries[next];
int cmp = cache_name_compare(name, namelen, ce-name,
htons(ce-ce_flags));
if (!cmp)
return next;
@@ -100,10 +112,10 @@
/* Remove entry, return true if there are more entries to go.. */
int remove_cache_entry_at(int pos)
{
- active_nr--;
- if (pos = active_nr)
+ cache-num_entries--;
+ if (pos = cache-num_entries)
return 0;
- memmove(active_cache + pos, active_cache + pos + 1, (active_nr - pos) *
sizeof(struct cache_entry *));
+ memmove(cache-entries + pos, cache-entries + pos + 1,
(cache-num_entries - pos) * sizeof(struct cache_entry *));
return 1;
}
@@ -123,20 +135,20 @@
int get_num_cache_entries()
{
- return active_nr;
+ return cache-num_entries;
}
struct cache_entry * get_cache_entry(int pos)
{
- return active_cache[pos];
+ return cache-entries[pos];
}
void set_cache_entry(struct cache_entry *ce, int pos)
{
- /* You can NOT just free active_cache[i] here, since it
+ /* You can NOT just free cache-entries[i] here, since it
* might not be necessarily malloc()ed but can also come
* from mmap(). */
- active_cache[pos] = ce;
+ cache-entries[pos] = ce;
}
int add_cache_entry(struct cache_entry *ce, int ok_to_add)
@@ -147,7 +159,7 @@
/* existing match? Just replace it */
if (pos = 0) {
- active_cache[pos] = ce;
+ cache-entries[pos] = ce;
return 0;
}
pos = -pos-1;
@@ -156,8 +168,8 @@
* Inserting a merged entry (stage 0) into the index
* will always replace all non-merged entries..
*/
- if (pos active_nr ce_stage(ce) == 0) {
- while (same_name(active_cache[pos], ce)) {
+ if (pos cache-num_entries ce_stage(ce) == 0) {
+ while (same_name(cache-entries[pos], ce)) {
ok_to_add = 1;
if (!remove_cache_entry_at(pos))
break;
@@ -168,16 +180,16 @@
return -1;
/* Make sure the array is big enough .. */
- if (active_nr == active_alloc) {
- active_alloc = alloc_nr(active_alloc);
- active_cache = realloc(active_cache, active_alloc *
sizeof(struct cache_entry *));
+ if (cache-num_entries == cache-allocated_entries) {
+
[PATCH 18/19] rename cache_match_stat to ce_match_stat to match other cache_entry related functions/macros
tree f8dd454f774d42526149193970b612a46f3ddd26
parent 058c25fd81e5949354d96f2aad222ae73a6c1dee
author Brad Roberts [EMAIL PROTECTED] 1114088345 -0700
committer Brad Roberts [EMAIL PROTECTED] 1114088345 -0700
[PATCH] rename cache_match_stat to ce_match_stat to match other cache_entry
related functions/macros
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
cache.h |3 ++-
check-files.c|2 +-
checkout-cache.c |2 +-
diff-cache.c |2 +-
read-cache.c |2 +-
show-diff.c |2 +-
update-cache.c |2 +-
7 files changed, 8 insertions(+), 7 deletions(-)
Index: cache.h
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/cache.h (mode:100644
sha1:a3018f9e12bfdd1a5273b20fcab5062667c6caec)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/cache.h (mode:100644
sha1:c64969602d80a0e9d7137b2716fb808c912b075c)
@@ -52,6 +52,8 @@
#define CE_STAGEMASK (0x3000)
#define CE_STAGESHIFT 12
+extern int ce_match_stat(struct cache_entry *ce, struct stat *st);
+
#define create_ce_flags(len, stage) htons((len) | ((stage) CE_STAGESHIFT))
#define ce_namelen(ce) (CE_NAMEMASK ntohs((ce)-ce_flags))
#define ce_size(ce) cache_entry_size(ce_namelen(ce))
@@ -76,7 +78,6 @@
extern int cache_name_pos(const char *name, int namelen);
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
-extern int cache_match_stat(struct cache_entry *ce, struct stat *st);
extern int get_num_cache_entries();
extern struct cache_entry * get_cache_entry(int pos);
extern void set_cache_entry(struct cache_entry *ce, int pos);
Index: check-files.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/check-files.c (mode:100644
sha1:919e418b5f0f85220445c876a37bf4cf61d26525)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/check-files.c (mode:100644
sha1:0973e81fbbc0f9f98031fb249254bd89d809)
@@ -31,7 +31,7 @@
if (fstat(fd, st) 0)
die(fstat(%s): %s, path, strerror(errno));
- changed = cache_match_stat(ce, st);
+ changed = ce_match_stat(ce, st);
if (changed)
die(preparing to update file '%s' not uptodate in cache,
path);
}
Index: checkout-cache.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/checkout-cache.c (mode:100644
sha1:bf9cd0572c883219d37f2788ec5f5553a136df2b)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/checkout-cache.c (mode:100644
sha1:27b559d5bcc5831eda441bcd1fd88d687f2567b8)
@@ -100,7 +100,7 @@
struct stat st;
if (!stat(ce-name, st)) {
- unsigned changed = cache_match_stat(ce, st);
+ unsigned changed = ce_match_stat(ce, st);
if (!changed)
return 0;
if (!force) {
Index: diff-cache.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/diff-cache.c (mode:100644
sha1:548211944fc00594bfc06b9ab90f0cb476688285)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/diff-cache.c (mode:100644
sha1:5ae6d5de5ed5ad34f72267904ff8eb6288855fc5)
@@ -125,7 +125,7 @@
show_file(-, path1, mode1, sha1, base);
return -1;
}
- changed = cache_match_stat(ce, st);
+ changed = ce_match_stat(ce, st);
close(fd);
if (changed) {
mode2 = st.st_mode;
Index: read-cache.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/read-cache.c (mode:100644
sha1:31e293a3686622c9ec180d41aa37d85ce49325e8)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/read-cache.c (mode:100644
sha1:8837d27ab683bf07d38aee33c62a90f5a7221588)
@@ -44,7 +44,7 @@
cache = NULL;
}
-int cache_match_stat(struct cache_entry *ce, struct stat *st)
+int ce_match_stat(struct cache_entry *ce, struct stat *st)
{
unsigned int changed = 0;
Index: show-diff.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/show-diff.c (mode:100644
sha1:6e04e9182667cbb79afa4c878a31b685fdea3229)
+++ 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/show-diff.c (mode:100644
sha1:4a0902f50b3120b7791a4d4627a9a4f729afdcf7)
@@ -193,7 +193,7 @@
}
continue;
}
- changed = cache_match_stat(ce, st);
+ changed = ce_match_stat(ce, st);
if (!changed)
continue;
if (!machine_readable)
Index: update-cache.c
===
--- 058c25fd81e5949354d96f2aad222ae73a6c1dee:1/update-cache.c (mode:100644
[PATCH 19/19] the end goal of the last dozen or so commits, there's no longer a global cache variable
tree 38adb888a4c1adfe083f24d4ec51018e0b5a8335
parent 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac
author Brad Roberts [EMAIL PROTECTED] 1114093024 -0700
committer Brad Roberts [EMAIL PROTECTED] 1114093024 -0700
[PATCH] the end goal of the last dozen or so commits, there's no longer a
global cache variable
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
cache.h | 21 +++---
check-files.c| 10 +++---
checkout-cache.c | 20 ++---
diff-cache.c | 20 ++---
merge-cache.c| 29 ++-
read-cache.c | 82 ---
read-tree.c | 51 ++
show-diff.c |8 ++---
show-files.c | 27 +-
update-cache.c | 35 ---
write-tree.c | 20 ++---
11 files changed, 167 insertions(+), 156 deletions(-)
Index: cache.h
===
--- 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/cache.h (mode:100644
sha1:c64969602d80a0e9d7137b2716fb808c912b075c)
+++ 7e396358c12c0129bcb4945e3e35a4fa76890a0c:1/cache.h (mode:100644
sha1:d8ade9f4b9bd9b6045f97b4df5bef8356c767d46)
@@ -72,16 +72,17 @@
#define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
-extern int read_cache(void);
-extern int write_cache(int newfd);
-extern void free_cache();
-extern int cache_name_pos(const char *name, int namelen);
-extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
-extern int remove_file_from_cache(char *path);
-extern int get_num_cache_entries();
-extern struct cache_entry * get_cache_entry(int pos);
-extern void set_cache_entry(struct cache_entry *ce, int pos);
-extern int remove_cache_entry_at(int pos);
+extern struct cache *new_cache(void);
+extern struct cache *read_cache(void);
+extern int write_cache(struct cache *cache, int newfd);
+extern void free_cache(struct cache *cache);
+extern int cache_name_pos(struct cache *cache, const char *name, int namelen);
+extern int add_cache_entry(struct cache *cache, struct cache_entry *ce, int
ok_to_add);
+extern int remove_file_from_cache(struct cache *cache, char *path);
+extern int get_num_cache_entries(struct cache *cache);
+extern struct cache_entry * get_cache_entry(struct cache *cache, int pos);
+extern void set_cache_entry(struct cache *cache, struct cache_entry *ce, int
pos);
+extern int remove_cache_entry_at(struct cache *cache, int pos);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
Index: check-files.c
===
--- 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/check-files.c (mode:100644
sha1:0973e81fbbc0f9f98031fb249254bd89d809)
+++ 7e396358c12c0129bcb4945e3e35a4fa76890a0c:1/check-files.c (mode:100644
sha1:4de6d39e4997d29f13261c21eeb378f74b3f8a8f)
@@ -8,7 +8,7 @@
*/
#include cache.h
-static void check_file(const char *path)
+static void check_file(struct cache *cache, const char *path)
{
int fd = open(path, O_RDONLY);
struct cache_entry *ce;
@@ -23,10 +23,10 @@
}
/* Exists but is not in the cache is not fine */
- pos = cache_name_pos(path, strlen(path));
+ pos = cache_name_pos(cache, path, strlen(path));
if (pos 0)
die(preparing to update existing file '%s' not in cache,
path);
- ce = get_cache_entry(pos);
+ ce = get_cache_entry(cache, pos);
if (fstat(fd, st) 0)
die(fstat(%s): %s, path, strerror(errno));
@@ -39,9 +39,9 @@
int main(int argc, char **argv)
{
int i;
+ struct cache *cache = read_cache();
- read_cache();
for (i = 1; i argc ; i++)
- check_file(argv[i]);
+ check_file(cache, argv[i]);
return 0;
}
Index: checkout-cache.c
===
--- 0a556dc01b8e48f684ce6e0c26f8c00b5e39c4ac:1/checkout-cache.c (mode:100644
sha1:27b559d5bcc5831eda441bcd1fd88d687f2567b8)
+++ 7e396358c12c0129bcb4945e3e35a4fa76890a0c:1/checkout-cache.c (mode:100644
sha1:2e8c61323a72f6052d8c9ef76a4eef05aa5ac0f9)
@@ -120,23 +120,23 @@
return write_entry(ce);
}
-static int checkout_file(const char *name)
+static int checkout_file(struct cache *cache, const char *name)
{
- int pos = cache_name_pos(name, strlen(name));
+ int pos = cache_name_pos(cache, name, strlen(name));
if (pos 0) {
if (!quiet)
fprintf(stderr, checkout-cache: %s is not in the
cache\n, name);
return -1;
}
- return checkout_entry(get_cache_entry(pos));
+ return checkout_entry(get_cache_entry(cache, pos));
}
-static int checkout_all(void)
+static int checkout_all(struct cache *cache)
{
int i;
- for (i = 0; i get_num_cache_entries() ; i++) {
- struct cache_entry *ce =
[PATCH 01-19/19] All of the above combined
Make the cache management code behave more like a library. There are no
longer any global variables in read-cache.c. Nothing ever uses more than
one cache yet, but I can see how it might simplify some of the merge code.
Signed-off-by: Brad Roberts [EMAIL PROTECTED]
---
cache.h | 36 +++--
check-files.c| 12 +--
checkout-cache.c | 22 +++---
diff-cache.c | 36 -
merge-cache.c| 29 ---
read-cache.c | 200 ---
read-tree.c | 71 +++
show-diff.c | 19 +++--
show-files.c | 27 +++
update-cache.c | 39 +-
write-tree.c | 24 +++---
11 files changed, 292 insertions(+), 223 deletions(-)
Index: cache.h
===
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/cache.h (mode:100644
sha1:828d660ab82bb35a1ca632a2ba4620dc483889bd)
+++ 38adb888a4c1adfe083f24d4ec51018e0b5a8335/cache.h (mode:100644
sha1:d8ade9f4b9bd9b6045f97b4df5bef8356c767d46)
@@ -17,21 +17,6 @@
#include zlib.h
/*
- * Basic data structures for the directory cache
- *
- * NOTE NOTE NOTE! This is all in the native CPU byte format. It's
- * not even trying to be portable. It's trying to be efficient. It's
- * just a cache, after all.
- */
-
-#define CACHE_SIGNATURE 0x44495243 /* DIRC */
-struct cache_header {
- unsigned int hdr_signature;
- unsigned int hdr_version;
- unsigned int hdr_entries;
-};
-
-/*
* The cache_time is just the low 32 bits of the
* time. It doesn't matter if it overflows - we only
* check it for equality in the 32 bits we save.
@@ -67,6 +52,8 @@
#define CE_STAGEMASK (0x3000)
#define CE_STAGESHIFT 12
+extern int ce_match_stat(struct cache_entry *ce, struct stat *st);
+
#define create_ce_flags(len, stage) htons((len) | ((stage) CE_STAGESHIFT))
#define ce_namelen(ce) (CE_NAMEMASK ntohs((ce)-ce_flags))
#define ce_size(ce) cache_entry_size(ce_namelen(ce))
@@ -78,8 +65,6 @@
#define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8)
~7)
const char *sha1_file_directory;
-struct cache_entry **active_cache;
-unsigned int active_nr, active_alloc;
#define DB_ENVIRONMENT SHA1_FILE_DIRECTORY
#define DEFAULT_DB_ENVIRONMENT .git/objects
@@ -87,12 +72,17 @@
#define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
-extern int read_cache(void);
-extern int write_cache(int newfd, struct cache_entry **cache, int entries);
-extern int cache_name_pos(const char *name, int namelen);
-extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
-extern int remove_file_from_cache(char *path);
-extern int cache_match_stat(struct cache_entry *ce, struct stat *st);
+extern struct cache *new_cache(void);
+extern struct cache *read_cache(void);
+extern int write_cache(struct cache *cache, int newfd);
+extern void free_cache(struct cache *cache);
+extern int cache_name_pos(struct cache *cache, const char *name, int namelen);
+extern int add_cache_entry(struct cache *cache, struct cache_entry *ce, int
ok_to_add);
+extern int remove_file_from_cache(struct cache *cache, char *path);
+extern int get_num_cache_entries(struct cache *cache);
+extern struct cache_entry * get_cache_entry(struct cache *cache, int pos);
+extern void set_cache_entry(struct cache *cache, struct cache_entry *ce, int
pos);
+extern int remove_cache_entry_at(struct cache *cache, int pos);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
Index: check-files.c
===
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/check-files.c (mode:100644
sha1:7d16691aa9d51b5b4670d5837b3527ee7c7da79c)
+++ 38adb888a4c1adfe083f24d4ec51018e0b5a8335/check-files.c (mode:100644
sha1:4de6d39e4997d29f13261c21eeb378f74b3f8a8f)
@@ -8,7 +8,7 @@
*/
#include cache.h
-static void check_file(const char *path)
+static void check_file(struct cache *cache, const char *path)
{
int fd = open(path, O_RDONLY);
struct cache_entry *ce;
@@ -23,15 +23,15 @@
}
/* Exists but is not in the cache is not fine */
- pos = cache_name_pos(path, strlen(path));
+ pos = cache_name_pos(cache, path, strlen(path));
if (pos 0)
die(preparing to update existing file '%s' not in cache,
path);
- ce = active_cache[pos];
+ ce = get_cache_entry(cache, pos);
if (fstat(fd, st) 0)
die(fstat(%s): %s, path, strerror(errno));
- changed = cache_match_stat(ce, st);
+ changed = ce_match_stat(ce, st);
if (changed)
die(preparing to update file '%s' not uptodate in cache,
path);
}
@@ -39,9 +39,9 @@
int main(int argc, char **argv)
{
int i;
+ struct cache *cache = read_cache();
- read_cache();
for (i = 1; i argc ; i++)
- check_file(argv[i]);
+ check_file(cache,
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
Using your suggested indexing method that uses [0:4] as the 1st level key and [0:3] [4:8] as the 2nd level key, I obtain an indexed archive that occupies 159M, where the top level contains 18665 1st level keys, the largest first level dir contains 5 entries, and all 2nd level dirs contain exactly 1 entry. That's just a mistake in the spec. The format should probably be multi-level but, yes, the fanout I suggested is currently quite bogus. When I write that part of that code (today or tomorrow) I'll fix it. A few people pointed that out. Thanks. -t - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] multi item packed files
Linus Torvalds [EMAIL PROTECTED] writes: Wrong. You most definitely _can_ lose: you end up having to optimize for one particular filesystem blocking size, and you'll lose on any other filesystem. And you'll lose on the special filesystem of network traffic, which is byte-granular. If someone needs better on-disk ratio, (s)he can go with 1 KB filesystem or something like that, without all the added complexity of packing. If we want to optimize that further, I would try doing it at the underlying filesystem level. For example, loop-mounted one. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] #!/bin/sh -- #!/usr/bin/env bash
On Thu, Apr 21, 2005 at 10:31:02PM +0800, Alecs King wrote: On Thu, Apr 21, 2005 at 12:23:26PM +0200, Klaus Robert Suetterlin wrote: 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. Hi, i did a similar patch a while back ago. As for ULONG_MAX, not every sytem has sys/limits.h, i think limits.h is the rite place to go. The patch below tested on both debian and fbsd. [snip] And as for bash, only gitdiff-do and gitlog.sh 'explicitly' use bash instead of /bin/sh. On most Linux distros, /bin/sh is just a symbolic link to bash. But not on some others. I found gitlsobj.sh could not work using a plain /bin/sh on fbsd. To make life easier, i think it might be better if we all explicitly use bash for all shell scripts. patch below assumes the patch above has been applied. commit 341cd1241815178d567ce612c97c2bb5a663021a tree abb16c39fe8354383b632f7fa9dd4611ff66e1d1 parent 2deea74db72fb57a8b80e7945f23814112b22723 author Alecs King alecsk ! gmail [EMAIL PROTECTED] com 1114107613 +0800 committer Alecs King alecsk ! gmail [EMAIL PROTECTED] com 1114107613 +0800 Explicitly use bash #!/bin/sh == #!/usr/bin/env bash Index: gitXlntree.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitXlntree.sh (mode:100755 sha1:c474913d09906739d8175f1b430720a3ac67e798) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitXlntree.sh (mode:100755 sha1:adc01eeb56f394a6168ae1f6f1fe4c40e1c2aecc) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Provide an independent view to the objects database. # Copyright (c) Petr Baudis, 2005 Index: gitXnormid.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitXnormid.sh (mode:100755 sha1:c0d53afabe8662ebfc3c697faf08b0a2b43c93f7) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitXnormid.sh (mode:100755 sha1:9b311aca57bd8b7012f45d730c6fd26d5fb5d2b2) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Internal: Normalize the given ID to a tree ID. # Copyright (c) Petr Baudis, 2005 Index: gitadd.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitadd.sh (mode:100755 sha1:3f5e9a2d6b452d596cd853f1585113bdb356a2e3) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitadd.sh (mode:100755 sha1:6feb7372e95be4546af17e0c6b55d10c9a1c441d) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Add new file to a GIT repository. # Copyright (c) Petr Baudis, 2005 Index: gitaddremote.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitaddremote.sh (mode:100755 sha1:a117b9e8d14b977143caa48c26fc51794e8b7135) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitaddremote.sh (mode:100755 sha1:bccaa9068063b07d13012477861c6706b7cd40a6) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Add new remote to the GIT repository. # Copyright (c) Petr Baudis, 2005 Index: gitapply.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitapply.sh (mode:100755 sha1:7703809dc0743c6e4c1fa5b7d922a4efc16b4276) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitapply.sh (mode:100755 sha1:794ea5ed6acdd34e34742a17cbd784dcbf738289) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Apply a diff generated by git diff. # Copyright (c) Petr Baudis, 2005 Index: gitcancel.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitcancel.sh (mode:100755 sha1:74b4083d67eda87d88a6f92c6c66877bba8bda8a) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitcancel.sh (mode:100755 sha1:c320ee98e2ed0b13a68de3b2ec4e4a8451b5189a) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Cancels current edits in the working tree. # Copyright (c) Petr Baudis, 2005 Index: gitcommit.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitcommit.sh (mode:100755 sha1:a13bef2c84492ed75679d7d52bb710df35544f8a) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitcommit.sh (mode:100755 sha1:0207f402cc5107de2a4685f6fcade081c41d91e9) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Commit into a GIT repository. # Copyright (c) Petr Baudis, 2005 Index: gitdiff.sh === --- 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/gitdiff.sh (mode:100755 sha1:8e14a868f513f4ec524a2c8974c8d202c6824038) +++ abb16c39fe8354383b632f7fa9dd4611ff66e1d1/gitdiff.sh (mode:100755 sha1:e27915d4172717ddd4d01269877312b08ed2acc4) @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash # # Make a diff between two GIT trees. # Copyright (c) Petr Baudis, 2005 Index: gitexport.sh === ---
[RFC] A suggestion for more versatile naming conventios in the object database
In the transition from git-0.04 to git-0.5 (Linus' track) the naming
convention of files in the object database has been changed: a file's
name passed from the sha1 of its contents to the sha1 of its contents
*before* compression.
This change was preceded by a long discussion hence both conventions
have arguments for and against.
I would like to suggest to adopt a more versatile solution:
preserve the pure sha1 based names for the sha1 sum of the file's
contents. I mean,
(*) for files with name xy/z{38} their sha1 sum is xyz{38}
allow other files (or links) with names of the form
xy/z{38}.EXTENSION
where for every EXTENSION the file's content would be the EXTENSION
representation of the file xy/z{38} . For every representation type
EXTENSION there should be procedures to derive the file xy/z{38}
from the name xy/z{38}.EXTENSION and vice-versa (assuming that the
representation type EXTENSION cares about the contents of file
xy/z{38}).
Let me give two examples:
all the files in the object database of git-0.04 are just fine, they
satisfy axiom (*)
the name of every file xy/z{38} in the git-0.5 data base should be
changed to xy/z{38}.g assuming that we will use EXTENSION g as the
git representation type. The conversion algorithms would be:
cat-file `cat-file -t xyz{38}` xyz{38} to obtain the contents
represented by xy/z{38}.g whose sha1 is xyz{38}
and a utility program has to be written to check whether a given
file F, is a valid contents as far as git is concerned and in
case it is compute its sha1 sum xyz{38} and also comute the file
the file xy/z{38}.g .
So, what are the advantages of this further complication? I see these ones:
git is separated from the idea of sha1 addressable contents, which
indeed is an idea larger than git itself. This same or similar
addressing schemes can (and most probably will) be applied to other
contents besides SCMs. An example would be a digital library of
scientific papers in pdf together with its OAI compliant meta data
(don't bother if you are not familiar with these terms, it is just
an example and I am sure you are able to come up with many other
examples where a sha1 addressable data base would be interesting)
all these uses could share common backup schemes where axiom (*)
would be enforced. One could think of a shared p2p database of
repositories of sha1 addressed contents of all kinds. This might be
important because, in general, the contents of xyz{38} cannot be
reconstructed from its name. The way to defend against file system
corruption is replication. Why not share these backup databases?
it would be easier to experiment with other compression schemes or
other proposals for meta data in git itself.
it would be easier to experiment with the factorization of common
chunks of contents, an idea very close to the secret of rsync's
amazing efficiency.
Well, that's the proposal. I would be happy to hear comments!
Cheers,
Imre Simon
PS: the way it is, the git-0.5 README file is inconsistent. The naming
change is not reflected in the README file which in many places states
that the sha1 sum of file xy/z{38} is xyz{38}.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] multi item packed files
On Thursday 21 April 2005 15:28, Krzysztof Halasa wrote: Linus Torvalds [EMAIL PROTECTED] writes: Wrong. You most definitely _can_ lose: you end up having to optimize for one particular filesystem blocking size, and you'll lose on any other filesystem. And you'll lose on the special filesystem of network traffic, which is byte-granular. If someone needs better on-disk ratio, (s)he can go with 1 KB filesystem or something like that, without all the added complexity of packing. If we want to optimize that further, I would try doing it at the underlying filesystem level. For example, loop-mounted one. Shrug, we shouldn't need help from the kernel for something like this. git as a database hits worst case scenarios for almost every FS. We've got: 1) subdirectories with lots of files 2) wasted space for tiny files 3) files that are likely to be accessed together spread across the whole disk One compromise for SCM use would be one packed file per commit, with an index that lets us quickly figure out which commit has a particular version of a given file. My hack gets something close to that (broken into 32k chunks for no good reason), and the index to find a given file is just the git directory tree. But my code does hide the fact that we're packing things from most of the git interfaces. So I can almost keep a straight face while claiming to be true to the original git design...almost. The whole setup is far from perfect, but it is one option for addressing points 2 3 above. -chris - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter
where Martin Schlemmer [EMAIL PROTECTED] told me that...
Hi,
Hi,
Just pulled linux-2.6.git, and got this:
New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320
Tracked branch, applying changes...
Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 -
3a6fd752a50af92765853879f4a11cc0cfcd0320
to a2755a80f40e5794ddc20e00f781af9d6320fafb...
Enter commit message, terminated by ctrl-D on a separate line:
Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320
Weird thing was that I made no changes.
did you compensate for the renamed hashes? Didn't you before update from
some very old git-pasky version?
Actually, did you do that git init _after_ the unsuccessful pull, or
before?
Digging a bit deeper, I saw that .git/HEAD was a symlink
to .git/heads/master, and the tracked branch was 'origin'. Due to the
fact that Linus only have a .git/heads/master on his rsync, and this
thus updated to the new sha1, but the 'origin' (and tracked) head is
still pointing to an older sha1 caused this confusion.
Duh. The remote branch always grabs the HEAD over there; you don't need
to care about the various branches over there, and you really do not
*want* to care. Actually I might add some ^branchname to the rsync URL,
to be able to refer to particular branches inside of the repository.
I replicated the linux tree via:
git init URL
So I had a look at gitinit.sh, which first creates the .git/heads/master
and symlinks HEAD to it, then on seeing a URL was supplied, creates
a .git/heads/origin, track it, but do *not* change the .git/HEAD
symlink ... Is this intended? I see also that gittrack.sh do not update
the HEAD symlink ... Is this also intended?
Yes.
You never work directly on the remote branch. Ever. That's what this
tracking stuff is for; you set up a local branch which follows the
remote one.
Otherwise, you fork to two trees, one is remote branch, second is local
branch, and you do git pull remotebranch in the second. You are in
trouble now. Also, if you do some local commit on the remote branch,
what would happen? This kind of stuff is why I decided that you just
cannot work on remote branches directly.
The last option however brings a problem or two. First, how do you do
the multi-head thing? Maybe add a command 'git lsheads' (and while at
it, also add 'git lstags'?)? Secondly, if there was more than one head,
Perhaps it would be useful to have some command classes (with at least
cg-*-(add|ls|rm)), like:
cg-branch-ls
cg-remote-rm
cg-tag-add
the local copy needs to be checked out ... don't know if 'git cancel' is
the logical thing the user will think to do ('git clone' perhaps?) ...
I don't know what do you mean here.
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
Yes, it really doesn't make much sense to have so big keys on the directories. It's official... i'm blushing wildly thank you for the various replies that pointed out my thinko. That part of my spec hasn't been coded yet --- i just wrote text. It really was the silly late-night error of sort: hmm...let's see, 4 hex digits plus 4 hex digits that's 16 bits sounds about right. Really, I'll fix it. -t - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add git push
Dear diary, on Thu, Apr 21, 2005 at 02:43:33PM CEST, I got a letter where Matthias Urlichs [EMAIL PROTECTED] told me that... This patch adds the ability to git push, as the obvious converse of git pull. While lack of locking is a problem for git-pasky too, for this git push it is a downright disaster waiting to happen. It might be also a good idea to check for remote 'blocked' file, which must exist and contain only a pushtree line. This is so that no (sensible) real working tree is attached to it, which would be a disaster for it too. You probably don't want to allow pushing if your local tree is blocked. And you want to allow pushing only when HEAD is your ancestor. (Helper tool wanted for this - we need this in git merge badly too.) BTW, it contains some unrelated and seemingly irrelevant tracking stuff. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
[your 0:3/4:7 directory hierarchy is horked] Absolutely. Made a dumb mistake the night I wrote that spec and embarassed that I initially defended it. I had an arithmetic error. Thanks, this time, for your persistence in pointing it out. -t - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
On Thu, 2005-04-21 at 22:29 +0200, Petr Baudis wrote:
Dear diary, on Thu, Apr 21, 2005 at 06:21:58PM CEST, I got a letter
where Martin Schlemmer [EMAIL PROTECTED] told me that...
Hi,
Hi,
Just pulled linux-2.6.git, and got this:
New branch: 3a6fd752a50af92765853879f4a11cc0cfcd0320
Tracked branch, applying changes...
Merging 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9 -
3a6fd752a50af92765853879f4a11cc0cfcd0320
to a2755a80f40e5794ddc20e00f781af9d6320fafb...
Enter commit message, terminated by ctrl-D on a separate line:
Merge with 3a6fd752a50af92765853879f4a11cc0cfcd0320
Weird thing was that I made no changes.
did you compensate for the renamed hashes? Didn't you before update from
some very old git-pasky version?
Actually, did you do that git init _after_ the unsuccessful pull, or
before?
I re-pulled it from scratch after the sha1 changes, so not that. Just
the next pull that went wonky.
Digging a bit deeper, I saw that .git/HEAD was a symlink
to .git/heads/master, and the tracked branch was 'origin'. Due to the
fact that Linus only have a .git/heads/master on his rsync, and this
thus updated to the new sha1, but the 'origin' (and tracked) head is
still pointing to an older sha1 caused this confusion.
Duh. The remote branch always grabs the HEAD over there; you don't need
to care about the various branches over there, and you really do not
*want* to care. Actually I might add some ^branchname to the rsync URL,
to be able to refer to particular branches inside of the repository.
Well, I just did a quick peek. I thought it just changed the local head
to the sha1 of the remote, and then updated the local files - haven't
yet looked at gitmerge.sh.
I replicated the linux tree via:
git init URL
So I had a look at gitinit.sh, which first creates the .git/heads/master
and symlinks HEAD to it, then on seeing a URL was supplied, creates
a .git/heads/origin, track it, but do *not* change the .git/HEAD
symlink ... Is this intended? I see also that gittrack.sh do not update
the HEAD symlink ... Is this also intended?
Yes.
You never work directly on the remote branch. Ever. That's what this
tracking stuff is for; you set up a local branch which follows the
remote one.
Ok, but for some weird reason it wanted to commit the merge between
remote and local.
Otherwise, you fork to two trees, one is remote branch, second is local
branch, and you do git pull remotebranch in the second. You are in
trouble now. Also, if you do some local commit on the remote branch,
what would happen? This kind of stuff is why I decided that you just
cannot work on remote branches directly.
The last option however brings a problem or two. First, how do you do
the multi-head thing? Maybe add a command 'git lsheads' (and while at
it, also add 'git lstags'?)? Secondly, if there was more than one head,
Perhaps it would be useful to have some command classes (with at least
cg-*-(add|ls|rm)), like:
cg-branch-ls
cg-remote-rm
cg-tag-add
Might make things more sane.
the local copy needs to be checked out ... don't know if 'git cancel' is
the logical thing the user will think to do ('git clone' perhaps?) ...
I don't know what do you mean here.
Don't worry, no biggy.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: Pasky problem with 'git init URL'
Petr == Petr Baudis [EMAIL PROTECTED] writes: Petr Perhaps it would be useful to have some command classes (with at least Petr cg-*-(add|ls|rm)), like: Petr cg-branch-ls Petr cg-remote-rm Petr cg-tag-add Just speaking of consistency, can we make it so that all the commands are just variations with out the damm dashes in them? Something like: git lsbranch git lstag ... Or something mildly along those lines. I don't even care what ORDER they are, whether the 'ls' comes before or after the object type it works on. But make it the same every where, so that ls, rm, add, check, foo, barzle, ... all use the same format. Makes it much much easier to extrapolate what command syntax to use when new objects to be acted upon are added. Does a standard like: git objecttype command args [obj ...] make sense? Easy to script, easy to remember. Even munging objtypecommand into a single word is ok. John - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs update
Dear diary, on Thu, Apr 21, 2005 at 11:16:11PM CEST, I got a letter where David Greaves [EMAIL PROTECTED] told me that... Petr Baudis wrote: Make a choice - either you are describing git or Cogito. The frmer has no RSYNC_FLAGS and does not care about any heads or anything at all (you might mention it as a recommended convention, though). I was going to do both - surely that's OK? I thought the original goal for README.reference was to be git-specific, and I planned to therefore push it to the core git at some point. I actually probably don't mind as long as you keep the two separated cleanly inside of the file, so if we shall want to include it in git, the trimming of the docs to only relevant parts is simple enough. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
Dear diary, on Thu, Apr 21, 2005 at 11:15:54PM CEST, I got a letter where John Stoffel [EMAIL PROTECTED] told me that... Petr == Petr Baudis [EMAIL PROTECTED] writes: Petr Perhaps it would be useful to have some command classes (with at least Petr cg-*-(add|ls|rm)), like: Petr cg-branch-ls Petr cg-remote-rm Petr cg-tag-add Does a standard like: git objecttype command args [obj ...] Isn't this basically what I was proposing? (Modulo the UI changes related to git-pasky - Cogito.) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.12-rc3
Hi! It seems that someone should write Kernel hacker's guide to git... Documentation/git.txt seems like good place. I guess I'll do it. just plain vanilla without rm -rf? git cancel will give you plain last commit. If you need plain vanilla, the hard way now is to just do commit-id .git/HEAD but your current HEAD will be lost forever. Or do git fork vanilla ~/vanilla linus and you will have the vanilla tree tracking linus in ~/vanilla. Ok, thanks. I'm not yet sure if we should have some Cogito interface for doing this and what its semantics should be. What is Cogito, BTW? I see quite a lot of problems with fsck-tree. Is that normal? (I ran out of disk space few times during different operations...) Actually, in case your tree is older than about two days, I hope you did the convert-cache magic or fetched a fresh tree? No, I did not anything like that. I guess it is rm -rf time, then... Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.12-rc3
Dear diary, on Thu, Apr 21, 2005 at 11:38:11PM CEST, I got a letter where Pavel Machek [EMAIL PROTECTED] told me that... Hi! It seems that someone should write Kernel hacker's guide to git... Documentation/git.txt seems like good place. I guess I'll do it. I've also started writing some tutorial-like guide to Cogito on my notebook, but I have time for that only during lectures. :^) I'm not yet sure if we should have some Cogito interface for doing this and what its semantics should be. What is Cogito, BTW? New name for git-pasky. Everyone will surely rejoice as the usage will change significantly. But better let's clean it up now. (For more details, check git@ archives for git-pasky-0.6 announcement.) I see quite a lot of problems with fsck-tree. Is that normal? (I ran out of disk space few times during different operations...) Actually, in case your tree is older than about two days, I hope you did the convert-cache magic or fetched a fresh tree? No, I did not anything like that. I guess it is rm -rf time, then... That's the root of all your problems then. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
Tom, please stop this ext* filesystem bashing ;-) For one thing... yes, i'm totally embarassed on this issue. I made a late-night math error in a spec. *hopefully* would have noticed it on my own as I coded to that spec but y'all have been wonderful at pointing out my mistake to me even though I initially defended it. As for ext* bashing it's not bashing exactly. I/O bandwidth gets a little better, disks get a bunch cheaper --- then ext* doesn't look bad at all in this respect. And we're awefully close to that point. Meanwhile, for times measured in years, I've gotten complaints from ext* users about software that is just fine on other filesystems over issues like the allocation size of small files. So ext*, from my perspective, was a little too far ahead of its time and, yes, my complaints about it are just about reaching their expiration date. Anyway, thanks for all the sanity about directory layout. Really, it was just an I'm too sleepy to be doing this right now error. -t - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pasky problem with 'git init URL'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Donnerstag, 21. April 2005 23:15 schrieb John Stoffel: Petr == Petr Baudis [EMAIL PROTECTED] writes: Petr Perhaps it would be useful to have some command classes (with at least Petr cg-*-(add|ls|rm)), like: Petr cg-branch-ls Petr cg-remote-rm Petr cg-tag-add Just speaking of consistency, can we make it so that all the commands are just variations with out the damm dashes in them? I think the dashes are especially useful, because of tab-completion. git objecttype command args [obj ...] I think thats exactly like above: cg-objtype-command cu Fabian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCaCHbI0lSH7CXz7MRAuSXAJ40v4yNgS13BIExfYTwPv8zbj2HcACdG7G6 YiLFD8u8Guh3xppaa14uD+I= =dkN/ -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3/5] Add http-pull
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. Daniel Barkalow replied: 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. You just need to defer adding tree/commit objects to the repository until after you have inserted all objects on which they depend. That's what my wget based version does ... it's very crude, in that it loads all tree commit objects into a temporary repository (.gittmp) ... since you can only use cat-file and ls-tree on things if they live in objects/xx/xxx..xxx The blobs can go directly into the real repo (but to be really safe you'd have to ensure that the whole blob had been pulled from the network before inserting it ... it's probably a good move to validate everything that you pull from the outside world too). -Tony - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-viz tool for visualising commit trees
* Olivier Andrieu [EMAIL PROTECTED] wrote: - naming the boxes by key is quite meaningless. It would be more informative to see the author's email shortcuts in the boxes. Also, it would be nice to see some simple graphical feedback about the size and scope of a changeset, without having to zoom on it. That's interesting. What do you mean exactly by scope ? usually there are two interesting things about a patchset: how many lines does it change, and how many files. Patches that change lots of files (but change only a couple of lines in every file) have a 'large' scope. Patches that change 1-2 files have a 'small' scope. A pure 'number of lines changed' metric is useful too. Generally patches that have either a large linecount or a large scope are more interesting. (I'm not sure how this could be displayed - perhaps the size of the rectangle could vary to a certain degree? Perhaps the shape too? Something non-numeric, so that one gets immediate visual feedback.) i guess you know it, and i'm definitely not complaining about prototype code, but rendering is quite slow: drawing the 340 changesets in the current kernel repository takes 15 seconds on a 2 GHz P4. Drawing the full kernel history (63,000 changesets) would take more than 45 minutes on this box. the current rate of kernel development is ~2000 changesets per month, so drawing the kernel history will get 3 seconds slower every day - it will exceed 1 minute in 20 days, so this will become a pressing issue quite soon i suspect. Right, it is slow. From what I could understand with a bit of profiling, the problem is with the text canvas item for the boxes' labels. I guess libgnomecanvas isn't using Pango properly or something: it lookups the font with fontconfig each time I create such an item. I'm not sure what I can do about this. when the redrawing happens in the visible area then one can see how really slow it is: 100-200 msec per rectangle (!). It works with Petr Baudis' git-pasky (it calls `git diff'). I don't know how to do that with the canonical git. ah, ok. I guess it will start working once Petr's changes are merged into Linus' tree. Ingo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wit 0.0.3 - a web interface for git available
On 4/21/05, Kay Sievers [EMAIL PROTECTED] wrote: On Wed, Apr 20, 2005 at 10:42:53AM +0100, Christoph Hellwig wrote: It's working now: http://ehlo.org/~kay/gitweb.pl Kay + Christian + Ken, That looks really great!. One suggestion: when drilling down through the tree it would be nice if the context of the parents could be dragged along too. So, for example, when displaying the BLOB, you could display its name because you have kept enough context around to allow that. This would also allow you to extend the functionality so that when you are at the BLOB level you could navigate to a history of changes to just that BLOB, at least from the point of view of the commit that got you there. Also, have you considered generating pure XML from the database and relying on XSLT (either at the server, or preferably at the client - they all do it well these days!) to do the HTML rendering? jon. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Colorized git log
Dear diary, on Thu, Apr 21, 2005 at 11:12:45PM CEST, I got a letter where Sean [EMAIL PROTECTED] told me that... On the off chance that someone else might like it, here is a pager script for the git log that adds a splash of color: Actually, I would've never expected that I would like it, but we all sometimes surprise ourselves. I made git log colorized if you pass it -c in current git-pasky. Thanks. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Make -p flag optional from commit-tree.
We cannot currently say:
$ commit-tree $(write-tree) $(cat .git/heads/junio .git/heads/linus)
The above must be written as:
$ commit-tree $(write-tree) \
-p $(cat .git/heads/junio) \
-p $(cat .git/heads/linus)
This patch makes -p flag optional. Existing scripts are
hopefully not affected because they are passing -p properly. If
we want to introduce non parent-ID parameters to commit-tree
later, we can give them their own -flag letters.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
commit-tree.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
commit-tree.c: c0b07f89286c3f6cceae8122b4c3142c8efaf8e1
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -297,10 +297,17 @@ int main(int argc, char **argv)
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]))
+ for (i = 2; i argc; i++) {
+ /* Historically commit-tree required -p in front of
+* each parent commit ID. This is confusing. We can
+* add non parent commit ID parameter later by defining
+* flags other than -p so let's just ignore them.
+*/
+ if (! strcmp(argv[i], -p))
+ continue;
+
+ /* Currently it just expects parent IDs. */
+ if (get_sha1_hex(argv[i], parent_sha1[parents]))
usage(commit_tree_usage);
check_valid(parent_sha1[parents], commit);
parents++;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] multi item packed files
On Thu, 21 Apr 2005, Chris Mason wrote: Shrug, we shouldn't need help from the kernel for something like this. git as a database hits worst case scenarios for almost every FS. I really disagree. We've got: 1) subdirectories with lots of files 2) wasted space for tiny files 3) files that are likely to be accessed together spread across the whole disk On the other hand, git does a lot of things that are just _lovely_ for a filesystem: - it never rewrites a file. Rewriting a file is unquestionably _the_ single worst access pattern for any filesystem. In contrast, never writing to a file again means that filesystems can optimize their layout and that things like defragmentation actually works. - it caches beautifully, and efficiently. Part of it comes from never modifying files after they are written (which means that any network filesystem automatically breathes a huge sign of relief), but part of it is that it always reads full files, and the layout is done so that it really actually _uses_ everything it reads. It also caches beautifully on a memory subsystem level, largely for the same reasons. - it doesn't use tons of directories. You say that subdirectories with lots of files is painful, but that's not really the whole story. A _deep_ directory structure tends to actually be worse in many ways, because it's much easier to optimize a flat directory structure than a deep one. In other words, git ends up making name hashing etc _productive_. So yes, it's a bit wasteful. But it's wasteful of what is absolutely the cheapest resource around: disk space. It's not a huge downside, and in fact I really do believe that the biggest downside _by_far_ in diskspace utilization is the _seek_ costs, not the space itself. Let's face it, anybody who wants three years of kernel archives and thinks that 3GB of disk is too much, has some serious problems. The _seek_ issue is real, but git actually has a very nice architecture even there: not only dos it cache really really well (and you can do a simple ls-tree $(cat .git/HEAD) and populate the case from the results), but the low level of indirection in a git archive means that it's almost totally prefetchable with near-perfect access patterns. In seeking, the real cost is synchronization, and the git model actually means that there are very few seeks that have to be synchronized. You could literally do the ls-tree thing and make an absolutely trivial prefetcher that did the prefetching with enough parallellism that the filesystem could probably get decent IO performance out of a disk. In other words, we really could have a git prefetch command that would populate the cache of the current head quite efficiently. Because the data layout supports that. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Docs update
DG == David Greaves [EMAIL PROTECTED] writes: Looks nice. I agree with Petr's comment that separating core part and Cogito part would be good, and I would appreciate if you pushed the core part documentation to Linus as well. Some nitpicks and notes on your core part description. DG commit-tree DG - commit-tree sha1 [-p sha1]* changelog DG + commit-tree sha1 [-p parent sha1...] changelog The above does not describe what commit-tree expects. It wants commit-tree tree-sha1 [-p parent1 sha1]* changelog That is, you need -p before every parent. I however think what coommit-tree does here this aspect is wrong, unless Linus has plans to give parameters other than parent IDs to commit-tree later. Even if that is the case, those non-parent things can have their own -flag in front of them so not requiring -p would be a good change. I'll ask opinion from Linus on this (I just sent out a patch). DG +A commit object usually has 1 parent (a commit after a change) or 2 DG +parents (a merge) although there is no reason it cannot have more than DG +2 parents. I'd rewrite the or 2 parents... part to up to 16 parents. More than one parent represents merge of branches that led to them. DG +If not provided, commit-tree uses your name, hostname and domain to DG +provide author and committer info. This can be overridden using the DG +following environment variables. DG + ... DG +(nb , and CRs are stripped) CRs are kept. It removes '\n' (which is not necessarily LF). DG +diff-cache DG + diff-cache [-r] [-z] tree/commit sha1 DG + DG +Compares the content and mode of the blobs found via a tree object DG +with the content of the current cache and, optionally, the stat state DG +of the file on disk. And the option to use working tree is not having the --cached flag you describe later. Please also update the usage at the top as well: diff-cache [-r] [-z] [--cached] tree/commit sha1 DG +In the special case of the file being changed on disk and out of sync with the cache, the sha1 DG + DG +Operating Modes Is the description truncated after the sha1??? DG DG diff-tree DG - diff-tree [-r] [-z] tree sha1 tree sha1 DG + diff-tree [-r] [-z] tree sha1 tree sha1 This command can take commit ID in place of tree ID. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ia64 git pull
Dear diary, on Fri, Apr 22, 2005 at 12:29:07AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote: I can't quite see how to manage multiple heads in git. I notice that in your tree on kernel.org that .git/HEAD is a symlink to heads/master ... perhaps that is a clue. It's mainly a clue to bad practice, in my opinion. I personally like the one repository, one head approach, and if you want multiple heads you just do multiple repositories (and you can then mix just the object database - set your SHA1_FILE_DIRECTORY environment variable to point to the shared object database, and you're good to go). There are two points regarding this: (i) You need to track heads of remote branches anyway. (ii) I want an easy way for user to refer to head of another working tree on the same repository (so that you can do just git merge testing). This is why the multiple heads are there, and it's actually everything they _do_. There's nothing more behind it. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Missing linefeeds
Hi,
Petr Baudis:
Why? report() already prints linefeed.
Ah, it didn't when I wrote this.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add DEST Makefile variable
Hi,
Junio C Hamano:
I sent essentially the same some time ago and got a comment to
follow established naming convention.
Well, for a Makefile which installs in basically one directory, that
seems to be overkill.
# DESTDIR=
BINDIR=$(HOME)/bin
install foobar $(DESTDIR)$(BINDIR)/
That doesn't make sense; if you set DESTDIR, you are not going to
install in $HOME.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Colorized git log
Hi!
On 4/21/05, Petr Baudis [EMAIL PROTECTED] wrote:
I made git log colorized if you pass it -c in current git-pasky.
This has two problems, solved in two patches:
* A space is added in front of header lines when you use color.
* It does not work in my (Debian) xterm. This is because here
setterm only works with TERM=linux.
-
Strip space in front of colorized header lines.
gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -27,7 +27,7 @@ fi
base=$(gitXnormid.sh -c $1) || exit 1
rev-tree $base | sort -rn | while read time commit parents; do
- echo $colheader commit ${commit%:*} $coldefault;
+ echo $colheadercommit ${commit%:*} $coldefault;
cat-file commit $commit | \
while read key rest; do
case $key in
@@ -43,10 +43,10 @@ rev-tree $base | sort -rn | while read t
dtz=${tz/+/+ }; dtz=${dtz/-/- }
pdate=$(date -Rud 1970-01-01 UTC + $sec sec
$dtz 2/dev/null)
if [ $pdate ]; then
- echo -n $color $key $rest | sed
s/.*/ ${pdate/+/$tz}/
+ echo -n $color$key $rest | sed s/.*/
${pdate/+/$tz}/
echo $coldefault
else
- echo $color $key $rest $coldefault
+ echo $color$key $rest $coldefault
fi
;;
)
@@ -56,7 +56,7 @@ rev-tree $base | sort -rn | while read t
'
;;
*)
- echo $colheader $key $rest $coldefault
+ echo $colheader$key $rest $coldefault
;;
esac
-
Uses tput instead of setterm to set colors, seems to work with more
terminals.
gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -11,11 +11,11 @@
if [ $1 = -c ]; then
shift
- colheader=$(setterm -foreground green)
- colauthor=$(setterm -foreground cyan)
- colcommitter=$(setterm -foreground magenta)
- colsignoff=$(setterm -foreground yellow)
- coldefault=$(setterm -foreground default)
+ colheader=$(tput setaf 2)
+ colauthor=$(tput setaf 6)
+ colcommitter=$(tput setaf 5)
+ colsignoff=$(tput setaf 3)
+ coldefault=$(tput op)
else
colheader=
colauthor=
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Colorized git log
Hi!
On 4/21/05, Petr Baudis [EMAIL PROTECTED] wrote:
Dear diary, on Fri, Apr 22, 2005 at 02:46:19AM CEST, I got a letter
where Daniel Serpell [EMAIL PROTECTED] told me that...
This has two problems, solved in two patches:
could you please sign them off?
Ok, here are, resent (I suppose it's ok tho put all in one e-mail),
and with the comments added.
--
Strip space in front of colorized header lines.
Signed-off-by: Daniel Serpell [EMAIL PROTECTED]
+++ b/gitlog.sh
@@ -27,7 +27,7 @@ fi
base=$(gitXnormid.sh -c $1) || exit 1
rev-tree $base | sort -rn | while read time commit parents; do
- echo $colheader commit ${commit%:*} $coldefault;
+ echo $colheadercommit ${commit%:*} $coldefault;
cat-file commit $commit | \
while read key rest; do
case $key in
@@ -43,10 +43,10 @@ rev-tree $base | sort -rn | while read t
dtz=${tz/+/+ }; dtz=${dtz/-/- }
pdate=$(date -Rud 1970-01-01 UTC + $sec sec
$dtz 2/dev/null)
if [ $pdate ]; then
- echo -n $color $key $rest | sed
s/.*/ ${pdate/+/$tz}/
+ echo -n $color$key $rest | sed s/.*/
${pdate/+/$tz}/
echo $coldefault
else
- echo $color $key $rest $coldefault
+ echo $color$key $rest $coldefault
fi
;;
)
@@ -56,7 +56,7 @@ rev-tree $base | sort -rn | while read t
'
;;
*)
- echo $colheader $key $rest $coldefault
+ echo $colheader$key $rest $coldefault
;;
esac
--
Uses tput instead of setterm to set colors, seems to work with more
terminals.
Signed-off-by: Daniel Serpell [EMAIL PROTECTED]
gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -11,11 +11,11 @@
if [ $1 = -c ]; then
shift
- colheader=$(setterm -foreground green)
- colauthor=$(setterm -foreground cyan)
- colcommitter=$(setterm -foreground magenta)
- colsignoff=$(setterm -foreground yellow)
- coldefault=$(setterm -foreground default)
+ colheader=$(tput setaf 2) # Green, see terminfo(5), Color Handling
+ colauthor=$(tput setaf 6) # Cyan
+ colcommitter=$(tput setaf 5) # Magenta
+ colsignoff=$(tput setaf 3) # Yellow
+ coldefault=$(tput op) # Restore default
else
colheader=
colauthor=
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Colorized git log
On Thursday 21 April 2005 06:54 pm, Petr Baudis wrote: Duh. And they say Where possible terminfo is consulted to find the string to use. in their manual page. :/ gitlog.sh: 6d24d857fb6c2f7e810954adaca1990599906f07 --- a/gitlog.sh +++ b/gitlog.sh @@ -11,11 +11,11 @@ if [ $1 = -c ]; then shift - colheader=$(setterm -foreground green) - colauthor=$(setterm -foreground cyan) - colcommitter=$(setterm -foreground magenta) - colsignoff=$(setterm -foreground yellow) - coldefault=$(setterm -foreground default) + colheader=$(tput setaf 2) + colauthor=$(tput setaf 6) + colcommitter=$(tput setaf 5) + colsignoff=$(tput setaf 3) + coldefault=$(tput op) else colheader= colauthor= Please at least stick the colors in comments after the assignment. Not everyone knows ANSI color codes off-hand (the last thing I've memorized were BIOS color codes in the distant DOS days). I like the color idea, but since many people have their own idea of what colors are appropriate, etc (I use a dark background, and the magenta is painful), perhaps we could have a LOG_COLORS file, similar in concept (but more readable) to the /etc/DIR_COLORS file. Great work ! Steven - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Colored log on any ANSI capable terminal
Hello! setterm only works on Linux terminal. It should be safe to use raw ANSI sequences -they work on most terminals, including xterm. Nobody forces you to use the -c option to git log on those stone-age terminals that neither support nor ignore ANSI color codes. I'm aware of $'...' but it may not work in bash 1.x. Signed-off-by: Pavel Roskin [EMAIL PROTECTED] --- a/gitlog.sh +++ b/gitlog.sh @@ -12,11 +12,11 @@ if [ $1 = -c ]; then shift - colheader=$(setterm -foreground green) - colauthor=$(setterm -foreground cyan) - colcommitter=$(setterm -foreground magenta) - colsignoff=$(setterm -foreground yellow) - coldefault=$(setterm -foreground default) + colheader=$(echo -ne '\e[32m') + colauthor=$(echo -ne '\e[36m') + colcommitter=$(echo -ne '\e[35m') + colsignoff=$(echo -ne '\e[33m') + coldefault=$(echo -ne '\e[39m') else colheader= colauthor= -- Regards, Pavel Roskin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ia64 git pull
Dear diary, on Fri, Apr 22, 2005 at 03:48:35AM CEST, I got a letter where Inaky Perez-Gonzalez [EMAIL PROTECTED] told me that... Petr Baudis [EMAIL PROTECTED] writes: I've just added to git-pasky a possibility to refer to branches inside of repositories by a fragment identifier: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#testing will refer to your testing branch in that repository. Can we use something other than #? we'll have to scape it all the time in the shell (or at least also allow some other char, something without special meta-character meaning in the shell, like %). Remember that it's an URL (so you can't use '%'), and '#' is the canonical URL fragment identifier delimiter. (And fragments are perfect for this kind of thing, if you look at the RFC, BTW.) Still, why would you escape it? My shell will not take # as a comment start if it is immediately after an alphanumeric character. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-pasky spec file
Here's a simple spec file to do rpm builds. It's against the
latest Makefile (which has the s/BINDIR/bindir/ change). I've used
DESTDIR, although it's not clear it's meant to stay in the Makefile.
For now, there's no dynamic (git.spec.in, for example) update to the
Version, so it's set against 0.6.3 (expecting it to be forthcoming
shortly). It installs to /usr/local/bin, and expects the tarball to be
named git-pasky-0.6.3.tar.bz2. Creates a package named git, which seems
fine since Linus' isn't likely to be packaged directly. Enjoy.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
--- /dev/null 1969-12-31 16:00:00.0 -0800
+++ git-pasky-0.6.3/git.spec2005-04-21 18:42:18.0 -0700
@@ -0,0 +1,43 @@
+Name: git
+Version: 0.6.3
+Release: 1
+Vendor:Petr Baudis [EMAIL PROTECTED]
+Summary: Git core and tools
+License: GPL
+Group: Development/Tools
+URL: http://pasky.or.cz/~pasky/dev/git/
+Source:
http://pasky.or.cz/~pasky/dev/git/%{name}-pasky-%{version}.tar.bz2
+Provides: git = %{version}
+BuildRequires: zlib-devel openssl-devel
+BuildRoot: %{_tmppath}/%{name}-%{version}-root
+Prereq:sh-utils diffutils
+
+%description
+GIT comes in two layers. The bottom layer is merely an extremely fast
+and flexible filesystem-based database designed to store directory trees
+with regard to their history. The top layer is a SCM-like tool which
+enables human beings to work with the database in a manner to a degree
+similar to other SCM tools (like CVS, BitKeeper or Monotone).
+
+%prep
+%setup -q -n %{name}-pasky-%{version}
+
+%build
+
+make
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make DESTDIR=$RPM_BUILD_ROOT/usr/local/ bindir=bin/ install
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root)
+/usr/local/bin/*
+#%{_mandir}/*/*
+
+%changelog
+* Thu Apr 21 2005 Chris Wright [EMAIL PROTECTED] 0.6.3-1
+- Initial rpm build
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-pasky spec file
Dear diary, on Fri, Apr 22, 2005 at 03:55:21AM CEST, I got a letter where Chris Wright [EMAIL PROTECTED] told me that... Here's a simple spec file to do rpm builds. It's against the latest Makefile (which has the s/BINDIR/bindir/ change). I've used DESTDIR, although it's not clear it's meant to stay in the Makefile. For now, there's no dynamic (git.spec.in, for example) update to the Version, so it's set against 0.6.3 (expecting it to be forthcoming shortly). It installs to /usr/local/bin, and expects the tarball to be named git-pasky-0.6.3.tar.bz2. Creates a package named git, which seems fine since Linus' isn't likely to be packaged directly. Enjoy. Thanks, applied. I'll gladly yet you maintain this file, but... --- /dev/null 1969-12-31 16:00:00.0 -0800 +++ git-pasky-0.6.3/git.spec 2005-04-21 18:42:18.0 -0700 @@ -0,0 +1,43 @@ +%install +rm -rf $RPM_BUILD_ROOT +make DESTDIR=$RPM_BUILD_ROOT/usr/local/ bindir=bin/ install I doubt this is actually what you want. I suppose you want make DESTDIR=$RPM_BUILD_ROOT prefix=/usr/local install instead. This may not matter now, but might well in future when we stuff some of the helper/library scripts to some lib/ or share/ directory, and will actually rewrite some paths somewhere based on $prefix during make install. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Eliminate use of mktemp's -t option
It turns out that mktemp's -t option, while useful, isn't available on many systems (Mandrake Red Hat Linux 9 at least, and probably piles of others). So, here's a portability patch that removes all use of mktemp's -t option. Unlike the quick hack I posted earlier, this should be clean everywhere (assuming you have mktemp). This is a patch against git-pasky 0.6.3. This is my first attempt to _post_ a patch using git itself, and I'm not entirely sure how you want it. Let me know if you have a problem with it! --- David A. Wheeler commit 5f926b684025b83e34386bf8e4ef30a97e2ae5ec tree 61059575269ed1027cfb66543251e182f87d1064 parent dd69ca5f806c8b10bb29ecb8d77c88be007c981c author David A. Wheeler [EMAIL PROTECTED] 1114138972 -0400 committer David A. Wheeler [EMAIL PROTECTED] 1114138972 -0400 Eliminated use of mktemp's -t option; older mktemps don't support it. Index: README === --- 6a612d42afdba20fd2150e319a689ed451b010e4/README (mode:100644 sha1:a71b5fbdbdac0bf2e2d021e422b9f49dd5481165) +++ 61059575269ed1027cfb66543251e182f87d1064/README (mode:100644 sha1:80952e2f67b28f64c10cfb913df375a5dd244cd9) @@ -141,7 +141,7 @@ C compiler bash basic shell environment (sed, grep, textutils, ...) - mktemp 1.5+ (Mandrake users beware!) + mktemp diff, patch libssl rsync Index: gitapply.sh === --- 6a612d42afdba20fd2150e319a689ed451b010e4/gitapply.sh (mode:100755 sha1:7703809dc0743c6e4c1fa5b7d922a4efc16b4276) +++ 61059575269ed1027cfb66543251e182f87d1064/gitapply.sh (mode:100755 sha1:14a13ff23cff2a80f9a44c053002f837fec13e2c) @@ -8,9 +8,13 @@ # # Takes the diff on stdin. -gonefile=$(mktemp -t gitapply.XX) -todo=$(mktemp -t gitapply.XX) -patchfifo=$(mktemp -t gitapply.XX) +if [ -z $TMPDIR]; then + TMPDIR=/tmp +fi + +gonefile=$(mktemp $TMPDIR/gitapply.XX) +todo=$(mktemp $TMPDIR/gitapply.XX) +patchfifo=$(mktemp $TMPDIR/gitapply.XX) rm $patchfifo mkfifo -m 600 $patchfifo show-files --deleted $gonefile Index: gitcommit.sh === --- 6a612d42afdba20fd2150e319a689ed451b010e4/gitcommit.sh (mode:100755 sha1:a13bef2c84492ed75679d7d52bb710df35544f8a) +++ 61059575269ed1027cfb66543251e182f87d1064/gitcommit.sh (mode:100755 sha1:ee777605dccdc9737cf743f4f8c96b9bacd97f10) @@ -16,6 +16,9 @@ exit 1 } +if [ -z $TMPDIR]; then + TMPDIR=/tmp +fi [ -s .git/blocked ] die committing blocked: $(cat .git/blocked) @@ -67,7 +70,7 @@ fi echo Enter commit message, terminated by ctrl-D on a separate line: -LOGMSG=$(mktemp -t gitci.XX) +LOGMSG=$(mktemp $TMPDIR/gitci.XX) if [ $merging ]; then echo -n 'Merge with ' $LOGMSG echo -n 'Merge with ' @@ -111,7 +114,7 @@ if [ ! $customfiles ]; then rm -f .git/add-queue .git/rm-queue else - greptmp=$(mktemp -t gitci.XX) + greptmp=$(mktemp $TMPDIR/gitci.XX) for file in $customfiles; do if [ -s .git/add-queue ]; then fgrep -vx $file .git/add-queue $greptmp Index: gitdiff-do === --- 6a612d42afdba20fd2150e319a689ed451b010e4/gitdiff-do (mode:100755 sha1:218dfabeb4a5dcbd2cf58bd6f672f385690ec397) +++ 61059575269ed1027cfb66543251e182f87d1064/gitdiff-do (mode:100755 sha1:caf20ae034b8dc9f88922ee9f82809bb32a56231) @@ -32,7 +32,11 @@ [ $labelapp ] label=$label ($labelapp) } -diffdir=$(mktemp -d -t gitdiff.XX) +if [ -z $TMPDIR]; then + TMPDIR=/tmp +fi + +diffdir=$(mktemp -d $TMPDIR/gitdiff.XX) diffdir1=$diffdir/$id1 diffdir2=$diffdir/$id2 mkdir $diffdir1 $diffdir2 Index: gitdiff.sh === --- 6a612d42afdba20fd2150e319a689ed451b010e4/gitdiff.sh (mode:100755 sha1:195c3b9962c764855ec6168a78babf5867ea3046) +++ 61059575269ed1027cfb66543251e182f87d1064/gitdiff.sh (mode:100755 sha1:278511a3f491ed7d5e41bbd642acfd9b5a1d8257) @@ -80,6 +80,10 @@ shift fi +if [ -z $TMPDIR]; then + TMPDIR=/tmp +fi + if [ $parent ]; then id2=$id1 id1=$(parent-id $id2 | head -n 1) @@ -88,7 +92,7 @@ if [ $id2 = ]; then if [ $id1 != ]; then - export GIT_INDEX_FILE=$(mktemp -t gitdiff.XX) + export GIT_INDEX_FILE=$(mktemp $TMPDIR/gitdiff.XX) read-tree $(gitXnormid.sh $id1) update-cache --refresh fi Index: gitmerge.sh === --- 6a612d42afdba20fd2150e319a689ed451b010e4/gitmerge.sh (mode:100755 sha1:683755729b6f689ea43c692712fad6e51eeac354) +++ 61059575269ed1027cfb66543251e182f87d1064/gitmerge.sh (mode:100755 sha1:1c733bbdb9fe54c41787d962d0f55bb5f67d4c63) @@ -19,6 +19,10 @@ exit 1 }
Re: ia64 git pull
Petr Baudis [EMAIL PROTECTED] writes: Still, why would you escape it? My shell will not take # as a comment start if it is immediately after an alphanumeric character. I guess there MIGHT be some command shell implementation that stupidly _DID_ accept # as a comment character, even immediately after an alphanumeric. If that's true, then using # there would be a pain for portability. But I think that's highly improbable. A quick peek at the Single Unix Specification as posted by the Open Group seems to say that, according to the standards, that's NOT okay: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02 Basically, the command shell is supposed to tokenize, and # only means comment if it's at the beginning of a token. And as far as I can tell, it's not an issue in practice either. I did a few quick tests on Fedora Core 3 and OpenBSD. On Fedora Core 3, I can say that bash, ash csh all do NOT consider # as a comment start if an alpha precedes it. The same is true for OpenBSD /bin/sh, /bin/csh, and /bin/rksh. If such different shells do the same thing (this stuff isn't even legal C-shell text!), it's likely others do too. --- David A. Wheeler - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git-pasky-0.6.3 request for testing
On Thursday 21 April 2005 09:09 pm, Petr Baudis wrote: Hello, FYI, I've released git-pasky-0.6.3 earlier in the night. It brings especially plenty of bugfixes, but also some tiny enhancements, like colored log and ability to pick branch in the remote repository. git log and git patch now also accept range of commits, so e.g. if you do Here's a patch to let people know about the nice color feature. Signed-off-by: Steven Cole [EMAIL PROTECTED] Index: git === --- 0a9ee5a4d947b998a7ce489242800b39f985/git (mode:100755 sha1:39969debd59ed51c57973c819cdcc3ca8a7da819) +++ uncommitted/git (mode:100755) @@ -35,7 +35,7 @@ forkBNAME BRANCH_DIR [COMMIT_ID] help initRSYNC_URL - log [COMMIT_ID | COMMIT_ID:COMMIT_ID] + log [-c] [COMMIT_ID | COMMIT_ID:COMMIT_ID] ls [TREE_ID] lsobj [OBJTYPE] lsremote Index: gitlog.sh === --- 0a9ee5a4d947b998a7ce489242800b39f985/gitlog.sh (mode:100755 sha1:50eab642cdf5e695cf15be4ce3a7469dd68637e7) +++ uncommitted/gitlog.sh (mode:100755) @@ -7,6 +7,14 @@ # Major optimizations by (c) Phillip Lougher. # Rendered trivial by Linus Torvalds. # +# Takes a -c option to add color to the output. +# Currently, the colors are: +# +# header Green +# author Cyan +# committer Magenta +# signoff Yellow +# # Takes an id resolving to a commit to start from (HEAD by default), # or id1:id2 representing an (id1;id2] range of commits to show. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT_INDEX_FILE environment variable
On Thu, 21 Apr 2005, Junio C Hamano wrote: I am thinking about an alternative way of doing the above by some modifications to the git core. I think the root of this problem is that there is no equivalent to GIT_INDEX_FILE and SHA1_FILE_DIRECTORY that tells the core git where the project top directory (i.e. the root of the working tree that corresponds to what $GIT_INDEX_FILE describes) is. I'd _really_ prefer to just try to teach people to work from the top directory instead. - A new environment variable GIT_WORKING_TREE points at the root of the working tree. - Each git core command [*1*] that looks at the working tree is modified to take the user supplied pathname as a path relative to the current working directory, and use GIT_WORKING_TREE value to figure out which path the user is talking about, relative to the tree structure GIT_INDEX_FILE describes. I really don't like it that much, but to some degree it obviously is exactly what --prefix= does to checkout-cache. It's basically saying that all normal file operations have to be prefixed with a magic string. And git really doesn't do too many of those, so maybe it's ok. What would the patch look like? I don't really love the idea, but if the patch is clean enough... Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] optimized SHA1 for powerpc
Linus,
Just for fun, I wrote a ppc-assembly SHA1 routine. It appears to be
about 2.5x faster than the generic version. It reduces the time for a
fsck-cache on a linux-2.6 tree from ~6.8 seconds to ~6.0 seconds on my
G4 powerbook.
Paul.
diff -urN git.orig/Makefile git/Makefile
--- git.orig/Makefile 2005-04-22 15:21:10.0 +1000
+++ git/Makefile2005-04-22 15:11:28.0 +1000
@@ -25,7 +25,12 @@
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o
LIB_FILE=libgit.a
-LIB_H=cache.h object.h
+LIB_H=cache.h object.h sha1.h
+
+arch := $(shell uname -m | tr -d 0-9)
+ifeq ($(arch),ppc)
+LIB_OBJS += sha1.o sha1ppc.o
+endif
$(LIB_FILE): $(LIB_OBJS)
$(AR) rcs $@ $(LIB_OBJS)
diff -urN git.orig/cache.h git/cache.h
--- git.orig/cache.h2005-04-22 15:21:10.0 +1000
+++ git/cache.h 2005-04-22 13:57:36.0 +1000
@@ -12,7 +12,7 @@
#include sys/mman.h
#include netinet/in.h
-#include openssl/sha.h
+#include sha1.h
#include zlib.h
/*
diff -urN git.orig/sha1.c git/sha1.c
--- /dev/null 2005-04-04 12:56:19.0 +1000
+++ git/sha1.c 2005-04-22 15:17:27.0 +1000
@@ -0,0 +1,72 @@
+/*
+ * SHA-1 implementation.
+ *
+ * Copyright (C) 2005 Paul Mackerras [EMAIL PROTECTED]
+ *
+ * This version assumes we are running on a big-endian machine.
+ * It calls an external sha1_core() to process blocks of 64 bytes.
+ */
+#include stdio.h
+#include string.h
+#include sha1.h
+
+extern void sha1_core(uint32_t *hash, const unsigned char *p,
+ unsigned int nblocks);
+
+int SHA1_Init(SHA_CTX *c)
+{
+ c-hash[0] = 0x67452301;
+ c-hash[1] = 0xEFCDAB89;
+ c-hash[2] = 0x98BADCFE;
+ c-hash[3] = 0x10325476;
+ c-hash[4] = 0xC3D2E1F0;
+ c-len = 0;
+ c-cnt = 0;
+ return 0;
+}
+
+int SHA1_Update(SHA_CTX *c, const void *ptr, unsigned long n)
+{
+ unsigned long nb;
+ const unsigned char *p = ptr;
+
+ c-len += n 3;
+ while (n != 0) {
+ if (c-cnt || n 64) {
+ nb = 64 - c-cnt;
+ if (nb n)
+ nb = n;
+ memcpy(c-buf.b[c-cnt], p, nb);
+ if ((c-cnt += nb) == 64) {
+ sha1_core(c-hash, c-buf.b, 1);
+ c-cnt = 0;
+ }
+ } else {
+ nb = n 6;
+ sha1_core(c-hash, p, nb);
+ nb = 6;
+ }
+ n -= nb;
+ p += nb;
+ }
+ return 0;
+}
+
+int SHA1_Final(unsigned char *hash, SHA_CTX *c)
+{
+ unsigned int cnt = c-cnt;
+
+ c-buf.b[cnt++] = 0x80;
+ if (cnt 56) {
+ if (cnt 64)
+ memset(c-buf.b[cnt], 0, 64 - cnt);
+ sha1_core(c-hash, c-buf.b, 1);
+ cnt = 0;
+ }
+ if (cnt 56)
+ memset(c-buf.b[cnt], 0, 56 - cnt);
+ c-buf.l[7] = c-len;
+ sha1_core(c-hash, c-buf.b, 1);
+ memcpy(hash, c-hash, 20);
+ return 0;
+}
diff -urN git.orig/sha1.h git/sha1.h
--- /dev/null 2005-04-04 12:56:19.0 +1000
+++ git/sha1.h 2005-04-22 15:06:53.0 +1000
@@ -0,0 +1,19 @@
+#ifndef __powerpc__
+#include openssl/sha.h
+#else
+#include stdint.h
+
+typedef struct sha_context {
+ uint32_t hash[5];
+ uint32_t cnt;
+ uint64_t len;
+ union {
+ unsigned char b[64];
+ uint64_t l[8];
+ } buf;
+} SHA_CTX;
+
+int SHA1_Init(SHA_CTX *c);
+int SHA1_Update(SHA_CTX *c, const void *p, unsigned long n);
+int SHA1_Final(unsigned char *hash, SHA_CTX *c);
+#endif
diff -urN git.orig/sha1ppc.S git/sha1ppc.S
--- /dev/null 2005-04-04 12:56:19.0 +1000
+++ git/sha1ppc.S 2005-04-22 15:18:19.0 +1000
@@ -0,0 +1,185 @@
+/*
+ * SHA-1 implementation for PowerPC.
+ *
+ * Copyright (C) 2005 Paul Mackerras.
+ */
+#define FS 80
+
+/*
+ * We roll the registers for T, A, B, C, D, E around on each
+ * iteration; T on iteration t is A on iteration t+1, and so on.
+ * We use registers 7 - 12 for this.
+ */
+#define RT(t) t)+5)%6)+7)
+#define RA(t) t)+4)%6)+7)
+#define RB(t) t)+3)%6)+7)
+#define RC(t) t)+2)%6)+7)
+#define RD(t) t)+1)%6)+7)
+#define RE(t) t)+0)%6)+7)
+
+/* We use registers 16 - 31 for the W values */
+#define W(t) (((t)%16)+16)
+
+#define STEPD0(t) \
+ and %r6,RB(t),RC(t);\
+ andc%r0,RD(t),RB(t);\
+ rotlwi RT(t),RA(t),5; \
+ rotlwi RB(t),RB(t),30; \
+ or %r6,%r6,%r0;\
+ add %r0,RE(t),%r15; \
+ add RT(t),RT(t),%r6;\
+ add %r0,%r0,W(t); \
+ add RT(t),RT(t),%r0
+
+#define STEPD1(t)
