[PATCH v3 2/4] trace.c: print program 'git' when child_process.git_cmd is set

We normally print full command line, including the program and its argument. When git_cmd is set, we have a special code path to run the right "git" program and child_process.argv[0] will not contain the program name anymore. As a result, we print just the command arguments. I thought it was a

Re: [PATCH v2] run-command.c: print env vars when GIT_TRACE is set

On Fri, Jan 12, 2018 at 2:27 AM, Junio C Hamano wrote: > I wonder how common it would be to attempt exporting a variable with > the same value, and to attempt unsetting a variable that is not > exported, which might help you reduce the clutter by hiding stuff > that truly do

[PATCH] tests: Deduplicate code in send-email test

Use the wrapper function around the sed statement like everywhere else in the test. Unfortunately the wrapper function is defined pretty late. Move the wrapper to the top of the test file, so future users have it available right away. Signed-off-by: Christian Ludwig ---

[PATCH v3 0/4] run-command.c: print env vars when GIT_TRACE is set

v3 turns a single patch into a series. Changes from v2 - env var quoting is now done correctly (from shell syntax perspective) - the program name is prepended in git_cmd mode - cwd is now printed too (because I have too, see 4/4) - we don't blindly print the env delta anymore but print the actual

[PATCH v3 1/4] trace.c: introduce trace_run_command()

This is the same as the old code that uses trace_argv_printf() in run-command.c. This function will be improved in later patches to print more information from struct child_process. A slight regression: the old code would print run-command.c:xxx as the trace location site while the new code

[PATCH v3 3/4] trace.c: print env vars in trace_run_command()

Occasionally submodule code could execute new commands with GIT_DIR set to some submodule. GIT_TRACE prints just the command line which makes it hard to tell that it's not really executed on this repository. Print modified env variables (compared to parent environment) in this case. Actually only

[PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

The previous concatenate_env() is kinda dumb. It receives a env delta in child_process and blindly follows it. If the run_command() user "adds" more vars of the same value, or deletes vars that do not exist in parent env in the first place (*), then why bother to print them? This patch checks

[PATCH] send-email: Support separate Reply-To address

In some projects contributions from groups are only accepted from a common group email address. But every individual may want to recieve replies to her own personal address. That's what we have 'Reply-To' headers for in SMTP. Introduce an optional '--reply-to' command line option. Unfortunately

[PATCH] RelNotes: minor typofix

Signed-off-by: SZEDER Gábor --- Documentation/RelNotes/2.16.0.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/2.16.0.txt b/Documentation/RelNotes/2.16.0.txt index 0c8464492..919f3eb3e 100644 ---

Re: [PATCH] send-email: Support separate Reply-To address

> In some projects contributions from groups are only accepted from a > common group email address. But every individual may want to recieve > replies to her own personal address. That's what we have 'Reply-To' > headers for in SMTP. > > Introduce an optional '--reply-to' command line option.

Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects

On Fri, Jan 12, 2018 at 4:33 AM, Ævar Arnfjörð Bjarmason wrote: > For those rusty on git-gc's defaults, this is what it looks like in this > scenario: > > 1. User runs "git pull" > 2. git gc --auto is called, there are >6700 loose objects > 3. it forks into the background,

Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects

On Fri, Jan 12 2018, Duy Nguyen jotted: > On Fri, Jan 12, 2018 at 4:33 AM, Ævar Arnfjörð Bjarmason > wrote: >> For those rusty on git-gc's defaults, this is what it looks like in this >> scenario: >> >> 1. User runs "git pull" >> 2. git gc --auto is called, there are >6700

RE: [BUG] Weird breakages in t1450 #2 on NonStop

On January 12, 2018 9:39 AM, Jeff King wrote: > On Thu, Jan 11, 2018 at 04:39:04PM -0500, Randall S. Becker wrote: > > > > executed because the test_commit fails with a non-zero git commit > > > completion code. There is no rn (actual r n 252 252 252 252) in > > > the objects directory - even

Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects

On Fri, Jan 12, 2018 at 08:46:09AM -0500, Jeff King wrote: > On Thu, Jan 11, 2018 at 10:33:15PM +0100, Ævar Arnfjörð Bjarmason wrote: > > > 4. At the end of all this, we check *again* if we have >6700 objects, > > if we do we print "run 'git prune'" to .git/gc.log, and will just > > emit

HELLO!!

Dear GOD Elect, It's my pleasure to have contact with you, based on the critical condition I find mine self, though, it's not financial problem, but my health, you might have know that cancer is not what to talk home about, though I don't know you, and my contact with you was not by mistake, but

Re: [PATCH] l10n: de.po: translate 72 new messages

Hi Ralf, thanks for your translations. The only thing that could be changed is: > #: builtin/submodule--helper.c:678 > msgid "" > "Use commit stored in the index instead of the one stored in the submodule " > "HEAD" > -msgstr "" > +msgstr "benutze den Commit, der im Index gespeichert ist,

Re: [PATCH v2 4/9] object: add clear_commit_marks_all()

On Thu, Jan 11, 2018 at 07:57:42PM +0100, René Scharfe wrote: > > Is it worth having: > > > >void clear_object_flags_from_type(int type, unsigned flags); > > > > rather than having two near-identical functions? I guess we'd need some > > way of saying "all types" to reimplement

[PATCH] Fixed pervasive enumeration warning in convert.h.

From: "Randall S. Becker" The actual enum value should be used rather than 0 and was causing a warning in an inline proc. Signed-off-by: Randall S. Becker --- convert.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v2 5/9] bisect: avoid using the rev_info flag leak_pending

On Thu, Jan 11, 2018 at 07:57:51PM +0100, René Scharfe wrote: > > If we already have the list of tips, could we just feed it ourselves to > > bisect_rev_setup (I think that would require us remembering which were > > "good" and "bad", but that doesn't seem like a big deal). > > That's done

Re: [BUG] Weird breakages in t1450 #2 on NonStop

On Thu, Jan 11, 2018 at 04:39:04PM -0500, Randall S. Becker wrote: > > executed because the test_commit fails with a non-zero git commit > > completion code. There is no rn (actual r n 252 252 252 252) in > > the objects directory - even the 'rn' does not correspond to > > anything.. I am

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

On 01/12, Jeff King wrote: > On Fri, Jan 12, 2018 at 11:19:44AM -0800, Junio C Hamano wrote: > > > Jeff King writes: > > > > > The actual prep_childenv() code looks like it would always do > > > last-one-wins, so we should treat FOO as unset in that final case. But > > > that

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

On Fri, Jan 12, 2018 at 11:19:44AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > The actual prep_childenv() code looks like it would always do > > last-one-wins, so we should treat FOO as unset in that final case. But > > that only kicks in on non-Windows. > > > > On

Re: [PATCH] Fixed pervasive enumeration warning in convert.h.

randall.s.bec...@rogers.com writes: > From: "Randall S. Becker" > > The actual enum value should be used rather than 0 and was causing > a warning in an inline proc. > > Signed-off-by: Randall S. Becker > --- > convert.h | 2 +- > 1 file changed,

Re: [PATCH v3 0/4] run-command.c: print env vars when GIT_TRACE is set

On Fri, Jan 12, 2018 at 5:36 AM, Jeff King wrote: > On Fri, Jan 12, 2018 at 04:56:03PM +0700, Nguyễn Thái Ngọc Duy wrote: > >> v3 turns a single patch into a series. Changes from v2 >> >> - env var quoting is now done correctly (from shell syntax perspective) >> - the program name

RE: [PATCH] Fixed pervasive enumeration warning in convert.h.

> From: Junio C Hamano [mailto:gits...@pobox.com] On January 12, 2018 2:25 PM, Junio C Hamano wrote: > > From: "Randall S. Becker" > > { > > - return convert_to_git(istate, path, NULL, 0, NULL, 0); > > + return convert_to_git(istate, path, NULL, 0, NULL, >

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

On Fri, Jan 12, 2018 at 10:24:28AM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> + /* > >> + * Do we have a sequence of "unset GIT_DIR; GIT_DIR=foo"? > >> + * Then don't bother with the unset thing. > >> + */ > >> + if (i

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

Jeff King writes: >> +/* >> + * Do we have a sequence of "unset GIT_DIR; GIT_DIR=foo"? >> + * Then don't bother with the unset thing. >> + */ >> +if (i + 1 < envs.nr && >> +!strcmp(env, envs.items[i +

RE: [ANNOUNCE] Git v2.16.0-rc2 - breakages in t1308 and 1404

On January 11, 2018 11:11 PM, Junio C Hamano wrote: > A release candidate Git v2.16.0-rc2 is now available for testing at the usual > places. It is comprised of 483 non-merge commits since v2.15.0, contributed > by 80 people, 23 of which are new faces. Please forgive my not knowing the proper

Re: [PATCH v3 0/4] run-command.c: print env vars when GIT_TRACE is set

On Fri, Jan 12, 2018 at 1:56 AM, Nguyễn Thái Ngọc Duy wrote: > v3 turns a single patch into a series. Changes from v2 > > - env var quoting is now done correctly (from shell syntax perspective) > - the program name is prepended in git_cmd mode > - cwd is now printed too

Re: [PATCH 0/4] Speed up git tag --contains

> This is a resubmission of Jeff King's patch series to speed up git tag > --contains with some changes. It's been cooking for a while as: Replying to this 6-year-old thread: Is there any chance this could be resurrected? We are using phabricator, which uses `git branch --contains` as part of

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

Jeff King writes: > The actual prep_childenv() code looks like it would always do > last-one-wins, so we should treat FOO as unset in that final case. But > that only kicks in on non-Windows. > > On Windows we feed cmd->env straight to mingw_spawnvpe(). That ends up > in

Re: [ANNOUNCE] Git v2.16.0-rc2 - breakages in t1308 and 1404

"Randall S. Becker" writes: > Sadly, fixing the "except" thing causes the test to break now. That is exactly what I wanted to say. If you want to "fix" it, you'd need to figure out what the author of the "except" thing wanted to test, adjust the args given to

Git uses wrong subkey for signing commits with GPG key

I have an issue with git and signing commits with GPG subkey. My setup: - master key used for certification only - subkey for my main workstation - subkey for my mobile workstation (a notebook). Both subkeys are used for signing only. I've configured git to use my specific subkey however it

Re: [PATCH v3 0/4] run-command.c: print env vars when GIT_TRACE is set

On Sat, Jan 13, 2018 at 12:19 AM, Stefan Beller wrote: >> Oh.. before anybody asks, I'm not adding git prefix to the "cd" part. >> You're supposed to know that git moves back to worktree top dir when >> you read $GIT_TRACE (or are welcome to improve the print out). > > Heh.

Re: [PATCH v4 0/7] Trace env variables in run_command()

On Sat, Jan 13, 2018 at 01:49:42PM +0700, Nguyễn Thái Ngọc Duy wrote: > v4: > > - incorporates Jeff patches and moves them on top > - removes strbuf release from print_trace_line > - prints 'unset a b c' instead of 'unset a; unset b; unset c' > - squashes v3 3/4 and 4/4 and Junio's patch into

Re: [PATCH v4 6/7] trace.c: print env vars in trace_run_command()

On Sat, Jan 13, 2018 at 01:49:48PM +0700, Nguyễn Thái Ngọc Duy wrote: > diff --git a/t/helper/test-run-command.c b/t/helper/test-run-command.c > index d24d157379..0ab71f14fb 100644 > --- a/t/helper/test-run-command.c > +++ b/t/helper/test-run-command.c > @@ -56,6 +56,10 @@ int cmd_main(int argc,

Re: [ANNOUNCE] Git v2.16.0-rc2 - breakages in t1308 and 1404

On Fri, Jan 12, 2018 at 5:27 PM, Junio C Hamano wrote: > > "Randall S. Becker" writes: > > > Sadly, fixing the "except" thing causes the test to break now. > > That is exactly what I wanted to say. If you want to "fix" it, > you'd need to figure out

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

On Sat, Jan 13, 2018 at 5:54 AM, Junio C Hamano wrote: > Jeff King writes: > >> I also think this is a special case of a more general problem. FOO could >> appear any number of times in the "env" array, as a deletion or with >> multiple values. Our

[PATCH v4 2/7] trace: avoid unnecessary quoting

From: Jeff King Trace output which contains arbitrary strings (e.g., the arguments to commands which we are running) is always passed through sq_quote_buf(). That function always adds single-quotes, even if the output consists of vanilla characters. This can make the output a bit

[PATCH v4 0/7] Trace env variables in run_command()

v4: - incorporates Jeff patches and moves them on top - removes strbuf release from print_trace_line - prints 'unset a b c' instead of 'unset a; unset b; unset c' - squashes v3 3/4 and 4/4 and Junio's patch into 6/7 - adds tests - cwd is separated in 7/7 interdiff with what's on 'pu': diff

[PATCH v4 4/7] trace.c: introduce trace_run_command()

This is the same as the old code that uses trace_argv_printf() in run-command.c. This function will be improved in later patches to print more information from struct child_process. A slight regression: the old code would print run-command.c:xxx as the trace location site while the new code

[PATCH v4 6/7] trace.c: print env vars in trace_run_command()

Occasionally submodule code could execute new commands with GIT_DIR set to some submodule. GIT_TRACE prints just the command line which makes it hard to tell that it's not really executed on this repository. Print the env delta (compared to parent environment) in this case. Helped-by: Junio C

[PATCH v4 3/7] trace.c: move strbuf_release() out of print_trace_line()

The function is about printing a trace line, not releasing the buffer it receives too. Move strbuf_release() back outside. This makes it easier to see how strbuf is managed. Signed-off-by: Nguyễn Thái Ngọc Duy --- trace.c | 5 - 1 file changed, 4 insertions(+), 1

[PATCH v4 1/7] sq_quote_argv: drop maxlen parameter

From: Jeff King No caller passes anything but "0" for this parameter, which requests that the function ignore it completely. In fact, in all of history there was only one such caller, and it went away in 7f51f8bc2b (alias: use run_command api to execute aliases, 2011-01-07).

[PATCH v4 7/7] trace.c: print new cwd in trace_run_command()

If a command sets a new env variable GIT_DIR=.git, we need more context to know where that '.git' is related to. Signed-off-by: Nguyễn Thái Ngọc Duy --- trace.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/trace.c b/trace.c index ffa1cf9b91..4bfd3fce10 100644 ---

[PATCH v4 5/7] trace.c: print program 'git' when child_process.git_cmd is set

We normally print full command line, including the program and its argument. When git_cmd is set, we have a special code path to run the right "git" program and child_process.argv[0] will not contain the program name anymore. As a result, we print just the command arguments. I thought it was a

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

On Sat, Jan 13, 2018 at 11:54 AM, Duy Nguyen wrote: > On Sat, Jan 13, 2018 at 5:54 AM, Junio C Hamano wrote: >> Jeff King writes: >> >>> I also think this is a special case of a more general problem. FOO could >>> appear any number of times

Re: [PATCH v4 3/7] trace.c: move strbuf_release() out of print_trace_line()

On Sat, Jan 13, 2018 at 01:49:45PM +0700, Nguyễn Thái Ngọc Duy wrote: > The function is about printing a trace line, not releasing the buffer it > receives too. Move strbuf_release() back outside. This makes it easier > to see how strbuf is managed. This is kind of a funny refactor, in that it

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

Jeff King writes: > I also think this is a special case of a more general problem. FOO could > appear any number of times in the "env" array, as a deletion or with > multiple values. Our prep_childenv() would treat that as "last one > wins", I think. Could we just do the same

RE: [ANNOUNCE] Git v2.16.0-rc2 - breakages in t1308 and 1404

On January 12, 2018 5:08 PM, Junio C Hamano wrote: > "Randall S. Becker" writes: > > It looks like the exit code is coming back as 1 not 2. There is also a > > file except vs expect. > > ./trash directory.t1308-config-set: ls a-directory actual config2 > > except expect

Re: [PATCH 5/4] sq_quote_argv: drop maxlen parameter

Jeff King writes: > No caller passes anything but "0" for this parameter, which > requests that the function ignore it completely. In fact, in > all of history there was only one such caller, and it went > away in 7f51f8bc2b (alias: use run_command api to execute > aliases,

Re: [ANNOUNCE] Git v2.16.0-rc2 - breakages in t1308 and 1404

"Randall S. Becker" writes: > It looks like the exit code is coming back as 1 not 2. There is > also a file except vs expect. > ./trash directory.t1308-config-set: ls > a-directory actual config2 except expect output result The test that leaves "except" does look

Re: Git uses wrong subkey for signing commits with GPG key

Hi Andrzej, Andrzej Ośmiałowski wrote: > I have an issue with git and signing commits with GPG subkey. > > My setup: > - master key used for certification only > - subkey for my main workstation > - subkey for my mobile workstation (a notebook). > > Both subkeys are used for signing only. > >

Re: [PATCH v3 2/4] trace.c: print program 'git' when child_process.git_cmd is set

On Fri, Jan 12, 2018 at 04:56:05PM +0700, Nguyễn Thái Ngọc Duy wrote: > We normally print full command line, including the program and its > argument. When git_cmd is set, we have a special code path to run the > right "git" program and child_process.argv[0] will not contain the > program name

Re: [PATCH v3 1/4] trace.c: introduce trace_run_command()

On Fri, Jan 12, 2018 at 04:56:04PM +0700, Nguyễn Thái Ngọc Duy wrote: > This is the same as the old code that uses trace_argv_printf() in > run-command.c. This function will be improved in later patches to > print more information from struct child_process. > > A slight regression: the old code

Re: [PATCH v3 3/4] trace.c: print env vars in trace_run_command()

On Fri, Jan 12, 2018 at 04:56:06PM +0700, Nguyễn Thái Ngọc Duy wrote: > Occasionally submodule code could execute new commands with GIT_DIR set > to some submodule. GIT_TRACE prints just the command line which makes it > hard to tell that it's not really executed on this repository. > > Print

Re: [PATCH] travis-ci: build Git during the 'script' phase

On Mon, Jan 8, 2018 at 11:38 PM, Lars Schneider wrote: > >> On 08 Jan 2018, at 23:07, Junio C Hamano wrote: >> >> SZEDER Gábor writes: >> >>> The reason why Travis CI does it this way and why it's a better >>> approach than ours

Re: [PATCH v3 4/4] trace.c: be smart about what env to print in trace_run_command()

On Fri, Jan 12, 2018 at 04:56:07PM +0700, Nguyễn Thái Ngọc Duy wrote: > The previous concatenate_env() is kinda dumb. It receives a env delta > in child_process and blindly follows it. If the run_command() user > "adds" more vars of the same value, or deletes vars that do not exist > in parent

Re: [PATCH v3 0/4] run-command.c: print env vars when GIT_TRACE is set

On Fri, Jan 12, 2018 at 04:56:03PM +0700, Nguyễn Thái Ngọc Duy wrote: > v3 turns a single patch into a series. Changes from v2 > > - env var quoting is now done correctly (from shell syntax perspective) > - the program name is prepended in git_cmd mode > - cwd is now printed too (because I have

[PATCH 5/4] sq_quote_argv: drop maxlen parameter

No caller passes anything but "0" for this parameter, which requests that the function ignore it completely. In fact, in all of history there was only one such caller, and it went away in 7f51f8bc2b (alias: use run_command api to execute aliases, 2011-01-07). Signed-off-by: Jeff King

Re: [PATCH v3 1/4] trace.c: introduce trace_run_command()

On Fri, Jan 12, 2018 at 08:05:22AM -0500, Jeff King wrote: > > +void trace_run_command(const struct child_process *cp) > > +{ > > + struct strbuf buf = STRBUF_INIT; > > + > > + if (!prepare_trace_line(__FILE__, __LINE__, > > + _default_key, )) > > + return;

[PATCH 6/4] trace: avoid unnecessary quoting

Trace output which contains arbitrary strings (e.g., the arguments to commands which we are running) is always passed through sq_quote_buf(). That function always adds single-quotes, even if the output consists of vanilla characters. This can make the output a bit hard to read. Let's avoid the

Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects

On Fri, Jan 12, 2018 at 7:07 PM, Duy Nguyen wrote: >> More generally, these hard limits seem contrary to what the user cares >> about. E.g. I suspect that most of these loose objects come from >> branches since deleted in upstream, whose objects could have a different >>

Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects

On Thu, Jan 11, 2018 at 10:33:15PM +0100, Ævar Arnfjörð Bjarmason wrote: > 4. At the end of all this, we check *again* if we have >6700 objects, > if we do we print "run 'git prune'" to .git/gc.log, and will just > emit that error for the next day before trying again, at which point >