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 not matter, while keep
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
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 prints
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 chil
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
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 reg
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
---
t/t9001-send-email.sh |
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
--- a/Documentation/RelNotes/2.16.0.txt
+++ b/Documentatio
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
th
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, tries to prune and re
> 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. Unfo
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 w
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 any
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__,
> > + &trace_default_key, &buf))
> > +
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 mod
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 lies in how unsuccessful build jobs are
>>> categorized. ...
>>> .
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 env
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 t
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
---
Just a c
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 quo
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
>> retention policy.
>
> Er..
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
>
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
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 susp
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 loose objects
>> 3.
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 b
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 clear_object_
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 alread
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
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 a/convert.h b/convert.h
index 4f2da22..a9a6658 100644
--- a
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, s
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 (because I have too, see 4/
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 is prepended in
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 + 1].string))
>>
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 + 1 < envs.nr &&
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 make_environment_block()
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 Windows we feed cmd
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, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c
> 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 it
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 wa
> 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,
> SAFE_CRLF_FALSE);
> > }
>
> I thin
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 only kicks in on no
"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 wrong. The relevant part
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 here?
Perhaps this
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 output result
>
> The
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, 2011-01-07).
>
> Signe
"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 test-config (it cannot be
the same
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 does
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.
>
> I
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 what the author of the "except" thing
> wanted
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 prep_childenv() would treat that as "last one
>>
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 in the "env" array, as a deletion or with
>>> multiple
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 prints
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 Ham
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 deletion(-)
diff --git a/tr
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 hard to read.
L
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 --git
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).
Signed-off-by: Jeff
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
--- a/trace.c
+++ b/tra
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 reg
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. Would appending "; cd
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 ma
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, c
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 6/7
64 matches
Mail list logo
