* [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
* [PATCH 2/3] Compile fix for MSVC: fix poll-related macro redefines
From: Vincent van Ravesteijn @ 2011-11-18 16:44 UTC (permalink / raw)
To: git
Cc: gitster, kusmabite, msysgit, j.sixt, Vincent van Ravesteijn,
Johannes Schindelin
In-Reply-To: <1321634670-4968-1-git-send-email-vfr@lyx.org>
This seems to be related to the poll-emulation... I see that these things
are guarded by an "#if(_WIN32_WINNT >= 0x0600)" in <winsock2.h>, which
means it's supported for Windows Vista and above... We still support
Windows XP, so it seems someone has set this too high :)
I'd prefer to set this from the Makefile, but this generates a warning in
compat/win32/poll.c about redefining a macro (poll.c wants it to be 0x502,
which is Windows XP with SP2, rather than 0x501 which is normal Windows
XP).
Proposed-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Submitted-by: Vincent van Ravesteijn <vfr@lyx.org>
---
compat/mingw.h | 1 +
git-compat-util.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index fecf0d0..ff18401 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..76cbfe6 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>
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/3] Compile fix for MSVC: Use NO_INET_PTON and NO_INET_NTOP
From: Vincent van Ravesteijn @ 2011-11-18 16:44 UTC (permalink / raw)
To: git; +Cc: gitster, kusmabite, msysgit, j.sixt, Vincent van Ravesteijn
In-Reply-To: <1321634670-4968-1-git-send-email-vfr@lyx.org>
This is needed to compile daemon.c.
In v1.7.3.2-162-ga666b47 (Nov 4 2010; Erik Faye-Lund <kusmabite@gmail.com>;
daemon: opt-out on features that require posix) this was introduced for
MingW, but this is also necessary for MSVC.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index ee34eab..b9d53aa 100644
--- a/Makefile
+++ b/Makefile
@@ -1120,6 +1120,8 @@ ifeq ($(uname_S),Windows)
BLK_SHA1 = YesPlease
NO_POSIX_GOODIES = UnfortunatelyYes
NATIVE_CRLF = YesPlease
+ NO_INET_PTON = YesPlease
+ NO_INET_NTOP = YesPlease
CC = compat/vcbuild/scripts/clink.pl
AR = compat/vcbuild/scripts/lib.pl
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] Compile fix for MSVC: Move poll.h out of sys-folder
From: Vincent van Ravesteijn @ 2011-11-18 16:47 UTC (permalink / raw)
To: kusmabite; +Cc: git, gitster, msysgit, j.sixt
In-Reply-To: <CABPQNSaV-TyznoOsRNQPYEWZCz553cuPOdRsyRQSpzU8QngBZA@mail.gmail.com>
Op 18-11-2011 15:28, Erik Faye-Lund schreef:
> 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
I resended a patch series including this one.
Vincent
^ permalink raw reply
* Re: [PATCH 2/3] Compile fix for MSVC: fix poll-related macro redefines
From: Sebastian Schuberth @ 2011-11-18 17:36 UTC (permalink / raw)
To: Vincent van Ravesteijn
Cc: git, gitster, kusmabite, msysgit, j.sixt, Johannes Schindelin
In-Reply-To: <1321634670-4968-2-git-send-email-vfr@lyx.org>
On 18.11.2011 17:44, Vincent van Ravesteijn wrote:
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 5ef8ff7..76cbfe6 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>
It seems the indentation is wrong (does not match the surrounding code)
here.
--
Sebastian Schuberth
^ permalink raw reply
* [PATCH] git-gui: Set both 16x16 and 32x32 icons on X to pacify Xming.
From: Samuel Bronson @ 2011-11-18 18:13 UTC (permalink / raw)
To: git; +Cc: Pat Thoyts, Shawn O. Pearce, Samuel Bronson
It would be better if the 32x32 icon was equivalent to the one used on
Windows (in git-gui.ico), but I'm not sure how that would best be done,
so I copied this code from gitk instead.
---
git-gui.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index c190cbe..9d01039 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -729,7 +729,12 @@ if {[is_Windows]} {
gitlogo put gray26 -to 5 15 11 16
gitlogo redither
- wm iconphoto . -default gitlogo
+ # TODO: should use something equivalent to the 32x32 image in
+ # the .ico file
+ image create photo gitlogo32 -width 32 -height 32
+ gitlogo32 copy gitlogo -zoom 2 2
+
+ wm iconphoto . -default gitlogo gitlogo32
}
}
--
1.7.6.3
^ permalink raw reply related
* Re: [PATCH] receive-pack, fetch-pack: reject bogus pack that records objects twice
From: Junio C Hamano @ 2011-11-18 18:41 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20111118103355.GA4854@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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?
Excising unwanted objects from the middle of an existing packfile would
mean you would need an equivalent of memmove() in the file, which amounts
to really rewriting the packfile, but the thing is, we are _not_ rewriting
in that sense in "index-pack --fix-thin"; it only appends and adjust the
fixed-size header.
^ permalink raw reply
* Re: [PATCH] receive-pack, fetch-pack: reject bogus pack that records objects twice
From: Jeff King @ 2011-11-18 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vd3cpl1cw.fsf@alter.siamese.dyndns.org>
On Fri, Nov 18, 2011 at 10:41:35AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > 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?
>
> Excising unwanted objects from the middle of an existing packfile would
> mean you would need an equivalent of memmove() in the file, which amounts
> to really rewriting the packfile, but the thing is, we are _not_ rewriting
> in that sense in "index-pack --fix-thin"; it only appends and adjust the
> fixed-size header.
I thought we took the packfile over --stdin, and we really were
writing the entire thing to disk as we processed it. So we could just
suppress writing the second entry. But I guess there is some complexity
with deltified entries? As in, if the first entry is deltified but the
second is not, you would want to keep the second one?
I'm not complaining if it's really too hard to do in practice, or not
worth the trouble. I just still don't understand what is causing these
and when it would come up.
-Peff
^ permalink raw reply
* Re: [PATCH] receive-pack, fetch-pack: reject bogus pack that records objects twice
From: Junio C Hamano @ 2011-11-18 19:22 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20111118184455.GA13782@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 18, 2011 at 10:41:35AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > 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?
>> ...
> ... But I guess there is some complexity
> with deltified entries? As in, if the first entry is deltified but the
> second is not, you would want to keep the second one?
I think you answered your own question here; it is not "some complexity"
but is exactly the "you need to memmove() in the output file" situation in
the message you are responding to.
Upon seeing a delta, you would not know if the same object as this delta
represents appears later in the pack stream, which means until you read to
the end you wouldn't know. You obviously would not want to hold onto all
deltas in-core to "just omit the duplicate".
^ permalink raw reply
* Re: A flaw in dep generation with gcc -MMD?
From: Andreas Schwab @ 2011-11-18 19:27 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Miles Bader, Jonathan Nieder, Git Mailing List
In-Reply-To: <CACsJy8BuCdT3rRjc5u6Ex5RRgSbL_0SFF0GW-dTGqet4sG2cwg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 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.
I'm also using ccache (version 3.1.3) and get correct dependencies.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: A flaw in dep generation with gcc -MMD?
From: Samuel Bronson @ 2011-11-18 18:30 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8CKmjq01KoLRzOnnaf6RwFCQJfjxziqKTZW9HDyd8CagA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
>
> On Fri, Nov 18, 2011 at 6:34 PM, Nguyen Thai Ngoc Duy <pclouds <at> 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).
I'm pretty sure you should report this against ccache; GCC seems to be
behaving as documented. (I believe there is another flag that ccache
should be passing in to tell GCC what target to use in the depfile.)
Of course, it'd be wise to make sure that this problem still occurs in
the most recent version of ccache you can conveniently try it with before
reporting...
^ permalink raw reply
* Re: [PATCH 4/4] refresh_index: notice typechanges in output
From: Junio C Hamano @ 2011-11-18 20:40 UTC (permalink / raw)
To: Jeff King; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20111118110938.GA5940@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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
Looks sensible; thanks. Will replace.
^ permalink raw reply
* .git ignored regardless of --git-dir value
From: Shawn Ferris @ 2011-11-18 20:56 UTC (permalink / raw)
To: git
Hi All --
Is it expected behavior to have the .git directory ignored, even after
specifying an alternate location with --git-dir? For example:
$ git --git-dir=.foo init
Initialized empty Git repository in /home/sferris/work/t/.foo/
$ mkdir .git
$ touch .git/filea
$ git --git-dir=.foo --work-tree=. add .
$ git --git-dir=.foo --work-tree=. status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: .foo/HEAD
# new file: .foo/config
# new file: .foo/description
# new file: .foo/hooks/applypatch-msg.sample
# new file: .foo/hooks/commit-msg.sample
# new file: .foo/hooks/post-update.sample
# new file: .foo/hooks/pre-applypatch.sample
# new file: .foo/hooks/pre-commit.sample
# new file: .foo/hooks/pre-rebase.sample
# new file: .foo/hooks/prepare-commit-msg.sample
# new file: .foo/hooks/update.sample
# new file: .foo/index.lock
# new file: .foo/info/exclude
#
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: .foo/index.lock
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .foo/index
# .foo/objects/
Notice that .foo was added, but .git was ignored. I would have
expected .foo to be ignored and .git to be added? (right, wrong or
indifferent..)
Thanks for any info!
Shawn
^ permalink raw reply
* Re: [PATCH] receive-pack, fetch-pack: reject bogus pack that records objects twice
From: Jeff King @ 2011-11-18 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7v62ihkzhb.fsf@alter.siamese.dyndns.org>
On Fri, Nov 18, 2011 at 11:22:08AM -0800, Junio C Hamano wrote:
> >> > 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?
> >> ...
> > ... But I guess there is some complexity
> > with deltified entries? As in, if the first entry is deltified but the
> > second is not, you would want to keep the second one?
>
> I think you answered your own question here; it is not "some complexity"
> but is exactly the "you need to memmove() in the output file" situation in
> the message you are responding to.
>
> Upon seeing a delta, you would not know if the same object as this delta
> represents appears later in the pack stream, which means until you read to
> the end you wouldn't know. You obviously would not want to hold onto all
> deltas in-core to "just omit the duplicate".
OK, that makes sense to me. It's nice to hear it confirmed from somebody
who obviously thought more about it.
-Peff
^ permalink raw reply
* Re: A flaw in dep generation with gcc -MMD?
From: Jonathan Nieder @ 2011-11-18 21:16 UTC (permalink / raw)
To: Samuel Bronson; +Cc: git, Nguyen Thai Ngoc Duy, Miles Bader
In-Reply-To: <loom.20111118T191851-152@post.gmane.org>
Hi,
(restoring cc list. Unfortunately gmane's web interface doesn't
provide a built-in way to reply-to-all. [1] has a hackish
workaround.)
Samuel Bronson wrote:
> Nguyen Thai Ngoc Duy writes:
>> "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.
[...]
> I'm pretty sure you should report this against ccache; GCC seems to be
> behaving as documented.
Seems to have been fixed by v3.0pre0~187:
commit e8354384
Author: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Date: Sun Nov 1 19:39:58 2009 +0100
Fix handling of the -MD and -MDD options
From <http://lists.samba.org/archive/ccache/2007q2/000272.html>:
The -MD and -MDD options automatically determine where the dependency file
should land and what the target should look like based on the -o option.
However, ccache drops -o and things mess up. The original patch was posted by
Kaz Kylheku but I reworked it to make it work properly. Here is his post:
http://lists.samba.org/archive/ccache/2006q4/000249.html
Workaround incoming in a few moments.
Thanks,
Jonathan
^ permalink raw reply
* Re: .git ignored regardless of --git-dir value
From: Junio C Hamano @ 2011-11-18 21:26 UTC (permalink / raw)
To: Shawn Ferris; +Cc: git
In-Reply-To: <CAC2kKA_PZNDg_dPjWXKeFU4ZVpMas3PubZfSgTnfCfVPuNPdsA@mail.gmail.com>
Shawn Ferris <shawn.ferris@gmail.com> writes:
> Is it expected behavior to have the .git directory ignored, even after
> specifying an alternate location with --git-dir? For example:
>
> $ git --git-dir=.foo init
> Initialized empty Git repository in /home/sferris/work/t/.foo/
GIT_DIR and --git-dir are meant to refer to a different .git dir (or a
bare-looking repository) located elsewhere, and not for a random pathname
like ".foo". No matter what, ".git/" anywhere is ignored from very early
days of Git, as Linus himself writes in the source, e.g. 8695c8b (Add
"show-files" command to show the list of managed (or non-managed) files.,
2005-04-11):
...
* Also, we currently ignore all names starting with a dot.
* That likely will not change.
...
^ permalink raw reply
* [ANNOUNCE] Git 1.7.7.4
From: Junio C Hamano @ 2011-11-18 22:38 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git 1.7.7.4 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
5b6920989480a37ec65977e756b24961578795dd git-1.7.7.4.tar.gz
6012cb017a04ded85c48ca5510f741e98c02f671 git-htmldocs-1.7.7.4.tar.gz
cb21e55ae793865453c165a0e666348f2db8c740 git-manpages-1.7.7.4.tar.gz
Also the following public repositories all have a copy of the v1.7.7.4
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.7.4 Release Notes
==========================
Fixes since v1.7.7.3
--------------------
* A few header dependencies were missing from the Makefile.
* Some newer parts of the code used C99 __VA_ARGS__ while we still
try to cater to older compilers.
* "git name-rev --all" tried to name all _objects_, naturally failing to
describe many blobs and trees, instead of showing only commits as
advertised in its documentation.
----------------------------------------------------------------
Changes since v1.7.7.3 are as follows:
Jonathan Nieder (2):
notes merge: eliminate OUTPUT macro
Makefile: add missing header file dependencies
Junio C Hamano (2):
name-rev --all: do not even attempt to describe non-commit object
Git 1.7.7.4
Marc-André Lureau (1):
mailmap: xcalloc mailmap_info
^ permalink raw reply
* Re: .git ignored regardless of --git-dir value
From: Junio C Hamano @ 2011-11-18 22:47 UTC (permalink / raw)
To: git; +Cc: Shawn Ferris
In-Reply-To: <7vsjlljf57.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Shawn Ferris <shawn.ferris@gmail.com> writes:
>
>> Is it expected behavior to have the .git directory ignored, even after
>> specifying an alternate location with --git-dir? For example:
>>
>> $ git --git-dir=.foo init
>> Initialized empty Git repository in /home/sferris/work/t/.foo/
>
> GIT_DIR and --git-dir are meant to refer to a different .git dir (or a
> bare-looking repository) located elsewhere, and not for a random pathname
> like ".foo". No matter what, ".git/" anywhere is ignored from very early
> days of Git, as Linus himself writes in the source, e.g. 8695c8b (Add
> "show-files" command to show the list of managed (or non-managed) files.,
> 2005-04-11):
>
> ...
> * Also, we currently ignore all names starting with a dot.
> * That likely will not change.
> ...
Sorry, but the above quote is wrong. The correct one is from 453ec4b
(libify git-ls-files directory traversal, 2006-05-16), and survives to
this day in dir.c:
...
* Read a directory tree. We currently ignore anything but
* directories, regular files and symlinks. That's because git
* doesn't handle them at all yet. Maybe that will change some
* day.
*
* Also, we ignore the name ".git" (even if it is not a directory).
* That likely will not change.
...
In other words, originally we ignored all names starting with a dot and
declared that likely will not change, but then loosened the rule to let
people manage their .bashrc and friends. But ".git" is still special, and
that likely will not change.
^ permalink raw reply
* [PATCH] Makefile: explicitly set target name for autogenerated dependencies
From: Jonathan Nieder @ 2011-11-18 23:23 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Fredrik Kuivinen, Junio C Hamano
In-Reply-To: <CACsJy8BZMDyf4MCiKxPJ5Z+XS+C-MC82SpMFyWgiXmb9xCnScw@mail.gmail.com>
"gcc -MF depfile -MMD -MP -c -o path/to/file.o" produces a makefile
snippet named "depfile" describing what files are needed to build the
target given by "-o". When ccache versions before v3.0pre0~187 (Fix
handling of the -MD and -MDD options, 2009-11-01) run, they execute
gcc -MF depfile -MMD -MP -E
instead to get the final content for hashing. Notice that the "-c -o"
combination is replaced by "-E". The result is a target name without
a leading path.
Thus when building git with such versions of ccache with
COMPUTE_HEADER_DEPENDENCIES enabled, the generated makefile snippets
define dependencies for the wrong target:
$ make builtin/add.o
GIT_VERSION = 1.7.8.rc3
* new build flags or prefix
CC builtin/add.o
$ head -1 builtin/.depend/add.o.d
add.o: builtin/add.c cache.h git-compat-util.h compat/bswap.h strbuf.h \
After a change in a header file, object files in a subdirectory are
not automatically rebuilt by "make":
$ touch cache.h
$ make builtin/add.o
$
Luckily we can prevent trouble by explicitly supplying the name of the
target to ccache and gcc, using the -MQ option. Do so.
Reported-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hi,
Nguyen Thai Ngoc Duy wrote:
> My builtin/.depend/add.o.d says
>
> add.o: .... cache.h ...
>
> Shouldn't it be "builtin/add.o: ... cache.h ..."?
The following seems to do the trick for me. Thanks again for catching
it.
Makefile | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index ee34eab8..71ad4b26 100644
--- a/Makefile
+++ b/Makefile
@@ -1250,7 +1250,8 @@ USE_COMPUTED_HEADER_DEPENDENCIES =
else
ifndef COMPUTE_HEADER_DEPENDENCIES
dep_check = $(shell $(CC) $(ALL_CFLAGS) \
- -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
+ -c -MF /dev/null -MQ /dev/null -MMD -MP \
+ -x c /dev/null -o /dev/null 2>&1; \
echo $$?)
ifeq ($(dep_check),0)
COMPUTE_HEADER_DEPENDENCIES=YesPlease
@@ -1912,7 +1913,7 @@ $(dep_dirs):
missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
dep_file = $(dir $@).depend/$(notdir $@).d
-dep_args = -MF $(dep_file) -MMD -MP
+dep_args = -MF $(dep_file) -MQ $@ -MMD -MP
ifdef CHECK_HEADER_DEPENDENCIES
$(error cannot compute header dependencies outside a normal build. \
Please unset CHECK_HEADER_DEPENDENCIES and try again)
--
1.7.8.rc3
^ permalink raw reply related
* Re: .git ignored regardless of --git-dir value
From: Shawn Ferris @ 2011-11-18 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h2xjbf4.fsf@alter.siamese.dyndns.org>
On Fri, Nov 18, 2011 at 3:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>>
>> GIT_DIR and --git-dir are meant to refer to a different .git dir (or a
>> bare-looking repository) located elsewhere, and not for a random pathname
>> like ".foo". No matter what, ".git/" anywhere is ignored from very early
I'm extremely green to git, so please forgive if this is obvious, but,
could I indulge and ask what a sample use case of that would be?
(since it's not intended for what I assumed it was) And, if the
behavior I expected was possible, simply, with perhaps a separate
option, what is the likelihood a patch would be accepted? (Or am I
just talking nonsense and should just go away) ;D
Thanks Again!
Shawn
^ permalink raw reply
* Re: [PATCH] receive-pack, fetch-pack: reject bogus pack that records objects twice
From: Shawn Pearce @ 2011-11-18 23:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20111118103355.GA4854@sigill.intra.peff.net>
On Fri, Nov 18, 2011 at 02:33, Jeff King <peff@peff.net> wrote:
> 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?
A buggy Git. We found a case where JGit could generate duplicate
objects in the pack stream during a clone. The resulting client
worked... until it tried to do `git gc` or really any sort of `git
pack-objects`.
In my opinion, a pack should never contain duplicate objects. Its a
buggy remote that sends them. What I like about this patch is it stops
and tells the user the remote is broken, which it is.
^ permalink raw reply
* Re: A flaw in dep generation with gcc -MMD?
From: Nguyen Thai Ngoc Duy @ 2011-11-19 4:53 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Miles Bader, Jonathan Nieder, Git Mailing List
In-Reply-To: <m21ut5dyei.fsf@igel.home>
On Sat, Nov 19, 2011 at 2:27 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> 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.
>
> I'm also using ccache (version 3.1.3) and get correct dependencies.
I use ccache-2.4. Jonathan pointed out 3.x has been fixed elsewhere in
this thread . I'm going to ask Gentoo to stablize one of 3.x version.
--
Duy
^ permalink raw reply
* Re: [PATCH] Makefile: explicitly set target name for autogenerated dependencies
From: Nguyen Thai Ngoc Duy @ 2011-11-19 5:13 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git Mailing List, Fredrik Kuivinen, Junio C Hamano
In-Reply-To: <20111118232324.GA8746@elie.hsd1.il.comcast.net>
On Sat, Nov 19, 2011 at 6:23 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Luckily we can prevent trouble by explicitly supplying the name of the
> target to ccache and gcc, using the -MQ option. Do so.
>
> Reported-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Hi,
>
> Nguyen Thai Ngoc Duy wrote:
>
>> My builtin/.depend/add.o.d says
>>
>> add.o: .... cache.h ...
>>
>> Shouldn't it be "builtin/add.o: ... cache.h ..."?
>
> The following seems to do the trick for me. Thanks again for catching
> it.
Works for me too.
--
Duy
^ permalink raw reply
* clean bug on ignored subdirectories with no tracked files?
From: Jay Soffian @ 2011-11-19 5:38 UTC (permalink / raw)
To: git
git init test_repo &&
cd test_repo &&
mkdir -p foo/bar &&
echo baz > foo/bar/baz &&
echo /foo/bar > .gitignore &&
git add .gitignore &&
git clean -n -d
Initialized empty Git repository in .../test_repo/.git/
Would remove foo/
Seems surprising. The work-around is either using '/foo' in the
top-level .gitignore or adding a tracked file to the 'foo' directory.
j.
^ permalink raw reply
* [PATCH] upload-archive: use start_command instead of fork
From: Jeff King @ 2011-11-19 7:40 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
The POSIX-function fork is not supported on Windows. Use our
start_command API instead, respawning ourselves in a special
"writer" mode to follow the alternate code path.
Remove the NOT_MINGW-prereq for t5000, as git-archive --remote
now works.
Signed-off-by: Jeff King <peff@peff.net>
---
Now that Junio has reverted the original implementation, I took a closer
look at how this ought to be done.
I looked briefly into doing the writing in-process, or using
start_async. But the code relies too heavily on being able to die(),
and having the parent process grab stderr and the exit code to send to
the client. So going that direction would involve a lot of changes
either to the async code, or to the archive code.
We really do want a separate process, as it fits in with our usual die()
mentality for errors. But fortunately looking into the async stuff made
me realize another issue with the original patch. Originally we forked
as the first thing. Thus any error messages or die()s (e.g., because we
couldn't enter_repo, or got bogus input from the client) would be in the
child process, and the parent sideband muxer would relay the errors
properly. But in your original patch, we do quite a bit of processing
before spawning; those errors would go to git-daemon's stderr, and the
client would just see an unexpected hangup.
So we really do want to just switch the "fork immediately" to "spawn
immediately". Which fortunately means the change ends up being even
smaller, and I'm way more confident that there won't be side effects;
it's almost nothing but converting pipe/fork code into start_command
code.
And as an added bonus, the diffstat hopefully speaks for itself. :)
builtin.h | 1 +
builtin/upload-archive.c | 43 ++++++++++++-------------------------------
git.c | 1 +
t/t5000-tar-tree.sh | 10 +++++-----
4 files changed, 19 insertions(+), 36 deletions(-)
diff --git a/builtin.h b/builtin.h
index 0e9da90..f2357a9 100644
--- a/builtin.h
+++ b/builtin.h
@@ -133,6 +133,7 @@ int copy_note_for_rewrite(struct notes_rewrite_cfg *c,
extern int cmd_update_ref(int argc, const char **argv, const char *prefix);
extern int cmd_update_server_info(int argc, const char **argv, const char *prefix);
extern int cmd_upload_archive(int argc, const char **argv, const char *prefix);
+extern int cmd_upload_archive_writer(int argc, const char **argv, const char *prefix);
extern int cmd_upload_tar(int argc, const char **argv, const char *prefix);
extern int cmd_var(int argc, const char **argv, const char *prefix);
extern int cmd_verify_tag(int argc, const char **argv, const char *prefix);
diff --git a/builtin/upload-archive.c b/builtin/upload-archive.c
index 2d0b383..b928beb 100644
--- a/builtin/upload-archive.c
+++ b/builtin/upload-archive.c
@@ -6,6 +6,7 @@
#include "archive.h"
#include "pkt-line.h"
#include "sideband.h"
+#include "run-command.h"
static const char upload_archive_usage[] =
"git upload-archive <repo>";
@@ -13,12 +14,9 @@
static const char deadchild[] =
"git upload-archive: archiver died with error";
-static const char lostchild[] =
-"git upload-archive: archiver process was lost";
-
#define MAX_ARGS (64)
-static int run_upload_archive(int argc, const char **argv, const char *prefix)
+int cmd_upload_archive_writer(int argc, const char **argv, const char *prefix)
{
const char *sent_argv[MAX_ARGS];
const char *arg_cmd = "argument ";
@@ -96,8 +94,8 @@ static ssize_t process_input(int child_fd, int band)
int cmd_upload_archive(int argc, const char **argv, const char *prefix)
{
- pid_t writer;
- int fd1[2], fd2[2];
+ struct child_process writer = { argv };
+
/*
* Set up sideband subprocess.
*
@@ -105,39 +103,24 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
* multiplexed out to our fd#1. If the child dies, we tell the other
* end over channel #3.
*/
- if (pipe(fd1) < 0 || pipe(fd2) < 0) {
- int err = errno;
- packet_write(1, "NACK pipe failed on the remote side\n");
- die("upload-archive: %s", strerror(err));
- }
- writer = fork();
- if (writer < 0) {
+ argv[0] = "upload-archive--writer";
+ writer.out = writer.err = -1;
+ writer.git_cmd = 1;
+ if (start_command(&writer)) {
int err = errno;
- packet_write(1, "NACK fork failed on the remote side\n");
+ packet_write(1, "NACK unable to spawn subprocess\n");
die("upload-archive: %s", strerror(err));
}
- if (!writer) {
- /* child - connect fd#1 and fd#2 to the pipe */
- dup2(fd1[1], 1);
- dup2(fd2[1], 2);
- close(fd1[1]); close(fd2[1]);
- close(fd1[0]); close(fd2[0]); /* we do not read from pipe */
-
- exit(run_upload_archive(argc, argv, prefix));
- }
- /* parent - read from child, multiplex and send out to fd#1 */
- close(fd1[1]); close(fd2[1]); /* we do not write to pipe */
packet_write(1, "ACK\n");
packet_flush(1);
while (1) {
struct pollfd pfd[2];
- int status;
- pfd[0].fd = fd1[0];
+ pfd[0].fd = writer.out;
pfd[0].events = POLLIN;
- pfd[1].fd = fd2[0];
+ pfd[1].fd = writer.err;
pfd[1].events = POLLIN;
if (poll(pfd, 2, -1) < 0) {
if (errno != EINTR) {
@@ -156,9 +139,7 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
if (process_input(pfd[0].fd, 1))
continue;
- if (waitpid(writer, &status, 0) < 0)
- error_clnt("%s", lostchild);
- else if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
+ if (finish_command(&writer))
error_clnt("%s", deadchild);
packet_flush(1);
break;
diff --git a/git.c b/git.c
index 8e34903..250f448 100644
--- a/git.c
+++ b/git.c
@@ -434,6 +434,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "update-ref", cmd_update_ref, RUN_SETUP },
{ "update-server-info", cmd_update_server_info, RUN_SETUP },
{ "upload-archive", cmd_upload_archive },
+ { "upload-archive--writer", cmd_upload_archive_writer },
{ "var", cmd_var, RUN_SETUP_GENTLY },
{ "verify-pack", cmd_verify_pack },
{ "verify-tag", cmd_verify_tag, RUN_SETUP },
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index d906898..889842e 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -96,7 +96,7 @@ test_expect_success 'git archive with --output' \
'git archive --output=b4.tar HEAD &&
test_cmp b.tar b4.tar'
-test_expect_success NOT_MINGW 'git archive --remote' \
+test_expect_success 'git archive --remote' \
'git archive --remote=. HEAD >b5.tar &&
test_cmp b.tar b5.tar'
@@ -266,7 +266,7 @@ test_expect_success 'archive --list mentions user filter' '
grep "^bar\$" output
'
-test_expect_success NOT_MINGW 'archive --list shows only enabled remote filters' '
+test_expect_success 'archive --list shows only enabled remote filters' '
git archive --list --remote=. >output &&
! grep "^tar\.foo\$" output &&
grep "^bar\$" output
@@ -298,7 +298,7 @@ test_expect_success 'extension matching requires dot' '
test_cmp b.tar config-implicittar.foo
'
-test_expect_success NOT_MINGW 'only enabled filters are available remotely' '
+test_expect_success 'only enabled filters are available remotely' '
test_must_fail git archive --remote=. --format=tar.foo HEAD \
>remote.tar.foo &&
git archive --remote=. --format=bar >remote.bar HEAD &&
@@ -341,12 +341,12 @@ test_expect_success GZIP,GUNZIP 'extract tgz file' '
test_cmp b.tar j.tar
'
-test_expect_success GZIP,NOT_MINGW 'remote tar.gz is allowed by default' '
+test_expect_success GZIP 'remote tar.gz is allowed by default' '
git archive --remote=. --format=tar.gz HEAD >remote.tar.gz &&
test_cmp j.tgz remote.tar.gz
'
-test_expect_success GZIP,NOT_MINGW 'remote tar.gz can be disabled' '
+test_expect_success GZIP 'remote tar.gz can be disabled' '
git config tar.tar.gz.remote false &&
test_must_fail git archive --remote=. --format=tar.gz HEAD \
>remote.tar.gz
--
1.7.7.3.8.g38efa
^ 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