* Re: [PATCH] Missing linefeeds
From: Petr Baudis @ 2005-04-21 16:26 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20050421124430.ACDC77F894@smurf.noris.de>
Dear diary, on Thu, Apr 21, 2005 at 02:44:30PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> This patch fixes die() and error() to print linefeeds after the message.
Why? report() already prints linefeed.
--
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: [PATCH] Improve usage messages
From: Petr Baudis @ 2005-04-21 16:25 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20050421124152.A28137F87D@smurf.noris.de>
Dear diary, on Thu, Apr 21, 2005 at 02:41:52PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> 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 <smurf@smurf.noris.de>
>
> 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\t<tree 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
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Chris Mason @ 2005-04-21 16:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504210832490.2344@ppc970.osdl.org>
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
^ permalink raw reply
* Pasky problem with 'git init URL'
From: Martin Schlemmer @ 2005-04-21 16:21 UTC (permalink / raw)
To: GIT Mailing Lists
[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow "git cancel" to change branches
From: Petr Baudis @ 2005-04-21 16:05 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <E1DObsr-0006Au-MA@server.smurf.noris.de>
Dear diary, on Thu, Apr 21, 2005 at 03:31:24PM CEST, I got a letter
where Matthias Urlichs <smurf@smurf.noris.de> told me that...
> "git cancel" may not be named correctly for this job, but it does almost
> everything you'd need for switching between one branch and another
> within a repository, so...
NO. That is something completely different, although technically it can
look similar.
--
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: Errors received during git pull from linux-2.6.git, but resulting kernel looks OK.
From: Petr Baudis @ 2005-04-21 16:04 UTC (permalink / raw)
To: Steven Cole; +Cc: git mailing list
In-Reply-To: <4267B0CE.7020504@mesatop.com>
Dear diary, on Thu, Apr 21, 2005 at 03:55:26PM CEST, I got a letter
where Steven Cole <elenstev@mesatop.com> 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
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Linus Torvalds @ 2005-04-21 15:41 UTC (permalink / raw)
To: Chris Mason; +Cc: git
In-Reply-To: <200504211113.13630.mason@suse.com>
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
^ permalink raw reply
* [PATCH] multi item packed files
From: Chris Mason @ 2005-04-21 15:13 UTC (permalink / raw)
To: git, torvalds
[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]
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
[-- Attachment #2: comp-tree.diff --]
[-- Type: text/x-diff, Size: 9944 bytes --]
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;
+ while(p < buf + *size) {
+ unsigned long item_len;
+ unsigned char sha1_hex[50];
+ unsigned char item_sha[20];
+ sscanf(p, "%50s %lu", sha1_hex, &item_len);
+ if (get_sha1_hex(sha1_hex, item_sha))
+ die("packed file corruption");
+ if (memcmp(item_sha, sha1, 20) == 0) {
+ char *temp;
+ char *r;
+ temp = p + strlen(p) + 1;
+ if (sscanf(temp, "%10s %lu", type, size) != 2)
+ return NULL;
+ r = malloc(*size);
+ if (!r)
+ return NULL;
+ memcpy(r, temp + strlen(temp) + 1, *size);
+ free(buf);
+ return r;
+ }
+ p += strlen(p) + 1 + item_len;
+ }
+ return NULL;
+ }
return buf;
}
@@ -159,7 +190,7 @@
map = map_sha1_file(sha1, &mapsize);
if (map) {
- buf = unpack_sha1_file(map, mapsize, type, size);
+ buf = unpack_sha1_file(sha1, map, mapsize, type, size);
munmap(map, mapsize);
return buf;
}
@@ -305,3 +336,111 @@
close(fd);
return 0;
}
+
+int pack_sha1_buffer(void *buf, unsigned long buf_len,
+ unsigned char *returnsha1, char **dest,
+ unsigned long *dest_size)
+{
+ unsigned char sha1[20];
+ SHA_CTX c;
+ char *filename;
+ struct stat st;
+ void *p;
+ int metadata_size;
+
+ /* Sha1.. */
+ SHA1_Init(&c);
+ SHA1_Update(&c, buf, buf_len);
+ SHA1_Final(sha1, &c);
+
+ if (returnsha1)
+ memcpy(returnsha1, sha1, 20);
+
+ filename = sha1_file_name(sha1);
+ if (stat(filename, &st) == 0)
+ return 0;
+
+ p = realloc(*dest, *dest_size + buf_len + 250);
+ if (!p)
+ return -1;
+ *dest = p;
+ p += *dest_size;
+ metadata_size = 1 + sprintf(p, "%s %lu", sha1_to_hex(sha1), buf_len);
+ p += metadata_size;
+ memcpy(p, buf, buf_len);
+ *dest_size += buf_len + metadata_size;
+ return 0;
+}
+
+int write_packed_buffer(void *buf, unsigned long len)
+{
+ unsigned char sha1[20];
+ SHA_CTX c;
+ char *filename;
+ char *p;
+ char *metadata = malloc(200);
+ unsigned char sha1_hex[50];
+ int metadata_size;
+ int fd;
+ int ret = 0;
+
+ metadata_size = 1+sprintf(metadata, "packed %lu", len);
+
+ SHA1_Init(&c);
+ SHA1_Update(&c, metadata, metadata_size);
+ SHA1_Update(&c, buf, len);
+ SHA1_Final(sha1, &c);
+
+ filename = strdup(sha1_file_name(sha1));
+ fd = open(filename, O_WRONLY | O_CREAT | O_EXCL, 0666);
+ if (fd < 0) {
+ if (errno != EEXIST)
+ return -1;
+ /* add collision check! */
+ } else {
+ char *compressed;
+ z_stream stream;
+ unsigned long size;
+ /* Set it up */
+ memset(&stream, 0, sizeof(stream));
+ deflateInit(&stream, Z_BEST_COMPRESSION);
+ size = deflateBound(&stream, len + metadata_size);
+ compressed = malloc(size);
+
+ /* Compress it */
+ stream.next_in = metadata;
+ stream.avail_in = metadata_size;
+ stream.next_out = compressed;
+ stream.avail_out = size;
+ while (deflate(&stream, 0) == Z_OK)
+ /* nothing */;
+ stream.next_in = buf;
+ stream.avail_in = len;
+ while (deflate(&stream, Z_FINISH) == Z_OK)
+ /* nothing */;
+ deflateEnd(&stream);
+ write(fd, compressed, stream.total_out);
+ close(fd);
+ }
+ free(metadata);
+ /* now we have the packed blob on disk, lets link to it */
+ p = buf;
+ while(p < (char *)buf + len) {
+ unsigned long item_len;
+ char *item_file;
+ sscanf(p, "%50s %lu\n", sha1_hex, &item_len);
+ /* + 1 for the null at the end of p */
+ p += strlen(p) + item_len + 1;
+
+ if (get_sha1_hex(sha1_hex, sha1))
+ die("packed file corruption");
+
+ item_file = sha1_file_name(sha1);
+ if (link(filename, item_file) && errno != EEXIST) {
+ ret = -errno;
+ break;
+ }
+ }
+ free(filename);
+ return ret;
+}
diff -ur linus.back/update-cache.c linus/update-cache.c
--- linus.back/update-cache.c 2005-04-21 11:05:27.979606728 -0400
+++ linus/update-cache.c 2005-04-21 10:42:08.109419344 -0400
@@ -14,55 +14,33 @@
*/
static int allow_add = 0, allow_remove = 0;
-static int index_fd(unsigned char *sha1, int fd, struct stat *st)
+static int index_fd(unsigned char *sha1, int fd, struct stat *st, char **packed_buffer, unsigned long *packed_len)
{
- z_stream stream;
unsigned long size = st->st_size;
- int max_out_bytes = size + 200;
- void *out = malloc(max_out_bytes);
void *metadata = malloc(200);
int metadata_size;
void *in;
- SHA_CTX c;
+ char *copy;
+ int ret;
in = "";
if (size)
in = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
- if (!out || (int)(long)in == -1)
+ if (!metadata || (int)(long)in == -1)
return -1;
metadata_size = 1+sprintf(metadata, "blob %lu", size);
-
- SHA1_Init(&c);
- SHA1_Update(&c, metadata, metadata_size);
- SHA1_Update(&c, in, size);
- SHA1_Final(sha1, &c);
-
- memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
-
- /*
- * ASCII size + nul byte
- */
- stream.next_in = metadata;
- stream.avail_in = metadata_size;
- stream.next_out = out;
- stream.avail_out = max_out_bytes;
- while (deflate(&stream, 0) == Z_OK)
- /* nothing */;
-
- /*
- * File content
- */
- stream.next_in = in;
- stream.avail_in = size;
- while (deflate(&stream, Z_FINISH) == Z_OK)
- /*nothing */;
-
- deflateEnd(&stream);
-
- return write_sha1_buffer(sha1, out, stream.total_out);
+ copy = malloc(metadata_size + size);
+ if (!copy)
+ return -1;
+ memcpy(copy, metadata, metadata_size);
+ memcpy(copy + metadata_size, in, size);
+ ret = pack_sha1_buffer(copy, metadata_size + size,
+ sha1, packed_buffer, packed_len);
+ munmap(in, size);
+ free(copy);
+ return ret;
}
/*
@@ -85,7 +63,7 @@
ce->ce_size = htonl(st->st_size);
}
-static int add_file_to_cache(char *path)
+static int add_file_to_cache(char *path, char **packed_buffer, unsigned long *packed_len)
{
int size, namelen;
struct cache_entry *ce;
@@ -113,9 +91,14 @@
ce->ce_mode = create_ce_mode(st.st_mode);
ce->ce_flags = htons(namelen);
- if (index_fd(ce->sha1, fd, &st) < 0)
+ if (index_fd(ce->sha1, fd, &st, packed_buffer, packed_len) < 0)
return -1;
+ if (*packed_len > 32768) {
+ if (write_packed_buffer(*packed_buffer, *packed_len))
+ return -1;
+ *packed_len = 0;
+ }
return add_cache_entry(ce, allow_add);
}
@@ -286,6 +269,8 @@
{
int i, newfd, entries;
int allow_options = 1;
+ char *packed_buffer = NULL;
+ unsigned long packed_len = 0;
newfd = open(".git/index.lock", O_RDWR | O_CREAT | O_EXCL, 0600);
if (newfd < 0)
@@ -330,9 +315,14 @@
fprintf(stderr, "Ignoring path %s\n", argv[i]);
continue;
}
- if (add_file_to_cache(path))
+ if (add_file_to_cache(path, &packed_buffer, &packed_len))
die("Unable to add %s to database", path);
}
+ if (packed_buffer) {
+ if (packed_len)
+ if (write_packed_buffer(packed_buffer, packed_len))
+ free(packed_buffer);
+ }
if (write_cache(newfd, active_cache, active_nr) ||
rename(".git/index.lock", ".git/index"))
die("Unable to write new cachefile");
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Ingo Molnar @ 2005-04-21 14:47 UTC (permalink / raw)
To: Olivier Andrieu; +Cc: git
In-Reply-To: <20050421144554.GA15032@elte.hu>
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.)
Ingo
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Ingo Molnar @ 2005-04-21 14:45 UTC (permalink / raw)
To: Olivier Andrieu; +Cc: git
In-Reply-To: <20050421143840.GA14059@elte.hu>
another thing, when i 'zoom out' of the graph far away (so that the
whole graph becomes visible on the screen), i'm getting lots of such
error messages:
*** attempt to put segment in horiz list twice
*** attempt to put segment in horiz list twice
*** attempt to put segment in horiz list twice
*** attempt to put segment in horiz list twice
*** attempt to put segment in horiz list twice
this doesnt seem to impact anything though.
Ingo
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Ingo Molnar @ 2005-04-21 14:38 UTC (permalink / raw)
To: Olivier Andrieu; +Cc: git
In-Reply-To: <20050421.155519.112619323.oandrieu@nerim.net>
* Olivier Andrieu <oandrieu@nerim.net> wrote:
> Yes, git-viz uses the `dot' program from the graphviz package (it's in
> Fedora Extra too I believe).
ah - that resolved all issues and i'm now running git-viz without any
problems.
I just checked how the kernel repository looks like with it, and i'm
impressed! The GUI is top-notch, and the whole graph output and
navigation is very mature visually. Kudos!
a couple of suggestions that are in the 'taste' category:
- isnt left-to-right layout the more natural thing instead of top-down
(as it aligns with the reading direction)? It's selectable in the
preferences, but you might want to make it default. OTOH, top-down
creates a more compressed view of the graph.
- there doesnt seem to be any performance difference between non-colored
and colored rendering - so you might as well want to make 'color by
author' (or color by branch) the default coloring, instead of
uncolored?
- 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.
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.
Ingo
^ permalink raw reply
* Re: HOWTO: PATCH: don't hardcode path-to-bash, use sys/limits.h
From: Alecs King @ 2005-04-21 14:31 UTC (permalink / raw)
To: git
In-Reply-To: <20050421102326.GA22541@xdt04.mpe-garching.mpg.de>
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.
commit 2deea74db72fb57a8b80e7945f23814112b22723
tree 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd
parent cd1c034369b73da7503da365fa556aab27004814
author Alecs King <alecsk ! gmail d@t com> 1114075114 +0800
committer Alecs King <alecsk ! gmail d@t com> 1114075114 +0800
trivial fix for making it more portable
Index: commit-tree.c
===================================================================
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/commit-tree.c (mode:100644 sha1:043c7aa371101a1ea8cfc467279abf6c8acc7fd1)
+++ 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/commit-tree.c (mode:100644 sha1:8a1f12dca07041d203ce22442b8470d42d322ef5)
@@ -252,7 +252,7 @@
then -= offset;
- snprintf(result, maxlen, "%lu %5.5s", then, p);
+ snprintf(result, maxlen, "%lu %5.5s", (unsigned long) then, p);
}
static void check_valid(unsigned char *sha1, const char *expect)
Index: commit.c
===================================================================
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/commit.c (mode:100644 sha1:eda45d7e15358ed6f2cd0502de2a08987307fc98)
+++ 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/commit.c (mode:100644 sha1:9f0668eb68cec56a738a58fe930ae0ae2960e2b2)
@@ -1,6 +1,7 @@
#include "commit.h"
#include "cache.h"
#include <string.h>
+#include <limits.h>
const char *commit_type = "commit";
Index: gitdiff-do
===================================================================
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/gitdiff-do (mode:100755 sha1:afed4e40b259a61b0f12979ba7326f26743bc553)
+++ 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/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)
+++ 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/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.
#
Index: revision.h
===================================================================
--- c0260bfb82da04aeff4e598ced5295d6ae2e262d/revision.h (mode:100644 sha1:46cc10440be781cea4993aca37ee35e251495084)
+++ 0c92ac3af53457b6b9651cf82d98ce3a7b166dcd/revision.h (mode:100644 sha1:f0754f5d8ea3da52503b8ea8c16b34566e4ae6e0)
@@ -10,6 +10,7 @@
* definition for this rev, and not just seen it as
* a parent target.
*/
+#include <limits.h>
#define marked(rev) ((rev)->flags & 0xffff)
#define SEEN 0x10000
#define USED 0x20000
--
Alecs King
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Edgar Toernig @ 2005-04-21 14:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050421064931.GA31910@pasky.ji.cz>
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.
^ permalink raw reply
* Re: Switching between branches
From: Matthias Urlichs @ 2005-04-21 14:12 UTC (permalink / raw)
To: git
In-Reply-To: <20050421073123.GD31910@pasky.ji.cz>
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
^ permalink raw reply
* Errors received during git pull from linux-2.6.git, but resulting kernel looks OK.
From: Steven Cole @ 2005-04-21 13:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git mailing list
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:
[steven@spc0 linux-2.6-origin]$ git lsremote
origin rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
[steven@spc0 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
real 6m4.771s
user 0m16.538s
sys 0m12.952s
[steven@spc0 linux-2.6-origin]$
Maybe those errors are "harmless". Checking out the new repo:
[steven@spc0 linux-2.6-origin]$ git export ../linux-2.6.12-rc3
[steven@spc0 linux-2.6-origin]$ cd ..
[steven@spc0 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.
[steven@spc0 GIT]$ diffstat gitdiff-2.6.12-rc3 | tail -n 2
sound/usb/usx2y/usbusx2yaudio.c | 1
4622 files changed, 271839 insertions(+), 156792 deletions(-)
[steven@spc0 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
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Olivier Andrieu @ 2005-04-21 13:55 UTC (permalink / raw)
To: mingo; +Cc: git
In-Reply-To: <20050421130242.GA5817@elte.hu>
> Ingo Molnar [Thu, 21 Apr 2005]:
>
> * Olivier Andrieu <oandrieu@nerim.net> 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.)
Yes, git-viz uses the `dot' program from the graphviz package (it's in
Fedora Extra too I believe).
> > 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.
er, what's weird. Here's what I get :
,----
| $ tar zxf git-viz-0.1.tar.gz
| $ cd git-viz-0.1
| $ ./configure
| checking for ocamlc... ocamlc
| OCaml version is 3.08.2
| OCaml library path is /usr/lib/ocaml
| checking for ocamlopt... ocamlopt
`----
--
Olivier
^ permalink raw reply
* [PATCH] Allow "git cancel" to change branches
From: Matthias Urlichs @ 2005-04-21 13:31 UTC (permalink / raw)
To: git
"git cancel" may not be named correctly for this job, but it does almost
everything you'd need for switching between one branch and another
within a repository, so...
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
--- f29be8140c5f1175052ec96ad2fa2b2901fd6ba5/git (mode:100755 sha1:5f23301eb97a0fadd505a6e9cc851e98741a512a)
+++ 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/git (mode:100755 sha1:557122dfb05580e4af2c55767f3d6f92b9110edd)
@@ -28,7 +28,7 @@
add FILE...
addremote RNAME RSYNC_URL
apply < patch on stdin
- cancel
+ cancel [NAME]
ci, commit [FILE]... < log message on stdin
diff [-p] [-r FROM_ID[:TO_ID]] [FILE]...
export DESTDIR [TREE_ID]
Index: gitcancel.sh
===================================================================
--- f29be8140c5f1175052ec96ad2fa2b2901fd6ba5/gitcancel.sh (mode:100755 sha1:a78cf8ccab98861ef7aecb4cb5a79e47d3a84b67)
+++ 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/gitcancel.sh (mode:100755 sha1:2fc3e522132ef6a5f71352ab67005c93b5efc04f)
@@ -9,6 +9,9 @@
# Basically, this is the opposite of git commit in some sense.
#
# Takes no arguments and the evil changes from the tree.
+#
+# ... actually, if you do give it an argument, it'll switch the HEAD to
+# that branch -- or create a new one.
[ -s ".git/add-queue" ] && rm $(cat .git/add-queue)
rm -f .git/add-queue .git/rm-queue
@@ -29,6 +32,11 @@
fi
fi
+if [ "$1" ] ; then
+ test -f .git/heads/$1 || cp .git/HEAD .git/heads/$1
+ ln -sf "heads/$1" .git/HEAD
+fi
+
rm -f .git/blocked .git/merging .git/merging-sym .git/merge-base
read-tree $(tree-id)
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Vincent Hanquez @ 2005-04-21 13:15 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Olivier Andrieu, pasky, git
In-Reply-To: <20050421130242.GA5817@elte.hu>
On Thu, Apr 21, 2005 at 03:02:42PM +0200, Ingo Molnar wrote:
> 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.)
Hey Ingo,
you probably don't have graphviz (dot is one of graphviz executable).
I have no idea if that is related to the later though.
--
Vincent Hanquez
^ permalink raw reply
* Re: git-viz tool for visualising commit trees
From: Ingo Molnar @ 2005-04-21 13:02 UTC (permalink / raw)
To: Olivier Andrieu; +Cc: pasky, git
In-Reply-To: <20050421.133136.78712855.oandrieu@nerim.net>
* Olivier Andrieu <oandrieu@nerim.net> 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
^ permalink raw reply
* [PATCH] Improve usage messages
From: Matthias Urlichs @ 2005-04-21 12:41 UTC (permalink / raw)
To: git
This patch adds somewhat-improved usage messages to some of Linus' programs.
Specifically, they now handle -? / --help.
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
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\t<tree 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");
^ permalink raw reply
* [PATCH] Add "git push"
From: Matthias Urlichs @ 2005-04-21 12:43 UTC (permalink / raw)
To: git
This patch adds the ability to "git push", as the obvious converse of
"git pull".
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
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
+
^ permalink raw reply
* [PATCH] Missing quotes
From: Matthias Urlichs @ 2005-04-21 12:45 UTC (permalink / raw)
To: git
gitXnormid.sh should quote its cat-file calls so that nonexisting ssha1
IDs don't result in shell errors.
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
--- 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
^ permalink raw reply
* [PATCH] Missing linefeeds
From: Matthias Urlichs @ 2005-04-21 12:44 UTC (permalink / raw)
To: git
This patch fixes die() and error() to print linefeeds after the message.
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
--- 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;
}
^ permalink raw reply
* [PATCH] Add DEST Makefile variable
From: Matthias Urlichs @ 2005-04-21 12:39 UTC (permalink / raw)
To: git
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 <smurf@smurf.noris.de>
--- 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)
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: David Woodhouse @ 2005-04-21 12:23 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: git, linux-kernel, torvalds
In-Reply-To: <1114079347.6277.29.camel@laptopd505.fenrus.org>
On Thu, 2005-04-21 at 12:29 +0200, Arjan van de Ven wrote:
> with BK this was not possible, but could we please have -p added to the
> diff parameters with git ? It makes diffs a LOT more reasable!
With BK this was not possible, but could you please provide your
criticism in 'diff -up' form?
I've done 'perl -pi -e s/-u/-up/ gitdiff-do' as a quick hack to provide
what you want, but a saner fix to make gitdiff-do obey the same
GIT_DIFF_CMD and GIT_DIFF_OPTS environment variables as show-diff.c
would be a more useful answer.
--
dwmw2
^ permalink raw reply
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