The core.commitGraph config setting was accidentally removed from
the config documentation. In that same patch, the config setting
that writes a commit-graph during garbage collection was incorrectly
written to the doc as "gc.commitGraph" instead of "gc.writeCommitGraph".
Reported-by: Szeder
I wanted to send another series to clarify things in
hash-function-transition.txt, but for some of the issues I don't know
the answer, and I had some questions after giving this another read.
So let's discuss that here first. Quoting from the document (available
at
The "head -c BYTES" option is non-portable (not in POSIX[1]). Change
such invocations to use the test_copy_bytes wrapper added in
48860819e8 ("t9300: factor out portable "head -c" replacement",
2016-06-30).
This fixes a test added in 9d2e330b17 ("ewah_read_mmap: bounds-check
mmap reads",
GNU seq is not a POSIX command, and doesn't exist on
e.g. OpenBSD. We've had the test_seq wrapper since d17cf5f3a3 ("tests:
Introduce test_seq", 2012-08-04), but use of it keeps coming back,
e.g. in the recently added "fetch negotiator" tests being added here.
So let's also add a check to "make
Hi Jonathan,
On Wed, 22 Aug 2018, Jonathan Nieder wrote:
> OPT_INTEGER(0, "creation-factor", _factor,
> N_("Percentage by which creation is weighted")),
> - OPT_BOOL(0, "no-dual-color", _color,
> - N_("color both diff
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
It accomplishes this by having the primary thread loop across the index file
tracking the offset and (for V4
On Thu, Aug 23, 2018 at 4:15 AM Jonathan Nieder wrote:
> > The remaining question becomes scripts. A script might do
> >
> > ... modify old-file and create new-file ...
> > git add new-file
> > git commit -m "some great message"
> >
> > which would trip this error. For that
On Thu, Aug 23 2018, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> A recently-added test case tries to verify that the output of `checkout
> -p` contains a certain piece of advice.
>
> But if Git was built without Perl and therefore lacks support for `git
> add
On Thu, Aug 23 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>>> - The trailer consists of the following:
>>> - A copy of the 20-byte SHA-256 checksum at the end of the
>>> corresponding packfile.
>>>
>>> - 20-byte SHA-256 checksum of all of the above.
>>
>> We need
Ævar Arnfjörð Bjarmason writes:
> Junio: Even though this isn't a 2.19.0-rc0 regression I think it makes
> sense for 2.19.0. The fix is trivial, and it'll unbreak (at least some
> of) the tests on stock git on OpenBSD.
I would have been a bit more sympathetic if this were recent
regression
Hi Stefan,
On Wed, 22 Aug 2018, Stefan Beller wrote:
> Instead of passing the sign directly to emit_line_ws_markup, pass only the
> index to lookup the sign in diff_options->output_indicators.
>
> Signed-off-by: Stefan Beller
Looks good to me!
> ---
> diff.c | 12 +---
> 1 file
While trying to run the build & test with NO_PERL, I noticed that t2024 had
a failing test case. This patch works around that failing test case by
skipping it when we know that the error message looks different than that
test case would expect.
Changes since v1 (which did not make it to the list
From: Johannes Schindelin
A recently-added test case tries to verify that the output of `checkout
-p` contains a certain piece of advice.
But if Git was built without Perl and therefore lacks support for `git
add -i`, the error output contains the hint that `-p` is not even
available instead.
Duy Nguyen writes:
> On Thu, Aug 23, 2018 at 4:15 AM Jonathan Nieder wrote:
>> > The remaining question becomes scripts. A script might do
>> >
>> > ... modify old-file and create new-file ...
>> > git add new-file
>> > git commit -m "some great message"
>> >
>> > which would
SZEDER Gábor writes:
> diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
> index 25a77ee5cb..592865d019 100644
> --- a/t/lib-rebase.sh
> +++ b/t/lib-rebase.sh
> @@ -47,7 +47,7 @@ set_fake_editor () {
> action=pick
> for line in $FAKE_LINES; do
> case $line in
> -
On Thu, Aug 23 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Junio: Even though this isn't a 2.19.0-rc0 regression I think it makes
>> sense for 2.19.0. The fix is trivial, and it'll unbreak (at least some
>> of) the tests on stock git on OpenBSD.
>
> I would have been a
On Thu, Aug 23, 2018 at 06:26:58AM -0400, Derrick Stolee wrote:
> Around the time that my proposed approaches were getting vetoed for
> alignment issues, I figured I was out of my depth here. I reached out to
> Daniel Lemire (of EWAH bitmap fame) on Twitter [1]. His blog is full of
> posts of
On Thu, Aug 23, 2018 at 06:20:26AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Here are numbers for p0001.2 run against linux.git on a few
> > versions. This is using -O2 with gcc 8.2.0.
> >
> > Test v2.18.0 v2.19.0-rc0 HEAD
> >
> >
On Thu, Aug 23, 2018 at 8:45 AM Ben Peart wrote:
>
> This patch helps address the CPU cost of loading the index by creating
> multiple threads to divide the work of loading and converting the cache
> entries across all available CPU cores.
>
> It accomplishes this by having the primary thread
Ben Peart writes:
> This patch helps address the CPU cost of loading the index by creating
> multiple threads to divide the work of loading and converting the cache
> entries across all available CPU cores.
Nice.
> +int git_config_get_fast_index(void)
> +{
> + int val;
> +
> + if
Ævar Arnfjörð Bjarmason writes:
> + echo Error (-1) reading configuration file a-directory.
> + > expect
> + mkdir a-directory
> + test_expect_code 2 test-tool config configset_get_value foo.bar
> a-directory
> + 2> output
> Value not found for "foo.bar"
>
Ævar Arnfjörð Bjarmason writes:
> GNU seq is not a POSIX command, and doesn't exist on
s/GNU //; the command did not even originate there, but came from V8
and/or Plan9 IIRC.
> e.g. OpenBSD. We've had the test_seq wrapper since d17cf5f3a3 ("tests:
> Introduce test_seq", 2012-08-04), but use
On Wed, Jul 11 2018, Eric Sunshine wrote:
Found in some 2.19 testing on AIX:
> +# here-doc -- swallow it to avoid false hits within its body (but keep the
> +# command to which it was attached)
> +/<<[ ]*[-\\]*EOF[]*/ {
> + s/[ ]*<<[ ]*[-\\]*EOF//
> + h
> +
On Thu, Aug 23, 2018 at 2:02 PM Ævar Arnfjörð Bjarmason
wrote:
> Found in some 2.19 testing on AIX:
Thanks for reporting these issues.
> > + /^[ ]*EOF[ ]*$/!bhereslurp
>
> AIX sed doesn't like this, and will yell:
> :hereslurp is greater than eight characters
> This on top fixes
Jeff King writes:
> So this turned into a bit of a rabbit hole. Here's what I have so far
> (which I think is not quite ready, but I wanted to start discussing).
>
> Issues (2) and (3) are actually the same issue. The caller that does the
> bogus appending for (2) is always append_signoff(). But
Ævar Arnfjörð Bjarmason writes:
> On Thu, Aug 23 2018, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason writes:
>>
- The trailer consists of the following:
- A copy of the 20-byte SHA-256 checksum at the end of the
corresponding packfile.
- 20-byte SHA-256
Derrick Stolee writes:
> The core.commitGraph config setting was accidentally removed from
> the config documentation. In that same patch, the config setting
> that writes a commit-graph during garbage collection was incorrectly
> written to the doc as "gc.commitGraph" instead of
On Tue, Aug 21, 2018 at 4:43 PM Jeff King wrote:
> On Tue, Aug 21, 2018 at 04:22:08PM -0400, Eric Sunshine wrote:
> > On Tue, Aug 21, 2018 at 3:36 PM Jeff King wrote:
> > How about using "git clone --shared" instead?
>
> That seems even more dangerous to me, since the created clone can become
>
On Thu, Aug 23 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> GNU seq is not a POSIX command, and doesn't exist on
>
> s/GNU //; the command did not even originate there, but came from V8
> and/or Plan9 IIRC.
>
>> e.g. OpenBSD. We've had the test_seq wrapper since
On Thu, Aug 23, 2018 at 03:25:01PM +, Ævar Arnfjörð Bjarmason wrote:
> The "head -c BYTES" option is non-portable (not in POSIX[1]). Change
> such invocations to use the test_copy_bytes wrapper added in
> 48860819e8 ("t9300: factor out portable "head -c" replacement",
> 2016-06-30).
>
> This
Hi Junio,
On Wed, 22 Aug 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > FWIW I am a lot more bold about these builtins, and want to get them
> > into Git for Windows v2.19.0, either as full replacements, or like I
> > did with the difftool: by offering them as experimental
Ævar Arnfjörð Bjarmason writes:
>> - The trailer consists of the following:
>> - A copy of the 20-byte SHA-256 checksum at the end of the
>> corresponding packfile.
>>
>> - 20-byte SHA-256 checksum of all of the above.
>
> We need to update both of these to 32 byte, right? Or are we
Hi,
Ævar Arnfjörð Bjarmason wrote:
> I wanted to send another series to clarify things in
> hash-function-transition.txt, but for some of the issues I don't know
> the answer, and I had some questions after giving this another read.
Thanks for looking it over! Let's go. :)
[...]
>> Objective
On Mon, Aug 20, 2018 at 8:43 AM Nguyễn Thái Ngọc Duy wrote:
> Instead, let's handle just this problem for now. This new option
> commit.preciousDirtyIndex, if set to false, will not allow `commit -a`
> to continue if the final index is different from the existing one. I
> don't think this can be
Ævar Arnfjörð Bjarmason wrote:
>> Objective
>> -
>> Migrate Git from SHA-1 to a stronger hash function.
>
> Should way say "Migrate Git from SHA-1 to SHA-256" here instead?
>
> Maybe it's overly specific, i.e. really we're also describnig how /any/
> hash function transition might happen,
On Thu, Aug 23, 2018 at 04:02:51PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > [...]
> > Goals
> > -
> > 1. The transition to SHA-256 can be done one local repository at a time.
> >a. Requiring no action by any other party.
> >b. A SHA-256 repository can communicate with SHA-1 Git
Hi,
brian m. carlson wrote:
> On Thu, Aug 23, 2018 at 04:02:51PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>> 1. Add SHA-256 support to Git protocol. This is valuable and the
>>>logical next step but it is out of scope for this initial design.
>>
>> This is a non-goal according to the docs, but
On Thu, Aug 23, 2018 at 5:16 PM Jeff King wrote:
>
> On Thu, Aug 23, 2018 at 08:06:37PM -0400, Jeff King wrote:
>
> > This almost works:
> >
> > @@
> > expression a, b;
> > statement s;
> > @@
> > - if (oidcmp(a, b)) s
> > + if (!oideq(a, b)) s
> >
> > [...]
>
> > So I really do want
On Thu, Aug 23, 2018 at 9:28 AM Junio C Hamano wrote:
> I think the above example forgets "-a" on the final "git commit"
> step. With it added, I can understand the concern (and I am sure
> you would, too).
>
> The user is trying to add everything done in the working tree, and
> "commit -a"
On Thu, Aug 23, 2018 at 07:48:42PM -0700, Jacob Keller wrote:
> Odd...
>
> What about..
>
> - if (oidcmp(a,b))
> + if(!oideq(a,b))
> { ... }
Nope, it doesn't like that syntactically.
> Or maybe you need to use something like
>
> <...
> - if (oidcmp(a,b))
> + if (!oideq(a,b))
> ...>
Hi Ævar,
On Thu, 23 Aug 2018, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Aug 23 2018, Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin
> >
> > A recently-added test case tries to verify that the output of `checkout
> > -p` contains a certain piece of advice.
> >
> >
On 8/23/2018 2:53 PM, Jeff King wrote:
On Thu, Aug 23, 2018 at 06:26:58AM -0400, Derrick Stolee wrote:
I think you can safely
ignore the rest of it if you are otherwise occupied. Even if v2.19 ships
without some mitigation, I don't know that it's all that big a deal,
given the numbers I
On 8/23/2018 2:06 PM, Junio C Hamano wrote:
Ben Peart writes:
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
Nice.
+int
Kyle Meyer wrote:
> OPT_BOOL(0, "no-dual-color", _color,
> - N_("color both diff and diff-between-diffs")),
> + N_("color only based on the diff-between-diffs")),
Reviewed-by: Jonathan Nieder
Dscho's suggestion "use simple diff
Ævar Arnfjörð Bjarmason writes:
> Improve the portability of chainlint by using shorter here-docs. On
> AIX sed will complain about:
>
> sed: 0602-417 The label :hereslurp is greater than eight
> characters
>
> As noted in [1] there's still a remaining recently introduced
> portability
On Thu, Aug 23, 2018 at 4:36 PM Ævar Arnfjörð Bjarmason
wrote:
> As noted in [1] there's still a remaining recently introduced
> portability issue also introduced in 878f988350 ("t/test-lib: teach
> --chain-lint to detect broken &&-chains in subshells", 2018-07-11), so
> under AIX the tests must
Hi Junio,
On Wed, 22 Aug 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I made this same mistake over and over again, myself. For some reason,
> > John Keeping decided to use the singular form "revision" in 1e0dacdbdb75
> > (rebase: omit patch-identical commits with
On Thu, Aug 23, 2018 at 06:26:58AM -0400, Derrick Stolee wrote:
> > I think you can safely
> > ignore the rest of it if you are otherwise occupied. Even if v2.19 ships
> > without some mitigation, I don't know that it's all that big a deal,
> > given the numbers I generated (which for some reason
Hi Gábor,
On Thu, 23 Aug 2018, SZEDER Gábor wrote:
> The verbose output of the test 'reword without issues functions as
> intended' in 't3423-rebase-reword.sh', added in a9279c6785 (sequencer:
> do not squash 'reword' commits when we hit conflicts, 2018-06-19),
> contains the following error
On 8/23/2018 1:31 PM, Stefan Beller wrote:
On Thu, Aug 23, 2018 at 8:45 AM Ben Peart wrote:
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
It
The "head -c BYTES" option is non-portable (not in POSIX[1]). Change
such invocations to use the test_copy_bytes wrapper added in
48860819e8 ("t9300: factor out portable "head -c" replacement",
2016-06-30).
This fixes a test added in 9d2e330b17 ("ewah_read_mmap: bounds-check
mmap reads",
Improve the portability of chainlint by using shorter here-docs. On
AIX sed will complain about:
sed: 0602-417 The label :hereslurp is greater than eight
characters
As noted in [1] there's still a remaining recently introduced
portability issue also introduced in 878f988350 ("t/test-lib:
The test guarded by PERLJSON added in 75459410ed ("json_writer: new
routines to create JSON data", 2018-07-13) assumed that a JSON boolean
value like "true" or "false" would be represented as "1" or "0" in
Perl.
This behavior can't be relied upon, e.g. with JSON.pm 2.50 and
JSON::PP A
The seq command is not in POSIX, and doesn't exist on
e.g. OpenBSD. We've had the test_seq wrapper since d17cf5f3a3 ("tests:
Introduce test_seq", 2012-08-04), but use of it keeps coming back,
e.g. in the recently added "fetch negotiator" tests being added here.
So let's also add a check to "make
This grew a bit more. I'm going to stop poking at this for now. The
tests are still broken on OpenBSD (3-5 broken) and on AIX something
like 20-30 are broken, but this makes it slightly better.
Ævar Arnfjörð Bjarmason (5):
tests: fix and add lint for non-portable head -c N
tests: fix and add
The --file option to grep isn't in POSIX[1], but -f is[1]. Let's check
for that in the future, and fix the portability regression in
f237c8b6fe ("commit-graph: implement git-commit-graph write",
2018-04-02) that broke e.g. AIX.
1. http://pubs.opengroup.org/onlinepubs/009695399/utilities/grep.html
Ævar Arnfjörð Bjarmason writes:
> The --file option to grep isn't in POSIX[1], but -f is[1]. Let's check
> for that in the future, and fix the portability regression in
> f237c8b6fe ("commit-graph: implement git-commit-graph write",
> 2018-04-02) that broke e.g. AIX.
>
> 1.
Hi Kyle,
On Wed, 22 Aug 2018, Kyle Meyer wrote:
> 275267937b (range-diff: make dual-color the default mode, 2018-08-13)
> replaced --dual-color with --no-dual-color but left the option's
> summary untouched. Rewrite the summary to describe --no-dual-color
> rather than dual-color.
>
>
Fix typos and convert a question which does not expect to be replied
to a simple advice.
Signed-off-by: Jean-Noël Avila
---
builtin/submodule--helper.c | 2 +-
config.c| 2 +-
sequencer.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Hi,
Johannes Schindelin wrote:
> On Wed, 22 Aug 2018, Jonathan Nieder wrote:
>> OPT_INTEGER(0, "creation-factor", _factor,
>> N_("Percentage by which creation is weighted")),
>> -OPT_BOOL(0, "no-dual-color", _color,
>> -
On Thu, Aug 23, 2018 at 06:54:38PM -0700, Jonathan Nieder wrote:
> brian m. carlson wrote:
> > I realize I have a lot of code that has not been sent in yet, but I also
> > tend to build on my own series a lot, and I probably need to be a bit
> > better about extracting reusable pieces that can go
brian m. carlson wrote:
> On Thu, Aug 23, 2018 at 06:54:38PM -0700, Jonathan Nieder wrote:
>> For what it's worth, even if it all is in one commit with message
>> "wip", I think I'd benefit from being able to see this code. I can
>> promise not to critique it, and to only treat it as a rough
>>
Hi Phillip,
On Fri, 17 Aug 2018, Phillip Wood wrote:
> On 10/08/2018 17:51, Alban Gruin wrote:
>
> > +{
> > + const char *quiet = getenv("GIT_QUIET");
> > +
> > + if (head_name)
> > + write_file(rebase_path_head_name(), "%s\n", head_name);
>
> write_file() can call die() which
275267937b (range-diff: make dual-color the default mode, 2018-08-13)
replaced --dual-color with --no-dual-color but left the option's
summary untouched. Rewrite the summary to describe --no-dual-color
rather than dual-color.
Helped-by: Jonathan Nieder
Helped-by: Johannes Schindelin
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Kyle Meyer wrote:
>>> Subject: [PATCH v3] range-diff: update stale summary of --no-dual-color
[...]
>> Reviewed-by: Jonathan Nieder
>
> Sorry, too late. I'll revert the merge of the previous round out of
> 'next' and requeue this one, but that
Hi Junio,
On Thu, 23 Aug 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 22 Aug 2018, Kyle Meyer wrote:
> >
> >> 275267937b (range-diff: make dual-color the default mode, 2018-08-13)
> >> replaced --dual-color with --no-dual-color but left the option's
> >> summary
Kyle Meyer writes:
> Junio C Hamano writes:
>
>> Johannes Schindelin writes:
>
> [...]
>
- N_("color both diff and diff-between-diffs")),
+ N_("restrict coloring to outer diff markers")),
>>>
>>> How about "use simple diff colors" instead?
>
On Thu, Aug 23, 2018 at 9:30 AM Jeff King wrote:
> I think that audit isn't actually too bad (but definitely not something
> we should do for v2.19). The cocci patch I showed earlier hits most of
> them. It misses the negated ones (e.g., "if (oidcmp(...))"). I'm not
> sure if there's a way to ask
On Thu, Aug 23, 2018 at 07:40:49PM -0400, Jeff King wrote:
> > You can look for explicitly "if (oidcmp(...))" though. I don't know if
> > you can catch *any* use which degrades to boolean outside of an if
> > statement, but I wouldn't expect there to be too many of those?
>
> Yeah, that was my
Junio C Hamano writes:
> Johannes Schindelin writes:
[...]
>>> - N_("color both diff and diff-between-diffs")),
>>> + N_("restrict coloring to outer diff markers")),
>>
>> How about "use simple diff colors" instead?
That's certainly better than the
Jean-Noël Avila writes:
> - die(_("run_command returned non-zero status while"
> + die(_("run_command returned non-zero status while "
> "recursing in the nested submodules of %s\n."),
Obviously good.
> diff --git a/config.c
On Thu, Aug 23, 2018 at 04:30:10PM -0700, Jacob Keller wrote:
> On Thu, Aug 23, 2018 at 9:30 AM Jeff King wrote:
> > I think that audit isn't actually too bad (but definitely not something
> > we should do for v2.19). The cocci patch I showed earlier hits most of
> > them. It misses the negated
Johannes Schindelin writes:
> On Wed, 22 Aug 2018, Kyle Meyer wrote:
>
>> 275267937b (range-diff: make dual-color the default mode, 2018-08-13)
>> replaced --dual-color with --no-dual-color but left the option's
>> summary untouched. Rewrite the summary to describe --no-dual-color
>> rather
Kyle Meyer wrote:
> 275267937b (range-diff: make dual-color the default mode, 2018-08-13)
> replaced --dual-color with --no-dual-color but left the option's
> summary untouched. Rewrite the summary to describe --no-dual-color
> rather than dual-color.
>
> Helped-by: Jonathan Nieder
Ha, I don't
Jonathan Nieder writes:
> Kyle Meyer wrote:
>
>> 275267937b (range-diff: make dual-color the default mode, 2018-08-13)
>> replaced --dual-color with --no-dual-color but left the option's
>> summary untouched. Rewrite the summary to describe --no-dual-color
>> rather than dual-color.
>>
>>
On Thu, Aug 23, 2018 at 08:06:37PM -0400, Jeff King wrote:
> This almost works:
>
> @@
> expression a, b;
> statement s;
> @@
> - if (oidcmp(a, b)) s
> + if (!oideq(a, b)) s
>
> [...]
> So I really do want some way of saying "all of the block, no matter what
> it is". Or of leaving
Kyle Meyer wrote:
> Jonathan Nieder writes:
>> I think what you mean is something like "color only based on the
>> diff-between-diffs".
>
> Yeah, I that sounds OK to me.
Thanks. Want to prepare a patch along those lines to finish this off?
I'm off to sleep now, can look at this again tomorrow
This has all the context:
https://stackoverflow.com/questions/22698505/how-to-show-full-paths-in-git-diff
I'd like `--show-abs-path` to show absolute paths in:
git diff --show-abs-path args...
eg:
git diff --no-index `get_file1` `get_file2`
could show:
--- a/Users/timothee/temp/ripgrep/help0.txt
The verbose output of the test 'reword without issues functions as
intended' in 't3423-rebase-reword.sh', added in a9279c6785 (sequencer:
do not squash 'reword' commits when we hit conflicts, 2018-06-19),
contains the following error output:
sed: -e expression #1, char 2: extra characters after
This is on OpenBSD 6.2 amd64 with my "tests: fix and add lint for
non-portable head -c N" patch (which fixes one failure).
$ for t in t1305-config-include.sh t1308-config-set.sh
t5004-archive-corner-cases.sh t5552-skipping-fetch-negotiator.sh; do ./$t
--no-color -v -x 2>&1 | grep -B10 "^not
The "head -c BYTES" option is non-portable (not in POSIX[1]). Change
such invocations to use the test_copy_bytes wrapper added in
48860819e8 ("t9300: factor out portable "head -c" replacement",
2016-06-30).
This fixes a test added in 9d2e330b17 ("ewah_read_mmap: bounds-check
mmap reads",
This has all the context:
https://stackoverflow.com/questions/22698505/how-to-show-full-paths-in-git-diff
I'd like `--show-abs-path` to show absolute paths in:
git diff --show-abs-path args...
eg:
git diff --no-index `get_file1` `get_file2`
could show:
--- a/Users/timothee/temp/ripgrep/help0.txt
On Thu, Aug 23, 2018 at 11:16 AM Timothee Cour wrote:
>
> This has all the context:
> https://stackoverflow.com/questions/22698505/how-to-show-full-paths-in-git-diff
It's helpful to copy it anyway, so we can discuss it here:
QUOTE
How do I show full paths in git diff? One can use
On Wed, 22 Aug 2018 08:29:25 -0700
Junio C Hamano wrote:
> Antonio Ospite writes:
>
[...]
> >> > > + else if (get_oid(GITMODULES_HEAD, ) >= 0)
> >> > > + config_source.blob = GITMODULES_HEAD;
> >> >
> >> Would using ":.gitmodules" instead of
On 8/23/2018 1:04 AM, Jeff King wrote:
On Thu, Aug 23, 2018 at 03:47:07AM +, brian m. carlson wrote:
I expect that's going to be the case as well. I have patches that
wire up actual SHA-256 support in my hash-impl branch.
However, having said that, I'm happy to defer to whatever everyone
> Wanting such a feature seems sensible
happy to hear that!
> So this seems to work for --no-index, or if it doesn't what situations
> doesn't it work in?
cases where path arguments are already absolute (as I showed earlier)
> Is this a mistake, or would you only like --show-abs-paths to
275267937b (range-diff: make dual-color the default mode, 2018-08-13)
replaced --dual-color with --no-dual-color but left the option's
summary untouched. Rewrite the summary to describe --no-dual-color
rather than dual-color.
Helped-by: Jonathan Nieder
Signed-off-by: Kyle Meyer
---
Derrick Stolee writes:
> I was thinking that having a mitigation for 2.19 is best, and then we
> can focus as part of the 2.20 cycle how we can properly avoid this
> cost, especially when 32 is a valid option.
> ...
> ... to
> take a 'hasheq' approach [2] like Peff suggested [3]. Since that
>
Jeff King writes:
> Here are numbers for p0001.2 run against linux.git on a few
> versions. This is using -O2 with gcc 8.2.0.
>
> Test v2.18.0 v2.19.0-rc0 HEAD
>
> --
> 0001.2:
89 matches
Mail list logo
