On Wed, Aug 22, 2018 at 8:20 AM Jeff King wrote:
>
> On Wed, Aug 22, 2018 at 05:36:26AM +, 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
On Sun, Aug 5, 2018 at 7:23 PM Thomas Gummerer wrote:
Late reply since I just saw this in next.
> Currently rerere can't handle nested conflicts and will error out when
> it encounters such conflicts. Do that by recursively calling the
> 'handle_conflict' function to normalize the conflict.
> [
On 8/21/2018 11:36 PM, Jeff King wrote:
On Tue, Aug 21, 2018 at 11:03:44PM -0400, Jeff King wrote:
with the obvious "oideq()" implementation added, that seems to get me to
2-3%. Not _quite_ as good as the original branching version I showed.
And we had to touch all the callsites (although argua
On 8/22/2018 3:39 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Aug 22, 2018 at 8:20 AM Jeff King wrote:
On Wed, Aug 22, 2018 at 05:36:26AM +, brian m. carlson wrote:
On Tue, Aug 21, 2018 at 11:03:44PM -0400, Jeff King wrote:
I don't know if something like this is an improvement or now, bu
On Mon, 20 Aug 2018 23:37:55 +0200
Antonio Ospite wrote:
> On Tue, 14 Aug 2018 13:36:17 -0700
> Junio C Hamano wrote:
>
> > Antonio Ospite writes:
[...]
> > >
> > > + # For more details about this check, see
> > > + # builtin/submodule--helper.c::module_config()
> > > + if test ! -e .gitmodu
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 anyway.
As a minimal fix, fix the
The test ' context does not include preceding empty lines' in the
block of tests 'change with long common tail and no context' in
't4051-diff-function-context.sh' tries to read the file
'long_common_tail.diff.diff', but that file doesn't exist as its name
contains one more '.diff' suffixes than nec
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 Gábor
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
the change in the output size of certain operations.
This patch introduces test_siz
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 e
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 guarant
This is the great brotherhood Illuminati,Do you want to become rich and
famous contact us now
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 portabi
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
> storing
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, th
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 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 "gc.commitGr
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 wa
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
> > the
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", a
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 merge
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
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 --
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 --git
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 m
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 --git
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 +32
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 a/
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 a
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 --git
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 | 124 +--
Documentation/receive-config.txt | 123 ++
2 files changed, 124 insertions(+), 123 deletions(-)
create mode 100644 Documentation/receive-config.txt
diff --
Æ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 the
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, sinc
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 any
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 'the_ha
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 recomm
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
> alre
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 o
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.
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
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 goin
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 2
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 sur
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).
>>
>> Loo
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 wr
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.
M
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 empt
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.
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:
>
> ht
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 spe
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 consistentl
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, a
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 af
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 t
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
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.
>
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?
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, I'd
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 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 resul
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 cod
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
> > something
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 c
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 o
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" && keep_empty="--keep-em
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 synon
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 aca
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 a/builtin/reba
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 inte
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.
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 of
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 read_from_s
"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
> ap
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 message.
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 sb/range-diff-colo
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 may
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 cha
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 not
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 fe
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 p
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
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 wh
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
positives.
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 confus
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
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
64-
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
has_conform
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 a
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);
>>> }
[...]
>
> > 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 or
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 the
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 thin
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);
>
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
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 cha
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
> ---
>
1 - 100 of 109 matches
Mail list logo
