Re: [PATCH] Pass amend to pre-commit hook

Jeff King peff.net> writes: > > On Mon, Sep 14, 2015 at 01:14:20PM +0100, Alan Clucas wrote: > > > Pass a single parameter 'amend' to the pre-commit hook when performing a > > commit amend. > > I think this is a sensible thing to want, and it has come up a few > times. I'm not sure why the las

[PATCH] builtin/apply.c: make a file local symbol static

Commit dddaaab62 ("apply: convert root string to strbuf", 24-09-2015) converted a combination of variables into a single 'struct strbuf' variable. In doing so, it unintentionally increased the visibility of the variable. In order to reduce the visibility to file local, add the static keyword to t

Re: Single brackets matching in .gitignore rules

On Sunday 27 September 2015 10:58 Andreas Schwab wrote: > > ] by itself is not special in a glob. > > Andreas. > OK, this would explain the current state: once Git sees opened bracket, it always tries to parse the glob pattern and if this fails (if the bracket is not closed), the ignore rule

[PATCH] git-multimail version 1.2 RC1

The changes are described in CHANGES. Contributions-by: Job Snijders Contributions-by: Richard Hansen Contributions-by: Elijah Newren Contributions-by: Michael Haggerty Contributions-by: Paul Sokolovsky Contributions-by: Vadim Zeitlin Contributions-by: Edward d'Auvergne Contributions-by: El

[PATCH 1/2] t3203: test 'detached at' after checkout --detach

This currently fails: the output is 'HEAD detached at HEAD'. --- t/t3203-branch-output.sh | 13 + 1 file changed, 13 insertions(+) diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh index f51d0f3..bf24dbf 100755 --- a/t/t3203-branch-output.sh +++ b/t/t3203-branch-output.

[PATCH 2/2] status: don't say 'HEAD detached at HEAD'

After using "git checkout --detach", the reflog is left with an entry like checkout: moving from ... to HEAD This message is parsed to generate the 'HEAD detached at' message in 'git branch' and 'git status', which leads to the not-so-useful message 'HEAD detached at HEAD'. Instead, when parsi

Re: [PATCH 60/68] prefer memcpy to strcpy

Am 27.09.2015 um 15:13 schrieb René Scharfe: Am 27.09.2015 um 15:06 schrieb Torsten Bögershausen: On 2015-09-27 13.19, René Scharfe wrote: Am 24.09.2015 um 23:08 schrieb Jeff King: When we already know the length of a string (e.g., because we just malloc'd to fit it), it's nicer to use memcpy

Re: [PATCH 60/68] prefer memcpy to strcpy

Am 27.09.2015 um 15:06 schrieb Torsten Bögershausen: On 2015-09-27 13.19, René Scharfe wrote: Am 24.09.2015 um 23:08 schrieb Jeff King: When we already know the length of a string (e.g., because we just malloc'd to fit it), it's nicer to use memcpy than strcpy, as it makes it more obvious that

Re: [PATCH 60/68] prefer memcpy to strcpy

On 2015-09-27 13.19, René Scharfe wrote: > Am 24.09.2015 um 23:08 schrieb Jeff King: >> When we already know the length of a string (e.g., because >> we just malloc'd to fit it), it's nicer to use memcpy than >> strcpy, as it makes it more obvious that we are not going to >> overflow the buffer (be

Re: [RFC/PATCH v1] Add Travis CI support

Luke Diamand writes: > It would be less intrusive for the CI system to have a fork. Otherwise > other people using git with the same CI system will get annoying merge > conflicts, What conflicts are you talking about? The ones in .travis.yml? The point is to share this file so that people using

Re: [PATCH 60/68] prefer memcpy to strcpy

Am 24.09.2015 um 23:08 schrieb Jeff King: When we already know the length of a string (e.g., because we just malloc'd to fit it), it's nicer to use memcpy than strcpy, as it makes it more obvious that we are not going to overflow the buffer (because the size we pass matches the size in the alloca

Re: Single brackets matching in .gitignore rules

Andrey Loskutov writes: > Next, the surprising table for ']': > -- > rule | file | match? > -- > ] ] true > ]* ] true > *] ] true > *] a]true > -- > > Here Git does no