* [PATCH 5/5] git-tar-tree: add symlink support
From: Rene Scharfe @ 2005-05-06 20:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Add symlink support to git-tar-tree.
---
commit 7cc9bcd638b69e7cb7fed5b9aa8887e71f88c6c7
tree 8326e0ed584a22abfe510f7cf71a5a569157920d
parent 2da87ce547b59294d4d1cf527009395fbec7bf91
author Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115312885 +0200
committer Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115312885 +0200
Index: tar-tree.c
===================================================================
--- 9eedd772d20dd5a66735f49efe80e17ced40f258/tar-tree.c (mode:100644 sha1:e99adc7dd781cf46efbed82221bf62975a4a3996)
+++ 8326e0ed584a22abfe510f7cf71a5a569157920d/tar-tree.c (mode:100644 sha1:a09cb416595094e493a52dd7f45d943c81c0310a)
@@ -6,10 +6,14 @@
#define TYPEFLAG_AUTO '\0'
#define TYPEFLAG_REG '0'
+#define TYPEFLAG_LNK '2'
#define TYPEFLAG_DIR '5'
#define TYPEFLAG_GLOBAL_HEADER 'g'
#define TYPEFLAG_EXT_HEADER 'x'
+#define EXT_HEADER_PATH 1
+#define EXT_HEADER_LINKPATH 2
+
static const char *tar_tree_usage = "tar-tree <key> [basedir]";
static char block[BLOCKSIZE];
@@ -209,9 +213,13 @@
void *content, unsigned int contentsize)
{
char *p;
- unsigned int pathlen, size;
+ unsigned int pathlen, size, linkpathlen = 0;
size = pathlen = extended_header_len("path", namelen);
+ if (flags & EXT_HEADER_LINKPATH) {
+ linkpathlen = extended_header_len("linkpath", contentsize);
+ size += linkpathlen;
+ }
if (size > RECORDSIZE)
die("tar-tree: extended header too big, wtf?");
write_header(NULL, TYPEFLAG_EXT_HEADER, NULL, NULL, headerfilename,
@@ -221,6 +229,8 @@
append_extended_header_prefix(&p, pathlen, "path");
append_path(&p, is_dir, basepath, prefix, path);
append_char(&p, '\n');
+ if (flags & EXT_HEADER_LINKPATH)
+ append_extended_header(&p, "linkpath", content, contentsize);
write_if_needed();
}
@@ -244,38 +254,60 @@
unsigned int mode, void *buffer, unsigned long size)
{
unsigned int namelen;
- char *p, *header = NULL;
+ char *header = NULL;
unsigned int checksum = 0;
int i;
+ unsigned int ext_header = 0;
if (typeflag == TYPEFLAG_AUTO) {
if (S_ISDIR(mode))
typeflag = TYPEFLAG_DIR;
+ else if (S_ISLNK(mode))
+ typeflag = TYPEFLAG_LNK;
else
typeflag = TYPEFLAG_REG;
}
namelen = path_len(S_ISDIR(mode), basepath, prefix, path);
- if (namelen > 500) {
+ if (namelen > 500)
die("tar-tree: name too log of object %s\n", sha1_to_hex(sha1));
- } else if (namelen > 100) {
- char *sha1_hex = sha1_to_hex(sha1);
+ else if (namelen > 100)
+ ext_header |= EXT_HEADER_PATH;
+ if (typeflag == TYPEFLAG_LNK && size > 100)
+ ext_header |= EXT_HEADER_LINKPATH;
+
+ /* the extended header must be written before the normal one */
+ if (ext_header) {
char headerfilename[51];
- sprintf(headerfilename, "%s.paxheader", sha1_hex);
- /* the extended header must be written before the normal one */
+ sprintf(headerfilename, "%s.paxheader", sha1_to_hex(sha1));
write_extended_header(headerfilename, S_ISDIR(mode),
- 0, basepath, prefix, path,
+ ext_header, basepath, prefix, path,
namelen, buffer, size);
+ }
- header = get_record();
- sprintf(header, "%s.data", sha1_hex);
+ header = get_record();
+
+ if (ext_header) {
+ sprintf(header, "%s.data", sha1_to_hex(sha1));
} else {
- p = header = get_record();
+ char *p = header;
append_path(&p, S_ISDIR(mode), basepath, prefix, path);
}
+ if (typeflag == TYPEFLAG_LNK) {
+ if (ext_header & EXT_HEADER_LINKPATH) {
+ sprintf(&header[157], "see %s.paxheader",
+ sha1_to_hex(sha1));
+ } else {
+ if (buffer)
+ strncpy(&header[157], buffer, size);
+ }
+ }
+
if (S_ISDIR(mode))
mode |= 0755; /* GIT doesn't store permissions of dirs */
+ if (S_ISLNK(mode))
+ mode |= 0777; /* ... nor of symlinks */
sprintf(&header[100], "%07o", mode & 07777);
/* XXX: should we provide more meaningful info here? */
@@ -284,7 +316,9 @@
strncpy(&header[265], "git", 31); /* uname */
strncpy(&header[297], "git", 31); /* gname */
- sprintf(&header[124], "%011lo", S_ISDIR(mode) ? 0 : size);
+ if (S_ISDIR(mode) || S_ISLNK(mode))
+ size = 0;
+ sprintf(&header[124], "%011lo", size);
sprintf(&header[136], "%011lo", archive_time);
header[156] = typeflag;
@@ -331,7 +365,7 @@
if (!strcmp(elttype, "tree")) {
this_prefix.name = path;
traverse_tree(eltbuf, eltsize, &this_prefix);
- } else if (!strcmp(elttype, "blob")) {
+ } else if (!strcmp(elttype, "blob") && !S_ISLNK(mode)) {
write_blocked(eltbuf, eltsize);
}
free(eltbuf);
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
* Stronger Hashes
From: uwesmail2005-git @ 2005-05-06 21:05 UTC (permalink / raw)
To: git
Cryptographic hashes are never strong enough, it seems. There are two
threats against which they have to be defended.
Defense against incidental collisions:
Can only be made by making the hash longer. Easy way to make the hash
6-times as long: pad to multiple of 6 bits (can be skipped if hash
algorithm is implemented with bit-granularity)
,create normal hash (from all bits),create hash from all even numbered
bits
,create hash from all odd numbered bits, create hash from all bits with
fully triple bit number, create hash from all bits that follow them and
last create a hash from all bit that precede a fully triple numbered
bit. Concatenate (or interleave) these 6 hashes and you're set.
The same is possible with 28. And all perfect numbers.
Defense against intentional collisions:
The mechanism by which a collision is computed uses the property of the
cryptographic hash to update an IV. If a collision was created, and
the next bytes are the same, these files will collide too. Such
computation is dependent on the concrete IV the hash starts with.
If that IV is not predictable anymore, these algorithms will break.
So the easiest way to break them is to hash 'cat file file'. More
secure
will be 'gzip -c<file|cat - file' because the starting offset of file
will probably be not aligned to the hash blocks. With
'$(hashprog)<file|cat - file' you can strike through "probably" and
replace "definitly".
Both methods can be combined.
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
^ permalink raw reply
* Re: [PATCH] Tweak git-diff-tree -v output further (take 2).
From: Linus Torvalds @ 2005-05-06 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr7ocfj7.fsf@assigned-by-dhcp.cox.net>
On Fri, 6 May 2005, Junio C Hamano wrote:
>
> The first hunk of this is a pure bugfix---it guards us against a
> commit message that does not end with a newline.
Why do you think it helps anything at all?
We have a _length_ of buffer. We don't have any zero-termination.
Linus
^ permalink raw reply
* Re: [PATCH] Tweak git-diff-tree -v output further (take 2).
From: H. Peter Anvin @ 2005-05-06 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vbr7ocfj7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> (This one is simpler than the previous one I just sent out)
>
> The first hunk of this is a pure bugfix---it guards us against a
> commit message that does not end with a newline.
No it doesn't. What it does is "guard" you against a commit message
which contains a null character. What's not entirely clear is if that's
what you wanted to do.
-hpa
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: H. Peter Anvin @ 2005-05-06 21:50 UTC (permalink / raw)
To: David Woodhouse, Marcelo Tosatti; +Cc: Git Mailing List
In-Reply-To: <1115364543.29495.24.camel@localhost.localdomain>
David Woodhouse wrote:
> On Thu, 2005-05-05 at 17:28 -0700, H. Peter Anvin wrote:
>
>>Could you add that to 2.4 as well, too?
>
> Is there a 2.4 git tree?
>
I thought so, but now I can't find it. Marcelo?
-hpa
^ permalink raw reply
* Re: [PATCH] Tweak git-diff-tree -v output further.
From: Linus Torvalds @ 2005-05-06 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5s4cfzq.fsf@assigned-by-dhcp.cox.net>
On Fri, 6 May 2005, Junio C Hamano wrote:
>
> This adds the full header information to git-diff-tree -v output
> in addition to the log message it already produces.
I don't actually like the git internal commit format, it's not very
readable. It's designed to be nicely readable by machines, not humans.
If you want machine-readable output, you shouldn't use "-v" (or probably
-p either) anyway, you'd be better off with the raw file changes.
> Maybe we want to stop indenting so that it matches what
> git-export produces better.
Again, it's indented so that it's human-readable, and I was planning on
adding _some_ human-readable output from the headers (author and a
human-readable date or something).
Linus
^ permalink raw reply
* Re: [PATCH] Tweak git-diff-tree -v output further (take 2).
From: Junio C Hamano @ 2005-05-06 22:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505061440180.2233@ppc970.osdl.org>
You are absolutely right.
^ permalink raw reply
* Re: How do I...
From: Linus Torvalds @ 2005-05-06 22:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, Frank Sorenson, git
In-Reply-To: <1115406628.16187.353.camel@hades.cambridge.redhat.com>
On Fri, 6 May 2005, David Woodhouse wrote:
>
> When I said 'show' I meant merely provide sufficient information.
To do that, you'd just have to always show the commit/parent pairs,
regardless of whether it had a difference or not. That's actually what the
first version did, but it was so ugly that I ended up changing it to only
showing pairs that had differences.
It would be easy to add a "--all" flag or something, that shows all
commit/parent information, and then you would use that, but the thing is,
you're likely better off just using git-rev-tree to build the graph in the
first place.
So it's doable, and it has nothing to do with git-diff-tree. So normally
you'd do something like "show me all differences between v2.6.12-rc2 and
now, and then you _do_ end up using git-rev-tree first to make a list of
commits, and then you feed that list of commits into git-diff-tree - and
notice that when you did the rev-tree in the first place, you actually did
build up the history tree to get there, so if you want to visualize it,
you should now use _that_ tree that you already built.
diff-tree never has any commit history tree information available to it.
It just doesn't know, care, or bother.
Linus
^ permalink raw reply
* I'm off for a week..
From: Linus Torvalds @ 2005-05-06 23:05 UTC (permalink / raw)
To: Git Mailing List; +Cc: Petr Baudis, Junio C Hamano
This is just a quick note to let people know that I'm taking a week off
for vacation, and thus what I have right now in my git tree is pretty much
what you'll see for the next week. I won't even have a computer with me,
much less do any development.
Anyway, especially with the new diff-tree, it all pretty much does what I
want, and I don't have any huge wish-list entries left. Now it's more
about getting people used to it, and making all the scripts nice and
friendly, as far as I'm concerned. Maybe in a week, you guys will have
made CVS go away. I hope so.
It's pretty exactly a month since I started, and I really think you guys
can do a better job by now.
Linus
^ permalink raw reply
* the blob metanet (welcome to the future)
From: Tom Lord @ 2005-05-06 23:20 UTC (permalink / raw)
To: gnu-arch-dev; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505061558400.2233@ppc970.osdl.org>
Check it out...
http://www.seyza.com/=clients/linus/tree/src/libdx/blob-xmt.html
This is handy background:
http://www.seyza.com/=clients/linus/tree/src/liblob/index.html
and neither of those documents are works of art yet -- just something
I should not be sitting on.
-t
^ permalink raw reply
* Re: How do I...
From: David Woodhouse @ 2005-05-06 23:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Frank Sorenson, git
In-Reply-To: <Pine.LNX.4.58.0505061552140.2233@ppc970.osdl.org>
On Fri, 2005-05-06 at 15:57 -0700, Linus Torvalds wrote:
> To do that, you'd just have to always show the commit/parent pairs,
> regardless of whether it had a difference or not.
Nah, you just prune the commits from which aren't interesting, then dump
the graph you're left with. So instead of printing just the immediate
parent(s) for each interesting commit, you print the "nearest
interesting ancestor(s)".
Take copy of rev-tree, let it mark commits as interesting if they touch
the file(s) in question, then effectively perform a list_del() on any
commit which _isn't_ interesting, and any merge which merges only
uninteresting commits... then dump the resulting pruned graph.
--
dwmw2
^ permalink raw reply
* Re: the blob metanet (welcome to the future)
From: Petr Baudis @ 2005-05-06 23:22 UTC (permalink / raw)
To: Tom Lord; +Cc: gnu-arch-dev, git
In-Reply-To: <200505062320.QAA00974@emf.net>
Dear diary, on Sat, May 07, 2005 at 01:20:46AM CEST, I got a letter
where Tom Lord <lord@emf.net> told me that...
> Check it out...
>
> http://www.seyza.com/=clients/linus/tree/src/libdx/blob-xmt.html
>
> This is handy background:
>
> http://www.seyza.com/=clients/linus/tree/src/liblob/index.html
>
> and neither of those documents are works of art yet -- just something
> I should not be sitting on.
Do you think you could make the pages not have all the content enclosed
within an HTML comment, please?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: the blob metanet (welcome to the future)
From: Tom Lord @ 2005-05-06 23:27 UTC (permalink / raw)
To: pasky; +Cc: gnu-arch-dev, git
In-Reply-To: <20050506232254.GI32629@pasky.ji.cz>
GAH!
From: Petr Baudis <pasky@ucw.cz>
Do you think you could make the pages not have all the content enclosed
within an HTML comment, please?
Yes, i'll fix that. Meanwhile, please just s/.html/.txt in the URL
and you can read things just fine.
-t
^ permalink raw reply
* [PATCH] Do not initialize sha1_file_directory by hand.
From: Junio C Hamano @ 2005-05-06 23:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Some commands initialize sha1_file_directory by hand. There is no
need to do so; sha1_file.c knows how to handle it.
The next patch will remove the variable altogether.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
ls-tree.c | 3 ---
read-cache.c | 5 -----
tar-tree.c | 5 -----
3 files changed, 13 deletions(-)
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -104,9 +104,6 @@ int main(int argc, char **argv)
usage(ls_tree_usage);
if (get_sha1(argv[1], sha1) < 0)
usage(ls_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");
return 0;
--- a/read-cache.c
+++ b/read-cache.c
@@ -193,11 +193,6 @@ int read_cache(void)
if (active_cache)
return error("more than one cachefile");
errno = ENOENT;
- sha1_file_directory = getenv(DB_ENVIRONMENT);
- if (!sha1_file_directory)
- sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
- if (access(sha1_file_directory, X_OK) < 0)
- return error("no access to SHA1 file directory");
fd = open(get_index_file(), O_RDONLY);
if (fd < 0)
return (errno == ENOENT) ? 0 : error("open failed");
--- a/tar-tree.c
+++ b/tar-tree.c
@@ -418,10 +418,6 @@ int main(int argc, char **argv)
usage(tar_tree_usage);
}
- sha1_file_directory = getenv(DB_ENVIRONMENT);
- if (!sha1_file_directory)
- sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
-
buffer = read_object_with_reference(sha1, "commit", &size, commit_sha1);
if (buffer) {
write_global_extended_header(commit_sha1);
----------------------------------------------------------------
^ permalink raw reply
* [PATCH] Remove unused sha1_file_directory variable.
From: Junio C Hamano @ 2005-05-06 23:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Now all the users have gone.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cache.h | 1 -
sha1_file.c | 3 ---
2 files changed, 4 deletions(-)
--- a/cache.h
+++ b/cache.h
@@ -96,7 +96,6 @@ static inline unsigned int create_ce_mod
#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;
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -9,8 +9,6 @@
#include <stdarg.h>
#include "cache.h"
-const char *sha1_file_directory = NULL;
-
#ifndef O_NOATIME
#if defined(__linux__) && (defined(__i386__) || defined(__PPC__))
#define O_NOATIME 01000000
----------------------------------------------------------------
^ permalink raw reply
* [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Junio C Hamano @ 2005-05-06 23:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
A new environment variable, SHA1_FILE_DIRECTORIES, is
introduced. This affects the routines that read existing
objects from the object database, but not creation of new
objects.
The environment variable, when exists, is a colon separated list of
directories. If an object is not found in the usual location
SHA1_FILE_DIRECTORY (or .git/objects), this list is consulted and if
object is found there it is returned.
This is an implementation of the idea floated on the GIT list a couple
of days ago to archive really old history on a separate directory, even
on a read-only DVD ROM media.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cache.h | 5 +-
sha1_file.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 112 insertions(+), 6 deletions(-)
--- a/cache.h
+++ b/cache.h
@@ -101,8 +101,7 @@ unsigned int active_nr, active_alloc;
#define DB_ENVIRONMENT "SHA1_FILE_DIRECTORY"
#define DEFAULT_DB_ENVIRONMENT ".git/objects"
-
-#define get_object_directory() (getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
+#define ALTERNATE_DB_ENVIRONMENT "SHA1_FILE_DIRECTORIES"
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
#define DEFAULT_INDEX_ENVIRONMENT ".git/index"
@@ -130,7 +129,7 @@ extern int index_fd(unsigned char *sha1,
#define DATA_CHANGED 0x0020
#define TYPE_CHANGED 0x0040
-/* Return a statically allocated filename matching the sha1 signature */
+/* Return a statically allocated filename matching the sha1 signature. */
extern char *sha1_file_name(const unsigned char *sha1);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -100,10 +100,19 @@ char * sha1_to_hex(const unsigned char *
return buffer;
}
+static const char *get_object_directory(void)
+{
+ return getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
+}
+
/*
* NOTE! This returns a statically allocated buffer, so you have to be
* careful about using it. Do a "strdup()" if you need to save the
* filename.
+ *
+ * Also note that this returns the location for creating. Reading
+ * SHA1 file can happen from any alternate directory listed in the
+ * SHA1_FILE_DIRECTORIES environment variable.
*/
char *sha1_file_name(const unsigned char *sha1)
{
@@ -130,6 +139,99 @@ char *sha1_file_name(const unsigned char
return base;
}
+static char *find_sha1_file(const unsigned char *sha1)
+{
+ struct stat st;
+ char *name = sha1_file_name(sha1);
+ static struct {
+ int pfxlen;
+ char *buf;
+ } *alternates = NULL;
+ static int num_alt = -1;
+ int i;
+
+ if (num_alt < 0) {
+ int cnt;
+ int totlen;
+ const char *cp, *last;
+ const char *alt = getenv(ALTERNATE_DB_ENVIRONMENT);
+ void *buf;
+ char *op;
+
+ if (!alt || !alt[0]) {
+ num_alt = 0;
+ return name;
+ }
+
+ for (last = cp = alt, totlen = cnt = 0; *cp; cp++) {
+ /* We could strip the empty path which would result
+ * in /xx/xxxxx from the filesystem root level,
+ * but who cares. We are only constructing list of
+ * paths to attempt to read not write.
+ */
+ if (*cp == ':') {
+ /* 40 bytes plus two / and terminating NUL */
+ totlen += cp - last + 43;
+ cnt++;
+ last = cp + 1;
+ }
+ }
+ if (cp != last) {
+ totlen += cp - last + 43;
+ cnt++;
+ }
+
+ if (!cnt) {
+ num_alt = 0;
+ return name;
+ }
+ num_alt = cnt;
+
+ buf = xmalloc(sizeof(*alternates) * (cnt + 1) + totlen);
+ alternates = buf;
+ alternates[num_alt].pfxlen = 0;
+ alternates[num_alt].buf = NULL;
+ op = (char*) (&alternates[cnt+1]);
+ for (last = cp = alt, i = 0; i < num_alt; cp++) {
+ if (*cp == ':' || *cp == 0) {
+ alternates[i].buf = op;
+ alternates[i].pfxlen = cp - last;
+ memcpy(op, last, cp - last);
+ op[cp - last] = 0;
+ op += (cp - last + 1);
+ last = cp + 1;
+ i++;
+ }
+ }
+ if (cp != last) {
+ alternates[i].buf = op;
+ alternates[i].pfxlen = last - cp;
+ memcpy(op, last, last - cp);
+ op[last-cp] = 0;
+ }
+ }
+ if (!stat(name, &st))
+ return name;
+ for (i = 0; i < num_alt; i++) {
+ char *alt = alternates[i].buf;
+ int len = alternates[i].pfxlen;
+ char *name = alt + len;
+ alt[len] = '/';
+ alt[len+3] = '/';
+ name = alt + len + 1;
+ for (i = 0; i < 20; i++) {
+ static char hex[] = "0123456789abcdef";
+ unsigned int val = sha1[i];
+ char *pos = name + i*2 + (i > 0);
+ *pos++ = hex[val >> 4];
+ *pos = hex[val & 0xf];
+ }
+ if (!stat(alt, &st))
+ return alt;
+ }
+ return NULL;
+}
+
int check_sha1_signature(unsigned char *sha1, void *map, unsigned long size, const char *type)
{
char header[100];
@@ -145,10 +247,14 @@ int check_sha1_signature(unsigned char *
void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
{
- char *filename = sha1_file_name(sha1);
struct stat st;
void *map;
int fd;
+ char *filename = find_sha1_file(sha1);
+ if (!filename) {
+ error("cannot map sha1 file %s", sha1_to_hex(sha1));
+ return NULL;
+ }
fd = open(filename, O_RDONLY | sha1_file_open_flag);
if (fd < 0) {
@@ -442,8 +548,10 @@ int write_sha1_from_fd(const unsigned ch
int has_sha1_file(const unsigned char *sha1)
{
- char *filename = sha1_file_name(sha1);
struct stat st;
+ char *filename = find_sha1_file(sha1);
+ if (!filename)
+ return 0;
if (!stat(filename, &st))
return 1;
----------------------------------------------------------------
^ permalink raw reply
* Re: How do I...
From: Linus Torvalds @ 2005-05-06 23:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, Frank Sorenson, git
In-Reply-To: <1115421642.29495.53.camel@localhost.localdomain>
On Sat, 7 May 2005, David Woodhouse wrote:
>
> Nah, you just prune the commits from which aren't interesting, then dump
> the graph you're left with. So instead of printing just the immediate
> parent(s) for each interesting commit, you print the "nearest
> interesting ancestor(s)".
Nope. That's just stupid.
Use the whole commit history, and if you want to simplify it from there
once you notice that some branches end up never being interesting, then
that's ok.
But trying to be clever while building this up is just crazy talk. When
diff-tree prints out the changes, it has no way of knowing what the
context around it was - it doesn't know about merges far away, and it
_shouldn't_ know.
Linus
^ permalink raw reply
* Re: Version of dirdiff to display diffs between git trees
From: Paul Mackerras @ 2005-05-07 0:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505060916320.2233@ppc970.osdl.org>
Linus Torvalds writes:
> If you use git-pull-script, it does this for you (except it calls it
OK, cool
> ORIG_HEAD), and you can just do
>
> git-diff-tree -p ORIG_HEAD HEAD
>
> to see the changes. In fact git-pull-script will do that for you, and
> output the diffstat of it.
Yes, girdiff with two trees is mostly equivalent to git-diff-tree,
except that I find the girdiff/dirdiff display much easier to nagivate
and parse than a patch viewed in an xterm with less. (I say "mostly
equivalent" because if neither tree is the ancestor of the other,
girdiff looks at the common ancestor to get an idea of which tree has
the more recent version of each file that differs, and colors that one
green and the other red, which is extra information that git-diff-tree
doesn't give you.)
Similarly, girdiff with a tree and "." is equivalent to
git-diff-cache.
Girdiff also has the new dirdiff features of being able to expand the
displayed context for a hunk, to move changed lines up and down within
a hunk (provided the movement doesn't change the meaning of the diff),
and to split context lines into identical -/+ lines (which, together
with being able to move -/+ lines makes it possible to rearrange a
diff to make it more understandable).
If the working directory is one of the trees being diffed, you can
select parts of the diff for a file to be applied to the working
directory file. (You can't apply changes to a git tree, of course,
because it's immutable.) You can also select parts of the diff for a
file and generate a patch embodying just the selected changes.
Next I want to do a commit viewer with the ability to display the
differences between arbitrary points in the commit tree using girdiff.
Paul.
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Sean @ 2005-05-07 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmzr8apxc.fsf@assigned-by-dhcp.cox.net>
On Fri, May 6, 2005 7:35 pm, Junio C Hamano said:
Hi Junio,
> This is an implementation of the idea floated on the GIT list a couple
> of days ago to archive really old history on a separate directory, even
> on a read-only DVD ROM media.
David Lang should get the credit for the idea.
> int has_sha1_file(const unsigned char *sha1)
> {
> - char *filename = sha1_file_name(sha1);
> struct stat st;
> + char *filename = find_sha1_file(sha1);
> + if (!filename)
> + return 0;
>
> if (!stat(filename, &st))
> return 1;
has_sha1_file can be reduced to:
int has_sha1_file(const unsigned char *sha1)
{
return (!!find_sha1_file(sha1));
}
Sean
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Junio C Hamano @ 2005-05-07 0:24 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <2637.10.10.10.24.1115425225.squirrel@linux1>
>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
S> has_sha1_file can be reduced to:
S> int has_sha1_file(const unsigned char *sha1)
S> {
S> return (!!find_sha1_file(sha1));
S> }
Not really. If you do not have alternates it does not even
bother to stat so you get the path that supposed to contain the
data and you need to do the checking yourself.
^ permalink raw reply
* [PATCH] git-tar-tree: Lift path length limit
From: Rene Scharfe @ 2005-05-07 0:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Petr Baudis
Last minute patch? This lifts the limits from path length and link
path length that are in git-tar-tree.
Have a nice vacation!
Rene
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
commit 2d7b8f2afc47c753aaab4bf48587fdea730b0db3
tree 378fae86e43460c1c53feccbde3573ced26818f6
parent a02ebff6127c5fc981668fb570f0a80f2b7657ca
author Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115320521 +0200
committer Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115320521 +0200
Index: tar-tree.c
===================================================================
--- 8477488c1965186c98b59ad0da04d221aff3c9a1/tar-tree.c (mode:100644 sha1:a09cb416595094e493a52dd7f45d943c81c0310a)
+++ 378fae86e43460c1c53feccbde3573ced26818f6/tar-tree.c (mode:100644 sha1:0fb6514c27a0f0edc2fc6e9850c361c8a58c0a9f)
@@ -212,7 +212,7 @@
const char *path, unsigned int namelen,
void *content, unsigned int contentsize)
{
- char *p;
+ char *buffer, *p;
unsigned int pathlen, size, linkpathlen = 0;
size = pathlen = extended_header_len("path", namelen);
@@ -220,18 +220,18 @@
linkpathlen = extended_header_len("linkpath", contentsize);
size += linkpathlen;
}
- if (size > RECORDSIZE)
- die("tar-tree: extended header too big, wtf?");
write_header(NULL, TYPEFLAG_EXT_HEADER, NULL, NULL, headerfilename,
0100600, NULL, size);
- p = get_record();
+ buffer = p = malloc(size);
+ if (!buffer)
+ die("git-tar-tree: %s", strerror(errno));
append_extended_header_prefix(&p, pathlen, "path");
append_path(&p, is_dir, basepath, prefix, path);
append_char(&p, '\n');
if (flags & EXT_HEADER_LINKPATH)
append_extended_header(&p, "linkpath", content, contentsize);
- write_if_needed();
+ write_blocked(buffer, size);
}
static void write_global_extended_header(const char *sha1)
@@ -269,9 +269,7 @@
}
namelen = path_len(S_ISDIR(mode), basepath, prefix, path);
- if (namelen > 500)
- die("tar-tree: name too log of object %s\n", sha1_to_hex(sha1));
- else if (namelen > 100)
+ if (namelen > 100)
ext_header |= EXT_HEADER_PATH;
if (typeflag == TYPEFLAG_LNK && size > 100)
ext_header |= EXT_HEADER_LINKPATH;
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Sean @ 2005-05-07 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vis1vc27f.fsf@assigned-by-dhcp.cox.net>
On Fri, May 6, 2005 8:24 pm, Junio C Hamano said:
>>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
>
> S> has_sha1_file can be reduced to:
>
> S> int has_sha1_file(const unsigned char *sha1)
> S> {
> S> return (!!find_sha1_file(sha1));
> S> }
>
> Not really. If you do not have alternates it does not even
> bother to stat so you get the path that supposed to contain the
> data and you need to do the checking yourself.
>
>
Perhaps I'm just missing something in your code, but this fragment makes
it look to me that stat is always called in find_sha1_file even when there
are no alternates:
+ char *name = sha1_file_name(sha1);
[...]
+ if (!stat(name, &st))
+ return name;
+ for (i = 0; i < num_alt; i++) {
Sean
^ permalink raw reply
* Re: How do I...
From: Benjamin Herrenschmidt @ 2005-05-07 0:45 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Frank Sorenson, git
In-Reply-To: <1115397368.16187.266.camel@hades.cambridge.redhat.com>
On Fri, 2005-05-06 at 17:36 +0100, David Woodhouse wrote:
> On Fri, 2005-05-06 at 09:13 -0700, Linus Torvalds wrote:
> > There has been at least two different scripts for this posted, and one C
> > source code version.
> >
> > I just haven't integrated them, because I'm an idiot, and too much choice
> > makes me run around in small circles and clucking.
> >
> > Guys - whoever wrote one of the scripts, can you please send out your
> > current version to the git list and cc me, and explain why yours is
> > superior to the other peoples version. Please?
>
> I already explained why mine sucks and shouldn't be merged. It was a
> proof of concept; hoping for the stone soup effect.
>
> I haven't seen a C version or indeed anything which actually does the
> right thing, although I outlined how it would work and _threatened_ to
> do one. I had a half-arsed attempt at it on the way home from
> linux.conf.au but my brain tends to melt while I'm on airplanes so I
> didn't get very far.
Note that paulus current dirdiff CVS can diff arbitrary revs of a git
tree afaik (or a rev against current edited content).
Ben.
^ permalink raw reply
* Re: [PATCH] git-tar-tree: Lift path length limit
From: Rene Scharfe @ 2005-05-07 0:57 UTC (permalink / raw)
To: Linus Torvalds, Petr Baudis; +Cc: git
In-Reply-To: <20050507002527.GA5082@lsrfire.ath.cx>
On Sat, May 07, 2005 at 02:25:27AM +0200, Rene Scharfe wrote:
> Last minute patch?
This leaks memory. D'oh!
Petr, would you add the (hopefully) fixed version below to your tree now
that Linus is on vacation? (Patch applies to tip of GIT tree.)
Thanks,
Rene
Lift path length limits from git-tar-tree.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
commit d36797f64ee0431e6a73aa1c77a7fe7c18b6ce9f
tree ab8e6967a08ac343b69b527f663e6a9722fcea08
parent bf60144c0ab50e88c0086a90c5cb35b81613ad14
author Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115322098 +0200
committer Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115322098 +0200
Index: tar-tree.c
===================================================================
--- 8ef25a2788d6c225641a3040622b82c364f987b8/tar-tree.c (mode:100644 sha1:9d9bd7be98502f64e4a643ef0973182f3483251e)
+++ ab8e6967a08ac343b69b527f663e6a9722fcea08/tar-tree.c (mode:100644 sha1:8b0d75bd2cf12a531aee3d51e59a8ac8102ba6be)
@@ -212,7 +212,7 @@
const char *path, unsigned int namelen,
void *content, unsigned int contentsize)
{
- char *p;
+ char *buffer, *p;
unsigned int pathlen, size, linkpathlen = 0;
size = pathlen = extended_header_len("path", namelen);
@@ -220,18 +220,19 @@
linkpathlen = extended_header_len("linkpath", contentsize);
size += linkpathlen;
}
- if (size > RECORDSIZE)
- die("tar-tree: extended header too big, wtf?");
write_header(NULL, TYPEFLAG_EXT_HEADER, NULL, NULL, headerfilename,
0100600, NULL, size);
- p = get_record();
+ buffer = p = malloc(size);
+ if (!buffer)
+ die("git-tar-tree: %s", strerror(errno));
append_extended_header_prefix(&p, pathlen, "path");
append_path(&p, is_dir, basepath, prefix, path);
append_char(&p, '\n');
if (flags & EXT_HEADER_LINKPATH)
append_extended_header(&p, "linkpath", content, contentsize);
- write_if_needed();
+ write_blocked(buffer, size);
+ free(buffer);
}
static void write_global_extended_header(const char *sha1)
@@ -269,9 +270,7 @@
}
namelen = path_len(S_ISDIR(mode), basepath, prefix, path);
- if (namelen > 500)
- die("tar-tree: name too log of object %s\n", sha1_to_hex(sha1));
- else if (namelen > 100)
+ if (namelen > 100)
ext_header |= EXT_HEADER_PATH;
if (typeflag == TYPEFLAG_LNK && size > 100)
ext_header |= EXT_HEADER_LINKPATH;
^ permalink raw reply
* Re: [patch] add simple git documentation
From: Andrew Morton @ 2005-05-07 0:58 UTC (permalink / raw)
To: Pavel Machek; +Cc: git
In-Reply-To: <20050505102600.GA16387@elf.ucw.cz>
Pavel Machek <pavel@ucw.cz> wrote:
>
> This adds short intro to git aimed at kernel hackers.
>
OK, but I'm hoping that shortly we'll have something more complete than
this, and your patch might not be a suitable starting point for that.
(Large hint-dropping sounds).
>
> ---
> commit addb0833bdadda14495d66749e6cb95b6a9445d7
> tree 7e66cb899004fbec0fadae5c9265d0731d3a26f3
> parent 1f9ca1262e6b27dde44d456a87c456d15f0a9b80
> author <pavel@amd.(none)> 1115288688 +0200
> committer <pavel@amd.(none)> 1115288688 +0200
>
> Index: Documentation/git.txt
> ===================================================================
> --- /dev/null (tree:de65e7579ed050d324357e3040b37c561676ab7d)
> +++ 7e66cb899004fbec0fadae5c9265d0731d3a26f3/Documentation/git.txt (mode:100644 sha1:353d5ae7f46eeb79c058be611cb429622167f784)
> @@ -0,0 +1,41 @@
> + Kernel hacker's guide to git
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + 2005 Pavel Machek <pavel@suse.cz>
> +
> +You can get cogito at http://www.kernel.org/pub/software/scm/cogito/
> +. Compile it, and place it somewhere in $PATH. Then you can get kernel
> +by running
> +
> +mkdir clean-cg; cd clean-cg
> +cg-init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> +
> +... Do cg-update origin to pickup latest changes from Linus. You can
> +do cg-diff to see what changes you done in your local tree. cg-cancel
> +will kill any such changes, and cg-commit will make them permanent.
> +
> +To get diff between your working tree and "next tree up", do cg-diff
> +-r origin: . If you want to get the same diff but separated
> +patch-by-patch, do cg-mkpatch origin: . If you want to pull changes
> +from the "up" tree to your working tree, do cg-update origin.
> +
> +
> +How to set up your trees so that you can cooperate with Linus
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +What I did:
> +
> +Created clean-cg. Initialized straight from Linus (as above). Then I
> +created "nice" tree, good for Linus to pull from
> +
> +mkdir /data/l/linux-good; cd /data/l/linux-good
> +cg-init /data/l/clean-cg
> +
> +and then my working tree, based on linux-good
> +
> +mkdir /data/l/linux-cg; cd /data/l/linux-cg
> +cg-init /data/l/linux-good
> +
> +. I do my work in linux-cg. If someone sends me nice patch I should
> +pass up, I apply it to linux-good with nice message and do
> +
> +cd /data/l/linux-cg; cg-update origin
>
> --
> Boycott Kodak -- for their patent abuse against Java.
^ 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