* 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
* 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: 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: [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: [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 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
* [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 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
* 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
* [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
* [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 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
* 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
* 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] 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: 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] 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: 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
* [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: [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
* 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: 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: [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: [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: 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
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