* [BUG] Recent git-svn gets checksum errors on very large fetches
From: Avery Pennarun @ 2008-06-25 3:23 UTC (permalink / raw)
To: Git Mailing List, aroben
My svn repo has 17000+ files in 1000+ directories. I managed to
narrow my problem down to this sequence of steps:
mkdir poo
cd poo
git init
git svn init file:///home/averyp/svn.bak/branches/MyBranch
git svn fetch -r3095 2>&1 | tee git.out
Which culminates in:
Checksum mismatch: ThirdParty/whateverdir/blahblah
expected: c342eaa17fe219a764c06642bb951474
got: 848bbb56e4c22755ffb687fb70ae1ac6
For extra excitement, if I run the same command multiple times, the
exact file (blahblah) with the checksum mismatch differs each time.
However, it tends to be a file approximately the same "distance" down
in the fetch: it's almost always in whateverdir, which contains only
333 out of the 17000 files.
This leads me to believe there's a race condition or buffer problem
somewhere causing the problem. Using git-bisect, I discovered that it
works fine in git 1.5.5.1, and that this patch is the one to blame:
commit ffe256f9bac8a40ff751a9341a5869d98f72c285
Author: Adam Roben <aroben@apple.com>
Date: Fri May 23 16:19:41 2008 +0200
git-svn: Speed up fetch
Figures. :)
Reverting it directly seems to cause a conflict, so I can't test for
sure that the latest master with this patch reverted would work
correctly.
Not quite sure what could be at fault here, or what to do next.
Unfortunately it's hard to assemble a test case for timing-related
problems like this. Thoughts?
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] factorize pack structure allocation
From: Junio C Hamano @ 2008-06-25 3:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Teemu Likonen
In-Reply-To: <alpine.LFD.1.10.0806241851420.2979@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> New pack structures are currently allocated in 2 different places
> and all members have to be initialized explicitly. This is prone
> to errors leading to segmentation faults as found by Teemu Likonen.
Thanks. This is a much better equivalent to the "probably fixed with
this" patch you sent earlier ;-)
^ permalink raw reply
* [PATCH] Keep some git-* programs in $(bindir)
From: Junio C Hamano @ 2008-06-25 3:22 UTC (permalink / raw)
To: しらいしななこ
Cc: Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080625120832.6117@nanako3.lavabit.com>
Otherwise remote executions directly over ssh won't find them as they used
to. --upload-pack and --receive-pack options _could_ be used on the
client side, but things should keep working out-of-box for older clients.
Later versions of clients (fetch-pack and send-pack) probably could start
asking for these programs with dashless form, but that is a different
topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* しらいしななこ <nanako3@lavabit.com> writes:
> Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?
Ok, how about this?
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 929136b..742e7d3 100644
--- a/Makefile
+++ b/Makefile
@@ -1268,7 +1268,7 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_TCLTK
--
1.5.6.56.g29b0d
^ permalink raw reply related
* [PATCH 4/4] verify-pack: test for detection of index v2 object CRC mismatch
From: Nicolas Pitre @ 2008-06-25 3:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
t/t5302-pack-index.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 09fd917..ecec591 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
@@ -162,4 +162,18 @@ test_expect_success \
'[index v2] 5) pack-objects refuses to reuse corrupted data' \
'! git pack-objects test-5 <obj-list'
+test_expect_success \
+ '[index v2] 6) verify-pack detects CRC mismatch' \
+ 'rm -f .git/objects/pack/* &&
+ git-index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
+ git verify-pack ".git/objects/pack/pack-${pack1}.pack" &&
+ chmod +w ".git/objects/pack/pack-${pack1}.idx" &&
+ dd if=/dev/zero of=".git/objects/pack/pack-${pack1}.idx" conv=notrunc \
+ bs=1 count=4 seek=$((8 + 256 * 4 + `wc -l <obj-list` * 20 + 0)) &&
+ ( while read obj
+ do git cat-file -p $obj >/dev/null || exit 1
+ done <obj-list ) &&
+ err=$(! git verify-pack ".git/objects/pack/pack-${pack1}.pack" 2>&1) &&
+ echo "$err" | grep "CRC mismatch"'
+
test_done
--
1.5.6.56.g29b0d
^ permalink raw reply related
* [PATCH 3/4] verify-pack: check packed object CRC when using index version 2
From: Nicolas Pitre @ 2008-06-25 3:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
To do so, check_pack_crc() moved from builtin-pack-objects.c to
pack-check.c where it is more logical to share.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 22 ----------------------
pack-check.c | 39 +++++++++++++++++++++++++++++++++++++--
pack.h | 2 +-
3 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 827673c..28207d9 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -209,28 +209,6 @@ static int check_pack_inflate(struct packed_git *p,
stream.total_in == len) ? 0 : -1;
}
-static int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
- off_t offset, off_t len, unsigned int nr)
-{
- const uint32_t *index_crc;
- uint32_t data_crc = crc32(0, Z_NULL, 0);
-
- do {
- unsigned int avail;
- void *data = use_pack(p, w_curs, offset, &avail);
- if (avail > len)
- avail = len;
- data_crc = crc32(data_crc, data, avail);
- offset += avail;
- len -= avail;
- } while (len);
-
- index_crc = p->index_data;
- index_crc += 2 + 256 + p->num_objects * (20/4) + nr;
-
- return data_crc != ntohl(*index_crc);
-}
-
static void copy_pack_data(struct sha1file *f,
struct packed_git *p,
struct pack_window **w_curs,
diff --git a/pack-check.c b/pack-check.c
index 5f02a65..f596bf2 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -4,8 +4,9 @@
struct idx_entry
{
- const unsigned char *sha1;
off_t offset;
+ const unsigned char *sha1;
+ unsigned int nr;
};
static int compare_entries(const void *e1, const void *e2)
@@ -19,6 +20,28 @@ static int compare_entries(const void *e1, const void *e2)
return 0;
}
+int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
+ off_t offset, off_t len, unsigned int nr)
+{
+ const uint32_t *index_crc;
+ uint32_t data_crc = crc32(0, Z_NULL, 0);
+
+ do {
+ unsigned int avail;
+ void *data = use_pack(p, w_curs, offset, &avail);
+ if (avail > len)
+ avail = len;
+ data_crc = crc32(data_crc, data, avail);
+ offset += avail;
+ len -= avail;
+ } while (len);
+
+ index_crc = p->index_data;
+ index_crc += 2 + 256 + p->num_objects * (20/4) + nr;
+
+ return data_crc != ntohl(*index_crc);
+}
+
static int verify_packfile(struct packed_git *p,
struct pack_window **w_curs)
{
@@ -61,13 +84,15 @@ static int verify_packfile(struct packed_git *p,
* we do not do scan-streaming check on the pack file.
*/
nr_objects = p->num_objects;
- entries = xmalloc(nr_objects * sizeof(*entries));
+ entries = xmalloc((nr_objects + 1) * sizeof(*entries));
+ entries[nr_objects].offset = pack_sig_ofs;
/* first sort entries by pack offset, since unpacking them is more efficient that way */
for (i = 0; i < nr_objects; i++) {
entries[i].sha1 = nth_packed_object_sha1(p, i);
if (!entries[i].sha1)
die("internal error pack-check nth-packed-object");
entries[i].offset = nth_packed_object_offset(p, i);
+ entries[i].nr = i;
}
qsort(entries, nr_objects, sizeof(*entries), compare_entries);
@@ -76,6 +101,16 @@ static int verify_packfile(struct packed_git *p,
enum object_type type;
unsigned long size;
+ if (p->index_version > 1) {
+ off_t offset = entries[i].offset;
+ off_t len = entries[i+1].offset - offset;
+ unsigned int nr = entries[i].nr;
+ if (check_pack_crc(p, w_curs, offset, len, nr))
+ err = error("index CRC mismatch for object %s "
+ "from %s at offset %"PRIuMAX"",
+ sha1_to_hex(entries[i].sha1),
+ p->pack_name, (uintmax_t)offset);
+ }
data = unpack_entry(p, entries[i].offset, &type, &size);
if (!data) {
err = error("cannot unpack %s from %s at offset %"PRIuMAX"",
diff --git a/pack.h b/pack.h
index 465071c..76e6aa2 100644
--- a/pack.h
+++ b/pack.h
@@ -56,7 +56,7 @@ struct pack_idx_entry {
};
extern char *write_idx_file(char *index_name, struct pack_idx_entry **objects, int nr_objects, unsigned char *sha1);
-
+extern int check_pack_crc(struct packed_git *p, struct pack_window **w_curs, off_t offset, off_t len, unsigned int nr);
extern int verify_pack(struct packed_git *);
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t);
extern char *index_pack_lockfile(int fd);
--
1.5.6.56.g29b0d
^ permalink raw reply related
* [PATCH 2/4] move show_pack_info() were it belongs
From: Nicolas Pitre @ 2008-06-25 3:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is called when verify_pack() has its verbose argument set, and
verbose in this context makes sense only for the actual 'git verify-pack'
command. Therefore let's move show_pack_info() to builtin-verify-pack.c
instead and remove useless verbose argument from verify_pack().
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-fsck.c | 2 +-
builtin-verify-pack.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++-
http-push.c | 2 +-
http-walker.c | 2 +-
pack-check.c | 66 +------------------------------------------------
pack.h | 2 +-
6 files changed, 67 insertions(+), 70 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 78a6e1f..b0f9648 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -585,7 +585,7 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
prepare_packed_git();
for (p = packed_git; p; p = p->next)
/* verify gives error messages itself */
- verify_pack(p, 0);
+ verify_pack(p);
for (p = packed_git; p; p = p->next) {
uint32_t j, num;
diff --git a/builtin-verify-pack.c b/builtin-verify-pack.c
index 4c515a0..222c39e 100644
--- a/builtin-verify-pack.c
+++ b/builtin-verify-pack.c
@@ -2,6 +2,58 @@
#include "cache.h"
#include "pack.h"
+
+#define MAX_CHAIN 50
+
+static void show_pack_info(struct packed_git *p)
+{
+ uint32_t nr_objects, i, chain_histogram[MAX_CHAIN+1];
+
+ nr_objects = p->num_objects;
+ memset(chain_histogram, 0, sizeof(chain_histogram));
+
+ for (i = 0; i < nr_objects; i++) {
+ const unsigned char *sha1;
+ unsigned char base_sha1[20];
+ const char *type;
+ unsigned long size;
+ unsigned long store_size;
+ off_t offset;
+ unsigned int delta_chain_length;
+
+ sha1 = nth_packed_object_sha1(p, i);
+ if (!sha1)
+ die("internal error pack-check nth-packed-object");
+ offset = nth_packed_object_offset(p, i);
+ type = packed_object_info_detail(p, offset, &size, &store_size,
+ &delta_chain_length,
+ base_sha1);
+ printf("%s ", sha1_to_hex(sha1));
+ if (!delta_chain_length)
+ printf("%-6s %lu %lu %"PRIuMAX"\n",
+ type, size, store_size, (uintmax_t)offset);
+ else {
+ printf("%-6s %lu %lu %"PRIuMAX" %u %s\n",
+ type, size, store_size, (uintmax_t)offset,
+ delta_chain_length, sha1_to_hex(base_sha1));
+ if (delta_chain_length <= MAX_CHAIN)
+ chain_histogram[delta_chain_length]++;
+ else
+ chain_histogram[0]++;
+ }
+ }
+
+ for (i = 0; i <= MAX_CHAIN; i++) {
+ if (!chain_histogram[i])
+ continue;
+ printf("chain length = %d: %d object%s\n", i,
+ chain_histogram[i], chain_histogram[i] > 1 ? "s" : "");
+ }
+ if (chain_histogram[0])
+ printf("chain length > %d: %d object%s\n", MAX_CHAIN,
+ chain_histogram[0], chain_histogram[0] > 1 ? "s" : "");
+}
+
static int verify_one_pack(const char *path, int verbose)
{
char arg[PATH_MAX];
@@ -41,7 +93,16 @@ static int verify_one_pack(const char *path, int verbose)
return error("packfile %s not found.", arg);
install_packed_git(pack);
- err = verify_pack(pack, verbose);
+ err = verify_pack(pack);
+
+ if (verbose) {
+ if (err)
+ printf("%s: bad\n", pack->pack_name);
+ else {
+ show_pack_info(pack);
+ printf("%s: ok\n", pack->pack_name);
+ }
+ }
return err;
}
diff --git a/http-push.c b/http-push.c
index 665712a..2cd068a 100644
--- a/http-push.c
+++ b/http-push.c
@@ -783,7 +783,7 @@ static void finish_request(struct transfer_request *request)
lst = &((*lst)->next);
*lst = (*lst)->next;
- if (!verify_pack(target, 0))
+ if (!verify_pack(target))
install_packed_git(target);
else
remote->can_update_info_refs = 0;
diff --git a/http-walker.c b/http-walker.c
index 99f397e..51c18f2 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -795,7 +795,7 @@ static int fetch_pack(struct walker *walker, struct alt_base *repo, unsigned cha
lst = &((*lst)->next);
*lst = (*lst)->next;
- if (verify_pack(target, 0))
+ if (verify_pack(target))
return -1;
install_packed_git(target);
diff --git a/pack-check.c b/pack-check.c
index d6dbd4b..5f02a65 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -96,62 +96,7 @@ static int verify_packfile(struct packed_git *p,
return err;
}
-
-#define MAX_CHAIN 50
-
-static void show_pack_info(struct packed_git *p)
-{
- uint32_t nr_objects, i, chain_histogram[MAX_CHAIN+1];
-
- nr_objects = p->num_objects;
- memset(chain_histogram, 0, sizeof(chain_histogram));
-
- for (i = 0; i < nr_objects; i++) {
- const unsigned char *sha1;
- unsigned char base_sha1[20];
- const char *type;
- unsigned long size;
- unsigned long store_size;
- off_t offset;
- unsigned int delta_chain_length;
-
- sha1 = nth_packed_object_sha1(p, i);
- if (!sha1)
- die("internal error pack-check nth-packed-object");
- offset = find_pack_entry_one(sha1, p);
- if (!offset)
- die("internal error pack-check find-pack-entry-one");
-
- type = packed_object_info_detail(p, offset, &size, &store_size,
- &delta_chain_length,
- base_sha1);
- printf("%s ", sha1_to_hex(sha1));
- if (!delta_chain_length)
- printf("%-6s %lu %lu %"PRIuMAX"\n",
- type, size, store_size, (uintmax_t)offset);
- else {
- printf("%-6s %lu %lu %"PRIuMAX" %u %s\n",
- type, size, store_size, (uintmax_t)offset,
- delta_chain_length, sha1_to_hex(base_sha1));
- if (delta_chain_length <= MAX_CHAIN)
- chain_histogram[delta_chain_length]++;
- else
- chain_histogram[0]++;
- }
- }
-
- for (i = 0; i <= MAX_CHAIN; i++) {
- if (!chain_histogram[i])
- continue;
- printf("chain length = %d: %d object%s\n", i,
- chain_histogram[i], chain_histogram[i] > 1 ? "s" : "");
- }
- if (chain_histogram[0])
- printf("chain length > %d: %d object%s\n", MAX_CHAIN,
- chain_histogram[0], chain_histogram[0] > 1 ? "s" : "");
-}
-
-int verify_pack(struct packed_git *p, int verbose)
+int verify_pack(struct packed_git *p)
{
off_t index_size;
const unsigned char *index_base;
@@ -177,14 +122,5 @@ int verify_pack(struct packed_git *p, int verbose)
err |= verify_packfile(p, &w_curs);
unuse_pack(&w_curs);
- if (verbose) {
- if (err)
- printf("%s: bad\n", p->pack_name);
- else {
- show_pack_info(p);
- printf("%s: ok\n", p->pack_name);
- }
- }
-
return err;
}
diff --git a/pack.h b/pack.h
index b31b376..465071c 100644
--- a/pack.h
+++ b/pack.h
@@ -57,7 +57,7 @@ struct pack_idx_entry {
extern char *write_idx_file(char *index_name, struct pack_idx_entry **objects, int nr_objects, unsigned char *sha1);
-extern int verify_pack(struct packed_git *, int);
+extern int verify_pack(struct packed_git *);
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t);
extern char *index_pack_lockfile(int fd);
--
1.5.6.56.g29b0d
^ permalink raw reply related
* [PATCH 1/4] optimize verify-pack a bit
From: Nicolas Pitre @ 2008-06-25 3:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Using find_pack_entry_one() to get object offsets is rather suboptimal
when nth_packed_object_offset() can be used directly.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
cache.h | 1 +
pack-check.c | 4 +---
sha1_file.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index a68866c..16222a3 100644
--- a/cache.h
+++ b/cache.h
@@ -711,6 +711,7 @@ extern void close_pack_windows(struct packed_git *);
extern void unuse_pack(struct pack_window **);
extern struct packed_git *add_packed_git(const char *, int, int);
extern const unsigned char *nth_packed_object_sha1(struct packed_git *, uint32_t);
+extern off_t nth_packed_object_offset(const struct packed_git *, uint32_t);
extern off_t find_pack_entry_one(const unsigned char *, struct packed_git *);
extern void *unpack_entry(struct packed_git *, off_t, enum object_type *, unsigned long *);
extern unsigned long unpack_object_header_gently(const unsigned char *buf, unsigned long len, enum object_type *type, unsigned long *sizep);
diff --git a/pack-check.c b/pack-check.c
index b99a917..d6dbd4b 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -67,9 +67,7 @@ static int verify_packfile(struct packed_git *p,
entries[i].sha1 = nth_packed_object_sha1(p, i);
if (!entries[i].sha1)
die("internal error pack-check nth-packed-object");
- entries[i].offset = find_pack_entry_one(entries[i].sha1, p);
- if (!entries[i].offset)
- die("internal error pack-check find-pack-entry-one");
+ entries[i].offset = nth_packed_object_offset(p, i);
}
qsort(entries, nr_objects, sizeof(*entries), compare_entries);
diff --git a/sha1_file.c b/sha1_file.c
index 9330bc4..a92f023 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1708,7 +1708,7 @@ const unsigned char *nth_packed_object_sha1(struct packed_git *p,
}
}
-static off_t nth_packed_object_offset(const struct packed_git *p, uint32_t n)
+off_t nth_packed_object_offset(const struct packed_git *p, uint32_t n)
{
const unsigned char *index = p->index_data;
index += 4 * 256;
--
1.5.6.56.g29b0d
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: しらいしななこ @ 2008-06-25 3:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vk5ge8bm5.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>>> It most likely makes sense to do (3) anyway. upload-pack, receive-pack,
>>> anything else?
>>
>> I think that's all.
>
> Then that would be this patch on top of nd/dashless topic.
>
> Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 929136b..babf16b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1268,7 +1268,7 @@ install: all
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> - $(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
> + $(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)'
> $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
> $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
> ifndef NO_TCLTK
Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-25 2:57 UTC (permalink / raw)
To: Miklos Vajna; +Cc: pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080624233236.GI29404@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> It most likely makes sense to do (3) anyway. upload-pack, receive-pack,
>> anything else?
>
> I think that's all.
Then that would be this patch on top of nd/dashless topic.
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 929136b..babf16b 100644
--- a/Makefile
+++ b/Makefile
@@ -1268,7 +1268,7 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_TCLTK
^ permalink raw reply related
* Re: [PATCH] Ship sample hooks with .sample suffix
From: Junio C Hamano @ 2008-06-25 2:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <7vtzfi8dvk.fsf_-_@gitster.siamese.dyndns.org>
I'll queue the patch to 'master' and I suspect that this will make 31d6632
(Windows: Change the name of hook scripts to make them not executable.,
2007-11-30) unnecessary.
I've looked at diff between ee1e0a3 (the original "pull" request) and
8fd39ba (after WS fixup on borrowed code and other changes).
They all looked fine except for git.c::main() where do .. while does not
have a { } around the body (which is not required by C language but it
just looked funny).
I am very tempted to pull MinGW series directly to 'master', or at least
to 'next', perhaps after dropping 31d6632. What's your confidence level
on the series? I think we should give this series extra priority so that
any potential issues with other series (like dr/ceil) that do pathname
traversal will become more apparent sooner rather than later.
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Theodore Tso @ 2008-06-25 2:33 UTC (permalink / raw)
To: David Jeske; +Cc: git
On Wed, Jun 25, 2008 at 12:36:03AM -0000, David Jeske wrote:
> The purpose of this mechanism is to host a distributed source
> repository in a world where most most developer contributors are
> behind firewalls and do not have access to, or do not want to
> configure a unix server, ftp, or ssh to possibly contribute to a
> project.
> design assumptions:
>
> - all developers are firewalled and can not be "pulled" from directly.
> - there can be one or more well-connected servers which all users can access.
> - .. but which they cannot have ssh, ftp, or other dangerous access to
> - .. and whose protocol should be layered on http(s)
> - there is a shared namespace for branches, and tags
> - .. users are not-trusted to change the branches or tags of other users
Up to here, you can do this all with repo.or.cz, and/or github; you
just give each developer their own repository, which they are allowed
to push to, and no once else. Within their own repository they can
make changes to their branches, so that all works just fine.
> (a) safely "share" every DAG, branch, and tag data in their
> repository to a well-connected server, into an established
> namespace, while only changing branches and tags in their
> namespace. This will allow all users to see the changes of other
> users, without needing direct access to their trees (which are
> inaccessible behind firewalls). [1]
Right, so thats github and/or git.or.cz. Each user gets his/her own
> repository, but thats a very minor change. Not a big deal.
> (b) fetch selected DAG, branch, and tag data of others to their tree, to see
> the changes of others (whether merged with head or not) while disconnected or
> remote.
This is also easy; you just establish remote tracking branches. I
have a single shell scripted command, git-get-all, which pulls from
all of the repositories I am interested in into various remote
tracking branches so while I am disconnected, I can see what other
folks have done on their trees.
> (c) grant and enforce permission for certain users to submit _merges
> only_ onto certain sub-portions of the "well-named branches"
This is the wierd one. *** Why ***? There is nothing magical about
merges; all a merge is a commit that contains more than one parent.
You can put anything into a merge, and in theory the result of a merge
could have nothing to do with either parent. It would be a very
perverse merge, but it's certainly possible. So what's the point of
trying to enforce rules about "merges only"?
- Ted
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Theodore Tso @ 2008-06-25 2:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, David Jeske, Jakub Narebski, Boaz Harrosh, git
In-Reply-To: <7vod5qa0tu.fsf@gitster.siamese.dyndns.org>
On Tue, Jun 24, 2008 at 04:07:57PM -0700, Junio C Hamano wrote:
> > Instead, I've just learned to be careful and my use of git reset
> > --hard is mainly for historical reasons.
>
> This makes it sound as if avoiding "reset --hard" is a good thing, but I
> do not understand why.
Well, it was Brandon Casey who was asserting that git reset --hard was
evil, which I generally don't agree with. I do use workflows that use
it a fair amount, usually because its more convenient to type "git
checkout <foo>; git reset --hard <baz>" than something involving "git
update-ref refs/heads/<foo> <baz>". The former has more characters
than the latter, and involves more disk I/O since it mutates the
working directory; but it's something about needing to type
"refs/heads/" such that I generally tend to type "git checkout....
git reset". I can't explain why; maybe it's just psychological.
The reason why I've been thinking that I should change my shell script
from:
git checkout integration
git reset --hard <foo>
to:
git update-ref ref/heads/integration HEAD
git checkout integration
Is actually because the first tends to touch more files in the working
directory than the second (because if the integration branch is a week
or two old, the git checkout unwinds the global state by two weeks,
and then the git reset --hard has to bring the state back up to
recentcy; the second generally involves a smaller set of files
changing). That's a very minor point, granted.
> The reason you have the diff-index check in the second sequence is because
> update-ref does not have the "local changes" check either. You could have
> used the same diff-index check in front of "reset --hard".
Definitely true. The reason why I don't have this check is because
I'm generally careful and I run a "git stat" to make sure there are no
local changes in the tree before I run the script.
> Moreover, in your original sequence above, doesn't "git checkout
> integration" list your local changes when you have any, and wouldn't that
> be a clue enough that the next "reset --hard origin" would discard them?
... because it's in a shell script; being fundamentally lazy, instead
of typing that sequence over and over again, I've scripted it. :-)
- Ted
^ permalink raw reply
* [PATCH] Ship sample hooks with .sample suffix
From: Junio C Hamano @ 2008-06-25 2:09 UTC (permalink / raw)
To: git; +Cc: Christian Holtje
In-Reply-To: <7v4p7i9ygd.fsf@gitster.siamese.dyndns.org>
We used to mark hooks we ship as samples by making them unexecutable, but
some filesystems cannot tell what is executable and what is not.
This makes it much more explicit. The hooks are suffixed with .sample
(but now are made executable), so enabling it is still one step operation
(instead of "chmod +x $hook", you would do "mv $hook.sample $hook") but
now they won't get accidentally enabled on systems without executable bit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is for actual application. Hopefully I got all the "to enable
this hook, make it executable" in the samples right.
Documentation/githooks.txt | 3 ++-
...applypatch-msg => hooks--applypatch-msg.sample} | 2 +-
...{hooks--commit-msg => hooks--commit-msg.sample} | 2 +-
...ooks--post-commit => hooks--post-commit.sample} | 2 +-
...ks--post-receive => hooks--post-receive.sample} | 13 ++++++-------
...ooks--post-update => hooks--post-update.sample} | 2 +-
...pre-applypatch => hooks--pre-applypatch.sample} | 2 +-
...{hooks--pre-commit => hooks--pre-commit.sample} | 2 +-
...{hooks--pre-rebase => hooks--pre-rebase.sample} | 0
...commit-msg => hooks--prepare-commit-msg.sample} | 2 +-
templates/{hooks--update => hooks--update.sample} | 2 +-
11 files changed, 16 insertions(+), 16 deletions(-)
rename templates/{hooks--applypatch-msg => hooks--applypatch-msg.sample} (86%)
mode change 100644 => 100755
rename templates/{hooks--commit-msg => hooks--commit-msg.sample} (93%)
mode change 100644 => 100755
rename templates/{hooks--post-commit => hooks--post-commit.sample} (63%)
mode change 100644 => 100755
rename templates/{hooks--post-receive => hooks--post-receive.sample} (40%)
mode change 100644 => 100755
rename templates/{hooks--post-update => hooks--post-update.sample} (63%)
mode change 100644 => 100755
rename templates/{hooks--pre-applypatch => hooks--pre-applypatch.sample} (84%)
mode change 100644 => 100755
rename templates/{hooks--pre-commit => hooks--pre-commit.sample} (96%)
mode change 100644 => 100755
rename templates/{hooks--pre-rebase => hooks--pre-rebase.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--prepare-commit-msg => hooks--prepare-commit-msg.sample} (94%)
mode change 100644 => 100755
rename templates/{hooks--update => hooks--update.sample} (97%)
mode change 100644 => 100755
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 4f06ae0..262a4f1 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -17,7 +17,8 @@ Hooks are little scripts you can place in `$GIT_DIR/hooks`
directory to trigger action at certain points. When
`git-init` is run, a handful example hooks are copied in the
`hooks` directory of the new repository, but by default they are
-all disabled. To enable a hook, make it executable with `chmod +x`.
+all disabled. To enable a hook, rename it by removing its `.sample`
+suffix.
This document describes the currently defined hooks.
diff --git a/templates/hooks--applypatch-msg b/templates/hooks--applypatch-msg.sample
old mode 100644
new mode 100755
similarity index 86%
rename from templates/hooks--applypatch-msg
rename to templates/hooks--applypatch-msg.sample
index 02de1ef..8b2a2fe
--- a/templates/hooks--applypatch-msg
+++ b/templates/hooks--applypatch-msg.sample
@@ -7,7 +7,7 @@
# appropriate message if it wants to stop the commit. The hook is
# allowed to edit the commit message file.
#
-# To enable this hook, make this file executable.
+# To enable this hook, rename this file to "applypatch-msg".
. git-sh-setup
test -x "$GIT_DIR/hooks/commit-msg" &&
diff --git a/templates/hooks--commit-msg b/templates/hooks--commit-msg.sample
old mode 100644
new mode 100755
similarity index 93%
rename from templates/hooks--commit-msg
rename to templates/hooks--commit-msg.sample
index 4ef86eb..6ef1d29
--- a/templates/hooks--commit-msg
+++ b/templates/hooks--commit-msg.sample
@@ -6,7 +6,7 @@
# status after issuing an appropriate message if it wants to stop the
# commit. The hook is allowed to edit the commit message file.
#
-# To enable this hook, make this file executable.
+# To enable this hook, rename this file to "commit-msg".
# Uncomment the below to add a Signed-off-by line to the message.
# Doing this in a hook is a bad idea in general, but the prepare-commit-msg
diff --git a/templates/hooks--post-commit b/templates/hooks--post-commit.sample
old mode 100644
new mode 100755
similarity index 63%
rename from templates/hooks--post-commit
rename to templates/hooks--post-commit.sample
index 8be6f34..2266821
--- a/templates/hooks--post-commit
+++ b/templates/hooks--post-commit.sample
@@ -3,6 +3,6 @@
# An example hook script that is called after a successful
# commit is made.
#
-# To enable this hook, make this file executable.
+# To enable this hook, rename this file to "post-commit".
: Nothing
diff --git a/templates/hooks--post-receive b/templates/hooks--post-receive.sample
old mode 100644
new mode 100755
similarity index 40%
rename from templates/hooks--post-receive
rename to templates/hooks--post-receive.sample
index b70c8fd..18d2e0f
--- a/templates/hooks--post-receive
+++ b/templates/hooks--post-receive.sample
@@ -1,16 +1,15 @@
#!/bin/sh
#
-# An example hook script for the post-receive event
+# An example hook script for the "post-receive" event.
#
-# This script is run after receive-pack has accepted a pack and the
-# repository has been updated. It is passed arguments in through stdin
-# in the form
+# The "post-receive" script is run after receive-pack has accepted a pack
+# and the repository has been updated. It is passed arguments in through
+# stdin in the form
# <oldrev> <newrev> <refname>
# For example:
# aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master
#
-# see contrib/hooks/ for an sample, or uncomment the next line (on debian)
-#
-
+# see contrib/hooks/ for an sample, or uncomment the next line and
+# rename the file to "post-receive".
#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
diff --git a/templates/hooks--post-update b/templates/hooks--post-update.sample
old mode 100644
new mode 100755
similarity index 63%
rename from templates/hooks--post-update
rename to templates/hooks--post-update.sample
index bcba893..5323b56
--- a/templates/hooks--post-update
+++ b/templates/hooks--post-update.sample
@@ -3,6 +3,6 @@
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
-# To enable this hook, make this file executable by "chmod +x post-update".
+# To enable this hook, rename this file to "post-update".
exec git-update-server-info
diff --git a/templates/hooks--pre-applypatch b/templates/hooks--pre-applypatch.sample
old mode 100644
new mode 100755
similarity index 84%
rename from templates/hooks--pre-applypatch
rename to templates/hooks--pre-applypatch.sample
index eeccc93..b1f187c
--- a/templates/hooks--pre-applypatch
+++ b/templates/hooks--pre-applypatch.sample
@@ -6,7 +6,7 @@
# The hook should exit with non-zero status after issuing an
# appropriate message if it wants to stop the commit.
#
-# To enable this hook, make this file executable.
+# To enable this hook, rename this file to "pre-applypatch".
. git-sh-setup
test -x "$GIT_DIR/hooks/pre-commit" &&
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit.sample
old mode 100644
new mode 100755
similarity index 96%
rename from templates/hooks--pre-commit
rename to templates/hooks--pre-commit.sample
index b25dce6..71c10f2
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit.sample
@@ -5,7 +5,7 @@
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.
#
-# To enable this hook, make this file executable.
+# To enable this hook, rename this file to "pre-commit".
# This is slightly modified from Andrew Morton's Perfect Patch.
# Lines you introduce should not have trailing whitespace.
diff --git a/templates/hooks--pre-rebase b/templates/hooks--pre-rebase.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--pre-rebase
rename to templates/hooks--pre-rebase.sample
diff --git a/templates/hooks--prepare-commit-msg b/templates/hooks--prepare-commit-msg.sample
old mode 100644
new mode 100755
similarity index 94%
rename from templates/hooks--prepare-commit-msg
rename to templates/hooks--prepare-commit-msg.sample
index d3c1da3..aa42acf
--- a/templates/hooks--prepare-commit-msg
+++ b/templates/hooks--prepare-commit-msg.sample
@@ -7,7 +7,7 @@
# message file. If the hook fails with a non-zero status,
# the commit is aborted.
#
-# To enable this hook, make this file executable.
+# To enable this hook, rename this file to "prepare-commit-msg".
# This hook includes three examples. The first comments out the
# "Conflicts:" part of a merge commit.
diff --git a/templates/hooks--update b/templates/hooks--update.sample
old mode 100644
new mode 100755
similarity index 97%
rename from templates/hooks--update
rename to templates/hooks--update.sample
index 4b69268..93c6055
--- a/templates/hooks--update
+++ b/templates/hooks--update.sample
@@ -3,7 +3,7 @@
# An example hook script to blocks unannotated tags from entering.
# Called by git-receive-pack with arguments: refname sha1-old sha1-new
#
-# To enable this hook, make this file executable by "chmod +x update".
+# To enable this hook, rename this file to "update".
#
# Config
# ------
--
1.5.6.56.g29b0d
^ permalink raw reply related
* Re: [PATCH/RFC] Created git-basis and modified git-bundle to accept --stdin.
From: Adam Brewster @ 2008-06-25 1:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430806241721j43f9443eu80e16dcd64b8d143@mail.gmail.com>
>
> Does it prefix bases with ^, i.e. ^basis (negative revision)?
> I think it should, then there would be no need for strange --stdin
> semantic, or implementing --stdin in such way that --not--stdin
> works as expected.
>
Yes.
I figure that patching to make --not --stdin work how I'd like would
break something else, and implementing --not-stdin seems hackish.
Adam Brewster
^ permalink raw reply
* policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 0:36 UTC (permalink / raw)
To: git
I'd like to hear feedback and ideas about a different mechanism than is being
used with git-pull or git-push.
The purpose of this mechanism is to host a distributed source repository in a
world where most most developer contributors are behind firewalls and do not
have access to, or do not want to configure a unix server, ftp, or ssh to
possibly contribute to a project. The model of allowing less-authoritative
developers to make their changes available for more-authoritative users to pull
is accepted as superior. However, no users are assumed to be authoritative over
each-other, or an entire tree, and many users should have authority only to
supply new deltas to their own branches. The ability to handle emailed patches
is an asset, but is deemed too manual for this need.
I believe git's design is strong; that many of the mechanisms are already
built; that new mechanisms to build this can be simple; and that with such
mechanisms, many more developers would have access to git's decentralized
development style. Further, it would address drawbacks in today's git relative
to public central version control systems, making this system closer to a 'best
of both worlds'.
design assumptions:
- all developers are firewalled and can not be "pulled" from directly.
- there can be one or more well-connected servers which all users can access.
- .. but which they cannot have ssh, ftp, or other dangerous access to
- .. and whose protocol should be layered on http(s)
- there is a shared namespace for branches, and tags
- .. users are not-trusted to change the branches or tags of other users
- .. only certain users are trusted to change the shared origin branches
- .. also allow directory ACLS on shared branch commits
- all their DAGs should be in a single repository for space efficiency
- users generally want to follow well-named branches
- .. will be free to follow any branch, and pull changes from any branch
I would like to make it easy for users to:
(a) safely "share" every DAG, branch, and tag data in their repository to a
well-connected server, into an established namespace, while only changing
branches and tags in their namespace. This will allow all users to see the
changes of other users, without needing direct access to their trees (which are
inaccessible behind firewalls). [1]
(b) fetch selected DAG, branch, and tag data of others to their tree, to see
the changes of others (whether merged with head or not) while disconnected or
remote.
(c) grant and enforce permission for certain users to submit _merges only_ onto
certain sub-portions of the "well-named branches"
There are many many benefits of git's mechanisms for this topology, and I
expect you know them so I'll skip them. I see the following challenges from the
current git implementation. Please tell me where I'm mistaken.. this is all
AFAIK, some from tests, some from docs.
(1) A server will need to support the required permissions and isolation
enforcement. Namely, permissions for portions of the branch/tag namespace,
assurance that DAGs are valid, and directory permissions.
(2) a "share" client command will need to be implemented which transmits-up
local changes to only my DAGs, branches, and tags without affecting the shared
origin namespace pointers on the server. It will share all these changes
regardless of what the user's "active" branch is. Local branches might be
mapped to a branch on the server such as origin/users/(username)/(branchname).
Branches which are supposed to stay local might be named "local/branch", and be
ignored by the "share". [1]
(3) a mechanism for controlling permissions (possibly based on checking out and
editing a special subtree, ala cvs)
(4) A mechanism to be sure "share" does not cause users who have permission to
inadvertently move the origin/master branch pointer, even if they are working
on their local master branch. For example, their changes would be named by
origin/users/(username)/master. This is necessary because "share" is the only
way for the firewalled user to make their changes available to others. As a
result, it is imperative that this be separate from a decision to promote their
changes onto the shared origin branch. Currently git-push implies both of these
together. git-share would be to git-push what git-fetch is git-pull. git-push
would continue to be used to tell the system you wish to promote your change to
origin/master. [2]
[1] - "share" permissions can be considered two ways. In the strictly client
server model, the server will only allow the client to change branch pointers
that it owns in the namespace. However, if clients establish their own PGP-keys
or other hash-identity keys with the server, then branch changes may be signed
by clients, and propagate between clients in any direction and order, until
they fully propagate. It's not clear if this additional complexity is worth it.
[2] - it might be reasonable to build a mechanism to allow a local "intent to
promote" preceed a git-share, in which case git-share could safetly
fast-forward the head. However, it's unclear what benefit this has over
git-fetch.
^ permalink raw reply
* policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 0:36 UTC (permalink / raw)
To: git
I'd like to hear feedback and ideas about a different mechanism than is being
used with git-pull or git-push.
The purpose of this mechanism is to host a distributed source repository in a
world where most most developer contributors are behind firewalls and do not
have access to, or do not want to configure a unix server, ftp, or ssh to
possibly contribute to a project. The model of allowing less-authoritative
developers to make their changes available for more-authoritative users to pull
is accepted as superior. However, no users are assumed to be authoritative over
each-other, or an entire tree, and many users should have authority only to
supply new deltas to their own branches. The ability to handle emailed patches
is an asset, but is deemed too manual for this need.
I believe git's design is strong; that many of the mechanisms are already
built; that new mechanisms to build this can be simple; and that with such
mechanisms, many more developers would have access to git's decentralized
development style. Further, it would address drawbacks in today's git relative
to public central version control systems, making this system closer to a 'best
of both worlds'.
design assumptions:
- all developers are firewalled and can not be "pulled" from directly.
- there can be one or more well-connected servers which all users can access.
- .. but which they cannot have ssh, ftp, or other dangerous access to
- .. and whose protocol should be layered on http(s)
- there is a shared namespace for branches, and tags
- .. users are not-trusted to change the branches or tags of other users
- .. only certain users are trusted to change the shared origin branches
- .. also allow directory ACLS on shared branch commits
- all their DAGs should be in a single repository for space efficiency
- users generally want to follow well-named branches
- .. will be free to follow any branch, and pull changes from any branch
I would like to make it easy for users to:
(a) safely "share" every DAG, branch, and tag data in their repository to a
well-connected server, into an established namespace, while only changing
branches and tags in their namespace. This will allow all users to see the
changes of other users, without needing direct access to their trees (which are
inaccessible behind firewalls). [1]
(b) fetch selected DAG, branch, and tag data of others to their tree, to see
the changes of others (whether merged with head or not) while disconnected or
remote.
(c) grant and enforce permission for certain users to submit _merges only_ onto
certain sub-portions of the "well-named branches"
There are many many benefits of git's mechanisms for this topology, and I
expect you know them so I'll skip them. I see the following challenges from the
current git implementation. Please tell me where I'm mistaken.. this is all
AFAIK, some from tests, some from docs.
(1) A server will need to support the required permissions and isolation
enforcement. Namely, permissions for portions of the branch/tag namespace,
assurance that DAGs are valid, and directory permissions.
(2) a "share" client command will need to be implemented which transmits-up
local changes to only my DAGs, branches, and tags without affecting the shared
origin namespace pointers on the server. It will share all these changes
regardless of what the user's "active" branch is. Local branches might be
mapped to a branch on the server such as origin/users/(username)/(branchname).
Branches which are supposed to stay local might be named "local/branch", and be
ignored by the "share". [1]
(3) a mechanism for controlling permissions (possibly based on checking out and
editing a special subtree, ala cvs)
(4) A mechanism to be sure "share" does not cause users who have permission to
inadvertently move the origin/master branch pointer, even if they are working
on their local master branch. For example, their changes would be named by
origin/users/(username)/master. This is necessary because "share" is the only
way for the firewalled user to make their changes available to others. As a
result, it is imperative that this be separate from a decision to promote their
changes onto the shared origin branch. Currently git-push implies both of these
together. git-share would be to git-push what git-fetch is git-pull. git-push
would continue to be used to tell the system you wish to promote your change to
origin/master. [2]
[1] - "share" permissions can be considered two ways. In the strictly client
server model, the server will only allow the client to change branch pointers
that it owns in the namespace. However, if clients establish their own PGP-keys
or other hash-identity keys with the server, then branch changes may be signed
by clients, and propagate between clients in any direction and order, until
they fully propagate. It's not clear if this additional complexity is worth it.
[2] - it might be reasonable to build a mechanism to allow a local "intent to
promote" preceed a git-share, in which case git-share could safetly
fast-forward the head. However, it's unclear what benefit this has over
git-fetch.
^ permalink raw reply
* Re: [PATCH/RFC] Created git-basis and modified git-bundle to accept --stdin.
From: Jakub Narebski @ 2008-06-25 0:21 UTC (permalink / raw)
To: Adam Brewster; +Cc: git
In-Reply-To: <c376da900806241655q85fc1d9r5bf67096a7930f94@mail.gmail.com>
On 6/25/08, Adam Brewster <adam@adambrewster.com> wrote:
>>
>> I was thinking about
>>
>> $ git bundle create my-bundle --all --not $(git ls-remote my-bundle | cut -f1)
>
> Not a bad idea, but it seems like I might be close to the maximum
> length for a command line (about 3200 objects) in a couple of cases
> (git-svn creates lots of branches).
Ah, sorry, I have forgot about that. This is definitely, both in the
case of revisions
packed in bundle, and basis (cutoff) of bundle, case for some kind of --stdin.
> This also means that I have to remember where I save the old bundles.
That's what second solution was to save only bases in some file.
>> Or even
>>
>> $ git ls-remote my-bundle | cut -f1 > my-bases
>> [...]
>> $ git bundle create my-bundle --all --not $(cat my-bases)
>>
>
>
> That's basically all the perl script does, except it will also create
> an intersection of several bases (I don't want to remember the options
> to comm).
Does it prefix bases with ^, i.e. ^basis (negative revision)?
I think it should, then there would be no need for strange --stdin
semantic, or implementing --stdin in such way that --not--stdin
works as expected.
> Now that you mention it, a --basis option in setup_revisions would be
> handy, but if I can't sell this, then I probably can't sell that
> either.
I think that --stdin would be better idea, as it can be used to enumerate
all refs to send, even if they are too many or they have too long names to
use arguments.
[...]
>>> I'll prepare another patch with documentation and changing --stdin to
>>> --revs when I get a chance.
>>
>> I'm not sure if another name, like --bases=<filename / basename> wouldn't
>> be better. Perhaps --stdin is a good name...
>
> On second thought I'm going to defend my choice of --stdin now that I
> remember why I chose it.
>
> The docs for git-bundle specify the syntax is "git-bundle create
> <file> <git-rev-list args>", where <git-rev-list args> is defined as
> "A list of arguments, acceptable to git-rev-parse and git-rev-list,
> that specify the specific objects and references to transport. ..."
> Git-rev-list takes --stdin, so it seems reasonable to expect that
> git-bundle will as well.
Ahh... git-rev-list... well, I though about git-pack-objects and its different
--stin semantic (which might make no sense for git-bundle).
[Sorry for bad wrapping, I'm sending it from GMail Web interface]
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] pre-commit hook should ignore carriage returns at EOL
From: Christian Holtje @ 2008-06-25 0:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vbq1q9zct.fsf@gitster.siamese.dyndns.org>
On Jun 24, 2008, at 7:39 PM, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Christian Holtje <docwhat@gmail.com> writes:
>>
>>> Based on the information about core.whitespace doesn't git do this
>>> already? Maybe we should just delete the pre-commit hook or make it
>>> empty with a note saying what you can do with it?
>>
>> pre-commit hook also detects unresolved merge conflicts, which
>> core.whitespace doesn't (and probably shouldn't).
>
> But perhaps "diff --check" should.
>
definitely; that sounds like an obvious thing for "diff --check".
Ciao!
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2008-06-25 0:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vk5gea0ff.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ah, there is not much we can do in that case then. git-upload-pack is
> what the client asks you to run, and if you do not have it in the path,
> you can (1) either make sure it is on the path, (2) have the client be
> more explicit when asking for git-upload-pack (--upload-pack=$where), or
> (3) leave the minimum git-* binaries that can remotely be launched
> directly in the usual $PATH.
>
> It most likely makes sense to do (3) anyway. upload-pack, receive-pack,
> anything else?
What does "git ls-remote server:/home/vmiklos/git/test" invoke on server?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Windows symlinks
From: Avery Pennarun @ 2008-06-25 0:04 UTC (permalink / raw)
To: Patrick.Higgins@cexp.com; +Cc: jnareb, git
In-Reply-To: <911589C97062424796D53B625CEC0025E46193@USCOBRMFA-SE-70.northamerica.cexp.com>
On 6/24/08, Patrick.Higgins@cexp.com <Patrick.Higgins@cexp.com> wrote:
> Agreed. The first thing we started working on was getting symlinks out of our repositories.
> Unfortunately, we chose to use them because we are using broken development tools that
> don't support proper modularity. We found the best way to get the IDE's compilation to work
> was to symlink shared code into each project. It's a nasty solution, but it was the only one
> that worked. Clearcase made this solution possible. As powerful and flexible as git is, it would
> have left us out in the cold in this situation.
Perhaps git-submodule would do what you're looking for.
Avery
^ permalink raw reply
* Re: [PATCH] pre-commit hook should ignore carriage returns at EOL
From: Junio C Hamano @ 2008-06-24 23:59 UTC (permalink / raw)
To: Christian Holtje; +Cc: git
In-Reply-To: <930163B6-4A7E-49C7-B9D5-F7B37699C2A9@gmail.com>
Christian Holtje <docwhat@gmail.com> writes:
> On Jun 24, 2008, at 6:31 PM, Junio C Hamano wrote:
> ...
>> It's an ancient sample hook that is not be enabled by default. I do
>> not want people to be wasting too much time on the relic.
>
> Part of the reason I'm fixing this is because it *is* enabled by
> default in windows. I don't know why, but cygwin always marks it with
> executable.
That's a packaging issue, and I've always wanted to see fixes related to
platform specific packaging issues come from people who _need_ fixes on
their platforms. I have been waiting forever for that to happen without
complaining to them. I was hoping some enlightened people will emerge
even from Windows camps, waiting patiently.
But I ran out of patience, and I am finally fed up waiting.
How about doing this everywhere, not just on Windows, for 1.6.0?
-- >8 --
[PATCH] Ship sample hooks with .sample suffix
We used to mark hooks we ship as samples by making them unexecutable, but
some filesystems cannot tell what is executable and what is not.
This makes it much more explicit. The hooks are suffixed with .sample
(but now are made executable), so enabling it is still one step operation
(instead of "chmod +x $hook", you would do "mv $hook.sample $hook") but
now they won't get accidentally enabled on systems without executable bit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/githooks.txt | 3 ++-
...applypatch-msg => hooks--applypatch-msg.sample} | 0
...{hooks--commit-msg => hooks--commit-msg.sample} | 0
...ooks--post-commit => hooks--post-commit.sample} | 0
...ks--post-receive => hooks--post-receive.sample} | 0
...ooks--post-update => hooks--post-update.sample} | 0
...pre-applypatch => hooks--pre-applypatch.sample} | 0
...{hooks--pre-commit => hooks--pre-commit.sample} | 0
...{hooks--pre-rebase => hooks--pre-rebase.sample} | 0
...commit-msg => hooks--prepare-commit-msg.sample} | 0
templates/{hooks--update => hooks--update.sample} | 0
11 files changed, 2 insertions(+), 1 deletions(-)
rename templates/{hooks--applypatch-msg => hooks--applypatch-msg.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--commit-msg => hooks--commit-msg.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--post-commit => hooks--post-commit.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--post-receive => hooks--post-receive.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--post-update => hooks--post-update.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--pre-applypatch => hooks--pre-applypatch.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--pre-commit => hooks--pre-commit.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--pre-rebase => hooks--pre-rebase.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--prepare-commit-msg => hooks--prepare-commit-msg.sample} (100%)
mode change 100644 => 100755
rename templates/{hooks--update => hooks--update.sample} (100%)
mode change 100644 => 100755
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 4f06ae0..262a4f1 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -17,7 +17,8 @@ Hooks are little scripts you can place in `$GIT_DIR/hooks`
directory to trigger action at certain points. When
`git-init` is run, a handful example hooks are copied in the
`hooks` directory of the new repository, but by default they are
-all disabled. To enable a hook, make it executable with `chmod +x`.
+all disabled. To enable a hook, rename it by removing its `.sample`
+suffix.
This document describes the currently defined hooks.
diff --git a/templates/hooks--applypatch-msg b/templates/hooks--applypatch-msg.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--applypatch-msg
rename to templates/hooks--applypatch-msg.sample
diff --git a/templates/hooks--commit-msg b/templates/hooks--commit-msg.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--commit-msg
rename to templates/hooks--commit-msg.sample
diff --git a/templates/hooks--post-commit b/templates/hooks--post-commit.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--post-commit
rename to templates/hooks--post-commit.sample
diff --git a/templates/hooks--post-receive b/templates/hooks--post-receive.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--post-receive
rename to templates/hooks--post-receive.sample
diff --git a/templates/hooks--post-update b/templates/hooks--post-update.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--post-update
rename to templates/hooks--post-update.sample
diff --git a/templates/hooks--pre-applypatch b/templates/hooks--pre-applypatch.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--pre-applypatch
rename to templates/hooks--pre-applypatch.sample
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--pre-commit
rename to templates/hooks--pre-commit.sample
diff --git a/templates/hooks--pre-rebase b/templates/hooks--pre-rebase.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--pre-rebase
rename to templates/hooks--pre-rebase.sample
diff --git a/templates/hooks--prepare-commit-msg b/templates/hooks--prepare-commit-msg.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--prepare-commit-msg
rename to templates/hooks--prepare-commit-msg.sample
diff --git a/templates/hooks--update b/templates/hooks--update.sample
old mode 100644
new mode 100755
similarity index 100%
rename from templates/hooks--update
rename to templates/hooks--update.sample
^ permalink raw reply related
* Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: A Large Angry SCM @ 2008-06-24 23:53 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Michael Haggerty, Johannes Schindelin, Jeff King, git
In-Reply-To: <486179C8.2000704@gmail.com>
Lea Wiemann wrote:
> Michael Haggerty wrote:
>> Therefore it should be easy to teach git-bisect to locate either kind of
>> transition, "bad" -> "good" or "good" -> "bad", depending only on where
>> the user places the original "good" and "bad" tags.
>
> I think this is a good suggestion (though I haven't thought things
> through). Another idea is to add "old" and "new" (or something like
> that) as aliases to "good" and "bad", since that's the only semantics
> that the bisect labels actually seem to have.
"Before" and "After" the "Change" maybe?
^ permalink raw reply
* RE: Windows symlinks
From: Patrick.Higgins @ 2008-06-24 23:42 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <m3od5qjtv1.fsf@localhost.localdomain>
> From: Jakub Narebski [mailto:jnareb@gmail.com]
>
> Patrick Higgins <Patrick.Higgins@cexp.com> writes:
>
> Second, the problem there can be _only_ if your repository contains
> (or contained) symlinks, and then it is your own damn fault.
Agreed. The first thing we started working on was getting symlinks out of our repositories. Unfortunately, we chose to use them because we are using broken development tools that don't support proper modularity. We found the best way to get the IDE's compilation to work was to symlink shared code into each project. It's a nasty solution, but it was the only one that worked. Clearcase made this solution possible. As powerful and flexible as git is, it would have left us out in the cold in this situation.
> I don't know how Cygwin, or msysGit deals with symlinks in a wirking
> directory
msysGit just created a file with the target of the symlink as it's contents, but its tools didn't know how to make use of it. I think Cygwin did the same thing, but ls, cat, and all the other Cygwin tools were able to make use of it. I tried to run the Java compiler over a symlinked file and it didn't work, though.
Copying files at build time is an interesting idea, but since the point was to get an IDE's build system to work, I don't I'll have the level of control I would need to make this work.
^ permalink raw reply
* Re: [PATCH] pre-commit hook should ignore carriage returns at EOL
From: Junio C Hamano @ 2008-06-24 23:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Christian Holtje, git
In-Reply-To: <m3k5gejtkp.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Christian Holtje <docwhat@gmail.com> writes:
>
>> Based on the information about core.whitespace doesn't git do this
>> already? Maybe we should just delete the pre-commit hook or make it
>> empty with a note saying what you can do with it?
>
> pre-commit hook also detects unresolved merge conflicts, which
> core.whitespace doesn't (and probably shouldn't).
But perhaps "diff --check" should.
^ permalink raw reply
* Re: [PATCH 1/3] Allow git-apply to ignore the hunk headers (AKA recountdiff)
From: Junio C Hamano @ 2008-06-24 23:35 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <200806242108.16379.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> diff --git a/builtin-apply.c b/builtin-apply.c
> index c497889..34c220f 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -153,6 +153,7 @@ struct patch {
> unsigned int is_binary:1;
> unsigned int is_copy:1;
> unsigned int is_rename:1;
> + unsigned int recount:1;
> struct fragment *fragments;
> char *result;
> size_t resultsize;
Why doesn't anybody find this quite wrong?
What is a "struct patch"? It describes a change to a single file
(i.e. information contained from one "diff --git" til next "diff --git"),
groups the hunks (called "fragments") together and holds the postimage
after applying these hunks. Is this new "recount" field a per file
attribute?
> + fragment->oldpos = 2;
> + fragment->oldlines = fragment->newlines = 0;
Why is this discarding the position information?
It is none of this function's business. The ONLY THING this function
should do is to discard fragment->oldlines and fragment->newlines, count
the contents and update these two fields, and nothing else. Touching
oldpos, leading and other things is an absolute no-no.
> @@ -1013,6 +1058,9 @@ static int parse_fragment(char *line, unsigned long size,
> offset = parse_fragment_header(line, len, fragment);
> if (offset < 0)
> return -1;
> + if (offset > 0 && patch->recount &&
> + recount_diff(line + offset, size - offset, fragment))
> + return -1;
And recount should not cause parse_fragment() to fail out either. If you
miscounted, the codepath that follows this part knows how to handle broken
patch correctly anyway.
I think I've already mentioned the above two points when this was
originally posted.
Somewhat disgusted...
^ 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