On Mon, Sep 29, 2014 at 10:43:41PM +0200, Johannes Sixt wrote:
Am 28.09.2014 um 15:24 schrieb Marat Radchenko:
This commit touches regcomp.c and poll.c from Gnulib,
both were fixed upstream in 2012 the same way.
Wrt ShellExecute, see [1].
[1]:
This patch series fixes building on modern MinGW and MinGW-W64 (including
x86_64!).
*Compilation* tested on:
- MSVC
- msysGit environment (twice)
- Linux cross-toolchain i686-pc-mingw32
- Linux cross-toolchain i686-w64-mingw32
- Linux cross-toolchain x86_64-w64-mingw32
Attention: in order
HAVE_LIBCHARSET_H and NO_R_TO_GCC_LINKER are not specific to
msysGit, they're general MinGW settings.
Logic behind HAVE_LIBCHARSET_H: if user is on MinGW and has iconv,
we expect him to have libcharset.h. If user doesn't have iconv,
he has to explicitly say so via NO_ICONV=1 regardless of this
Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
compat/mingw.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index df0e320..ed79368
Is it absolutely valid and possible to have cURL in generic
MinGW environment. Building Git without cURL is still possible
by passing NO_CURL=1
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
config.mak.uname | 2 --
1 file changed, 2
Unlike MinGW, MinGW-W64 has CONSOLE_FONT_INFOEX already properly defined
in wincon.h.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/winansi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/winansi.c b/compat/winansi.c
index efc5bb3..0ac3297 100644
fork() is not used in MinGW builds but causes a compiler warning
on x86_64 MinGW-W64: conflicting types for built-in function 'fork'
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
compat/mingw.h | 2 --
1 file changed, 2 deletions(-)
diff
From: Ray Donnelly mingw.andr...@gmail.com
Signed-off-by: Ray Donnelly mingw.andr...@gmail.com
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index
All MinGW flavors have inttypes.h, so just include it.
However, we need to pass -D__USE_MINGW_ANSI_STDIO=1 to select
GNU-compatible macro definitions on MinGW-W64:
http://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/
As a side-effect, Git no longer builds with MSVC 2010 due to
its lack of
pid_t is available in sys/types.h on both MinGW and MinGW-W64
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
compat/mingw.h | 1 -
compat/msvc.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.h
-D__USE_MINGW_ACCESS only affects MinGW and does nothing when
MSVC is used.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.mak.uname
This commit touches regcomp.c and poll.c from Gnulib,
both were fixed upstream in 2012 the same way.
Also, this commit touches regex_internal.h from Gnulib,
which was fixed upstream in 2005.
Wrt ShellExecute in winansi.c, quoting [1]:
MSDN says you can cast the result to an integer and
When crosscompiling, one cannot rely on `uname` from host system.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 5 +
1 file changed, 5 insertions(+)
diff --git a/config.mak.uname b/config.mak.uname
index 9f7037e..182da50 100644
--- a/config.mak.uname
+++
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
git-compat-util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 9d2d5ab..5f6659c 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -474,7 +474,7 @@ extern int
To ease cross-compilation process, introduce a single variable
with the prefix to all compiler-related executables.
Define CROSS_COMPILE=foo- if your compiler and binary utilities
are foo-cc, foo-ar, foo-strip, etc. More specific variables
override this, so if you set CC=gcc
1. Unlike MinGW, MinGW-W64 already provides _ReadWriteBarrier macro,
so don't try to redefine it.
2. MinGW-W64 has a strange definition FORCEINLINE as
extern __inline__ __attribute__((__always_inline__,__gnu_inline__))
'extern' doesn't work together with 'static', so #undef MinGW-W64
On Tue, Sep 30, 2014 at 12:48 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Sun, Sep 28, 2014 at 2:50 PM, Ben Walton bdwal...@gmail.com wrote:
Oracle Studio compilers don't allow for static variables in functions
that are defined to be inline. GNU C does
On 09/26/2014 06:31 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
* Rebase to current master.
When you say this, could you be a bit more descriptive? Has the
series updated to use something new that appeared on 'master' since
the last series was posted and
On Tue, Sep 30, 2014 at 2:02 PM, Marat Radchenko ma...@slonopotamus.org wrote:
This patch series fixes building on modern MinGW and MinGW-W64 (including
x86_64!).
*Compilation* tested on:
- MSVC
- msysGit environment (twice)
- Linux cross-toolchain i686-pc-mingw32
Thanks. I always
On 09/26/2014 08:33 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Document a couple more functions and the flags argument as used by
hold_lock_file_for_update() and hold_lock_file_for_append().
Reorganize the document to make it more accessible.
Helped-by:
Ok. Yes, it 's kind of tricky. But the `-- path` does both things.
`-- path` looks for the relative path within the current directory
but defaults to the work-tree root if your current directory does not
belong to the repo.
About `git -C dir`, awesome feature, I love that, but it's not my
point.
On 09/26/2014 10:40 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
+If you need to close the file descriptor you obtained from a
+`hold_lock_file_*` function yourself, do so by calling
+`close_lock_file`. You should never call `close(2)` yourself!
This is
On 09/26/2014 09:00 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Even the one lockfile object needn't be allocated each time the
function is called. Instead, define one statically-allocated
lock_file object and reuse it for every call.
Suggested-by: Jeff King
My dear good friend,
Good day to you,i got your contact from a business directory
in my agent office and i decide to contact you directly for
the sake of business.
My full name is Mrs Mariam Mohammed we are from Congo,I am
now searching for a reliable and experience business partner
I
From: Julien Carsique julien.carsi...@gmail.com
When using the name option of GIT_PS1_SHOWUPSTREAM to show the upstream
abbrev name, if the upstream name is the same as the local name, then some
space could be saved in the prompt. This is especially needed on long branch
names.
Replace the
Duy Nguyen pclo...@gmail.com writes:
Hmm.. no. Even if the function is inlined in multiple places, inline
code still points to the same offset variable.
OK, thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
On Tue, Sep 30, 2014 at 03:41:55PM +0200, Michael Haggerty wrote:
I didn't fix it because IMO the correct fix is to add a stdio-oriented
entry point to the lockfile API, and teach the lockfile code to handle
closing the FILE correctly when necessary.
I think so, too, after our discussion[1]
Michael Haggerty mhag...@alum.mit.edu writes:
I was being repetitive because I didn't want the docs to depend on the
user remembering what the bss section is (which, technically, is also
not part of the C standard). I think a better way would be to just not
mention bss section at all and
FreeBSD's printf(1) doesn't accept empty strings for numerical format
specifiers:
$ printf %d\n /dev/null; echo $?
printf: : expected numeric value
1
Initialize the AWK variable c to make sure the shell variable
subtree_count always contains a numerical value, in order
Jeff King p...@peff.net writes:
On Tue, Sep 30, 2014 at 03:41:55PM +0200, Michael Haggerty wrote:
I didn't fix it because IMO the correct fix is to add a stdio-oriented
entry point to the lockfile API, and teach the lockfile code to handle
closing the FILE correctly when necessary.
I think
Michael Haggerty mhag...@alum.mit.edu writes:
On 09/26/2014 09:00 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Even the one lockfile object needn't be allocated each time the
function is called. Instead, define one statically-allocated
lock_file object and reuse
Hi list,
I'd like to shorten the time needed by our continuous integration (CI)
tool to clone the source repositories. Currently the full clone takes
about 10 minutes (even from local server). Our main repository has
several submodules so the CI tool runs git submodule update --init. My
idea was
The latest maintenance release Git v2.1.2 is now available at the
usual places. With this, v2.1.x has all the important fixes that
have been already applied to the 'master' front for the next feature
release. It also contains some updates to German translation.
The tarballs are found at:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Many fixes on the 'master' has been merged down to 'maint' and the
tip of the latter is at v2.1.2 now. Among the topics that have been
cooking
On Tue, Sep 30, 2014 at 01:23:18PM -0700, Junio C Hamano wrote:
Here are the topics that have been cooking.
It looks like my boring git-mailinfo doc patch [1] fell through the
cracks here ;). Or maybe it's just cooking a bit longer before
getting queued?
Cheers,
Trevor
[1]: Gmane:
W. Trevor King wk...@tremily.us writes:
On Tue, Sep 30, 2014 at 01:23:18PM -0700, Junio C Hamano wrote:
Here are the topics that have been cooking.
It looks like my boring git-mailinfo doc patch [1] fell through the
cracks here ;). Or maybe it's just cooking a bit longer before
getting
W. Trevor King wk...@tremily.us writes:
And explain how it interacts with the scissors setting.
Signed-off-by: W. Trevor King wk...@tremily.us
---
The three-dash limit comes from f0658cf2 (restrict the patch
filtering, 2007-03-12), but I couldn't find any associated
documentation. Since
On 2014-09-30 11:36, Julien Carsique wrote:
From: Julien Carsique julien.carsi...@gmail.com
When using the name option of GIT_PS1_SHOWUPSTREAM to show the upstream
abbrev name, if the upstream name is the same as the local name, then some
space could be saved in the prompt. This is
On Tue, Sep 30, 2014 at 02:12:58PM -0700, Junio C Hamano wrote:
If we are extending the documentation on ---, …
Ah, I see that the --- are actually mentioned already in the
DISCUSSION section of git-am(1) since 2499857b (git-am documentation:
describe what is taken from where, 2007-03-24). I
Julien Carsique julien.carsi...@gmail.com writes:
From: Julien Carsique julien.carsi...@gmail.com
When using the name option of GIT_PS1_SHOWUPSTREAM to show the upstream
abbrev name, if the upstream name is the same as the local name, then some
space could be saved in the prompt. This is
Richard Hansen rhan...@bbn.com writes:
Additional cases could be added to handle git-svn if needed.
Thanks for a review (everything I omitted above looked good to me).
+
__git_ps1_upstream_name=${__git_ps1_upstream_name/$__head/=}
* This could break if
W. Trevor King wk...@tremily.us writes:
... Maybe we should drop this patch in favor of notes
in git-mailinfo(1) and git-format-patch(1) pointing folks at the
DISCUSSION section in git-am(1) and a more easily grepable “three
dashes ('---') in gi-am(1)?
I am all for dropping new changes and
Hi Torsten,
Thank you for taking the time to review my patch.
On 28 September 2014 04:52, Torsten Bögershausen tbo...@web.de wrote:
On 2014-09-28 02.37, Hilco Wijbenga wrote:
If ~/.gitconfig contains a core.filemode entry then git init
should honour that setting.
Signed-off-by: Hilco
On Tue, Sep 30, 2014 at 01:23:18PM -0700, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
* da/include-compat-util-first-in-c (2014-09-15) 4 commits
- SQUASH???
On 2014-09-30 18:35, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
* While this syntax works in both Bash and Zsh (assuming no
pattern-special characters), my preference is to stick to POSIX[1]
when possible.
Nah. The existing script is full of bash-isms like local
45 matches
Mail list logo
