Re: msysgit works on wine

On 10/10/2014 02:04 PM, Duy Nguyen wrote: > On Fri, Oct 10, 2014 at 7:02 PM, Thomas Braun > wrote: >> Are you compiling git.git or msysgit.git? > > git.git > >> And how about the test suite? > > running right now, fingers crossed.. kinda slow, not sure if it's > wine or it's the msys thing. We

Re: $GIT_DIR/info/exclude fails to negate a pattern defined by core.excludesfile

Hey Duy, I'm not sure why the pattern would have to be as you describe - I'm just looking to ignore `*.out` as a general configuration, and disable it for one specific project, so it would seem a plain `!*.out` should work. In any case, I added a `.gitignore` file with the single pattern `!*.out`

[PATCH] Initialise hash variable to prevent compiler warnings

The 'hash' variable in test-hashmap.c is not initialised properly which causes some 'gcc' versions to complain during compilation. Signed-off-by: Felipe Franciosi --- test-hashmap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test-hashmap.c b/test-hashmap.c index 07aa7

Re: [PATCH v2] Handle atexit list internaly for unthreaded builds

On Mon, Oct 13, 2014 at 2:56 AM, Duy Nguyen wrote: > On Sun, Oct 12, 2014 at 4:09 PM, Etienne Buira > wrote: > > Replace atexit()s calls with cmd_atexit that is atexit() on threaded > > builds, but handles the callbacks list internally for unthreaded builds. > > Maybe hide this in git-compat-ut

[PATCH v3] Handle atexit list internaly for unthreaded builds

Wrap atexit()s calls on unthreaded builds to handle callback list internally. This is needed because on unthreaded builds, asyncs inherits parent's atexit() list, that gets run as soon as the async exit()s (and again at the end of the parent process). That led to remove temporary and lock files to

Re: [PATCH 2/3] t5304: use helper to report failure of "test foo = bar"

Jeff King wrote: > For small outputs, we sometimes use: > > test "$(some_cmd)" = "something we expect" > > instead of a full test_cmp. The downside of this is that > when it fails, there is no output at all from the script. There's another downside to that construct: it loses the exit status fr

Re: [PATCH v3] Handle atexit list internaly for unthreaded builds

Etienne Buira writes: > +#define tmp_atexit atexit > +#define atexit tmp_atexit > +#undef tmp_atexit What is this supposed to do? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely diffe

Re: [PATCH] remote.c - Make remote definition require a url

Mark Levedahl writes: > Some options may be configured globally for a remote (e.g, tagopt). Or some remotes may have only pushurl and not url. "git remote" output for me has a few such remotes but wouldn't this patch break it? If a caller that walks the list of remotes misbehaves only because

Re: Performance Issues with Git Rebase

"Crabtree, Andrew" writes: > I'm getting the same output with both the triple and double dot for my > specific case, but I have no idea if that change makes sense for all > cases or not. Any guidance? The difference only matters if any of your 4 patches have been sent to your upstream and accep

Smart HTTP

Hi, I guess this comment is aimed at Scott Chacon. I have read your blog post on Smart HTTP (http://git-scm.com/blog/2010/03/04/smart-http.html) and wondered if there is any documentation that compares in terms of thoroughness with your sections in the book on using SSH, which does explain the

RE: Performance Issues with Git Rebase

Ah gotcha. That makes sense. Default behavior is to do a patch-id check on all of them which is exactly what you would normally want to happen, and suppressing that speeds things up considerably at the risk of attempting to re-apply an already existing patch. Thanks much for the explanation.

[PATCH v16 03/11] trailer: read and process config information

Read the configuration to get trailer information, and then process it and store it in a doubly linked list. The config information is stored in the list whose first item is pointed to by: static struct trailer_item *first_conf_item; Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

[PATCH v16 02/11] trailer: process trailers from input message and arguments

Implement the logic to process trailers from the input message and from arguments. At the beginning trailers from the input message are in their own "in_tok" doubly linked list, and trailers from arguments are in their own "arg_tok" doubly linked list. The lists are traversed and when an "arg_tok

[PATCH v16 04/11] trailer: process command line trailer arguments

Parse the trailer command line arguments and put the result into an arg_tok doubly linked list. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- trailer.c | 112 ++ 1 file changed, 112 insertions(+) diff --git a/trail

[PATCH v16 01/11] trailer: add data structures and basic functions

We will use a doubly linked list to store all information about trailers and their configuration. This way we can easily remove or add trailers to or from trailer lists while traversing the lists in either direction. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- Makefile |

[PATCH v16 10/11] trailer: add tests for commands in config file

And add a few other tests for some special cases. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- t/t7513-interpret-trailers.sh | 125 ++ 1 file changed, 125 insertions(+) diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-t

[PATCH v16 00/11] Add interpret-trailers builtin

[Sorry to resend this v16, but the series didn't make it to list the first time...] This patch series implements a new command: git interpret-trailers and an infrastructure to process trailers that can be reused, for example in "commit.c". 1) Rationale This command should help with RFC

[PATCH v16 06/11] trailer: put all the processing together and print

This patch adds the process_trailers() function that calls all the previously added processing functions and then prints the results on the standard output. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- trailer.c | 69 +

[PATCH v16 05/11] trailer: parse trailers from file or stdin

Read trailers from a file or from stdin, parse the trailers and then put the result into a doubly linked list. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- trailer.c | 123 ++ 1 file changed, 123 insertions(+) dif

[PATCH v16 08/11] trailer: add tests for "git interpret-trailers"

Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- t/t7513-interpret-trailers.sh | 738 ++ 1 file changed, 738 insertions(+) create mode 100755 t/t7513-interpret-trailers.sh diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-tr

[PATCH v16 09/11] trailer: execute command from 'trailer..command'

Let the user specify a command that will give on its standard output the value to use for the specified trailer. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- trailer.c | 85 ++- 1 file changed, 84 insertions(+), 1

[PATCH v16 11/11] Documentation: add documentation for 'git interpret-trailers'

While at it add git-interpret-trailers to "command-list.txt". Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- Documentation/git-interpret-trailers.txt | 314 +++ command-list.txt | 1 + 2 files changed, 315 insertions(+) c

[PATCH v16 07/11] trailer: add interpret-trailers command

This patch adds the "git interpret-trailers" command. This command uses the previously added process_trailers() function in trailer.c. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano --- .gitignore | 1 + Makefile | 1 + builtin.h

Re: [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables

Jeff King writes: > ... Which makes me wonder if safe-include is really helping that > much versus a project shipping a shell script that munges the repository > config. The latter is less safe (you are, after all, running code, but > you would at least have the chance to examine it), but is way

Re: [PATCH 0/3] "-x" tracing option for tests

Jeff King writes: > These patches are pulled out of the prune-mtime series I posted > earlier[1]. The discussion veered off and there's no reason that the two > topics need to be part of the same series. These look all sensible. Is your plan to reroll the prune-mtime stuff on top of these? The

[PATCH v4] Handle atexit list internaly for unthreaded builds

Wrap atexit()s calls on unthreaded builds to handle callback list internally. This is needed because on unthreaded builds, asyncs inherits parent's atexit() list, that gets run as soon as the async exit()s (and again at the end of the parent process). That led to remove temporary and lock files to

Re: [PATCH v2 3/3] test-lib.sh: support -x option for shell-tracing

Jeff King writes: >> Hmph. I had originally intended to make this "set -x;" with a semicolon, >> to keep it split from $*. But I forgot to, and much to my surprise, all >> of the tests still passed. Yup, I was wondering why you posted a version without the semicolon, which looked obviously bogus

Re: [PATCH v1] rebase -m: Use empty tree base for parentless commits

Hi, Junio C Hamano writes: > Fabian Ruch writes: >> diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh >> index d3fb67d..3f754ae 100644 >> --- a/git-rebase--merge.sh >> +++ b/git-rebase--merge.sh >> @@ -67,7 +67,13 @@ call_merge () { >> GIT_MERGE_VERBOSITY=1 && export GIT_MERGE

Re: Smart HTTP

On Mon, 13 Oct 2014 17:29:05 + "John Norris" wrote: > I guess this comment is aimed at Scott Chacon. > I have read your blog post on Smart HTTP > (http://git-scm.com/blog/2010/03/04/smart-http.html) and wondered if > there is any documentation that compares in terms of thoroughness > with y

Re: [PATCH] receive-pack: plug minor memory leak in unpack()

Jeff King writes: > On Sat, Oct 11, 2014 at 01:00:16PM +0200, René Scharfe wrote: > >> The argv_array used in unpack() is never freed. Instead of adding >> explicit calls to argv_array_clear() use the args member of struct >> child_process and let run_command() and friends clean up for us. > > L

Re: [PATCH 1/2] fix compilation with --disable-pthreads

Etienne Buira writes: > Subject: Re: [PATCH 1/2] fix compilation with --disable-pthreads That probably is a typo of "NO_PTHREADS=NoThanks" or something. Thanks. Just out of curiosity, are you porting to some exotic platforms? > Signed-off-by: Etienne Buira > --- > builtin/index-pack.c | 3 ++

Re: [PATCH v3 2/3] mergetool: don't require a work tree for --tool-help

David Aguilar writes: > From: Charles Bailey > > Signed-off-by: Charles Bailey > Signed-off-by: David Aguilar > --- > Changes since v2: > > This now uses the new git_dir_init function. > > git-mergetool.sh | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/git-merget

Re: [PATCH] mergetool: add an option for writing to a temporary directory

David Aguilar writes: > Teach mergetool to write files in a temporary directory when > 'mergetool.writeToTemp' is true. > > This is helpful for tools such as Eclipse which cannot cope with > multiple copies of the same file in the worktree. > > Suggested-by: Charles Bailey > Signed-off-by: David

Re: [PATCH] mergetool: add an option for writing to a temporary directory

David Aguilar writes: > Teach mergetool to write files in a temporary directory when > 'mergetool.writeToTemp' is true. > > This is helpful for tools such as Eclipse which cannot cope with > multiple copies of the same file in the worktree. With this can we drop the "change the temporary file na

Re: [PATCH v2] mergetool: use more conservative temporary filenames

David Aguilar writes: > Avoid filenames with multiple dots so that overly-picky tools do > not misinterpret their extension. > > Previously, foo/bar.ext in the worktree would result in e.g. > > ./foo/bar.ext.BASE.1234.ext > > This can be improved by having only a single .ext and using > und

Re: [PATCH 2/2] Remove spurious 'no threads support' warnings

Etienne Buira writes: > Threads count being defaulted to 0 (autodetect), and --disable-pthreads > build checking that thread count==1, there were spurious warnings about > threads being ignored, despite not specified on command line/conf. > > Fixes tests 5521 and 5526 that were broken in --disabl

Re: [PATCH v4] Handle atexit list internaly for unthreaded builds

Etienne Buira writes: > Wrap atexit()s calls on unthreaded builds to handle callback list > internally. > > This is needed because on unthreaded builds, asyncs inherits parent's > atexit() list, that gets run as soon as the async exit()s (and again at > the end of the parent process). That led to

Re: [PATCH] Initialise hash variable to prevent compiler warnings

Felipe Franciosi writes: > The 'hash' variable in test-hashmap.c is not initialised properly > which causes some 'gcc' versions to complain during compilation. FNV/I/IDIV10/0 covers all the possibilities of (method & 3), I would have to say that the compiler needs to be fixed. Or insert "defaul

Re: [PATCH 1/4] Documentation: adjust document title underlining

Thanks, obviously correct. -- 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 http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] Allow building Git with Asciidoctor

"brian m. carlson" writes: > This series is designed to implement the changes necessary to build Git > using Asciidoctor instead of AsciiDoc. > > The first two patches are bug fixes. Asciidoctor is stricter about > title underline lengths (± 1 character instead of 2) and requires > matching deli

Re: [PATCH 0/3] "-x" tracing option for tests

On Mon, Oct 13, 2014 at 11:24:42AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > These patches are pulled out of the prune-mtime series I posted > > earlier[1]. The discussion veered off and there's no reason that the two > > topics need to be part of the same series. > > These look al

Re: [PATCH 2/3] t5304: use helper to report failure of "test foo = bar"

On Mon, Oct 13, 2014 at 09:10:22AM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > > For small outputs, we sometimes use: > > > > test "$(some_cmd)" = "something we expect" > > > > instead of a full test_cmp. The downside of this is that > > when it fails, there is no output at all from th

Re: [msysGit] Re: msysgit works on wine

Hi Michael, On Mon, 13 Oct 2014, Michael Stefaniuc wrote: > On 10/10/2014 02:04 PM, Duy Nguyen wrote: > > On Fri, Oct 10, 2014 at 7:02 PM, Thomas Braun > > > >> Are you compiling git.git or msysgit.git? > > > > git.git > > > >> And how about the test suite? > > > > running right now, fingers c

Re: [PATCH 2/3] t5304: use helper to report failure of "test foo = bar"

Jeff King wrote: > On Mon, Oct 13, 2014 at 09:10:22AM -0700, Jonathan Nieder wrote: >> There's another downside to that construct: it loses the exit >> status from some_cmd. > > Yes, although I think in many cases it's not a big deal. For example, > here we lose the exit code of count-objects, but

Re: [PATCH 2/3] t5304: use helper to report failure of "test foo = bar"

On Mon, Oct 13, 2014 at 2:31 PM, Jonathan Nieder wrote: > Jeff King wrote: >> On Mon, Oct 13, 2014 at 09:10:22AM -0700, Jonathan Nieder wrote: > >>> There's another downside to that construct: it loses the exit >>> status from some_cmd. >> >> Yes, although I think in many cases it's not a big deal

Re: [PATCH 2/3] t5304: use helper to report failure of "test foo = bar"

On Mon, Oct 13, 2014 at 02:31:32PM -0700, Jonathan Nieder wrote: > > One of my goals was to provide a more generic helper so that we don't > > have to make little helpers like this for every command. So I'd much > > rather something like: > > > > test_output () { > > printf "%s\n" "$1" >expe

Re: [PATCH 2/3] t5304: use helper to report failure of "test foo = bar"

Junio C Hamano wrote: > On Mon, Oct 13, 2014 at 2:31 PM, Jonathan Nieder wrote: >> It could segfault after producing the good output, but sure, >> count-objects code doesn't change very often. > > "Doesn't change very often" is not the issue. Here we are not testing > if it can count correctly wi

Re: [PATCH] Initialise hash variable to prevent compiler warnings

On Mon, Oct 13, 2014 at 10:53 PM, Felipe Franciosi wrote: > > On Mon, Oct 13, 2014 at 9:12 PM, Junio C Hamano wrote: >> >> Felipe Franciosi writes: >> >> > The 'hash' variable in test-hashmap.c is not initialised properly >> > which causes some 'gcc' versions to complain during compilation. >> >

Re: [PATCH 2/3] t5304: use helper to report failure of "test foo = bar"

Jonathan Nieder writes: > Junio C Hamano wrote: >> On Mon, Oct 13, 2014 at 2:31 PM, Jonathan Nieder wrote: > >>> It could segfault after producing the good output, but sure, >>> count-objects code doesn't change very often. >> >> "Doesn't change very often" is not the issue. Here we are not test

Re: [PATCH RFC] git-am: support any number of signatures

Christian Couder writes: > On Sun, Oct 12, 2014 at 11:36 AM, Christian Couder > wrote: >> >> With v16 you can easily choose if you want to have the S-o-b in the >> output or not, when there is already one, ... > > By the way, I sent v16 just before the above email, but the series > still hasn't

Re: [PATCH v2 3/3] test-lib.sh: support -x option for shell-tracing

Jeff King writes: > On Fri, Oct 10, 2014 at 02:21:56AM -0400, Jeff King wrote: > >> diff --git a/t/test-lib.sh b/t/test-lib.sh >> index a60ec75..81ceb23 100644 >> --- a/t/test-lib.sh >> +++ b/t/test-lib.sh >> @@ -237,7 +237,11 @@ do >> shift ;; >> -x) >> test_eval_s

Re: [PATCH v2 3/3] test-lib.sh: support -x option for shell-tracing

Junio C Hamano writes: > Does 1308 pass with this patch for you (running it without "-x")? > > The original that expects a hardcoded line number (not relative to > the original or something) is a bad taste, and also the test setup > procedure is broken (see below for a fix of that breakage, which

Re: [PATCH v2 3/3] test-lib.sh: support -x option for shell-tracing

On Mon, Oct 13, 2014 at 03:22:50PM -0700, Junio C Hamano wrote: > > Rerolled patch is below. Sorry for all the emails. I'll stop looking at > > it now to give you guys a chance to find any remaining mistakes. ;) > > Does 1308 pass with this patch for you (running it without "-x")? Hmph. It does

Re: [PATCH v2 3/3] test-lib.sh: support -x option for shell-tracing

Jeff King writes: > This fixes it: > > diff --git a/t/test-lib.sh b/t/test-lib.sh > index 4dab575..059bb25 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -528,8 +528,7 @@ maybe_setup_valgrind () { > test_eval_inner_ () { > eval " > test \"$trace\" = t && set -x > -

Re: [PATCH v2 3/3] test-lib.sh: support -x option for shell-tracing

On Mon, Oct 13, 2014 at 06:33:03PM -0400, Jeff King wrote: > > But still it is disturbing to see that there is a blank line > > difference with and without this change in the file created by the > > test (i.e. the client of the code this patch touches). > > This fixes it: > > diff --git a/t/test

Re: [PATCH v2 3/3] test-lib.sh: support -x option for shell-tracing

Jeff King writes: > OK, I lied. I couldn't resist spending 5 more minutes on it. > > If you instrument t1308 on master to look at the contents of .git/config > directly after the setup step, you'll see that the file ends with (tabs > marked as ^I): > > [...] > ^I^Ihorns > ^IEOF > > Which ma

What's cooking summary snapshot

I do not want to do too many "What's cooking" report, so here is just a summary of the status of various topics. Hopefully I'll do the real one later this week after a few more integrations. Thanks. $ Meta/cook -w Expecting a reroll. - jk/makefile

Re: [PATCH 0/4] Allow building Git with Asciidoctor

On Mon, Oct 13, 2014 at 01:41:31PM -0700, Junio C Hamano wrote: > "brian m. carlson" writes: > > > The second two patches implement some basic support for building with > > Asciidoctor. The first of these moves some items into variables due to > > some differences between the AsciiDoc and Asciid

Re: [PATCH v2 3/3] test-lib.sh: support -x option for shell-tracing

On Mon, Oct 13, 2014 at 04:14:59PM -0700, Junio C Hamano wrote: > We came to more or less the same conclusion. With your $*" fixed, > the test "works" as before, with the same definition of "works", > because without your patch the file ends with EOF and with > your original $*" the file ends wit

Re: [PATCH] remote.c - Make remote definition require a url

On 10/13/2014 01:19 PM, Junio C Hamano wrote: Mark Levedahl writes: Some options may be configured globally for a remote (e.g, tagopt). Or some remotes may have only pushurl and not url. "git remote" output for me has a few such remotes but wouldn't this patch break it? If a caller that wal

Re: [PATCH] Initialise hash variable to prevent compiler warnings

On Mon, Oct 13, 2014 at 2:53 PM, Felipe Franciosi wrote: > > On Mon, Oct 13, 2014 at 9:12 PM, Junio C Hamano wrote: >> >> FNV/I/IDIV10/0 covers all the possibilities of (method & 3), I would >> have to say that the compiler needs to be fixed. >> >> Or insert "default:" just before "case HASH_METH

[PATCH] git-prompt.sh: Hide prompt for ignored pwd

Set __git_ps1 to display nothing when present working directory is ignored, triggered by either the new environmental variable GIT_PS1_HIDE_ON_IGNORED_PWD or the new repository configuration variable bash.hideOnIgnoredPwd (or both). In the absence of these settings this change has no effect. Many

You are sending a virus mail

You sent a virus mail, please check you computer for virus. Mail header info: From: git@vger.kernel.org To: yanhua.d...@wolong.com Subject: Returned mail: see transcript for details Date: Tue, 14 Oct 2014 11:32:19 +0700 N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~�

You are sending a virus mail

You sent a virus mail, please check you computer for virus. Mail header info: From: git@vger.kernel.org To: yanhua.d...@wolong.com Subject: Returned mail: see transcript for details Date: Tue, 14 Oct 2014 11:32:19 +0700 N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~�

Re: [PATCH RFC] git-am: support any number of signatures

From: Junio C Hamano > > Christian Couder writes: > >> On Sun, Oct 12, 2014 at 11:36 AM, Christian Couder >> wrote: >>> >>> With v16 you can easily choose if you want to have the S-o-b in the >>> output or not, when there is already one, ... >> >> By the way, I sent v16 just before the above em