* Re: [ANNOUNCE] git-pasky-0.7
From: Daniel Barkalow @ 2005-04-24 4:32 UTC (permalink / raw)
To: Paul Jackson; +Cc: Petr Baudis, git
In-Reply-To: <20050423205847.7758bfaa.pj@sgi.com>
On Sat, 23 Apr 2005, Paul Jackson wrote:
> I'm missing something here (well, missing alot, but ...).
>
> What are the exact steps, given that I have an empty chunk
> of diskspace, to get Linux 2.6.12-rc3 to appear there, using
> git.
>
> Actually, I got part way. Perhaps someone can complete
> the following:
>
> mkdir git
> cd git
> curl -O ftp://ftp.kernel.org/pub/software/scm/cogito/git-pasky-0.6.3.tar.bz2
> tar xvfj git-pasky-0.6.3.tar.bz2
> cd git-pasky-0.6.3
> ls -l /usr/local/include/openssl/sha.h # yup - I have openssl header
> make
> ./git init rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> make install
> git addremote pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> git pull pasky
You might need a "git seek" or a "git cancel" or a "git track
pasky" here; make sure that VERSION is 0.7.
Then do make install again (to install the 0.7 version that you just got).
Then you want to go into the directory you want linux in:
cd ..
mkdir linux
cd linux
And get a version of Linux:
git init linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
(IIRC; I've only really worked on git with git)
If you do another addremote in the git directory, it will think that both
remote repositories are for different versions of the same project, and it
will be unhappy with the fact that they are completely unrelated.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-changes-script to show inter tree changes
From: James Bottomley @ 2005-04-24 1:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050423230937.GF13222@pasky.ji.cz>
On Sun, 2005-04-24 at 01:09 +0200, Petr Baudis wrote:
> Linus isn't probably the right person to Cc on this, since this is
> git-pasky thing. Can you please post it as a signed-off patch?
I'm just offering it as one of the scripts I need to operate a git tree
as a maintainer. I don't have git-pasky installed, so I can't patch it
against anything. However, feel free to incorporate any pieces you
need.
> I don't get what are you doing anyway. I don't know the "bk changes"
> tool. Can't you just do
>
> git log theothertree yourtree
No idea .. not used it. However, how does this show the -L and -R diffs
since there are two possible views of changes between trees? It's
primarily -L (changes in local) I need to keep the changes in my local
tree. -R (changes in remote) is just useful to show what changes I'm
missing and might need to merge.
James
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: James Purser @ 2005-04-24 4:17 UTC (permalink / raw)
To: Paul Jackson; +Cc: Petr Baudis, git
In-Reply-To: <20050423205847.7758bfaa.pj@sgi.com>
Try separating out the git directory and linux directory. As I
understand it each project/git repo needs its own directory.
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Paul Jackson @ 2005-04-24 3:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050424005923.GA8859@pasky.ji.cz>
I'm missing something here (well, missing alot, but ...).
What are the exact steps, given that I have an empty chunk
of diskspace, to get Linux 2.6.12-rc3 to appear there, using
git.
Actually, I got part way. Perhaps someone can complete
the following:
mkdir git
cd git
curl -O ftp://ftp.kernel.org/pub/software/scm/cogito/git-pasky-0.6.3.tar.bz2
tar xvfj git-pasky-0.6.3.tar.bz2
cd git-pasky-0.6.3
ls -l /usr/local/include/openssl/sha.h # yup - I have openssl header
make
./git init rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
make install
git addremote pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
git pull pasky
git addremote linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git pull linus
And I have the SHA1 for Linus's 2.6.12-rc3:
a2755a80f40e5794ddc20e00f781af9d6320fafb
And I've set DB_ENVIRONMENT=<this-git-directory>/.git/objects
Now I'd like to get 2.6.12-rc3 working kernel files to appear
in a separate directory.
Now what ... how do I do that?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: [PATCH] Add --strict switch to diff-cache to force SHA1 checking
From: Linus Torvalds @ 2005-04-24 3:57 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: pasky, git
In-Reply-To: <20050424033554.GA23293@diku.dk>
On Sun, 24 Apr 2005, Jonas Fonseca wrote:
>
> It seems by far the easiest to let diff-cache take care of skipping
> files which have not been modified. The alternative is to keep
> diff-cache's lazy checking and make cogito's diff jump through hoops.
> Note, although the new SHA1 signature is derived, diff-cache still
> prints the special no-SHA1 for the modified file.
The reason I don't want this is that if the commands keep on silently
fixing things like this up, then performance will go down the toilet.
What _should_ happen is that you do an "update-cache --refresh" before
doing the diff-cache. That way you do _not_ end up having to check the
sha1 match over and over again if you just did a "touch" on the file.
In other words, you're adding bandage for a problem that shouldn't exist,
and you're doing it in a way which means that _if_ the problem exists,
you'll never fix it, but you'll just rely on your bandage all the time.
So cogito definitely does not have to jump through any hoops at all. It
should just make sure to keep the cache up-to-date if it ever cares (ie
do "update-cache --refresh").
Some commands obviously won't care.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Linus Torvalds @ 2005-04-24 3:45 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: Petr Baudis, git
In-Reply-To: <1114306009.27940.23.camel@nosferatu.lan>
On Sun, 24 Apr 2005, Martin Schlemmer wrote:
>
> Over here gitmerge-file.sh is looking for a 'merge' command not present.
It's usually packaged up with RCS. So in that sense git does need RCS,
although it's really only the traditional three-way merge program it
wants.
Do "yum install rcs" and you should get it (or whatever your local
alternative is).
Linus
^ permalink raw reply
* [PATCH] Use diff-cache --strict in gitdiff.sh
From: Jonas Fonseca @ 2005-04-24 3:38 UTC (permalink / raw)
To: pasky, git
In-Reply-To: <20050424033554.GA23293@diku.dk>
Use diff-cache --strict invokation to only show diff of changed files.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
--- 2aaf94eae20acc451553766f3c063bc46cfa75c6/gitdiff.sh (mode:100755 sha1:1478a0cfb23a85c259eae1a36cf2a48597fbe8a2)
+++ uncommitted/gitdiff.sh (mode:100755)
@@ -76,7 +76,7 @@
# FIXME: Update ret based on what did we match. And take "$@"
# to account after all.
ret=
- diff-cache -r -z $tree | xargs -0 gitdiff-do "$tree" uncommitted "$filter"
+ diff-cache -r -z --strict $tree | xargs -0 gitdiff-do "$tree" uncommitted "$filter"
if [ "$id1" != " " ]; then
rm $GIT_INDEX_FILE
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] Add --strict switch to diff-cache to force SHA1 checking
From: Jonas Fonseca @ 2005-04-24 3:35 UTC (permalink / raw)
To: torvalds, pasky; +Cc: git
It seems by far the easiest to let diff-cache take care of skipping
files which have not been modified. The alternative is to keep
diff-cache's lazy checking and make cogito's diff jump through hoops.
Note, although the new SHA1 signature is derived, diff-cache still
prints the special no-SHA1 for the modified file.
-
Add --strict switch to diff-cache to force it to check the SHA1
signature of modified files so files are only listed if the mode or
content changed.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
--- 3b4a5bb703599458ce8fe504f37f8e28b77bd6ca/diff-cache.c (mode:100644 sha1:2ec6c29ab6b79a10277a2ff9021a2032d656abf0)
+++ uncommitted/diff-cache.c (mode:100644)
@@ -1,6 +1,7 @@
#include "cache.h"
static int cached_only = 0;
+static int strict_checking = 0;
static int line_termination = '\n';
/* A file entry went away or appeared */
@@ -10,6 +11,26 @@
sha1_to_hex(ce->sha1), ce->name, line_termination);
}
+static int check_modified_signature(struct cache_entry *old, struct stat *st)
+{
+ void *map;
+ int ret = -1;
+ int fd = open(old->name, O_RDONLY);
+
+ if (fd < 0)
+ return -1;
+
+ map = mmap(NULL, st->st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if (map != MAP_FAILED) {
+ ret = check_sha1_signature(old->sha1, map, st->st_size, "blob");
+ munmap(map, st->st_size);
+ }
+
+ close(fd);
+
+ return ret;
+}
+
static int show_modified(struct cache_entry *old, struct cache_entry *new)
{
unsigned int mode = ntohl(new->ce_mode), oldmode;
@@ -27,6 +48,12 @@
changed = cache_match_stat(new, &st);
if (changed) {
mode = st.st_mode;
+
+ if (strict_checking
+ && mode == ntohl(old->ce_mode)
+ && check_modified_signature(old, &st) == 0)
+ return 0;
+
sha1 = no_sha1;
}
}
@@ -85,7 +112,7 @@
}
}
-static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
+static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] [--strict] <tree sha1>";
int main(int argc, char **argv)
{
@@ -110,6 +137,10 @@
cached_only = 1;
continue;
}
+ if (!strcmp(arg, "--strict")) {
+ strict_checking = 1;
+ continue;
+ }
usage(diff_cache_usage);
}
--
Jonas Fonseca
^ permalink raw reply
* Re: Date handling.
From: James Purser @ 2005-04-24 3:33 UTC (permalink / raw)
To: Jan Harkes; +Cc: David Woodhouse, Linus Torvalds, git
In-Reply-To: <20050424030416.GE16751@delft.aura.cs.cmu.edu>
Wouldn't it be easier to force GMT or UTC as the base timezone for the
application. This would remove any confusion between different
timezones.
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* [PATCH] Add -u option to diff-cache to show UNCHANGED files
From: Andreas Gal @ 2005-04-24 3:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231906110.2344@ppc970.osdl.org>
With -u diff-cache shows unchanged files, instead of files that changed.
This is useful to implement a "git clean" command that throws away all
checked out files that have not changed (yes, I really would like to
have that). One could also do show-files and then substract the
diff-cache output from it, but thats slow and clumsy.
Signed-off-by: Andreas Gal <gal@uci.edu>
--- b407d753e520fa0b1523d770d98b3015af197275/diff-cache.c
+++ diff-cache.c
@@ -2,6 +2,7 @@
static int cached_only = 0;
static int line_termination = '\n';
+static int show_unchanged = 0;
/* A file entry went away or appeared */
static void show_file(const char *prefix, struct cache_entry *ce)
@@ -32,7 +33,7 @@
}
oldmode = ntohl(old->ce_mode);
- if (mode == oldmode && !memcmp(sha1, old->sha1, 20))
+ if ((mode == oldmode && !memcmp(sha1, old->sha1, 20)) != show_unchanged)
return 0;
strcpy(old_sha1_hex, sha1_to_hex(old->sha1));
@@ -85,7 +86,7 @@
}
}
-static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
+static char *diff_cache_usage = "diff-cache [-r] [-u] [-z] [--cached] <tree sha1>";
int main(int argc, char **argv)
{
@@ -102,6 +103,10 @@
/* We accept the -r flag just to look like diff-tree */
continue;
}
+ if (!strcmp(arg, "-u")) {
+ show_unchanged = 1;
+ continue;
+ }
if (!strcmp(arg, "-z")) {
line_termination = '\0';
continue;
^ permalink raw reply
* Re: Date handling.
From: Jan Harkes @ 2005-04-24 3:04 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, git
In-Reply-To: <1113500316.27227.8.camel@hades.cambridge.redhat.com>
On Thu, Apr 14, 2005 at 06:38:36PM +0100, David Woodhouse wrote:
> +/* Gr. strptime is crap for this; it doesn't have a way to require RFC2822
> + (i.e. English) day/month names, and it doesn't work correctly with %z. */
> +static void parse_rfc2822_date(char *date, char *result, int maxlen)
> +{
...
> + then = mktime(&tm); /* mktime appears to ignore the GMT offset, stupidly */
I noticed that some commit timestamps seemed to be off, looking into it
a bit more it seems like mktime is influenced by the setting of the
local TZ environment. However in parse_rfc2822_date we are trying to
interpret a time in the timezone of the original author not in the
timezone of the committer.
Here is a short test program that I believe shows the problem.
The question is, do we want to just calculate the time_t offset
ourselves without using mktime, or force the TZ environment to UTC.
Jan
/* cc -o mktime mktime.c ; ./mktime
*
* I get the following output,
* current 18000
* TZ=EST 18000
* TZ=UTC 0
* TZ=CET -3600
*/
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
struct tm tm = { 0, };
time_t zero;
/* 1970-01-01 00:00:00 UTC, should map to 'time_t 0' */
tm.tm_mday = 1;
tm.tm_year = 70;
zero = mktime(&tm); printf("current %d\n", zero);
setenv("TZ", "EST", 1); zero = mktime(&tm); printf("TZ=EST %d\n", zero);
setenv("TZ", "UTC", 1); zero = mktime(&tm); printf("TZ=UTC %d\n", zero);
setenv("TZ", "CET", 1); zero = mktime(&tm); printf("TZ=CET %d\n", zero);
}
^ permalink raw reply
* [PATCH] Allow multiple date-ordered lists
From: Daniel Barkalow @ 2005-04-24 2:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.21.0504232230080.30848-100000@iabervon.org>
Make pop_most_recent_commit() return the same objects multiple times, but only
if called with different bits to mark.
This is necessary to make merge-base work again.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
---
commit 58ec99a22e3a8dac158d9949b0a704752991ac8a
tree 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05
parent f4adf2687593e8d6e58ac1c4710e0385a82500e5
author Daniel Barkalow <barkalow@iabervon.org> 1114311416 -0400
committer Daniel Barkalow <barkalow@silva-tulga.(none)> 1114311416 -0400
Index: commit.c
===================================================================
--- 34933617a2e8284ffca6ab2a1b2f00d6996a58e7/commit.c (mode:100644 sha1:0243e77cb8e839e2972a2882bb1d0719f6e3cff1)
+++ 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05/commit.c (mode:100644 sha1:2502688262819033f5b8ed60a7bef5eed0aa2d6a)
@@ -114,7 +114,8 @@
*list = ret;
}
-struct commit *pop_most_recent_commit(struct commit_list **list)
+struct commit *pop_most_recent_commit(struct commit_list **list,
+ unsigned int mark)
{
struct commit *ret = (*list)->item;
struct commit_list *parents = ret->parents;
@@ -125,8 +126,9 @@
while (parents) {
struct commit *commit = parents->item;
- if (!commit->object.parsed) {
- parse_commit(commit);
+ parse_commit(commit);
+ if (!(commit->object.flags & mark)) {
+ commit->object.flags |= mark;
insert_by_date(list, commit);
}
parents = parents->next;
Index: commit.h
===================================================================
--- 34933617a2e8284ffca6ab2a1b2f00d6996a58e7/commit.h (mode:100644 sha1:c8684d1cd07d7c9ed0af06a3f3d9e7b49fbed0a2)
+++ 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05/commit.h (mode:100644 sha1:d61d084c89c72f4fe79c654db721df31c4f04224)
@@ -31,6 +31,7 @@
/** Removes the first commit from a list sorted by date, and adds all
* of its parents.
**/
-struct commit *pop_most_recent_commit(struct commit_list **list);
+struct commit *pop_most_recent_commit(struct commit_list **list,
+ unsigned int mark);
#endif /* COMMIT_H */
Index: merge-base.c
===================================================================
--- 34933617a2e8284ffca6ab2a1b2f00d6996a58e7/merge-base.c (mode:100644 sha1:0e4c58ede915aca5719bbd12ecd1945f2f300590)
+++ 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05/merge-base.c (mode:100644 sha1:2c40881302e586366f03ae6ac6e7c0035847e2f0)
@@ -6,29 +6,11 @@
int other_mark)
{
struct commit *item = (*list_p)->item;
-
- if (item->object.flags & this_mark) {
- /*
- printf("%d already seen %s %x\n",
- this_mark
- sha1_to_hex(posn->parent->sha1),
- posn->parent->flags);
- */
- /* do nothing; this indicates that this side
- * split and reformed, and we only need to
- * mark it once.
- */
- *list_p = (*list_p)->next;
- } else if (item->object.flags & other_mark) {
+
+ if (item->object.flags & other_mark) {
return item;
} else {
- /*
- printf("%d based on %s\n",
- this_mark,
- sha1_to_hex(posn->parent->sha1));
- */
- pop_most_recent_commit(list_p);
- item->object.flags |= this_mark;
+ pop_most_recent_commit(list_p, this_mark);
}
return NULL;
}
@@ -39,7 +21,9 @@
struct commit_list *rev2list = NULL;
commit_list_insert(rev1, &rev1list);
+ rev1->object.flags |= 0x1;
commit_list_insert(rev2, &rev2list);
+ rev2->object.flags |= 0x2;
parse_commit(rev1);
parse_commit(rev2);
Index: rev-list.c
===================================================================
--- 34933617a2e8284ffca6ab2a1b2f00d6996a58e7/rev-list.c (mode:100644 sha1:1c797d24a91b44994dc11180dd61c3ecf8f93349)
+++ 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05/rev-list.c (mode:100644 sha1:77bfc29db1aad08ba9d7d87ce08d33d4a88e74e3)
@@ -16,7 +16,7 @@
commit_list_insert(commit, &list);
do {
- struct commit *commit = pop_most_recent_commit(&list);
+ struct commit *commit = pop_most_recent_commit(&list, 0x1);
printf("%s\n", sha1_to_hex(commit->object.sha1));
} while (list);
return 0;
^ permalink raw reply
* Re: [PATCH] PPC assembly implementation of SHA1
From: Benjamin Herrenschmidt @ 2005-04-24 2:49 UTC (permalink / raw)
To: linux; +Cc: Paul Mackerras, git
In-Reply-To: <20050423124246.30071.qmail@science.horizon.com>
On Sat, 2005-04-23 at 12:42 +0000, linux@horizon.com wrote:
> - You don't need to decrement %r1 before saving registers.
> The PPC calling convention defines a "red zone" below the
> current stack pointer that is guaranteed never to be touched
> by signal handlers or the like. This is specifically for
> leaf procedure optimization, and is at least 224 bytes.
On ELF ppc32 ABI ? Hrm... the SysV ABI document says
"The only permitted references with negative offsets from the stack
pointer are those described here for establishing a stack frame."
I know MacOS had a red zone, but do we ?
> - Is that many stw/lwz instructions faster than stmw/lmw?
> The latter is at least more cahce-friendly.
More cache friendly ? Hrm.. I wouldn't be sure. Also, I remember readind
a while ago that those store/load multiple instructions aren't that
recommended. They aren't very good on some CPU models. I would expect
the bus/cache bandwidth to be the limiting factor here anyway, and as
you point out below, the they don't deal with unaligned access very well
in all cases.
^ permalink raw reply
* Re: A very basic tutorial
From: James Purser @ 2005-04-24 2:45 UTC (permalink / raw)
To: dwheeler; +Cc: git
In-Reply-To: <426B0226.8020001@dwheeler.com>
Thanks for the heads up, I shall update the tutorial with the new
information as soon as possible.
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: [PATCH 1/5] Add some functions for commit lists
From: Daniel Barkalow @ 2005-04-24 2:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231916300.2344@ppc970.osdl.org>
On Sat, 23 Apr 2005, Linus Torvalds wrote:
>
>
> On Sat, 23 Apr 2005, Linus Torvalds wrote:
> >
> > Ok. This is more in like with what I was hoping for, looks good.
>
> Oh, Daniel, I notice that you have the same old bug: it will happily add
> the same parent to the list several times. You need to prune them out, and
> ignore things you've seen.
>
> I pushed out the fix (don't parse and add parents to the list that were
> already parsed).
This won't actually work for merge-base, which wants to run two of these,
one for each head, in parallel, and find the first commit on both lists. I
think making insert_by_date() ignore items already in the list is a better
solution, although that might run into problems if there's a complicated
graph of commits all with the same time.
Another option is to specify a object.flags bit to mark for each commit
and ignore commits that are already marked.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/5] Add some functions for commit lists
From: Linus Torvalds @ 2005-04-24 2:20 UTC (permalink / raw)
To: Daniel Barkalow, Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231906110.2344@ppc970.osdl.org>
On Sat, 23 Apr 2005, Linus Torvalds wrote:
>
> Ok. This is more in like with what I was hoping for, looks good.
Oh, Daniel, I notice that you have the same old bug: it will happily add
the same parent to the list several times. You need to prune them out, and
ignore things you've seen.
I pushed out the fix (don't parse and add parents to the list that were
already parsed).
Linus
^ permalink raw reply
* Re: A very basic tutorial
From: David A. Wheeler @ 2005-04-24 2:19 UTC (permalink / raw)
To: James Purser, git
In-Reply-To: <1114305552.3114.3.camel@kryten>
James Purser wrote:
> I've done a very basic tutorial for using git. If someone who knows more
> about git (pretty much everyone on this list I think) could have a look
> and point out any glaring errors that would be great.
You mention two layers, but the layers are about to get (pun?)
separate names: git (lower layer) and Cogito (upper layer, and
separable from the "real" git lower layer). You should explain
the two names.
You concentrate on Cogito, which is almost certainly reasonable
for normal starting points, but that's not clear in your text.
Also: The Cogito user interface is about to undergo a
significant rename of the commands. It won't be hard to update
your text for it, but you'll need to do so.
--- David A. Wheeler
^ permalink raw reply
* Re: [PATCH 1/5] Add some functions for commit lists
From: Linus Torvalds @ 2005-04-24 2:12 UTC (permalink / raw)
To: Daniel Barkalow, Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.21.0504232003490.30848-100000@iabervon.org>
On Sat, 23 Apr 2005, Daniel Barkalow wrote:
>
> This adds a function for inserting an item in a commit list, a function
> for sorting a commit list by date, and a function for progressively
> scanning a commit history from most recent to least recent.
Ok. This is more in like with what I was hoping for, looks good.
All patches applied and pushed out, and I wrote a trivial "rev-list" thing
that is kind of a cut-down rev-tree which just lists the commits in the
order the "fake time order".
The "fake time order" just uses this progressive commit history scan,
which is different from the old "sort by date" in that it still takes
parenthood into account, and always shows the child first.
It turns out that since git is so damn fast, when I commit a mbox of
patches, they often all get the same date, since we "only" do dates with a
one-second granularity. So sorting by date ends up doing strange things,
when some of the entries have no sort order.
Daniel's date-based incremental scanning solves this problem, and also
means that we get output immediately without having to parse the whole
tree down to the root.
So with this, git-pasky should probably do the following..
Linus
-
Make gitlog.sh use the new simple time-based commit traversal
helpers.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
gitlog.sh: a496a864f9586e47a4d7bd3ae0af0b3e07b7deb8
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -11,7 +11,7 @@
base=$(gitXnormid.sh -c $1) || exit 1
-rev-tree $base | sort -rn | while read time commit parents; do
+rev-list $base | while read commit; do
echo commit ${commit%:*};
cat-file commit $commit | \
while read key rest; do
^ permalink raw reply
* fsck-cache problem
From: Morten Welinder @ 2005-04-24 1:55 UTC (permalink / raw)
To: GIT Mailing List, Linus Torvalds
While downloading the sparse git database I got impatient and ran
fsck-cache on it.
I got...
...
missing (null) ff515b91674ff2f5b082a927676dbf392d04d9ce
missing (null) ff94be6fbcce10b83824defbdc2f8819121bbd4d
missing (null) ffa4ddda950185bf313654e903207a3fc2d5f261
That "(null)" is not from git, but from glibc in response to NULL
passed for %s. It might
as well crash (as some other libc do) or send in the marines.
Morten
^ permalink raw reply
* [PATCH] Add archive-tree, a cpio archive creator
From: Rene Scharfe @ 2005-04-24 1:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, torvalds
This patch adds archive-tree, a program to create a cpio archive of all
files referenced by a given tree or commit object. Why cpio and not
e.g., tar? The cpio format I chose (GNU cpio calls it "odc") is dead
simple compared to any tar variant. I was simply being lazy. :-P
archive-tree optionally accepts a basedir, i.e. a prefix added to all
names in the archive. Example usage:
$ ./archive-tree `tree-id` frob-1.1 | gzip -9 > frob-1.1.cpio.gz
Directory permissions are not handled properly, yet. All directories
get a mode of (at least) 0755.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
--- git-pasky/Makefile~ 2005-04-20 01:43:51.000000000 +0200
+++ git-pasky/Makefile 2005-04-24 02:02:22.000000000 +0200
@@ -29,7 +29,7 @@
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base merge-cache unpack-file git-export \
- diff-cache convert-cache
+ diff-cache convert-cache archive-tree
SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
--- /dev/null 2004-12-03 19:50:49.000000000 +0100
+++ git-pasky/archive-tree.c 2005-04-24 03:31:39.000000000 +0200
@@ -0,0 +1,206 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Linus Torvalds, 2005
+ */
+#include "cache.h"
+
+const char *basedir = NULL;
+
+struct path_prefix {
+ struct path_prefix *prev;
+ const char *name;
+};
+
+static void append_string(char **buffer, const char *s)
+{
+ unsigned int len = strlen(s);
+ memcpy(*buffer, s, len);
+ *buffer += len;
+}
+
+static void append_char(char **buffer, char c)
+{
+ **buffer = c;
+ *buffer += 1;
+}
+
+static unsigned int path_prefix_len(struct path_prefix *prefix)
+{
+ if (!prefix)
+ return 0;
+ return path_prefix_len(prefix->prev) + strlen(prefix->name) + 1;
+}
+
+static void append_path_prefix(char **buffer, struct path_prefix *prefix)
+{
+ if (!prefix)
+ return;
+ append_path_prefix(buffer, prefix->prev);
+ append_string(buffer, prefix->name);
+ append_char(buffer, '/');
+}
+
+static unsigned long loopy_write(void *buf, unsigned long size)
+{
+ while (size > 0) {
+ long ret = write(1, buf, size);
+ if (ret < 0) {
+ if (errno == EAGAIN)
+ continue;
+ /* Ignore epipe */
+ if (errno == EPIPE)
+ break;
+ die("archive-tree: %s", strerror(errno));
+ } else if (!ret) {
+ die("archive-tree: disk full?");
+ }
+ size -= ret;
+ buf += ret;
+ }
+ return size;
+}
+
+static long write_header(const char *basepath,
+ struct path_prefix *prefix,
+ const char *path,
+ unsigned int mode,
+ unsigned long size)
+{
+ unsigned int namelen;
+ char *header, *p;
+ long ret;
+
+ namelen = path_prefix_len(prefix) + strlen(path) + 1;
+ if (basepath)
+ namelen += strlen(basepath) + 1;
+
+ header = malloc(76 + namelen);
+ if (!header)
+ die("archive-tree: %s", strerror(errno));
+
+ sprintf(header, "%06o%06o%06o%06o%06o%06o%06o%06o%011o%06o%011lo",
+ 070707, /* magic */
+ 0, /* dev */
+ 0, /* ino */
+ S_ISDIR(mode) ? mode | 0755 : mode, /* mode */ /*FIXME*/
+ 0, /* uid */
+ 0, /* gid */
+ 1, /* nlink */
+ 0, /* rdev */
+ 0, /* mtime */
+ namelen, /* namesize */
+ S_ISDIR(mode) ? 0 : size); /* filesize */
+
+ p = header + 76;
+ if (basepath) {
+ append_string(&p, basepath);
+ append_char(&p, '/');
+ }
+ append_path_prefix(&p, prefix);
+ append_string(&p, path);
+ append_char(&p, '\0');
+
+ ret = loopy_write(header, 76 + namelen);
+ free(header);
+ return ret;
+}
+
+static void write_trailer(void)
+{
+ write_header(NULL, NULL, "TRAILER!!!", 0, 0);
+}
+
+static void list_recursive(void *buffer,
+ const unsigned char *type,
+ unsigned long size,
+ struct path_prefix *prefix)
+{
+ struct path_prefix this_prefix;
+ this_prefix.prev = prefix;
+
+ if (strcmp(type, "tree"))
+ die("expected a 'tree' node");
+
+ while (size) {
+ int namelen = strlen(buffer)+1;
+ void *eltbuf;
+ char elttype[20];
+ unsigned long eltsize;
+ unsigned char *sha1 = buffer + namelen;
+ char *path = strchr(buffer, ' ') + 1;
+ unsigned int mode;
+
+ if (size < namelen + 20 || sscanf(buffer, "%o", &mode) != 1)
+ die("corrupt 'tree' file");
+ buffer = sha1 + 20;
+ size -= namelen + 20;
+
+ if (! (eltbuf = read_sha1_file(sha1, elttype, &eltsize)) ) {
+ error("cannot read %s", sha1_to_hex(sha1));
+ continue;
+ }
+
+ if (write_header(basedir, prefix, path, mode, eltsize))
+ die("archive-tree: could not write header");
+
+ if (S_ISDIR(mode)) {
+ this_prefix.name = path;
+ list_recursive(eltbuf, elttype, eltsize, &this_prefix);
+ } else {
+ if (loopy_write(eltbuf, eltsize))
+ die("archive-tree: could not write body");
+ }
+
+ free(eltbuf);
+ }
+}
+
+static int list(unsigned char *sha1)
+{
+ void *buffer;
+ unsigned long size;
+
+ buffer = read_tree_with_tree_or_commit_sha1(sha1, &size, 0);
+ if (!buffer)
+ die("unable to read sha1 file");
+ if (basedir)
+ write_header(NULL, NULL, basedir, 040755, 0); /*FIXME*/
+ list_recursive(buffer, "tree", size, NULL);
+ free(buffer);
+ return 0;
+}
+
+static const char *archive_tree_usage = "archive-tree <key> [basedir]";
+
+int main(int argc, char **argv)
+{
+ unsigned char sha1[20];
+
+ while (1 < argc && argv[1][0] == '-') {
+ switch (argv[1][1]) {
+ default:
+ usage(archive_tree_usage);
+ }
+ argc--; argv++;
+ }
+
+ switch (argc) {
+ case 3:
+ basedir = argv[2];
+ /* FALLTHROUGH */
+ case 2:
+ if (get_sha1_hex(argv[1], sha1) < 0)
+ usage(archive_tree_usage);
+ break;
+ default:
+ usage(archive_tree_usage);
+ }
+ sha1_file_directory = getenv(DB_ENVIRONMENT);
+ if (!sha1_file_directory)
+ sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
+ if (list(sha1) < 0)
+ die("list failed");
+ write_trailer();
+ return 0;
+}
^ permalink raw reply
* git-pasky "tutorial"
From: Benjamin Herrenschmidt @ 2005-04-24 1:35 UTC (permalink / raw)
To: git
Hi !
Is it really only my own stupidity, or is the "tutorial" in the README
file in there only understandable if you in fact already know what it
tries to explain ?
The more I read it, the more confused I am about the whole thing...
Is there some document somewhere that starts by explaining what are the
concepts of "branch", "tracking", etc... in the context of git ?
Ben.
^ permalink raw reply
* Old "sparse" archive converted..
From: Linus Torvalds @ 2005-04-24 1:25 UTC (permalink / raw)
To: sparse mailing list, Git Mailing List
Ok, I expanded on "convert-cache" quite a bit, to the point where it could
actually re-write "commit" and "tree" objects entirely, at which point it
now became possible to convert the broken old sparse archive that had the
wrong date format in its commit objects, and had the old flat-file format
for the "tree" objects.
I updated the tree at
kernel.org:/pub/linux/kernel/people/torvalds/sparse.git
to be this modern-format tree that fsck-cache no longer complains about.
If anybody is keeping an old-format tree around, I'll just warn you that
I'm not going to necessarily guarantee that git will be able to read it in
the future, so you should replace it with the modern one (which should
just be a matter of either deleting the old one and getting a new copy, or
you could do a
convert-cache $(cat .git/HEAD)
echo ..result.. > .git/HEAD
git-prune-script
read-tree $(cat .git/HEAD)
update-cache --refresh
fsck-cache --unreachable $(cat .git/HEAD)
which _should_ get you a clean tree with a top commit with the name
f765413f020fd2c97c22716320dc96b33cda7c43 if everything went right.
I'm considering turning on SHA1 validation by default when reading
objects, just because it's the right thing to do from a "find any fs
corruption early" angle, and it should be fairly cheap. That will make old
pre-conversion trees no longer work.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Martin Schlemmer @ 2005-04-24 1:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050424005923.GA8859@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
On Sun, 2005-04-24 at 02:59 +0200, Petr Baudis wrote:
> Hello,
>
> this is the last release of git-pasky, my SCMish layer over Linus' git
> tree history storage tool. The next releases will be called 'cogito' and
> will feature a significantly reworked user interface (finally). Get
> git-pasky-0.7 at
>
Over here gitmerge-file.sh is looking for a 'merge' command not present.
Cheers,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* A very basic tutorial
From: James Purser @ 2005-04-24 1:19 UTC (permalink / raw)
To: GIT Mailing List
I've done a very basic tutorial for using git. If someone who knows more
about git (pretty much everyone on this list I think) could have a look
and point out any glaring errors that would be great.
http://ksit.dynalias.com/articles.php?s_id=46&art_id=39
Thanks
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: Hash collision count
From: Ray Heasman @ 2005-04-24 1:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <426AD835.5070404@pobox.com>
On Sat, 2005-04-23 at 19:20 -0400, Jeff Garzik wrote:
> Ray Heasman wrote:
> > On Sat, 2005-04-23 at 16:27 -0400, Jeff Garzik wrote:
> >
> >>Ideally a hash + collision-count pair would make the best key, rather
> >>than just hash alone.
> >>
> >>A collision -will- occur eventually, and it is trivial to avoid this
> >>problem:
> >>
> >> $n = 0
> >> attempt to store as $hash-$n
> >> if $hash-$n exists (unlikely)
> >> $n++
> >> goto restart
> >> key = $hash-$n
> >>
> >
> >
> > Great. So what have you done here? Suppose you have 32 bits of counter
> > for n. Whoopee, you just added 32 bits to your hash, using a two stage
> > algorithm. So, you have a 192 bit hash assuming you started with the 160
> > bit SHA. And, one day your 32 bit counter won't be enough. Then what?
>
> First, there is no 32-bit limit. git stores keys (aka hashes) as
> strings. As it should.
Oh great, now we have variable length id strings too. And we'll have to
pretend the OS can store infinite length file names.
> Second, in your scenario, it's highly unlikely you would get 4 billion
> sha1 hash collisions, even if you had the disk space to store such a git
> database.
Er. So your so-unlikely-the-sun-will-burn-out-first scenario beats my
so-unlikely-the-sun-will-burn-out-first scenario? Why am I not worried?
> > You aren't solving anything. You're just putting it off, and doing it in
> > a way that breaks all the wonderful semantics possible by just assuming
> > that the hash is unique. All of a sudden we are doing checks of data
> > that we never did before, and we have to do the check trillions of times
> > before the CPU time spent pays off.
>
> First, the hash is NOT unique.
Nooooo. Really?
Why not just use a 8192 bit hash for each 1KiB of data? We could store a
zero length file and store all the data in the filename. Guaranteed, no
hash collisions that way.
We make an assumption that we know is right most of the time, and we use
it because we know our computer will crash from random quantum
fluctuations before we have a chance of bumping into the problem. You do
know that metastability means that every logic gate in your computer
hardware is guaranteed to fail every "x" operations, where x is defined
by process size, voltage and temperature? Sure, any failures in git
would be data dependent rather than random, but that just means we don't
get to store carefully crafted blocks invented by hypothetical
cryptographers that have completely broken SHA.
> Second, you lose data if you pretend it is unique. I don't like losing
> data.
You lose data either way. Just we get to burn out a few extra suns
before yours dies, and I can burn out whole galaxies before mine dies by
using a 256 bit hash, anyway.
> Third, a data check only occurs in the highly unlikely case that a hash
> already exists -- a collision. Rather than "trillions of times", more
> like "one in a trillion chance."
Heh. I calculate it has a 50% probability of happening after you have
seen 10^24 input blocks. So, you are off by a factor of a trillion or
so.
Assuming we store 1 KiB blocks with a 160-bit hash, we would be able to
store 1000 Trillion Terabytes before the chance of hitting a collision
goes to 50%. To use marketing units, that is around 10 Trillion
Libraries of Congress. Every 2 bits we add to the hash doubles the
amount of data we can store before we hit a 50% probability of
collision.
I'm not sure how I could convince you that we're arguing about the
number of angels that could dance on a pin.
Ciao,
Ray
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox