On Thu, Aug 23, 2018 at 01:02:25AM -0400, Jeff King wrote:
> Here's the patch. For some reason my numbers aren't quite as large as
> they were yesterday (I was very careful to keep the system unloaded
> today, whereas yesterday I was doing a few other things, so perhaps that
> is the difference).
Jeff King wrote:
> Here's the patch. For some reason my numbers aren't quite as large as
> they were yesterday (I was very careful to keep the system unloaded
> today, whereas yesterday I was doing a few other things, so perhaps that
> is the difference).
>
> -- >8 --
> Subject: [PATCH] hashcmp:
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 else
> thinks is best for 2.19.
On Wed, Aug 22, 2018 at 07:27:56PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > FWIW, it's not 10%. The best I measured was ~4% on a very
> > hashcmp-limited operation, and I suspect even that may be highly
> > dependent on the compiler. We might be able to improve more by
> >
Jonathan Nieder writes:
- N_("color both diff and diff-between-diffs")),
+ N_("restrict coloring to outer diff markers")),
[...]
> Aha: I think you're missing a few words (e.g. "color only according to
> outer diff markers"). Though based on
On Wed, Aug 22, 2018 at 10:16:18PM -0400, Jeff King wrote:
> FWIW, it's not 10%. The best I measured was ~4% on a very
> hashcmp-limited operation, and I suspect even that may be highly
> dependent on the compiler. We might be able to improve more by
> sprinkling more asserts around, but there are
Kyle Meyer wrote:
> Jonathan Nieder writes:
>> Kyle Meyer wrote:
>>> - N_("color both diff and diff-between-diffs")),
>>> + N_("restrict coloring to outer diff markers")),
[...]
>> What is an outer diff marker?
>
> The diff markers from the diff of
Jonathan Nieder writes:
[...]
> What is an outer diff marker?
The diff markers from the diff of patches as opposed to the ones from
the original patches. I took the term from git-range-diff.txt:
--no-dual-color::
When the commit diffs differ, `git range-diff` recreates the
Hi,
Johannes Schindelin wrote:
[nice description snipped]
> This patch fixes that.
Please include this information in the commit message. It's super
helpful to find this kind of information about why a patch does what
it does when encountering a patch later "in the wild" (in git log -S
Hi,
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.
>
> Signed-off-by: Kyle Meyer
> ---
>
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.
Signed-off-by: Kyle Meyer
---
builtin/range-diff.c | 2 +-
1 file
Jeff King wrote:
> FWIW, it's not 10%. The best I measured was ~4% on a very
> hashcmp-limited operation, and I suspect even that may be highly
> dependent on the compiler. We might be able to improve more by
> sprinkling more asserts around, but there are 75 mentions of
> the_hash_algo->rawsz. I
On Wed, Aug 22, 2018 at 06:23:43PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
> >> On Tue, 2018-08-21 at 23:03 -0400, Jeff King wrote:
>
> >>> static inline int hashcmp(const unsigned char *sha1, const unsigned
> >>> char *sha2)
> >>> {
> >>> + assert(the_hash_algo->rawsz == 20);
>
A few quick corrections:
Jonathan Nieder wrote:
> I'm starting to lean toward having this on unconditionally, with a
> message that points the user who really doesn't want to clobber their
... who really *does* want to clobber their index ...
> index toward "git add -u", as a good idea. I
Duy Nguyen wrote:
> On Mon, Aug 20, 2018 at 9:30 PM Jonathan Nieder wrote:
>> I frequently use "git commit -a" this way intentionally, so I would be
>> unlikely to turn this config on. That leads me to suspect it's not a
>> good candidate for configuration:
>>
>> - it's not configuration for
> > On Tuesday, February 16, 2016 8:33:54 PM MST Junio C Hamano wrote:
> Wow, that's quite an old discussion ;-)
It wasn't intended to be so
> After these:
> tells me that "--short" still does not notice that there _is_
> something to be committed, either with an ancient version like
> v2.10.5
Hi,
Jeff King wrote:
>> On Tue, 2018-08-21 at 23:03 -0400, Jeff King wrote:
>>> static inline int hashcmp(const unsigned char *sha1, const unsigned
>>> char *sha2)
>>> {
>>> + assert(the_hash_algo->rawsz == 20);
>>> return memcmp(sha1, sha2, the_hash_algo->rawsz);
>>> }
[...]
>
Hi,
Sachin Sharma wrote:
> What do I need from Git?
>
> Guidance, neither too deep nor too short(optimum).
>
> How can I get started for a contribution?
>
> What are the necessary technical skills needed for a contribution to
> Git?
To add to what Stefan wrote:
This is a good question. There
The append_signoff() function takes an "ignore_footer"
argument, which specifies a number of bytes at the end of
the message buffer which should not be considered (they
cannot contain trailers, and the trailer is spliced in
before them).
But to find the existing trailers, it calls into
The append_signoff() function takes an "int" to specify the
number of bytes to ignore. Most callers just pass 0, and the
remainder use ignore_non_trailer() to skip over cruft.
That function also returns an int, and uses them internally.
On systems where size_t is larger than an int (i.e., most
When the sequencer code appends a signoff or cherry-pick
origin, it uses the default trailer-parsing options, which
treat "---" as the end of the commit message. As a result,
it may be fooled by a commit message that contains that
string and fail to find the existing trailer block. Even
more
In both of these cases we know that we are feeding the
trailer-parsing code a pure commit message. We should tell
it so, which avoids false positives for a commit message
that contains a "---" line.
Signed-off-by: Jeff King
---
pretty.c | 3 +++
ref-filter.c
Even with the newly-tightened "---" parser, it's still
possible for a commit message to trigger a false positive if
it contains something like "--- foo". If the caller knows
that it has only a single commit message, it can now tell us
with the "--no-divider" option, eliminating any false
The interpret-trailers command accepts not only raw commit
messages, but it also can manipulate trailers in
format-patch output. That means it must find the "---"
boundary separating the commit message from the patch.
However, it does so by looking for any line starting with
"---", regardless of
Most of the trailer code has an "opts" struct which is
filled in by the caller. We don't pass it down to
trailer_info_get(), which does the initial parsing, because
there hasn't yet been a need to do so.
Let's start passing it down in preparation for adding new
options. Note that there's a single
We store the length of the trailers list in a size_t. So on
a 64-bit system with a 32-bit int, in the unlikely case that
we manage to actually allocate a list with 2^31 entries,
we'd loop forever trying to iterate over it (our "int" would
wrap to negative before exceeding info->trailer_nr).
This
Many of the string-parsing functions inside trailer.c return
integer offsets into the string (e.g., to point to the end
of the trailer block). Several of these use an "int" to
return or store the offsets. On a system where "size_t" is
much larger than "int" (e.g., most 64-bit ones), it's easy
to
On Tue, Aug 21, 2018 at 01:57:07PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Ah, yeah, I think you're right. We call find_patch_start(), which thinks
> > the "---" line is the end of the commit message. That makes sense when
> > parsing trailers out of "format-patch" output, but
As of the release of 2.18.0, $GIT_DIR is no longer set before calling
pre-commit hooks. This change was introduced in "set_work_tree: use
chdir_notify" (8500e0de) and is still present in master.
I reviewed the discussion when this change was initially submitted,
and I don't think this behavior
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 options in the installer.
>
> Maybe this will remain a dream, but
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
---
diff.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
So something like this on top of
On Wed, Aug 22, 2018 at 02:50:05PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes. I was thinking it had more purpose than this, but it really is just
> > a flag to check "did we do this already?". Which is one of the main
> > purposes I claimed for the new flag in my commit
Jeff King writes:
> Yes. I was thinking it had more purpose than this, but it really is just
> a flag to check "did we do this already?". Which is one of the main
> purposes I claimed for the new flag in my commit message. :)
OK.
The reason I was on the fence was primarily because
"Johannes Schindelin via GitGitGadget"
writes:
> This patch fixes that.
>
> Note: while this patch targets pk/rebase-in-c-6-final, it will not work
> correctly without ag/rebase-i-in-c. So my suggestion is to rewrite the
> pk/rebas-in-c-6-final branch by first merging ag/rebase-i-in-c, then
>
Hi Junio,
On Wed, 22 Aug 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Here are the topics that have been cooking. Commits prefixed with
> > '-' are only in 'pu' (proposed updates) while commits prefixed with
> > '+' are in 'next'. The ones marked with '.' do not appear in any
Junio C Hamano writes:
> I think this makes sense, but if we were to give a dedicated field
> in the revs structure, can we lose the local variable at the same
> time, I wonder?
>
> Thanks.
Well, the answer to "can we" is always "yes"; what I was truly
wondering was if it makes sense to do so.
On Wed, Aug 22, 2018 at 01:42:26PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Instead, let's keep two flags: one to denote when we got
> > actual input (which triggers both roles) and one for when we
> > read stdin (which triggers only the first).
> >
> > This does mean a caller
From: Johannes Schindelin
It is no longer a shell script, so we need to call it in a different way
than the other backends.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 81
1 file changed, 81 insertions(+)
diff --git
The builtin rebase and the builtin interactive rebase have been developed
independently, on purpose: Google Summer of Code rules specifically state
that students have to work on independent projects, they cannot collaborate
on the same project.
The reason is probably the very fine tradition in
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 --fork-point, 2014-07-16), not
> the plural.
Perhaps we should give a
Hi Alban,
thank you for your tireless work on this!
One thing that needs to be fixed, though:
On Fri, 10 Aug 2018, Alban Gruin wrote:
> +run_interactive () {
> + GIT_CHERRY_PICK_HELP="$resolvemsg"
> + export GIT_CHERRY_PICK_HELP
> +
> + test -n "$keep_empty" &&
Thomas Gummerer writes:
> Hmm, it does describe what happens in the code, which is what this
> patch implements. Maybe we should rephrase the title here?
>
> Or are you suggesting dropping this patch (and the next one)
> completely, as we don't want to try and handle the case where this
> kind
Jeff King writes:
> Instead, let's keep two flags: one to denote when we got
> actual input (which triggers both roles) and one for when we
> read stdin (which triggers only the first).
>
> This does mean a caller interested in the first role has to
> check both flags, but there's only one such
On 08/22, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > But why not add this to the git-rerere manpage? These technical docs
> > get way less exposure, and in this case we're not describing some
> > interna implementation detail, which the technical docs are for, but
> >
On Wed, Aug 22, 2018 at 2:59 PM SZEDER Gábor wrote:
> On Wed, Aug 22, 2018 at 7:53 PM Eric Sunshine wrote:
> > Can you say a word or two (here in the email thread) about how you're
> > finding these failures (across the various test fixes you've posted
> > recently)? Are you instrumenting the
On Wed, Aug 22, 2018 at 03:23:08PM -0400, Jeff King wrote:
> > + /*
> > +* Even if revs->pending is empty after all the above, if we
> > +* handled "--stdin", then the caller really meant to give us
> > +* an empty commit range. Just let the traversal give an
> > +* empty
On Wed, Aug 22, 2018 at 11:50:46AM -0700, Junio C Hamano wrote:
> > test_expect_failure 'rev-list should succeed with empty output on empty
> > stdin' '
> > - git rev-list --stdin actual &&
> > + git rev-list --stdin actual &&
> > test_must_be_empty actual
> > '
>
> By the way, it may
On Wed, Aug 22, 2018 at 09:46:08AM -0700, Hari Lubovac wrote:
> I don't know where else to report this. It relates to the "log"
> command with "--pretty:format" argument.
>
> It appears to me that "%C" format argument combined with "%+" or "%-"
> results in no color applied.
>
> For example,
On Wed, Aug 22, 2018 at 7:53 PM Eric Sunshine wrote:
> Can you say a word or two (here in the email thread) about how you're
> finding these failures (across the various test fixes you've posted
> recently)? Are you instrumenting the code in some fashion? Or, finding
> them by visual inspection?
SZEDER Gábor writes:
> Redirect 'git rev-list's stdin explicitly from /dev/null to provide
> empty input. (Strictly speaking we don't need this redirection,
> because the test script's stdin is already redirected from /dev/null
> anyway, but I think it's better to be explicit about it.)
Yes.
I would encourage use of an existing function to check for emptiness,
but require a particular argument for it to be considered "the right
way:"
test_cmp /dev/null actual
This means less vocabulary to memorize for test writers. It's usually a
code smell to have special logic for a specific value
The test 'store updates stash ref and reflog' in 't3903-stash.sh'
creates a stash from a new file, runs 'git reset --hard' to throw away
any modifications to the work tree, and then runs '! grep' to ensure
that the staged contents are gone. Since the file didn't exist
before, it shouldn't exist
Several tests in 't3420-rebase-autostash.sh' start various rebase
processes that are expected to fail because of merge conflicts. These
tests then run '! grep' to ensure that the autostash feature did its
job, and the dirty contents of a file is gone. However, due to the
test repo's history and
SZEDER Gábor writes:
> Prior to d3c6751b18 (tests: make use of the test_must_be_empty
> function, 2018-07-27), in the test 'rev-list should succeed with empty
> output on empty stdin' in 't6018-rev-list-glob' the empty 'expect'
> file served dual purpose: besides specifying the expected output,
On Tue, Aug 21, 2018 at 2:46 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> >> ...
> >> OTOH, if it were up to me I would have just gotten rid of
> >> test_must_be_empty and used an existing function with the right
> >> argument, like `test_cmp /dev/null` - but using some form
On Wed, Aug 22, 2018 at 1:48 PM SZEDER Gábor wrote:
> Prior to d3c6751b18 (tests: make use of the test_must_be_empty
> function, 2018-07-27), in the test 'rev-list should succeed with empty
> output on empty stdin' in 't6018-rev-list-glob' the empty 'expect'
> file served dual purpose: besides
Welcome!
In the Git community we do not ask permission to write code, but just do it.
See https://github.com/git/git/blob/master/Documentation/SubmittingPatches
or Documentation/SubmittingPatches in your local copy of git.
Cheers,
Stefan
On Tue, Aug 21, 2018 at 11:01 PM Gaux Nation wrote:
>
>
Note that you can also trivially convert a lot more instances of empty
checking to the "right" way: 'test_line_count = 0'
$ grep -Ir 'test_line_count = 0' t | wc -l
76
I think it would be nice to clean these up as well.
Prior to d3c6751b18 (tests: make use of the test_must_be_empty
function, 2018-07-27), in the test 'rev-list should succeed with empty
output on empty stdin' in 't6018-rev-list-glob' the empty 'expect'
file served dual purpose: besides specifying the expected output, as
usual, it also served as
Junio C Hamano writes:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
On 8/22/2018 12:58 PM, Duy Nguyen wrote:
On Wed, Aug 22, 2018 at 6:49 PM Derrick Stolee wrote:
On 8/22/2018 12:26 PM, Jeff King wrote:
On Wed, Aug 22, 2018 at 06:14:24PM +0200, Duy Nguyen wrote:
On Wed, Aug 22, 2018 at 6:08 PM Duy Nguyen wrote:
On Wed, Aug 22, 2018 at 6:03 PM Jeff King
Jeff King writes:
> On Wed, Aug 22, 2018 at 12:49:34PM -0400, Derrick Stolee wrote:
>
>> > Yes, that was what I meant. We actually did switch to that hand-rolled
>> > loop, but later we went back to memcmp in 0b006014c8 (hashcmp: use
>> > memcmp instead of open-coded loop, 2017-08-09).
>>
>>
On Wed, Aug 22, 2018 at 12:49:34PM -0400, Derrick Stolee wrote:
> > Yes, that was what I meant. We actually did switch to that hand-rolled
> > loop, but later we went back to memcmp in 0b006014c8 (hashcmp: use
> > memcmp instead of open-coded loop, 2017-08-09).
>
> Looking at that commit, I'm
On Wed, Aug 22, 2018 at 6:49 PM Derrick Stolee wrote:
>
> On 8/22/2018 12:26 PM, Jeff King wrote:
> > On Wed, Aug 22, 2018 at 06:14:24PM +0200, Duy Nguyen wrote:
> >
> >> On Wed, Aug 22, 2018 at 6:08 PM Duy Nguyen wrote:
> >>> On Wed, Aug 22, 2018 at 6:03 PM Jeff King wrote:
> On Wed, Aug
On 8/22/2018 12:26 PM, Jeff King wrote:
On Wed, Aug 22, 2018 at 06:14:24PM +0200, Duy Nguyen wrote:
On Wed, Aug 22, 2018 at 6:08 PM Duy Nguyen wrote:
On Wed, Aug 22, 2018 at 6:03 PM Jeff King wrote:
On Wed, Aug 22, 2018 at 07:14:42AM -0400, Derrick Stolee wrote:
The other thing I was
Hi -
I don't know where else to report this. It relates to the "log"
command with "--pretty:format" argument.
It appears to me that "%C" format argument combined with "%+" or "%-"
results in no color applied.
For example, I'd expect the last part of the output line ("%+D") to be
colored red (it
Hi everyone,
The 42nd edition of Git Rev News is now published:
https://git.github.io/rev_news/2018/08/22/edition-42/
Thanks a lot to the contributors: Derrick Stolee and Ævar Arnfjörð Bjarmason!
Enjoy,
Christian, Jakub, Markus and Gabriel.
On Wed, Aug 22, 2018 at 09:11:08AM -0700, Junio C Hamano wrote:
> This originates from fd777141 ("t0020: fix ignored exit code inside
> loops", 2015-03-25) where a loop
>
> for f in one dir/two
> do
> do things on "$f" || break
> done
>
> was unrolled to correctly break
Nguyễn Thái Ngọc Duy writes:
> I notice a couple times lately that people added new config keys in
> the wrong place, which is understandable since this file has become so
> big, it's hard to see the structure of anything.
>
> Since we have broken down some parts of it into separate files
>
On Wed, Aug 22, 2018 at 06:14:24PM +0200, Duy Nguyen wrote:
> On Wed, Aug 22, 2018 at 6:08 PM Duy Nguyen wrote:
> >
> > On Wed, Aug 22, 2018 at 6:03 PM Jeff King wrote:
> > >
> > > On Wed, Aug 22, 2018 at 07:14:42AM -0400, Derrick Stolee wrote:
> > >
> > > > The other thing I was going to
On Wed, Aug 22, 2018 at 6:08 PM Duy Nguyen wrote:
>
> On Wed, Aug 22, 2018 at 6:03 PM Jeff King wrote:
> >
> > On Wed, Aug 22, 2018 at 07:14:42AM -0400, Derrick Stolee wrote:
> >
> > > The other thing I was going to recommend (and I'll try to test this out
> > > myself later) is to see if
SZEDER Gábor writes:
> In the test 'checkout with autocrlf=input' in 't0020-crlf.sh', one of
> the 'has_cr' checks looks at the non-existing file 'two' instead of
> 'dir/two'. The test still succeeds, without actually checking what it
> was supposed to, because this check is expected to fail
On Wed, Aug 22, 2018 at 6:03 PM Jeff King wrote:
>
> On Wed, Aug 22, 2018 at 07:14:42AM -0400, Derrick Stolee wrote:
>
> > The other thing I was going to recommend (and I'll try to test this out
> > myself later) is to see if 'the_hash_algo->rawsz' is being treated as a
> > volatile variable,
Ævar Arnfjörð Bjarmason writes:
> But why not add this to the git-rerere manpage? These technical docs
> get way less exposure, and in this case we're not describing some
> interna implementation detail, which the technical docs are for, but
> something that's user-visible, let's put that in
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 83 +-
Documentation/submodule-config.txt | 82 +
2 files changed, 83 insertions(+), 82 deletions(-)
create mode 100644 Documentation/submodule-config.txt
diff
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt| 68 +
Documentation/gitcvs-config.txt | 67
2 files changed, 68 insertions(+), 67 deletions(-)
create mode 100644 Documentation/gitcvs-config.txt
diff
I notice a couple times lately that people added new config keys in
the wrong place, which is understandable since this file has become so
big, it's hard to see the structure of anything.
Since we have broken down some parts of it into separate files
already, this continues in that direction and
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 66 +-
Documentation/fetch-config.txt | 65 +
2 files changed, 66 insertions(+), 65 deletions(-)
create mode 100644 Documentation/fetch-config.txt
diff --git
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt| 88 +
Documentation/format-config.txt | 87
2 files changed, 88 insertions(+), 87 deletions(-)
create mode 100644 Documentation/format-config.txt
diff
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 414e28244e..a0eaf40564 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1c42364988..30adca61ee 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -3282,7
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 58 +---
Documentation/gui-config.txt | 57 +++
2 files changed, 58 insertions(+), 57 deletions(-)
create mode 100644 Documentation/gui-config.txt
diff --git
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 37 +--
Documentation/pull-config.txt | 36 ++
2 files changed, 37 insertions(+), 36 deletions(-)
create mode 100644 Documentation/pull-config.txt
diff --git
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 114 +-
Documentation/push-config.txt | 113 +
2 files changed, 114 insertions(+), 113 deletions(-)
create mode 100644 Documentation/push-config.txt
diff
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 124 +--
Documentation/receive-config.txt | 123 ++
2 files changed, 124 insertions(+), 123 deletions(-)
create mode 100644 Documentation/receive-config.txt
diff
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 64 +-
Documentation/sendemail-config.txt | 63 +
2 files changed, 64 insertions(+), 63 deletions(-)
create mode 100644 Documentation/sendemail-config.txt
diff
Stephen Smith writes:
> On Tuesday, February 16, 2016 8:33:54 PM MST Junio C Hamano wrote:
Wow, that's quite an old discussion ;-)
>> So if you do this:
>>
>> $ git reset --hard HEAD
>> $ >a-new-file && git add a-new-file
>> $ git commit --dry-run --short; echo $?
>>
>> you'd get
SZEDER Gábor writes:
> The test '--dry-run with conflicts fixed from a merge' in
> 't7501-commit.sh', added in 8dc874b2ee (wt-status.c: set commitable
> bit if there is a meaningful merge., 2016-02-15), runs the following
> unnecessary and downright bogus command substitution:
>
> ! $(git
Am 22.08.2018 um 15:16 schrieb Derrick Stolee:
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1c42364988..f846543414 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -917,7 +917,11 @@ core.notesRef::
This setting defaults to "refs/notes/commits",
On Wed, Aug 22, 2018 at 09:40:55AM -0400, Derrick Stolee wrote:
> On 8/21/2018 3:06 PM, Jeff King wrote:
> > The main objective of scripts in the perf framework is to
> > run "test_perf", which measures the time it takes to run
> > some operation. However, it can also be interesting to see
> >
Antonio Ospite writes:
> Maybe "submodule--helper config --check-writeable" could be a better
> name to avoid confusion between the boolean return value of the C
> function (0: false, 1: true) and the exit status returned to the shell
> (0: safe to write, !0: unsafe).
Perhaps. The main point
On Wed, Aug 22, 2018 at 3:18 PM Derrick Stolee wrote:
>
> 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
On Wed, Aug 22, 2018 at 10:28:56AM -0400, Derrick Stolee wrote:
> In my testing, I've had the best luck with this change:
>
> diff --git a/cache.h b/cache.h
> index b1fd3d58ab..6c8b51c390 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1023,7 +1023,14 @@ extern const struct object_id null_oid;
>
>
On Wed, Aug 22, 2018 at 08:42:20AM -0400, Paul Smith wrote:
> On Tue, 2018-08-21 at 23:03 -0400, Jeff King wrote:
> > static inline int hashcmp(const unsigned char *sha1, const unsigned
> > char *sha2)
> > {
> > + assert(the_hash_algo->rawsz == 20);
> > return memcmp(sha1, sha2,
On Wed, Aug 22, 2018 at 07:14:42AM -0400, Derrick Stolee wrote:
> The other thing I was going to recommend (and I'll try to test this out
> myself later) is to see if 'the_hash_algo->rawsz' is being treated as a
> volatile variable, since it is being referenced through a pointer. Perhaps
>
On Wed, Aug 22, 2018 at 09:39:57AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I don't have a good option. The assert() thing works until I add in the
> > "32" branch, but that's just punting the issue off until you add support
> > for the new hash.
> >
> > Hand-rolling our own asm or C is a
This is the great brotherhood Illuminati,Do you want to become rich and
famous contact us now
On 8/22/2018 1:36 AM, brian m. carlson wrote:
On Tue, Aug 21, 2018 at 11:03:44PM -0400, Jeff King wrote:
So I wonder if there's some other way to tell the compiler that we'll
only have a few values. An enum comes to mind, though I don't think the
enum rules are strict enough to make this
On Tue, 2018-08-21 at 23:03 -0400, Jeff King wrote:
> static inline int hashcmp(const unsigned char *sha1, const unsigned
> char *sha2)
> {
> + assert(the_hash_algo->rawsz == 20);
> return memcmp(sha1, sha2, the_hash_algo->rawsz);
> }
I'm not familiar with Git code, but for most
1 - 100 of 111 matches
Mail list logo
