On 2014-09-30 18:35, Junio C Hamano wrote:
> Richard Hansen 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 you
>
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
Hi Torsten,
Thank you for taking the time to review my patch.
On 28 September 2014 04:52, Torsten Bögershausen 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 Wijbe
"W. Trevor King" 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 expecially
Richard Hansen 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 ${__head} contai
Julien Carsique writes:
> From: Julien Carsique
>
> 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.
>
> R
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
On 2014-09-30 11:36, Julien Carsique wrote:
> From: Julien Carsique
>
> 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 br
"W. Trevor King" writes:
> And explain how it interacts with the scissors setting.
>
> Signed-off-by: W. Trevor King
> ---
> The three-dash limit comes from f0658cf2 (restrict the patch
> filtering, 2007-03-12), but I couldn't find any associated
> documentation. Since the effect is so similar
"W. Trevor King" 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 queued?
No
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: http://arti
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
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:
ht
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
Michael Haggerty writes:
> On 09/26/2014 09:00 PM, Junio C Hamano wrote:
>> Michael Haggerty 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.
>>>
>>>
Jeff King 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 so,
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 ord
Michael Haggerty 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 reword the rest.
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]
Duy Nguyen 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 majordomo info at
From: Julien Carsique
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 upstream name with the sign '
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
On 09/26/2014 09:00 PM, Junio C Hamano wrote:
> Michael Haggerty 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
>> Signed-
On 09/26/2014 10:40 PM, Junio C Hamano wrote:
> Michael Haggerty 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 sometimes untenable
Ok. Yes, it 's kind of tricky. But the `-- ` does both things.
`-- ` 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 `, awesome feature, I love that, but it's not my
point. (and I'm ac
On 09/26/2014 08:33 PM, Junio C Hamano wrote:
> Michael Haggerty 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: Jonathan Nieder
On Tue, Sep 30, 2014 at 2:02 PM, Marat Radchenko 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 wanted to do this bu
On 09/26/2014 06:31 PM, Junio C Hamano wrote:
> Michael Haggerty 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 needed to be rebas
On Tue, Sep 30, 2014 at 12:48 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sun, Sep 28, 2014 at 2:50 PM, Ben Walton wrote:
>>> Oracle Studio compilers don't allow for static variables in functions
>>> that are defined to be inline. GNU C does permit this. Let's reference
>>> the C99 st
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 compare
Signed-off-by: Marat Radchenko
---
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 git_munmap(void *start, size_
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 CROSS_COMPILE=ia64-li
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
When crosscompiling, one cannot rely on `uname` from host system.
Signed-off-by: Marat Radchenko
---
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
+++ b/config.mak.uname
@@ -14,6
-D__USE_MINGW_ACCESS only affects MinGW and does nothing when
MSVC is used.
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.mak.uname b/config.mak.uname
index a2f380f..20cbdcf 100644
--- a/co
From: Ray Donnelly
Signed-off-by: Ray Donnelly
Signed-off-by: Marat Radchenko
---
config.mak.uname | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 324a7fc..4470a928 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -6,
Unlike MinGW, MinGW-W64 has CONSOLE_FONT_INFOEX already properly defined
in wincon.h.
Signed-off-by: Marat Radchenko
---
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
--- a/compat/winansi.c
+
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
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
in
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 std
pid_t is available in sys/types.h on both MinGW and MinGW-W64
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 1 -
compat/msvc.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 948a174..d113b19 100644
---
Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h.
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index df0e320..ed79368 100644
--- a/compat/mingw.h
+++ b/compat/mi
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 t
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
com
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
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 --
1 file changed, 2 deletions(-)
diff --git a/config.mak.uname b/co
44 matches
Mail list logo
