* [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
* Re: [PATCH] honour GIT_ASKPASS for querying username in git-svn
From: Erik Faye-Lund @ 2011-11-18 14:19 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, gitster
In-Reply-To: <4EC65DE4.90005@tu-clausthal.de>
On Fri, Nov 18, 2011 at 2:30 PM, Sven Strickroth
<sven.strickroth@tu-clausthal.de> wrote:
> 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).
>
You are right, it does. Documentation/config.txt documents it as being
for passwords without mentioning that it also affects usernames,
that's why I wondered. I've also verified what happens here on my
config, and git-svn doesn't prompt my username here without the patch
either. So consider my comment withdrawn ;)
^ permalink raw reply
* Re: [PATCH] Compile fix for MSVC: Move poll.h out of sys-folder
From: Erik Faye-Lund @ 2011-11-18 14:28 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, gitster, msysgit, j.sixt
In-Reply-To: <CABPQNSa+ZjAMSxpBTqGW7P=v-tJTW_jdx3MO=vCpzc-z_XdHTg@mail.gmail.com>
On Fri, Nov 18, 2011 at 3:09 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> 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.
Johannes Schindelin was nice enough to create a commit based on my
e-mail, feel free to pick it up and submit it:
https://github.com/msysgit/git/commit/9ca803910f3625bf686699f6b0bf71a8c68bccae
^ permalink raw reply
* Re: [PATCH] Compile fix for MSVC: Move poll.h out of sys-folder
From: Vincent van Ravesteijn @ 2011-11-18 14:42 UTC (permalink / raw)
To: kusmabite; +Cc: git, gitster, msysgit, j.sixt
In-Reply-To: <CABPQNSa+ZjAMSxpBTqGW7P=v-tJTW_jdx3MO=vCpzc-z_XdHTg@mail.gmail.com>
> 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,
Yes, it should just be removed. Having poll.h in the sys directory was
wrong and the patch I sent was needed to make 0f77dea compile.
Your patch is indeed necessary to compile later revisions as well.
> 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...
The fix for this is already in 'next' now. So, with your patch, 'next'
does compile.
Vincent
^ permalink raw reply
* [PATCH 1/3] MSVC: Remove vcbuild/include/sys/poll.h
From: Vincent van Ravesteijn @ 2011-11-18 16:44 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,
this file was no longer used.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
compat/vcbuild/include/sys/poll.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
delete mode 100644 compat/vcbuild/include/sys/poll.h
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
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