Signed-off-by: Alex Henrie
---
builtin/log.c | 9 -
t/t4202-log.sh | 10 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 281af8c1e..d755a5960 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -52,6 +52,11 @@ struct line_opt_
2017-03-23 12:03 GMT-06:00 Junio C Hamano :
> Alex Henrie writes:
>
>> Yes, that makes sense. I assume that when you talk about 'next', you
>> mean 'master'?
>
> No, I do mean 'next'. See "A note from the maintainer" post that
> are sent to the list every once in a while (i.e. after a new release
Junio C Hamano wrote:
> Signed-off-by: Junio C Hamano
> ---
> Documentation/git-branch.txt | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Jonathan Nieder
Thanks.
The paragraph begins with a sample command line `git branch `
that has nothing to do with the option being described. Remove it,
but use the space to instead show that multiple patterns can be
given.
Also mention the unfortunate `-l` that can be easily confused with
it.
Helped-by: Jonathan Niede
Uses dir_iterator to traverse through remove_subtree()'s directory tree,
avoiding the need for recursive calls to readdir() and simplifying code.
Suggested in the GSoC microproject list, as well as:
https://public-inbox.org/git/xmqqk27m4h3h@gitster.mtv.corp.google.com/
A conversion similar in
On Wed, Mar 22, 2017 at 10:43:18PM -0700, Junio C Hamano wrote:
> - test_eval_ "(exit 117) && $1"
> - if test "$?" != 117; then
> - error "bug in the test script: broken &&-chain: $1"
> + if test "OK-117" != "$(test_eval_ "(exit 117) &&
> $1
Jonathan Nieder writes:
>> without failure (e.g. "cat" in the above example), which makes the
>> command appear to work, without eve executing the remainder of the
>
> s/eve/ever/
Oops.
>> +if test "OK-117" != "$(test_eval_ "(exit 117) &&
>> $1${LF}${LF}echo OK-\$?" 3>&1)"
>> +
Hi,
Junio C Hamano wrote:
> We found a few run-away here documents that are started with an
> end-of-here-doc marker that is incorrectly spelled, e.g.
>
> git some command >actual &&
> cat ...
> EOF &&
> test_cmp expect actual
>
> which ends up slurping the
On Thu, Mar 23, 2017 at 04:38:37PM +0100, SZEDER Gábor wrote:
> The one-liner awk script in __git_match_ctag() listing ctags symbol
> names for 'git grep ' is already smart enough to list only symbol
> names matching the current word to be completed.
>
> Extend this helper function to accept pref
Johannes Schindelin writes:
> @@ -926,14 +930,14 @@ static void record_in_rewritten(struct object_id *oid,
> static int do_pick_commit(enum todo_command command, struct commit *commit,
> struct replay_opts *opts, int final_fixup)
> {
> - int edit = opts->edit, cleanup_commit_m
Hi,
Ævar Arnfjörð Bjarmason wrote:
> --- a/t/README
> +++ b/t/README
> @@ -612,8 +612,10 @@ library for your script to use.
> - test_have_prereq
>
> Check if we have a prerequisite previously set with
> - test_set_prereq. The most common use of this directly is to skip
> - all the te
On Thu, Mar 23, 2017 at 04:38:39PM +0100, SZEDER Gábor wrote:
> Just like in the case of search patterns for 'git grep', see 29eec71f2
> (completion: match ctags symbol names in grep patterns, 2011-10-21)),
> a common thing to look for using 'git log -S', '-G' and '-L:' is the
> name of a symbol.
Hi,
Ævar Arnfjörð Bjarmason wrote:
> I couldn't find any previous list discussion about this, but if not I
> think something like:
>
> git [checkout|branch] --copy src dest
>
> Would make sense as an interface for this.
Sounds good to me. :)
Thanks,
Jonathan
On Thu, Mar 23, 2017 at 04:38:38PM +0100, SZEDER Gábor wrote:
> The previous commit doubled the number of __git_match_ctag()'s
> positional parameters, and, to keep the position of existing
> parameters for the sake of backwards compatibility, the prefix,
> current word and suffix parameters ended
Junio C Hamano wrote:
> I can go without "Do not forget ..." and everything that follows,
> though, and if we are going to do so, then
>
> --list::
> List branches. With optional ...,
> e.g. `git branch --list 'maint-*`, list only the
> branches tha
On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote:
> Santiago Torres writes:
>
> > This sounds like a helpful addition to implement. We could update/add
> > tests for compliance on this once the feature is addded and fix the
> > ambiguous behavior in the tests now.
>
> OK, so has e
On Thu, Mar 23, 2017 at 4:04 PM, Stefan Beller wrote:
>
> We could have had closing before the child finished before as well:
> * the first read happens with strbuf_read(&buf, cp.out, 1024);
The 1024 is only a hint. So it actually reads the output in full.
So I guess I'll come up with a test for
On Thu, Mar 23, 2017 at 3:50 PM, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
>> Instead of implementing line reading yet again, make use of our beautiful
>> library functions.
>>
>> Signed-off-by: Stefan Beller
>> ---
>> submodule.c | 14 ++
>> 1 file changed, 2 insertions(+), 12
Hi Juraj,
On 23/03/2017 15:26, Juraj Oršulić wrote:
> Hello Igor (and others), I have something else to report about the
> commit amend functionality in git-gui, and I think it could be
> related to my original question. It seems that git-gui messes up
> international signs on amending.
>
> E.g.
Stefan Beller wrote:
> Instead of implementing line reading yet again, make use of our beautiful
> library functions.
>
> Signed-off-by: Stefan Beller
> ---
> submodule.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
This changes buffering behavior in two ways:
- by u
Jonathan Nieder writes:
> Brandon Williams wrote:
>
>> When using rebase --interactive where one of the lines is marked as
>> 'edit' this is the resulting output:
>>
>> Stopped at ec3b9c4... stuffYou can amend the commit now, with
> [...]
>> Signed-off-by: Brandon Williams
>> ---
>> sequen
Stefan Beller wrote:
> struct argv_array is easier to use and maintain
Yes!
[...]
> submodule.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
I also like the diffstat. :)
[...]
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1043,12 +1043,6 @@ unsigned is_submodule_modified
When a nested submodule has untracked files, it would be reported as
"modified submodule" in the superproject, because submodules are not
parsed correctly in is_submodule_modified as they are bucketed into
the modified pile as "they are not an untracked file".
Signed-off-by: Stefan Beller
---
su
Migrate 'is_submodule_modified' to the new porcelain format of
git-status. This conversion attempts to convert faithfully, i.e.
the behavior ought to be exactly the same.
As the output in the parsing only distinguishes between untracked files
and the rest, this is easy to port to the new format, a
This makes it easier for a follow up patch.
Signed-off-by: Stefan Beller
---
submodule.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/submodule.c b/submodule.c
index da1db90dda..93d6f08b50 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1072,16 +1072,14 @@ un
struct argv_array is easier to use and maintain
Signed-off-by: Stefan Beller
---
submodule.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/submodule.c b/submodule.c
index 3200b7bb2b..2c667ac95a 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1043,12 +1043,6 @@ uns
By having a stricter check in the superproject we catch errors earlier,
instead of spawning a child process to tell us.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
submodule.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/submodule.c b/submodule.c
in
Instead of implementing line reading yet again, make use of our beautiful
library functions.
Signed-off-by: Stefan Beller
---
submodule.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/submodule.c b/submodule.c
index 2c667ac95a..c1b7b78260 100644
--- a/submod
If I add an untracked file to a submodule or modify a tracked file,
currently "git status --short" treats the change in the same way as
changes to the current HEAD of the submodule:
$ git clone --quiet --recurse-submodules
https://gerrit.googlesource.com/gerrit
$ echo hello >gerri
v5:
* fixed rebase error in the first 2 patches
* the last 3 patches introduce behavior change outside the scope of
is_modified_submodule
whereas the first 4 ought to just be local changes.
Thanks,
Stefan
v4:
* broken down in a lot of tiny patches.
Jonathan wrote:
> Patch 1/3 is the one tha
On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote:
> Santiago Torres writes:
> OK, so has everybody agreed what the next step would be?
I believe it is, although I imagine getting a confirmation from Peff
would be adequate.
> Is the patch below a good first step (I still need to
Johannes Schindelin wrote:
> On Wed, 22 Mar 2017, Jonathan Nieder wrote:
> > Johannes Schindelin wrote:
>>> As to the default of seriously slowing down all SHA-1 computations:
>>> since you made that the default, at compile time, with no way to turn
>>> on the faster computation, this will have a
On Thu, Mar 23, 2017 at 10:36 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Thu, Mar 23, 2017 at 6:13 PM, Junio C Hamano wrote:
>>> Ævar Arnfjörð Bjarmason writes:
>>>
Amend the test suite to test for more invalid uses like "-l -a"
etc. This change tests this co
Brandon Williams wrote:
> When using rebase --interactive where one of the lines is marked as
> 'edit' this is the resulting output:
>
> Stopped at ec3b9c4... stuffYou can amend the commit now, with
[...]
> Signed-off-by: Brandon Williams
> ---
> sequencer.c | 2 +-
> 1 file changed, 1 inse
Santiago Torres writes:
> This sounds like a helpful addition to implement. We could update/add
> tests for compliance on this once the feature is addded and fix the
> ambiguous behavior in the tests now.
OK, so has everybody agreed what the next step would be? Is the
patch below a good first s
Ævar Arnfjörð Bjarmason writes:
> On Thu, Mar 23, 2017 at 7:15 PM, Junio C Hamano wrote:
>> Ulrik Sverdrup writes:
>>
>>> Git produces a misleading error when you tell it `git revert -m 0`.
>>
>> Thanks.
>>
>> I think this is the same issue as the one with 'cherry-pick' that
>> was reported ear
Ævar Arnfjörð Bjarmason writes:
> On Thu, Mar 23, 2017 at 6:13 PM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> Amend the test suite to test for more invalid uses like "-l -a"
>>> etc. This change tests this code path in builtin/tag.c:
>>>
>>> `(argc == 0 && !cmdmode)`
>
Ævar Arnfjörð Bjarmason writes:
>> Hmph, wouldn't we want to instead replace it with
>>
>> ... something to set expectation ... >expect &&
>> git tag -n 100 >actual &&
>> test_cmp expect actual &&
>>
>> here?
>
> Nope, we already have detailed tests for "tag -n 100" and th
Ævar Arnfjörð Bjarmason writes:
>>> --list::
>>> - Activate the list mode. `git branch ` would try to create a
>>> branch,
>>> + Activate the list mode. `git branch ` would try to create
>>> a branch,
>>> use `git branch --list ` to list matching branches.
>>
>> This makes the de
On Thu, Mar 23, 2017 at 2:09 PM, Stefan Beller wrote:
> v4:
> * broken down in a lot of tiny patches.
>
except for the first 2 patches, which are a rebase error :(
Please ignore.
If I add an untracked file to a submodule or modify a tracked file,
currently "git status --short" treats the change in the same way as
changes to the current HEAD of the submodule:
$ git clone --quiet --recurse-submodules
https://gerrit.googlesource.com/gerrit
$ echo hello >gerri
Signed-off-by: Stefan Beller
---
submodule.c | 16 ++--
t/t3600-rm.sh | 2 +-
t/t7506-status-submodule.sh | 2 +-
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/submodule.c b/submodule.c
index e06e52b993..0f477f3a4e 100644
--- a/submodu
v4:
* broken down in a lot of tiny patches.
Jonathan wrote:
> Patch 1/3 is the one that gives me pause, since I hadn't been able to
> chase down all callers. Would it be feasible to split that into two:
> one patch to switch to --porcelain=2 but not change behavior, and a
> separate patch to impr
By having a stricter check in the superproject we catch errors earlier,
instead of spawning a child process to tell us.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
submodule.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/submodule.c b/submodule.c
in
Migrate 'is_submodule_modified' to the new porcelain format of
git-status.
As the old porcelain only reported ' M' for submodules, no
matter what happened inside the submodule (untracked files,
changes to tracked files or move of HEAD), the new API
properly reports the different scenarios.
In a f
struct argv_array is easier to use and maintain
Signed-off-by: Stefan Beller
---
submodule.c | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/submodule.c b/submodule.c
index d355ddb46b..dc61ca7103 100644
--- a/submodule.c
+++ b/sub
This makes it easier for a follow up patch.
Signed-off-by: Stefan Beller
---
submodule.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/submodule.c b/submodule.c
index da1db90dda..93d6f08b50 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1072,16 +1072,14 @@ un
Instead of implementing line reading yet again, make use of our beautiful
library functions.
Signed-off-by: Stefan Beller
---
submodule.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/submodule.c b/submodule.c
index dc61ca7103..f01e84faff 100644
--- a/submod
Migrate 'is_submodule_modified' to the new porcelain format of
git-status. This conversion attempts to convert faithfully, i.e.
the behavior ought to be exactly the same.
As the output in the parsing only distinguishes between untracked files
and the rest, this is easy to port to the new format, a
On Thu, Mar 23, 2017 at 6:01 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Change an example for `git branch ` to say `git branch
>> ` to be consistent with the synopsis. This changes
>> documentation added in d8d33736b5 ("branch: allow pattern arguments",
>> 2011-08-28).
>>
>
On Thu, Mar 23, 2017 at 2:38 PM, Jeff King wrote:
> On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:
>
>> > I think we do build against PRs now. E.g.:
>> >
>> > https://travis-ci.org/git/git/builds/213896051
>> >
>> > But it looks like we can turn that off.
>>
>> When we add a secr
On Thu, Mar 23, 2017 at 09:39:14PM +0100, Lars Schneider wrote:
> > Could be. Looking at:
> >
> > https://travis-ci.org/peff/git/branches
> >
> > It seems to timeout on over half the branches (in fact, there are only a
> > few that passed all of the tests). My pattern is particularly spiky from
On Thu, Mar 23, 2017 at 01:30:41PM -0700, Junio C Hamano wrote:
> >> We can blacklist these branches with a regex in the travis.yml:
> >> https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches
> >
> > I had a feeling it might be something like that. So we would all need t
On Thu, Mar 23, 2017 at 7:15 PM, Junio C Hamano wrote:
> Ulrik Sverdrup writes:
>
>> Git produces a misleading error when you tell it `git revert -m 0`.
>
> Thanks.
>
> I think this is the same issue as the one with 'cherry-pick' that
> was reported earlier. We have a fix in the 'master' branch
On Thu, Mar 23, 2017 at 6:29 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
>> index 2640c6955c..491dba065c 100644
>> --- a/Documentation/git-tag.txt
>> +++ b/Documentation/git-tag.txt
>> @@ -82,10 +82,11 @@ OPT
> On 23 Mar 2017, at 21:20, Jeff King wrote:
>
> On Thu, Mar 23, 2017 at 09:00:33PM +0100, Lars Schneider wrote:
>
>>> Ah, OK, that makes sense. So we would only have to worry about our _own_
>>> code accidentally disclosing it. But that should be easy to look for by
>>> grepping the log (did s
On Thu, Mar 23, 2017 at 6:13 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Amend the test suite to test for more invalid uses like "-l -a"
>> etc. This change tests this code path in builtin/tag.c:
>>
>> `(argc == 0 && !cmdmode)`
>> ->
>> `((create_tag_object || fo
Jeff King writes:
>> We can blacklist these branches with a regex in the travis.yml:
>> https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches
>
> I had a feeling it might be something like that. So we would all need to
> agree on the convention for WIP branch names. If
On Thu, Mar 23, 2017 at 09:00:33PM +0100, Lars Schneider wrote:
> > Ah, OK, that makes sense. So we would only have to worry about our _own_
> > code accidentally disclosing it. But that should be easy to look for by
> > grepping the log (did somebody do that?).
>
> This is how a successful Windo
Lars Schneider writes:
> Things, that would need to be done:
> * Someone with write access to https://travis-ci.org/git/git would need
> to add the secret token as "GFW_CI_TOKEN" variable in the TravisCI
> repository setting [1]. Afterwards the build should just work.
As coordinating the tim
Lars Schneider writes:
>>> I agree it's not ideal. But I think it is an improvement to check
>>> pu/next/master/maint continuously :-)
>>
>> I am not sure what you mean. We are building each and every branch
>> updates already, and I do not see any improvement over what we are
>> doing now. Ca
Am 23.03.2017 um 20:39 schrieb Jeff King:
On Thu, Mar 23, 2017 at 12:33:06PM -0700, Junio C Hamano wrote:
Nice, but why add the "if" when it's doing nothing?
It's short-circuiting in the conditional.
I think René meant this:
/* just for side effects */
skip_prefix(name, "refs/hea
On Thu, Mar 23, 2017 at 8:39 PM, Jeff King wrote:
> On Thu, Mar 23, 2017 at 12:33:06PM -0700, Junio C Hamano wrote:
>
>> >> Nice, but why add the "if" when it's doing nothing?
>> >
>> > It's short-circuiting in the conditional.
>>
>> I think René meant this:
>>
>> /* just for side effects */
Jeff King writes:
> On Thu, Mar 23, 2017 at 12:33:06PM -0700, Junio C Hamano wrote:
>
>> >> Nice, but why add the "if" when it's doing nothing?
>> >
>> > It's short-circuiting in the conditional.
>>
>> I think René meant this:
>>
>> /* just for side effects */
>> skip_prefix(name, "re
> On 23 Mar 2017, at 20:38, Jeff King wrote:
>
> On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:
>
>>> I think we do build against PRs now. E.g.:
>>>
>>> https://travis-ci.org/git/git/builds/213896051
>>>
>>> But it looks like we can turn that off.
>>
>> When we add a secret
René Scharfe writes:
>> I think René meant this:
>>
>> /* just for side effects */
>> skip_prefix(name, "refs/heads/", &name) ||
>> skip_prefix(name, "refs/tags/", &name) ||
>> skip_prefix(name, "refs/remotes/", &name);
>>
>> return name;
>>
>> which still short-sircuits,
On Thu, Mar 23, 2017 at 12:33:06PM -0700, Junio C Hamano wrote:
> >> Nice, but why add the "if" when it's doing nothing?
> >
> > It's short-circuiting in the conditional.
>
> I think René meant this:
>
> /* just for side effects */
> skip_prefix(name, "refs/heads/", &name) ||
> sk
On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:
> > I think we do build against PRs now. E.g.:
> >
> > https://travis-ci.org/git/git/builds/213896051
> >
> > But it looks like we can turn that off.
>
> When we add a secret variable, then TravisCI will not build Pull Requests
>
Am 23.03.2017 um 20:33 schrieb Junio C Hamano:
Jeff King writes:
On Thu, Mar 23, 2017 at 08:18:26PM +0100, René Scharfe wrote:
Am 23.03.2017 um 16:50 schrieb SZEDER Gábor:
This eliminates three magic numbers.
Signed-off-by: SZEDER Gábor
---
refs.c | 10 +-
1 file changed, 5 inser
> On 23 Mar 2017, at 20:30, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> "[...] we do not provide these values to untrusted builds,
>> triggered by pull requests from another repository."
>>
>> See:
>> https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Rep
Jeff King writes:
> On Thu, Mar 23, 2017 at 08:18:26PM +0100, René Scharfe wrote:
>
>> Am 23.03.2017 um 16:50 schrieb SZEDER Gábor:
>> > This eliminates three magic numbers.
>> >
>> > Signed-off-by: SZEDER Gábor
>> > ---
>> > refs.c | 10 +-
>> > 1 file changed, 5 insertions(+), 5 dele
On Thu, Mar 23, 2017 at 12:23 PM, Jeff King wrote:
> On Thu, Mar 23, 2017 at 08:18:26PM +0100, René Scharfe wrote:
>
>> Am 23.03.2017 um 16:50 schrieb SZEDER Gábor:
>> > This eliminates three magic numbers.
>> >
>> > Signed-off-by: SZEDER Gábor
>> > ---
>> > refs.c | 10 +-
>> > 1 file c
Lars Schneider writes:
> "[...] we do not provide these values to untrusted builds,
> triggered by pull requests from another repository."
>
> See:
> https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings
OK, it is a releaf to see an indication that so
Am 23.03.2017 um 19:00 schrieb matt...@giassa.net:
Hi there,
Following up on an earlier question of mine from yesterday, is there any
formal documentation (save for source diving) on the internal format
used by libxdiff/xdiff when it generates a patch by comparing two
plaintext files?
I'd like
> On 23 Mar 2017, at 20:17, Jeff King wrote:
>
> On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> For instance, if it's in the environment, can I push up a branch that
>>> does "set | grep GFW_CI_TOKEN", open a PR, and see it? I don't know the
>>>
On Thu, Mar 23, 2017 at 08:18:26PM +0100, René Scharfe wrote:
> Am 23.03.2017 um 16:50 schrieb SZEDER Gábor:
> > This eliminates three magic numbers.
> >
> > Signed-off-by: SZEDER Gábor
> > ---
> > refs.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a
Am 23.03.2017 um 16:50 schrieb SZEDER Gábor:
This eliminates three magic numbers.
Signed-off-by: SZEDER Gábor
---
refs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index e7606716d..0272e332c 100644
--- a/refs.c
+++ b/refs.c
@@ -366,11 +366,11
On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > For instance, if it's in the environment, can I push up a branch that
> > does "set | grep GFW_CI_TOKEN", open a PR, and see it? I don't know the
> > answer.
>
> I think the documentation said
>
> Var
Jeff King writes:
> I think both Junio and I have access to the Travis config. Travis does
> have a "this is secret" flag for setup config. But I think we'd need to
> verify that running the Travis build does not leak the variable in any
> other way.
I am not sure if I want to "Authorize applica
Jeff King writes:
> For instance, if it's in the environment, can I push up a branch that
> does "set | grep GFW_CI_TOKEN", open a PR, and see it? I don't know the
> answer.
I think the documentation said
Variables defined in repository settings are the same for all
builds, and when you
Kyle Meyer writes:
> Signed-off-by: Kyle Meyer
> ---
Thanks.
> Documentation/config.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 0d8df5a9f..1df196545 100644
> --- a/Documentation/config.txt
> +++
Jeff King writes:
> Side note: I also have a feeling that any operation that cares about
> non-object sha1 performance is probably ripe for other, bigger
> optimizations. If you update 300MB worth of index entries, then the
> cost of computing a checksum over it isn't a big deal. But if y
Ramsay Jones writes:
>> I am not sure if it makes that much sense to have that sentence here
>> in the first place (after all, it is describing a behaviour of a
>> mode that is *not* the list mode), but I guess that it may be a
>> common mistake to forget to specify "-l" while asking for branches
On Wed, Mar 22, 2017 at 11:09 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> Stefan Beller wrote:
>>
>>> Migrate 'is_submodule_modified' to the new porcelain format of
>>> git-status.
>>>
>>> As the old porcelain only reported ' M' for submodules, no
>>> matter what happened inside the
SZEDER Gábor writes:
> This series is the updated version of 'sg/completion-refs-speedup'.
> It speeds up refs completion for large number of refs, partly by
> giving up disambiguating ambiguous refs and partly by eliminating most
> of the shell processing between 'git for-each-ref' and 'ls-remot
On 03/23, Jeff King wrote:
> On Thu, Mar 23, 2017 at 10:47:16AM -0700, Brandon Williams wrote:
>
> > On 03/23, Johannes Schindelin wrote:
> > > Hi Brandon,
> > >
> > > On Thu, 23 Mar 2017, Brandon Williams wrote:
> > >
> > > > When using rebase --interactive where one of the lines is marked as
>
On Thu, Mar 23, 2017 at 02:22:21PM -0400, Jeff King wrote:
> > > > When using rebase --interactive where one of the lines is marked as
> > > > 'edit' this is the resulting output:
> > > >
> > > > Stopped at ec3b9c4... stuffYou can amend the commit now, with
> > >
> > > Ugh, I should have ca
> On 22 Mar 2017, at 20:29, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> Therefore, we did the following:
>> * Johannes Schindelin set up a Visual Studio Team Services build
>> sponsored by Microsoft and made it accessible via an Azure Function
>> that speaks a super-simple API. We
On Thu, Mar 23, 2017 at 10:47:16AM -0700, Brandon Williams wrote:
> On 03/23, Johannes Schindelin wrote:
> > Hi Brandon,
> >
> > On Thu, 23 Mar 2017, Brandon Williams wrote:
> >
> > > When using rebase --interactive where one of the lines is marked as
> > > 'edit' this is the resulting output:
>
On Thu, Mar 23, 2017 at 10:30 AM, Johannes Schindelin
wrote:
>> Are you sure about that? From what I had looked into userdiff.c, there
>> is no support for shell. There just a recent patch for [go patterns][0].
>> Or perhaps I should have rename it as "userdiff.c: patterns for "shell"
>> language"
Brandon Williams writes:
> When using rebase --interactive where one of the lines is marked as
> 'edit' this is the resulting output:
>
> Stopped at ec3b9c4... stuffYou can amend the commit now, with
>
> git commit --amend
>
> Once you are satisfied with your changes, run
>
>
> On 22 Mar 2017, at 16:49, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Wed, 22 Mar 2017, Lars Schneider wrote:
...
>> +
>> +gfwci () {
>> +curl \
>> +-H "Authentication: Bearer $TOKEN" \
>> +--silent --retry 5 \
>> +"https://git-for-windows-ci.azur
Ulrik Sverdrup writes:
> Git produces a misleading error when you tell it `git revert -m 0`.
Thanks.
I think this is the same issue as the one with 'cherry-pick' that
was reported earlier. We have a fix in the 'master' branch already;
please try it out.
Alex Henrie writes:
> Yes, that makes sense. I assume that when you talk about 'next', you
> mean 'master'?
No, I do mean 'next'. See "A note from the maintainer" post that
are sent to the list every once in a while (i.e. after a new release
is tagged) for the project structure.
https://pu
On Thu, Mar 23, 2017 at 05:22:51PM +0100, Johannes Schindelin wrote:
> > The benefit is that Windows CI does not have to subscribe to the
> > GitHub repository to get notified (instead uses Travis as a relay
> > for update notification) and the result can be seen at the same
> > place as results o
On Thu, Mar 23, 2017 at 4:03 AM, Dennis Kaarsemaker
wrote:
> On Wed, 2017-03-22 at 18:32 -0600, Edmundo Carmona Antoranz wrote:
>>
>> $ git blame --no-progress -w --line-porcelain -L 72,72
>> author-mail
>>
>> $ git cat-file -p 3290fe6dd2a7e2bb35ac760443335dec58802ff1
>> author Stefan Beller 148
Hi there,
Following up on an earlier question of mine from yesterday, is there any
formal documentation (save for source diving) on the internal format
used by libxdiff/xdiff when it generates a patch by comparing two
plaintext files?
I'd like to generate a human-readable "pretty" diff from the
Michael J Gruber writes:
> Are we at a point where we can still rename the new feature at least? If
> yes, and keeping everything else is mandatory, than "workspace" or
> "working space" may be a serious contender for naming the new thing.
I do not have a good answer to the first question, but w
g...@jeffhostetler.com writes:
> From: Jeff Hostetler
>
> Version 2 of this patch series addresses the coding
> style issues, compile errors in non-threaded builds,
> and updated API documentation.
>
>
> This patch series is a performance optimization for
> lazy_init_name_hash() in name-hash.c on
On Thu, Mar 23, 2017 at 10:16:23AM -0700, Linus Torvalds wrote:
> > If I write out an index, I should not suffer the slowdown from detecting
> > collisions.
>
> The index case is a complete red herring.
>
> As already noted, the proper fix for the index case is to simply do it
> asynchronously o
1 - 100 of 190 matches
Mail list logo