Git development
 help / color / mirror / Atom feed
* Re: [PATCH 8/8] Enable GIT_DEBUG_MEMCHECK on git_pathname()
From: Jonathan Nieder @ 2011-11-18  6:52 UTC (permalink / raw)
  To: Johan Herland
  Cc: Nguyen Thai Ngoc Duy, Jeff King, Ramkumar Ramachandra, git,
	Junio C Hamano, Michael Haggerty
In-Reply-To: <CALKQrgfTKmSd8se3n3xq89SXRmNPm3qz3Ckv2mUghot8kStKxA@mail.gmail.com>

Johan Herland wrote:

> Acked-by: Johan Herland <johan@herland.net>

Thanks for looking it over.

^ permalink raw reply

* [PATCH 0/3] bulk-checkin continued
From: Junio C Hamano @ 2011-11-18  7:11 UTC (permalink / raw)
  To: git
In-Reply-To: <1319846051-462-1-git-send-email-gitster@pobox.com>

This updates the earlier bulk-checkin series ($gmane/184440) to further
enhance the "large file" topic from 1.7.6 cycle.

The first one adds two API functions to allow truncating a checksummed
file that is being written. This is the same patch as the one I sent
earlier today.

The second one prevents the bulk-checkin code from writing the same object
twice to the stream, and the third one further makes it notice that the
object it has just written already exists in the repository. In either
case, the packfile is rewound using the new sha1file_checkpoint/truncate
API, and the packfile itself is removed if truncation results in an empty
output.

The next step is to add the "split-blob" entry in the packfile, but that
is a much larger task and will take longer.

Junio C Hamano (3):
  csum-file: introduce sha1file_checkpoint
  bulk-checkin: do not write the same object twice
  bulk-checkin: do not write an object that already exists

 bulk-checkin.c   |   40 +++++++++++++++++++++++++++++++++++-----
 csum-file.c      |   20 ++++++++++++++++++++
 csum-file.h      |    9 +++++++++
 fast-import.c    |   25 ++++++++-----------------
 t/t1050-large.sh |   38 ++++++++++++++++++++++++++++++--------
 5 files changed, 102 insertions(+), 30 deletions(-)

-- 
1.7.8.rc3.111.g7d421

^ permalink raw reply

* [PATCH 2/3] bulk-checkin: do not write the same object twice
From: Junio C Hamano @ 2011-11-18  7:11 UTC (permalink / raw)
  To: git
In-Reply-To: <1321600317-30546-1-git-send-email-gitster@pobox.com>

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 bulk-checkin.c   |   28 ++++++++++++++++++++++++----
 t/t1050-large.sh |   20 +++++++++++++-------
 2 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/bulk-checkin.c b/bulk-checkin.c
index c7e693e..82166ba 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -52,6 +52,17 @@ static void finish_bulk_checkin(struct bulk_checkin_state *state)
 	reprepare_packed_git();
 }
 
+static int already_written(struct bulk_checkin_state *state, unsigned char sha1[])
+{
+	int i;
+
+	/* Might want to keep the list sorted */
+	for (i = 0; i < state->nr_written; i++)
+		if (!hashcmp(state->written[i]->sha1, sha1))
+			return 1;
+	return 0;
+}
+
 static void deflate_to_pack(struct bulk_checkin_state *state,
 			    unsigned char sha1[],
 			    int fd, size_t size, enum object_type type,
@@ -64,6 +75,7 @@ static void deflate_to_pack(struct bulk_checkin_state *state,
 	int write_object = (flags & HASH_WRITE_OBJECT);
 	int status = Z_OK;
 	struct pack_idx_entry *idx = NULL;
+	struct sha1file_checkpoint checkpoint;
 
 	hdrlen = sprintf((char *)obuf, "%s %" PRIuMAX,
 			 typename(type), (uintmax_t)size) + 1;
@@ -73,6 +85,7 @@ static void deflate_to_pack(struct bulk_checkin_state *state,
 	if (write_object) {
 		idx = xcalloc(1, sizeof(*idx));
 		idx->offset = state->offset;
+		sha1file_checkpoint(state->f, &checkpoint);
 		crc32_begin(state->f);
 	}
 	memset(&s, 0, sizeof(s));
@@ -121,10 +134,17 @@ static void deflate_to_pack(struct bulk_checkin_state *state,
 	git_SHA1_Final(sha1, &ctx);
 	if (write_object) {
 		idx->crc32 = crc32_end(state->f);
-		hashcpy(idx->sha1, sha1);
-		ALLOC_GROW(state->written,
-			   state->nr_written + 1, state->alloc_written);
-		state->written[state->nr_written++] = idx;
+
+		if (already_written(state, sha1)) {
+			sha1file_truncate(state->f, &checkpoint);
+			state->offset = checkpoint.offset;
+			free(idx);
+		} else {
+			hashcpy(idx->sha1, sha1);
+			ALLOC_GROW(state->written,
+				   state->nr_written + 1, state->alloc_written);
+			state->written[state->nr_written++] = idx;
+		}
 	}
 }
 
diff --git a/t/t1050-large.sh b/t/t1050-large.sh
index 36def25..fbd5ced 100755
--- a/t/t1050-large.sh
+++ b/t/t1050-large.sh
@@ -7,22 +7,28 @@ test_description='adding and checking out large blobs'
 
 test_expect_success setup '
 	git config core.bigfilethreshold 200k &&
-	echo X | dd of=large bs=1k seek=2000 &&
+	echo X | dd of=large1 bs=1k seek=2000 &&
+	echo X | dd of=large2 bs=1k seek=2000 &&
 	echo Y | dd of=huge bs=1k seek=2500
 '
 
 test_expect_success 'add a large file or two' '
-	git add large huge &&
+	git add large1 huge large2 &&
 	# make sure we got a single packfile and no loose objects
-	bad= count=0 &&
+	bad= count=0 idx= &&
 	for p in .git/objects/pack/pack-*.pack
 	do
 		count=$(( $count + 1 ))
-		test -f "$p" && continue
+		if test -f "$p" && idx=${p%.pack}.idx && test -f "$idx"
+		then
+			continue
+		fi
 		bad=t
 	done &&
 	test -z "$bad" &&
 	test $count = 1 &&
+	cnt=$(git show-index <"$idx" | wc -l) &&
+	test $cnt = 2 &&
 	for l in .git/objects/??/??????????????????????????????????????
 	do
 		test -f "$l" || continue
@@ -32,10 +38,10 @@ test_expect_success 'add a large file or two' '
 '
 
 test_expect_success 'checkout a large file' '
-	large=$(git rev-parse :large) &&
-	git update-index --add --cacheinfo 100644 $large another &&
+	large1=$(git rev-parse :large1) &&
+	git update-index --add --cacheinfo 100644 $large1 another &&
 	git checkout another &&
-	cmp large another ;# this must not be test_cmp
+	cmp large1 another ;# this must not be test_cmp
 '
 
 test_done
-- 
1.7.8.rc3.111.g7d421

^ permalink raw reply related

* [PATCH 1/3] csum-file: introduce sha1file_checkpoint
From: Junio C Hamano @ 2011-11-18  7:11 UTC (permalink / raw)
  To: git
In-Reply-To: <1321600317-30546-1-git-send-email-gitster@pobox.com>

It is useful to be able to rewind a check-summed file to a certain
previous state after writing data into it using sha1write() API. The
fast-import command does this after streaming a blob data to the packfile
being generated and then noticing that the same blob has already been
written, and it does this with a private code truncate_pack() that is
commented as "Yes, this is a layering violation".

Introduce two API functions, sha1file_checkpoint(), that allows the caller
to save a state of a sha1file, and then later revert it to the saved state.
Use it to reimplement truncate_pack().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 csum-file.c   |   20 ++++++++++++++++++++
 csum-file.h   |    9 +++++++++
 fast-import.c |   25 ++++++++-----------------
 3 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/csum-file.c b/csum-file.c
index fc97d6e..53f5375 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -158,6 +158,26 @@ struct sha1file *sha1fd_throughput(int fd, const char *name, struct progress *tp
 	return f;
 }
 
+void sha1file_checkpoint(struct sha1file *f, struct sha1file_checkpoint *checkpoint)
+{
+	sha1flush(f);
+	checkpoint->offset = f->total;
+	checkpoint->ctx = f->ctx;
+}
+
+int sha1file_truncate(struct sha1file *f, struct sha1file_checkpoint *checkpoint)
+{
+	off_t offset = checkpoint->offset;
+
+	if (ftruncate(f->fd, offset) ||
+	    lseek(f->fd, offset, SEEK_SET) != offset)
+		return -1;
+	f->total = offset;
+	f->ctx = checkpoint->ctx;
+	f->offset = 0; /* sha1flush() was called in checkpoint */
+	return 0;
+}
+
 void crc32_begin(struct sha1file *f)
 {
 	f->crc32 = crc32(0, NULL, 0);
diff --git a/csum-file.h b/csum-file.h
index 6a7967c..3b540bd 100644
--- a/csum-file.h
+++ b/csum-file.h
@@ -17,6 +17,15 @@ struct sha1file {
 	unsigned char buffer[8192];
 };
 
+/* Checkpoint */
+struct sha1file_checkpoint {
+	off_t offset;
+	git_SHA_CTX ctx;
+};
+
+extern void sha1file_checkpoint(struct sha1file *, struct sha1file_checkpoint *);
+extern int sha1file_truncate(struct sha1file *, struct sha1file_checkpoint *);
+
 /* sha1close flags */
 #define CSUM_CLOSE	1
 #define CSUM_FSYNC	2
diff --git a/fast-import.c b/fast-import.c
index 8d8ea3c..a8db41b 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1143,17 +1143,11 @@ static int store_object(
 	return 0;
 }
 
-static void truncate_pack(off_t to, git_SHA_CTX *ctx)
+static void truncate_pack(struct sha1file_checkpoint *checkpoint)
 {
-	if (ftruncate(pack_data->pack_fd, to)
-	 || lseek(pack_data->pack_fd, to, SEEK_SET) != to)
+	if (sha1file_truncate(pack_file, checkpoint))
 		die_errno("cannot truncate pack to skip duplicate");
-	pack_size = to;
-
-	/* yes this is a layering violation */
-	pack_file->total = to;
-	pack_file->offset = 0;
-	pack_file->ctx = *ctx;
+	pack_size = checkpoint->offset;
 }
 
 static void stream_blob(uintmax_t len, unsigned char *sha1out, uintmax_t mark)
@@ -1166,8 +1160,8 @@ static void stream_blob(uintmax_t len, unsigned char *sha1out, uintmax_t mark)
 	unsigned long hdrlen;
 	off_t offset;
 	git_SHA_CTX c;
-	git_SHA_CTX pack_file_ctx;
 	git_zstream s;
+	struct sha1file_checkpoint checkpoint;
 	int status = Z_OK;
 
 	/* Determine if we should auto-checkpoint. */
@@ -1175,11 +1169,8 @@ static void stream_blob(uintmax_t len, unsigned char *sha1out, uintmax_t mark)
 		|| (pack_size + 60 + len) < pack_size)
 		cycle_packfile();
 
-	offset = pack_size;
-
-	/* preserve the pack_file SHA1 ctx in case we have to truncate later */
-	sha1flush(pack_file);
-	pack_file_ctx = pack_file->ctx;
+	sha1file_checkpoint(pack_file, &checkpoint);
+	offset = checkpoint.offset;
 
 	hdrlen = snprintf((char *)out_buf, out_sz, "blob %" PRIuMAX, len) + 1;
 	if (out_sz <= hdrlen)
@@ -1245,14 +1236,14 @@ static void stream_blob(uintmax_t len, unsigned char *sha1out, uintmax_t mark)
 
 	if (e->idx.offset) {
 		duplicate_count_by_type[OBJ_BLOB]++;
-		truncate_pack(offset, &pack_file_ctx);
+		truncate_pack(&checkpoint);
 
 	} else if (find_sha1_pack(sha1, packed_git)) {
 		e->type = OBJ_BLOB;
 		e->pack_id = MAX_PACK_ID;
 		e->idx.offset = 1; /* just not zero! */
 		duplicate_count_by_type[OBJ_BLOB]++;
-		truncate_pack(offset, &pack_file_ctx);
+		truncate_pack(&checkpoint);
 
 	} else {
 		e->depth = 0;
-- 
1.7.8.rc3.111.g7d421

^ permalink raw reply related

* [PATCH 3/3] bulk-checkin: do not write an object that already exists
From: Junio C Hamano @ 2011-11-18  7:11 UTC (permalink / raw)
  To: git
In-Reply-To: <1321600317-30546-1-git-send-email-gitster@pobox.com>

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 bulk-checkin.c   |   12 +++++++++++-
 t/t1050-large.sh |   18 +++++++++++++++++-
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/bulk-checkin.c b/bulk-checkin.c
index 82166ba..60178ef 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -29,7 +29,11 @@ static void finish_bulk_checkin(struct bulk_checkin_state *state)
 	if (!state->f)
 		return;
 
-	if (state->nr_written == 1) {
+	if (state->nr_written == 0) {
+		close(state->f->fd);
+		unlink(state->pack_tmp_name);
+		goto clear_exit;
+	} else if (state->nr_written == 1) {
 		sha1close(state->f, sha1, CSUM_FSYNC);
 	} else {
 		int fd = sha1close(state->f, sha1, 0);
@@ -45,6 +49,8 @@ static void finish_bulk_checkin(struct bulk_checkin_state *state)
 			    &state->pack_idx_opts, sha1);
 	for (i = 0; i < state->nr_written; i++)
 		free(state->written[i]);
+
+clear_exit:
 	free(state->written);
 	memset(state, 0, sizeof(*state));
 
@@ -56,6 +62,10 @@ static int already_written(struct bulk_checkin_state *state, unsigned char sha1[
 {
 	int i;
 
+	/* The object may already exist in the repository */
+	if (has_sha1_file(sha1))
+		return 1;
+
 	/* Might want to keep the list sorted */
 	for (i = 0; i < state->nr_written; i++)
 		if (!hashcmp(state->written[i]->sha1, sha1))
diff --git a/t/t1050-large.sh b/t/t1050-large.sh
index fbd5ced..0726472 100755
--- a/t/t1050-large.sh
+++ b/t/t1050-large.sh
@@ -9,6 +9,7 @@ test_expect_success setup '
 	git config core.bigfilethreshold 200k &&
 	echo X | dd of=large1 bs=1k seek=2000 &&
 	echo X | dd of=large2 bs=1k seek=2000 &&
+	echo X | dd of=large3 bs=1k seek=2000 &&
 	echo Y | dd of=huge bs=1k seek=2500
 '
 
@@ -34,7 +35,22 @@ test_expect_success 'add a large file or two' '
 		test -f "$l" || continue
 		bad=t
 	done &&
-	test -z "$bad"
+	test -z "$bad" &&
+
+	# attempt to add another copy of the same
+	git add large3 &&
+	bad= count=0 &&
+	for p in .git/objects/pack/pack-*.pack
+	do
+		count=$(( $count + 1 ))
+		if test -f "$p" && idx=${p%.pack}.idx && test -f "$idx"
+		then
+			continue
+		fi
+		bad=t
+	done &&
+	test -z "$bad" &&
+	test $count = 1
 '
 
 test_expect_success 'checkout a large file' '
-- 
1.7.8.rc3.111.g7d421

^ permalink raw reply related

* Re: [PATCH 8/8] Enable GIT_DEBUG_MEMCHECK on git_pathname()
From: Junio C Hamano @ 2011-11-18  7:35 UTC (permalink / raw)
  To: Johan Herland
  Cc: Jonathan Nieder, Nguyen Thai Ngoc Duy, Jeff King,
	Ramkumar Ramachandra, git, Junio C Hamano, Michael Haggerty
In-Reply-To: <CALKQrgfTKmSd8se3n3xq89SXRmNPm3qz3Ckv2mUghot8kStKxA@mail.gmail.com>

Thanks, both. Will queue.

^ permalink raw reply

* [PATCH v2] Makefile: add option to disable automatic dependency generation
From: Jonathan Nieder @ 2011-11-18  9:58 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, Git Mailing List, Fredrik Kuivinen
In-Reply-To: <7vty62klg9.fsf@alter.siamese.dyndns.org>

Now that the COMPUTE_HEADER_DEPENDENCIES feature is turned on
automatically for compilers that support it (see v1.7.8-rc0~142^2~1,
2011-08-18), there is no easy way to force it off.  For example,
setting COMPUTE_HEADER_DEPENDENCIES to the empty string in config.mak
just tells the makefile to treat it as undefined and run a test
command to see if the -MMD option is supported.

So allow setting COMPUTE_HEADER_DEPENDENCIES=no to explicitly force
the feature off.  The new semantics:

 - "yes" means to explicitly enable the feature
 - "no" means to disable it
 - "auto" means to autodetect

The default is still "auto".  Any value other than these three will
cause the build to error out with a descriptive message so typos and
stale settings in config.mak don't result in mysterious behavior.

	Makefile:1278: *** please set COMPUTE_HEADER_DEPENDENCIES to
	yes, no, or auto (not "1").  Stop.

So now when someone using a compiler without -MMD support reports
trouble building git, you can reproduce it by running "make
COMPUTE_HEADER_DEPENDENCIES=no".

Suggested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:

> Eek. At least at the end user UI level, couldn't we do this as a tristate?

Nice idea.  Here it is.

 Makefile |   31 ++++++++++++++++++++++++-------
 1 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index 34ac7957..b1c80a67 100644
--- a/Makefile
+++ b/Makefile
@@ -250,6 +250,12 @@ all::
 #   DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR',
 #   DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork'
 #
+# Define COMPUTE_HEADER_DEPENDENCIES to "yes" if you want dependencies on
+# header files to be automatically computed, to avoid rebuilding objects when
+# an unrelated header file changes.  Define it to "no" to use the hard-coded
+# dependency rules.  The default is "auto", which means to use computed header
+# dependencies if your compiler is detected to support it.
+#
 # Define CHECK_HEADER_DEPENDENCIES to check for problems in the hard-coded
 # dependency rules.
 #
@@ -1246,21 +1252,32 @@ endif
 endif
 
 ifdef CHECK_HEADER_DEPENDENCIES
-COMPUTE_HEADER_DEPENDENCIES =
+COMPUTE_HEADER_DEPENDENCIES = no
 USE_COMPUTED_HEADER_DEPENDENCIES =
-else
+endif
+
 ifndef COMPUTE_HEADER_DEPENDENCIES
+COMPUTE_HEADER_DEPENDENCIES = auto
+endif
+
+ifeq ($(COMPUTE_HEADER_DEPENDENCIES),auto)
 dep_check = $(shell $(CC) $(ALL_CFLAGS) \
 	-c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
 	echo $$?)
 ifeq ($(dep_check),0)
-COMPUTE_HEADER_DEPENDENCIES=YesPlease
-endif
+override COMPUTE_HEADER_DEPENDENCIES = yes
+else
+override COMPUTE_HEADER_DEPENDENCIES = no
 endif
 endif
 
-ifdef COMPUTE_HEADER_DEPENDENCIES
+ifeq ($(COMPUTE_HEADER_DEPENDENCIES),yes)
 USE_COMPUTED_HEADER_DEPENDENCIES = YesPlease
+else
+ifneq ($(COMPUTE_HEADER_DEPENDENCIES),no)
+$(error please set COMPUTE_HEADER_DEPENDENCIES to yes, no, or auto \
+(not "$(COMPUTE_HEADER_DEPENDENCIES)"))
+endif
 endif
 
 ifdef SANE_TOOL_PATH
@@ -1907,7 +1924,7 @@ OBJECTS := $(GIT_OBJS) $(XDIFF_OBJS) $(VCSSVN_OBJS)
 dep_files := $(foreach f,$(OBJECTS),$(dir $f).depend/$(notdir $f).d)
 dep_dirs := $(addsuffix .depend,$(sort $(dir $(OBJECTS))))
 
-ifdef COMPUTE_HEADER_DEPENDENCIES
+ifeq ($(COMPUTE_HEADER_DEPENDENCIES),yes)
 $(dep_dirs):
 	@mkdir -p $@
 
@@ -1920,7 +1937,7 @@ Please unset CHECK_HEADER_DEPENDENCIES and try again)
 endif
 endif
 
-ifndef COMPUTE_HEADER_DEPENDENCIES
+ifneq ($(COMPUTE_HEADER_DEPENDENCIES),yes)
 ifndef CHECK_HEADER_DEPENDENCIES
 dep_dirs =
 missing_dep_dirs =
-- 
1.7.8.rc2

^ permalink raw reply related

* [PATCH] Makefile: add missing header file dependencies
From: Jonathan Nieder @ 2011-11-18 10:02 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, Git Mailing List, Fredrik Kuivinen
In-Reply-To: <20111118095820.GF25145@elie.hsd1.il.comcast.net>

When the streaming filter API was introduced in v1.7.7-rc0~60^2~7
(2011-05-20), we forgot to add its header to LIB_H.  Most translation
units depend on streaming.h via cache.h.

v1.7.5-rc0~48 (Fix sparse warnings, 2011-03-22) introduced undeclared
dependencies by url.o on url.h and thread-utils.o on thread-utils.h.

Noticed by make CHECK_HEADER_DEPENDENCIES=1.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Some makefile buglets found while testing.

 Makefile |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index ee34eab8..34ac7957 100644
--- a/Makefile
+++ b/Makefile
@@ -518,6 +518,7 @@ LIB_H += compat/win32/syslog.h
 LIB_H += compat/win32/poll.h
 LIB_H += compat/win32/dirent.h
 LIB_H += connected.h
+LIB_H += convert.h
 LIB_H += csum-file.h
 LIB_H += decorate.h
 LIB_H += delta.h
@@ -2009,13 +2010,13 @@ builtin/branch.o builtin/checkout.o builtin/clone.o builtin/reset.o branch.o tra
 builtin/bundle.o bundle.o transport.o: bundle.h
 builtin/bisect--helper.o builtin/rev-list.o bisect.o: bisect.h
 builtin/clone.o builtin/fetch-pack.o transport.o: fetch-pack.h
-builtin/grep.o builtin/pack-objects.o transport-helper.o: thread-utils.h
+builtin/grep.o builtin/pack-objects.o transport-helper.o thread-utils.o: thread-utils.h
 builtin/send-pack.o transport.o: send-pack.h
 builtin/log.o builtin/shortlog.o: shortlog.h
 builtin/prune.o builtin/reflog.o reachable.o: reachable.h
 builtin/commit.o builtin/revert.o wt-status.o: wt-status.h
 builtin/tar-tree.o archive-tar.o: tar.h
-connect.o transport.o http-backend.o: url.h
+connect.o transport.o url.o http-backend.o: url.h
 http-fetch.o http-walker.o remote-curl.o transport.o walker.o: walker.h
 http.o http-walker.o http-push.o http-fetch.o remote-curl.o: http.h url.h
 
-- 
1.7.8.rc2

^ permalink raw reply related

* Re: [PATCH v2] Makefile: add option to disable automatic dependency generation
From: Nguyen Thai Ngoc Duy @ 2011-11-18 10:07 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Junio C Hamano, Git Mailing List, Fredrik Kuivinen
In-Reply-To: <20111118095820.GF25145@elie.hsd1.il.comcast.net>

On Fri, Nov 18, 2011 at 4:58 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Now that the COMPUTE_HEADER_DEPENDENCIES feature is turned on
> automatically for compilers that support it (see v1.7.8-rc0~142^2~1,
> 2011-08-18), there is no easy way to force it off.  For example,
> setting COMPUTE_HEADER_DEPENDENCIES to the empty string in config.mak
> just tells the makefile to treat it as undefined and run a test
> command to see if the -MMD option is supported.
>
> So allow setting COMPUTE_HEADER_DEPENDENCIES=no to explicitly force
> the feature off.  The new semantics:
>
>  - "yes" means to explicitly enable the feature
>  - "no" means to disable it
>  - "auto" means to autodetect
>
> The default is still "auto".  Any value other than these three will
> cause the build to error out with a descriptive message so typos and
> stale settings in config.mak don't result in mysterious behavior.
>
>        Makefile:1278: *** please set COMPUTE_HEADER_DEPENDENCIES to
>        yes, no, or auto (not "1").  Stop.
>
> So now when someone using a compiler without -MMD support reports
> trouble building git, you can reproduce it by running "make
> COMPUTE_HEADER_DEPENDENCIES=no".
>
> Suggested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> Improved-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

Tested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
-- 
Duy

^ permalink raw reply

* Re: [PATCH] receive-pack, fetch-pack: reject bogus pack that records objects twice
From: Jeff King @ 2011-11-18 10:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7v7h2znv36.fsf@alter.siamese.dyndns.org>

On Wed, Nov 16, 2011 at 10:04:13PM -0800, Junio C Hamano wrote:

> When receive-pack & fetch-pack are run and store the pack obtained over
> the wire to a local repository, they internally run the index-pack command
> with the --strict option. Make sure that we reject incoming packfile that
> records objects twice to avoid spreading such a damage.

If we are fixing a thin pack (which should be the case most of the
time), we are rewriting the packfile anyway. Shouldn't we just omit
the duplicate?

I guess I'm a little confused about what is generating these duplicates.
A buggy git? A malicious server? Bad luck?

-Peff

^ permalink raw reply

* Fixing a broken GIT repo
From: Bart van den Burg @ 2011-11-18 10:54 UTC (permalink / raw)
  To: git

Hi

I somehow managed to break my GIT repo. Whenever I try to clone or fetch 
from a clean local repo, I get an error.

I'm able to go back on the server, to the very last commit where 
everything works, but as soon as I make a change locally and push it, it 
breaks again. I've been trying to figure out what's wrong here for about 
two days now, but I'm completely lost.

Here's the steps I take to reproduce the problem.

On the server, I can reset the ref to the last working commit:

git@server:~/shifter_rai.git$ echo 
"cc5693a275c25003edc77b59f5a5c603a857f711" > refs/heads/master

Then, on my local computer, I can clone fine, but after making a commit, 
it breaks again:

bbu@SIT-WST-05 /d/workspace9
$ git clone git@git.samson-it.nl:/home/git/shifter_rai
Cloning into shifter_rai...
remote: Counting objects: 9557, done.
remote: Compressing objects: 100% (1887/1887), done.
remote: Total 9557 (delta 7107), reused 9397 (delta 7019)
Receiving objects: 100% (9557/9557), 2.85 MiB | 1.06 MiB/s, done.
Resolving deltas: 100% (7107/7107), done.

bbu@SIT-WST-05 /d/workspace9
$ cd shifter_rai/

bbu@SIT-WST-05 /d/workspace9/shifter_rai (master)
$ echo "test" > test

bbu@SIT-WST-05 /d/workspace9/shifter_rai (master)
$ git add test
warning: LF will be replaced by CRLF in test.
The file will have its original line endings in your working directory.

bbu@SIT-WST-05 /d/workspace9/shifter_rai (master)
$ git commit
[master 85d1ee9] test
warning: LF will be replaced by CRLF in test.
The file will have its original line endings in your working directory.
  1 files changed, 1 insertions(+), 0 deletions(-)
  create mode 100644 test

bbu@SIT-WST-05 /d/workspace9/shifter_rai (master)
$ git push
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 271 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@git.samson-it.nl:/home/git/shifter_rai
    cc5693a..85d1ee9  master -> master

bbu@SIT-WST-05 /d/workspace9/shifter_rai (master)
$ cd ..

bbu@SIT-WST-05 /d/workspace9
$ rm -rf shifter_rai/

bbu@SIT-WST-05 /d/workspace9
$ git clone git@git.samson-it.nl:/home/git/shifter_rai
Cloning into shifter_rai...
remote: Counting objects: 9557, done.
remote: Compressing objects: 100% (1887/1887), done.
remote: Total 9557 (delta 7107), reused 9397 (delta 7019)
Receiving objects: 100% (9557/9557), 2.85 MiB | 1.16 MiB/s, done.
Resolving deltas: 100% (7107/7107), done.
error: refs/remotes/origin/master does not point to a valid object!
error: Trying to write ref refs/heads/master with nonexistant object 
85d1ee957c65485ed9c937a4f1bfdd44fda4ea35
fatal: Cannot update the ref 'HEAD'.

Needless to say, the mentioned object in fact does exist on the server:
git@server:~/shifter_rai.git$ ls -la 
objects/85/d1ee957c65485ed9c937a4f1bfdd44fda4ea35
-r--r--r-- 1 git git 153 Nov 18 11:39 
objects/85/d1ee957c65485ed9c937a4f1bfdd44fda4ea35

Can anyone tell me what is happening here, and how I can fix it?

^ permalink raw reply

* Re: [PATCH 4/4] refresh_index: notice typechanges in output
From: Jeff King @ 2011-11-18 11:09 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20111115020506.GA6305@sigill.intra.peff.net>

On Mon, Nov 14, 2011 at 09:05:06PM -0500, Jeff King wrote:

> Do you want to add your patch on top, or do you want me to re-roll with
> this squashed in? I can also hold the re-roll until post-release if you
> want.

You mentioned squashing in the "what's cooking" message. Rather than
squashing just the typechange bits, how about this re-roll, which I
think is a little easier to follow:

  [1/3]: read-cache: let refresh_cache_ent pass up changed flags
  [2/3]: refresh_index: rename format variables
  [3/3]: refresh_index: make porcelain output more specific

-Peff

^ permalink raw reply

* [PATCHv2 1/3] read-cache: let refresh_cache_ent pass up changed flags
From: Jeff King @ 2011-11-18 11:11 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20111118110938.GA5940@sigill.intra.peff.net>

This will enable refresh_cache to differentiate more cases
of modification (such as typechange) when telling the user
what isn't fresh.

Signed-off-by: Jeff King <peff@peff.net>
---
Same as 3/4 from my v1 series.

 read-cache.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index 5790a91..8e69ea3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1001,7 +1001,8 @@ int add_index_entry(struct index_state *istate, struct cache_entry *ce, int opti
  */
 static struct cache_entry *refresh_cache_ent(struct index_state *istate,
 					     struct cache_entry *ce,
-					     unsigned int options, int *err)
+					     unsigned int options, int *err,
+					     int *changed_ret)
 {
 	struct stat st;
 	struct cache_entry *updated;
@@ -1033,6 +1034,8 @@ int add_index_entry(struct index_state *istate, struct cache_entry *ce, int opti
 	}
 
 	changed = ie_match_stat(istate, ce, &st, options);
+	if (changed_ret)
+		*changed_ret = changed;
 	if (!changed) {
 		/*
 		 * The path is unchanged.  If we were told to ignore
@@ -1130,7 +1133,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 		if (pathspec && !match_pathspec(pathspec, ce->name, strlen(ce->name), 0, seen))
 			continue;
 
-		new = refresh_cache_ent(istate, ce, options, &cache_errno);
+		new = refresh_cache_ent(istate, ce, options, &cache_errno, NULL);
 		if (new == ce)
 			continue;
 		if (!new) {
@@ -1157,7 +1160,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 
 static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really)
 {
-	return refresh_cache_ent(&the_index, ce, really, NULL);
+	return refresh_cache_ent(&the_index, ce, really, NULL, NULL);
 }
 
 static int verify_hdr(struct cache_header *hdr, unsigned long size)
-- 
1.7.7.3.8.g38efa

^ permalink raw reply related

* [PATCHv2 2/3] refresh_index: rename format variables
From: Jeff King @ 2011-11-18 11:11 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20111118110938.GA5940@sigill.intra.peff.net>

When refreshing the index, for modified (or unmerged) files
we will print "needs update" (or "needs merge") for plumbing,
or a "diff --name-status"-ish line for porcelain.

The variables holding which type of message to show are
named after the plumbing messages. However, as we begin to
differentiate more cases at the porcelain level (with the
plumbing message stayin the same), that naming scheme will
become awkward.

Instead, name the variables after which case we found
(modified or unmerged), not what we will output.

Signed-off-by: Jeff King <peff@peff.net>
---
Same as 1/4 from my v1 series.

 read-cache.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index 8e69ea3..f19b2f1 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1105,11 +1105,11 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 	int first = 1;
 	int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
 	unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
-	const char *needs_update_fmt;
-	const char *needs_merge_fmt;
+	const char *modified_fmt;
+	const char *unmerged_fmt;
 
-	needs_update_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
-	needs_merge_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
+	modified_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
+	unmerged_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
 	for (i = 0; i < istate->cache_nr; i++) {
 		struct cache_entry *ce, *new;
 		int cache_errno = 0;
@@ -1125,7 +1125,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 			i--;
 			if (allow_unmerged)
 				continue;
-			show_file(needs_merge_fmt, ce->name, in_porcelain, &first, header_msg);
+			show_file(unmerged_fmt, ce->name, in_porcelain, &first, header_msg);
 			has_errors = 1;
 			continue;
 		}
@@ -1148,7 +1148,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 			}
 			if (quiet)
 				continue;
-			show_file(needs_update_fmt, ce->name, in_porcelain, &first, header_msg);
+			show_file(modified_fmt, ce->name, in_porcelain, &first, header_msg);
 			has_errors = 1;
 			continue;
 		}
-- 
1.7.7.3.8.g38efa

^ permalink raw reply related

* [PATCH 3/3] refresh_index: make porcelain output more specific
From: Jeff King @ 2011-11-18 11:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20111118110938.GA5940@sigill.intra.peff.net>

If you have a deleted file and a porcelain refreshes the
cache, we print:

  Unstaged changes after reset:
  M	file

This is technically correct, in that the file is modified,
but it's friendlier to the user if we further differentiate
the case of a deleted file (especially because this output
looks a lot like "diff --name-status", which would also make
the distinction).

Similarly, we can distinguish typechanges ("T") and
intent-to-add files ("A"), both of which appear as just "M"
in the current output.

The plumbing output for all cases remains "needs update" for
historical compatibility.

Signed-off-by: Jeff King <peff@peff.net>
---
This is my deletion and typechange patches squashed together with your
intent-to-add, and using an if/else series instead of the ternary
operator, as you did.

 read-cache.c |   23 +++++++++++++++++++++--
 1 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index f19b2f1..27e9fc6 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1106,13 +1106,20 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 	int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
 	unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
 	const char *modified_fmt;
+	const char *deleted_fmt;
+	const char *typechange_fmt;
+	const char *added_fmt;
 	const char *unmerged_fmt;
 
 	modified_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
+	deleted_fmt = (in_porcelain ? "D\t%s\n" : "%s: needs update\n");
+	typechange_fmt = (in_porcelain ? "T\t%s\n" : "%s needs update\n");
+	added_fmt = (in_porcelain ? "A\t%s\n" : "%s needs update\n");
 	unmerged_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
 	for (i = 0; i < istate->cache_nr; i++) {
 		struct cache_entry *ce, *new;
 		int cache_errno = 0;
+		int changed = 0;
 
 		ce = istate->cache[i];
 		if (ignore_submodules && S_ISGITLINK(ce->ce_mode))
@@ -1133,10 +1140,12 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 		if (pathspec && !match_pathspec(pathspec, ce->name, strlen(ce->name), 0, seen))
 			continue;
 
-		new = refresh_cache_ent(istate, ce, options, &cache_errno, NULL);
+		new = refresh_cache_ent(istate, ce, options, &cache_errno, &changed);
 		if (new == ce)
 			continue;
 		if (!new) {
+			const char *fmt;
+
 			if (not_new && cache_errno == ENOENT)
 				continue;
 			if (really && cache_errno == EINVAL) {
@@ -1148,7 +1157,17 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
 			}
 			if (quiet)
 				continue;
-			show_file(modified_fmt, ce->name, in_porcelain, &first, header_msg);
+
+			if (cache_errno == ENOENT)
+				fmt = deleted_fmt;
+			else if (ce->ce_flags & CE_INTENT_TO_ADD)
+				fmt = added_fmt; /* must be before other checks */
+			else if (changed & TYPE_CHANGED)
+				fmt = typechange_fmt;
+			else
+				fmt = modified_fmt;
+			show_file(fmt,
+				  ce->name, in_porcelain, &first, header_msg);
 			has_errors = 1;
 			continue;
 		}
-- 
1.7.7.3.8.g38efa

^ permalink raw reply related

* Re: A flaw in dep generation with gcc -MMD?
From: Nguyen Thai Ngoc Duy @ 2011-11-18 11:34 UTC (permalink / raw)
  To: Miles Bader; +Cc: Jonathan Nieder, Git Mailing List
In-Reply-To: <buor516m3w7.fsf@dhlpc061.dev.necel.com>

On Fri, Nov 18, 2011 at 11:49 AM, Miles Bader <miles@gnu.org> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>> Interesting.  What compiler do you use?
>>
>> $ gcc --version
>> gcc (Gentoo 4.4.4-r2 p1.2, pie-0.4.5) 4.4.4
>
> FWIW, gcc 4.4.6 on debian does the correct thing too...
>

OK it's not gcc problem. I upgraded to 4.5.3 and still had the same
problem. I used ccache though. Without ccache, gcc produced correct
.o.d files.
-- 
Duy

^ permalink raw reply

* Re: [PATCH] honour GIT_ASKPASS for querying username in git-svn
From: Erik Faye-Lund @ 2011-11-18 11:36 UTC (permalink / raw)
  To: Sven Strickroth; +Cc: git, gitster
In-Reply-To: <4EC52508.9070907@tu-clausthal.de>

On Thu, Nov 17, 2011 at 4:15 PM, Sven Strickroth
<sven.strickroth@tu-clausthal.de> wrote:
> From 8e576705ca949c32ff22d3216006073ee70652eb Mon Sep 17 00:00:00 2001
> From: Sven Strickroth <email@cs-ware.de>
> Date: Thu, 17 Nov 2011 15:43:25 +0100
> Subject: [PATCH 1/2] honour GIT_ASKPASS for querying username
>
> git-svn reads usernames from an interactive terminal.
> This behavior cause GUIs to hang waiting for git-svn to
> complete (http://code.google.com/p/tortoisegit/issues/detail?id=967).
>
> Also see commit 56a853b62c0ae7ebaad0a7a0a704f5ef561eb795.
>
> Signed-off-by: Sven Strickroth <email@cs-ware.de>

IIUC, GIT_ASKPASS is intended for passwords and not usernames. Won't
this cause console-users to not see their username prompted anymore?

^ permalink raw reply

* Re: [RFC/PATCH] i18n: add infrastructure for translating Git with gettext
From: Ævar Arnfjörð Bjarmason @ 2011-11-18 12:29 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7v39dmmj8k.fsf@alter.siamese.dyndns.org>

On Fri, Nov 18, 2011 at 00:17, Junio C Hamano <gitster@pobox.com> wrote:
> Just an extremely minor issue, but a few things seem to seep through the
> "make V=''" build:
>
>    SUBDIR perl
> /usr/bin/perl -pe "s<\Q++LOCALEDIR++\E><.../share/locale>" <Git/I18N.pm >blib/lib/Git/I18N.pm
> /usr/bin/perl -pe "s<\Q++LOCALEDIR++\E><.../share/locale>" <Git.pm >blib/lib/Git.pm
> Manifying blib/man3/Git::I18N.3pm
> Manifying blib/man3/Git.3pm
>    SUBDIR git_remote_helpers

That behavior hasn't changed with this patch, we just print out more
stuff now. Without the patch with V='':

        SUBDIR perl
    cp Git.pm blib/lib/Git.pm
    Manifying blib/man3/Git.3pm

And with it:

        SUBDIR perl
    /usr/bin/perl -pe "s<\Q++LOCALEDIR++\E></home/avar/share/locale>"
<Git/I18N.pm >blib/lib/Git/I18N.pm
    /usr/bin/perl -pe "s<\Q++LOCALEDIR++\E></home/avar/share/locale>"
<Git.pm >blib/lib/Git.pm
    Manifying blib/man3/Git::I18N.3pm
    Manifying blib/man3/Git.3pm

So the change is:

 * We now have 2 files instead of 1
 * We have a filtering command instead of just a "cp".

The reason this happens is that we have this in the perl.mak:

    PM_FILTER = $(PERL) -pe "s<\Q++LOCALEDIR++\E></home/avar/share/locale>"

And we then later call:

    pm_to_blib : $(FIRST_MAKEFILE) $(TO_INST_PM)
        $(NOECHO) $(ABSPERLRUN) -MExtUtils::Install -e
'pm_to_blib({@ARGV}, '\''$(INST_LIB)/auto'\'', q[$(PM_FILTER)],
'\''$(PERM_DIR)'\'')' -- \
          Git/I18N.pm $(INST_LIBDIR)/Git/I18N.pm \
          Git.pm $(INST_LIBDIR)/Git.pm
        $(NOECHO) $(TOUCH) pm_to_blib

Which in ExtUtils::Install calls pm_to_blib, which is defined like this:

    sub pm_to_blib {
        my($fromto,$autodir,$pm_filter) = @_;

        _mkpath($autodir,0,0755);
        while(my($from, $to) = each %$fromto) {
            if( -f $to && -s $from == -s $to && -M $to < -M $from ) {
                print "Skip $to (unchanged)\n";
                next;
            }

            # When a pm_filter is defined, we need to pre-process the
source first
            # to determine whether it has changed or not.  Therefore,
only perform
            # the comparison check when there's no filter to be ran.
            #    -- RAM, 03/01/2001

            my $need_filtering = defined $pm_filter && length $pm_filter &&
                                 $from =~ /\.pm$/;

            if (!$need_filtering && 0 == compare($from,$to)) {
                print "Skip $to (unchanged)\n";
                next;
            }
            if (-f $to){
                # we wont try hard here. its too likely to mess things up.
                forceunlink($to);
            } else {
                _mkpath(dirname($to),0,0755);
            }
            if ($need_filtering) {
                run_filter($pm_filter, $from, $to);
                print "$pm_filter <$from >$to\n";
            } else {
                _copy( $from, $to );
                print "cp $from $to\n";
            }

I.e. there's no way to stop it from printing what it copies /
filters. We could quiet it with some Perl or Makefile hack, but let's
try to address that outside of this series.

^ permalink raw reply

* Re: Fixing a broken GIT repo
From: Felipe Contreras @ 2011-11-18 12:54 UTC (permalink / raw)
  To: Bart van den Burg; +Cc: git
In-Reply-To: <ja5dgo$nlf$1@dough.gmane.org>

On Fri, Nov 18, 2011 at 12:54 PM, Bart van den Burg <bart@burgov.nl> wrote:
> Needless to say, the mentioned object in fact does exist on the server:
> git@server:~/shifter_rai.git$ ls -la
> objects/85/d1ee957c65485ed9c937a4f1bfdd44fda4ea35
> -r--r--r-- 1 git git 153 Nov 18 11:39
> objects/85/d1ee957c65485ed9c937a4f1bfdd44fda4ea35
>
> Can anyone tell me what is happening here, and how I can fix it?

Well, if you can't find that object on the server or your local box,
then you would have to find the last commit that worked, and reset the
'master' branch to that.

-- 
Felipe Contreras

^ permalink raw reply

* Re: [PATCH 8/8] Enable GIT_DEBUG_MEMCHECK on git_pathname()
From: Bernhard R. Link @ 2011-11-18 12:50 UTC (permalink / raw)
  To: Jeff King
  Cc: Ramkumar Ramachandra, Nguyễn Thái Ngọc Duy, git,
	Junio C Hamano, Michael Haggerty, Jonathan Nieder
In-Reply-To: <20111117134201.GA30718@sigill.intra.peff.net>

* Jeff King <peff@peff.net> [111117 14:42]:
> Variable-argument macros were definitely introduced in C99 (and were a
> gcc extension for a while before then).

Though AFAIK not that long. Before that gcc had it's own variadic
syntax a la

#define eprintf(args...) fprintf (stderr, args)

	Bernhard R. Link

^ permalink raw reply

* Re: [PATCH] honour GIT_ASKPASS for querying username in git-svn
From: Sven Strickroth @ 2011-11-18 13:30 UTC (permalink / raw)
  To: kusmabite; +Cc: git, gitster
In-Reply-To: <CABPQNSZ0iPAE+BnDU6Nz8_PkrAtPbjL4RoJuQS=Um2wxPt-2DQ@mail.gmail.com>

Am 18.11.2011 12:36 schrieb Erik Faye-Lund:
> On Thu, Nov 17, 2011 at 4:15 PM, Sven Strickroth
> <sven.strickroth@tu-clausthal.de> wrote:
>> From 8e576705ca949c32ff22d3216006073ee70652eb Mon Sep 17 00:00:00 2001
>> From: Sven Strickroth <email@cs-ware.de>
>> Date: Thu, 17 Nov 2011 15:43:25 +0100
>> Subject: [PATCH 1/2] honour GIT_ASKPASS for querying username
>>
>> git-svn reads usernames from an interactive terminal.
>> This behavior cause GUIs to hang waiting for git-svn to
>> complete (http://code.google.com/p/tortoisegit/issues/detail?id=967).
>>
>> Also see commit 56a853b62c0ae7ebaad0a7a0a704f5ef561eb795.
>>
>> Signed-off-by: Sven Strickroth <email@cs-ware.de>
> 
> IIUC, GIT_ASKPASS is intended for passwords and not usernames. Won't
> this cause console-users to not see their username prompted anymore?

git also asks for username using the GIT_ASKPASS tool (if GIT_ASKPASS is
set).

-- 
Best regards,
 Sven Strickroth
 ClamAV, a GPL anti-virus toolkit   http://www.clamav.net
 PGP key id F5A9D4C4 @ any key-server

^ permalink raw reply

* [PATCH] Compile fix for MSVC: Move poll.h out of sys-folder
From: Vincent van Ravesteijn @ 2011-11-18 13:47 UTC (permalink / raw)
  To: git; +Cc: gitster, kusmabite, msysgit, j.sixt, Vincent van Ravesteijn

In v1.7.7.1-432-g0f77dea (Oct 24 2011; Erik Faye-Lund; mingw: move
poll out of sys-folder) poll.h was moved out of the compat/win32/sys
folder. As the change in the Makefile also affects the MSVC build,
the same must be done for poll.h in compat/vcbuild/include/sys/poll.h.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
 compat/vcbuild/include/poll.h     |    1 +
 compat/vcbuild/include/sys/poll.h |    1 -
 2 files changed, 1 insertions(+), 1 deletions(-)
 create mode 100644 compat/vcbuild/include/poll.h
 delete mode 100644 compat/vcbuild/include/sys/poll.h

diff --git a/compat/vcbuild/include/poll.h b/compat/vcbuild/include/poll.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/poll.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/poll.h b/compat/vcbuild/include/sys/poll.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/poll.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
-- 
1.7.4.1

^ permalink raw reply related

* Re: Fixing a broken GIT repo
From: Johannes Sixt @ 2011-11-18 13:49 UTC (permalink / raw)
  To: Bart van den Burg; +Cc: git
In-Reply-To: <ja5dgo$nlf$1@dough.gmane.org>

Am 11/18/2011 11:54, schrieb Bart van den Burg:
> I somehow managed to break my GIT repo. Whenever I try to clone or fetch
> from a clean local repo, I get an error.
> 
> I'm able to go back on the server, to the very last commit where
> everything works, but as soon as I make a change locally and push it, it
> breaks again.
...
> $ git clone git@git.samson-it.nl:/home/git/shifter_rai
...
> Receiving objects: 100% (9557/9557), 2.85 MiB | 1.06 MiB/s, done.
...
> $ git push
> Counting objects: 4, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 271 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> To git@git.samson-it.nl:/home/git/shifter_rai
>    cc5693a..85d1ee9  master -> master

It looks like you are pushing via git protocol from Windows
(Git-for-Windows). This is known to dead-lock in most cases, and even
though it did not here, I would not be surprised if it had other issues.

Do not do it. Push via ssh instead.

> bbu@SIT-WST-05 /d/workspace9
> $ git clone git@git.samson-it.nl:/home/git/shifter_rai
> Cloning into shifter_rai...
> remote: Counting objects: 9557, done.
> remote: Compressing objects: 100% (1887/1887), done.
> remote: Total 9557 (delta 7107), reused 9397 (delta 7019)
> Receiving objects: 100% (9557/9557), 2.85 MiB | 1.16 MiB/s, done.
> Resolving deltas: 100% (7107/7107), done.

Did you notice that this downloaded the exact same number of objects as
the first clone? There should have been at least 9558, but most likely
9560 objects. There's something fishy.

> error: refs/remotes/origin/master does not point to a valid object!
> error: Trying to write ref refs/heads/master with nonexistant object
> 85d1ee957c65485ed9c937a4f1bfdd44fda4ea35
> fatal: Cannot update the ref 'HEAD'.
>
> Needless to say, the mentioned object in fact does exist on the server:
> git@server:~/shifter_rai.git$ ls -la
> objects/85/d1ee957c65485ed9c937a4f1bfdd44fda4ea35
> -r--r--r-- 1 git git 153 Nov 18 11:39
> objects/85/d1ee957c65485ed9c937a4f1bfdd44fda4ea35

Does git fsck --full on the server indeed report a good repository? Can
you clone this repository to a different client?

-- Hannes

^ permalink raw reply

* Re: [PATCH] Compile fix for MSVC: Move poll.h out of sys-folder
From: Erik Faye-Lund @ 2011-11-18 14:09 UTC (permalink / raw)
  To: Vincent van Ravesteijn; +Cc: git, gitster, msysgit, j.sixt
In-Reply-To: <1321624070-4246-1-git-send-email-vfr@lyx.org>

On Fri, Nov 18, 2011 at 2:47 PM, Vincent van Ravesteijn <vfr@lyx.org> wrote:
> In v1.7.7.1-432-g0f77dea (Oct 24 2011; Erik Faye-Lund; mingw: move
> poll out of sys-folder) poll.h was moved out of the compat/win32/sys
> folder. As the change in the Makefile also affects the MSVC build,
> the same must be done for poll.h in compat/vcbuild/include/sys/poll.h.
>
> Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
> ---
>  compat/vcbuild/include/poll.h     |    1 +
>  compat/vcbuild/include/sys/poll.h |    1 -
>  2 files changed, 1 insertions(+), 1 deletions(-)
>  create mode 100644 compat/vcbuild/include/poll.h
>  delete mode 100644 compat/vcbuild/include/sys/poll.h
>

This looks strange to me. vcbuild/include/poll.h will only prevent the
correct header from being included, while compiling an linking against
compat/win32/poll.[co]... That seems dangerous to me, because the
interface might be declared differently.

Instead, I think compat/vcbuild/include/poll.h should be removed, and
_WIN32_WINNT set to a value below 0x600. That way the poll-stuff
doesn't get pulled in by winsock2.h (as it's Vista and above only).

This was already discussed in your "[PATCHv2] Compile fix for MSVC" thread:
http://mid.gmane.org/CABPQNSaCRRRpEQPG1Mb4DovkMdQSBhHTm-i7y5M4iT+ndHX4XA@mail.gmail.com

Here's the patch that fixes it. I still can't build Junio's master,
due to sys/resource.h missing. This comes from ebae9ff ("compat: add
missing #include <sys/resource.h>"), and is only guarded against
MinGW, not MSVC...

$ git diff
diff --git a/compat/mingw.h b/compat/mingw.h
index dfb0e87..a06269d 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -1,3 +1,4 @@
+#define _WIN32_WINNT 0x0501
 #include <winsock2.h>
 #include <ws2tcpip.h>

diff --git a/git-compat-util.h b/git-compat-util.h
index 5ef8ff7..c52be6c 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,6 +85,7 @@
 #define _SGI_SOURCE 1

 #ifdef WIN32 /* Both MinGW and MSVC */
+#define _WIN32_WINNT 0x0501
 #define WIN32_LEAN_AND_MEAN  /* stops windows.h including winsock.h */
 #include <winsock2.h>
 #include <windows.h>

^ permalink raw reply related

* Re: A flaw in dep generation with gcc -MMD?
From: Nguyen Thai Ngoc Duy @ 2011-11-18 14:12 UTC (permalink / raw)
  To: Miles Bader; +Cc: Jonathan Nieder, Git Mailing List
In-Reply-To: <CACsJy8BuCdT3rRjc5u6Ex5RRgSbL_0SFF0GW-dTGqet4sG2cwg@mail.gmail.com>

On Fri, Nov 18, 2011 at 6:34 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> OK it's not gcc problem. I upgraded to 4.5.3 and still had the same
> problem. I used ccache though. Without ccache, gcc produced correct
> .o.d files.

"gcc -MF depfile -MMD -MP -c -o path/to/file.o" will produce "depfile"
with target given by "-o". When ccache runs, it executes "gcc -MF
depfile -MMD -MP -E" instead to get the final content for hashing.
Notice that "-c -o" combination is replaced by "-E". The latter
produces target without leading path.

Not sure if I should report this to ccache or gcc. In the meantime,
may be we should recognize the situation and switch off
COMPUTE_HEADER_DEPENDENCIES when ccache is used (maybe hard).
-- 
Duy

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox