Re: [PATCH v1] fsmonitor: simplify determining the git worktree under Windows

Ben Peart writes: > I haven't tested the non Windows paths but the patch looks reasonable. I do not think the above line part of the proposed log message for this patch ;-) I guess I'll strip these earlier parts and leave only the last paragraph while queuing. > > This

Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments

Kaartic Sivaraam writes: > I've tried to improve it, does the following paragraph sound clear > enough? > > branch: group related arguments of create_branch() > > New arguments were added to create_branch() whenever the need > arised and they were

Re: [PATCH v1 2/2] worktree: make add dwim

Thomas Gummerer writes: > I'm a bit torn about hiding his behind an additional flag in git > worktree add or not. I would like to have the feature without the > additional flag, but it might break some peoples expectations, so > dunno. Yeah, I agree with the sentiment.

Re: [PATCH 4/4] sequencer: Show rename progress during cherry picks

Elijah Newren writes: > Subject: Re: [PATCH 4/4] sequencer: Show rename progress during cherry picks Style: s/Show/show/ > When trying to cherry-pick a change that has lots of renames, it is > somewhat unsettling to wait a really long time without any feedback. > >

Re: [PATCH 3/4] progress: Fix progress meters when dealing with lots of work

Elijah Newren writes: > Subject: Re: [PATCH 3/4] progress: Fix progress meters when dealing with lots > of work Style: s/Fix/fix/; > The possibility of setting merge.renameLimit beyond 2^16 raises the > possibility that the values passed to progress can exceed 2^32. For my

Re: [PATCH] Fix NO_LIBPCRE1_JIT to fully disable JIT

On Mon, Nov 13, 2017 at 12:53:15PM +0900, Junio C Hamano wrote: > > Thanks. This patch needs a sign-off, by the way. Signed-off-by: cbaile...@bloomberg.net (I can resend the full patch if required or if anyone requests futher changes. > > But that we should take it anyway regardless of that

Re: [RFC] cover-at-tip

Le 10/11/2017 à 19:22, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin writes: > >> I would need to add "some" level of parsing to am.c to make sure >> the patch content is just garbage and that there are no actual >> hunks for that. >> >> I did not find any

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Sunday 12 November 2017 11:53 PM, Kevin Daudt wrote: On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote: From: Kaartic Sivaraam When trying to rename an inexistent branch to with a name of a branch This sentence does not read well. Probably

Re: [PATCH v3 0/4] Hash abstraction

"brian m. carlson" writes: > This is a series proposing a basic abstraction for hash functions. > > The full description of the series can be found here: > https://public-inbox.org/git/20171028181239.59458-1-sand...@crustytoothpaste.net/ > > At the bottom of this

Re: [Query] Separate hooks for Git worktrees

On 10-11-17, 10:00, Stefan Beller wrote: > Well it is the same project with different upstream workflows. > For example I would imagine that Viresh wants to cherry-pick > from one branch to another, or even send the same patch > (just with different commit messages, with or without the > ChangeId)

Re: [PATCH] builtin/describe.c: describe a blob

Stefan Beller writes: > Sometimes users are given a hash of an object and they want to > identify it further (ex.: Use verify-pack to find the largest blobs, > but what are these? or [1]) Thanks for finishing the topic you started. > @@ -11,6 +11,7 @@ SYNOPSIS > [verse] >

Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments

On Mon, 2017-11-13 at 11:32 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > I've tried to improve it, does the following paragraph sound clear > > enough? > > > > branch: group related arguments of create_branch() > > > > New arguments

Re: [PATCH] Fix NO_LIBPCRE1_JIT to fully disable JIT

Ævar Arnfjörð Bjarmason writes: > On Sun, Nov 12 2017, Charles Bailey jotted: > >> From: Charles Bailey >> >> If you have a pcre1 library which is compiled with JIT enabled then >> PCRE_STUDY_JIT_COMPILE will be defined whether or not the >>

Re: [PATCH v2] gpg-interface: strip CR chars for Windows gpg2

Eric Sunshine writes: > Thanks for the re-roll... > > On Sun, Nov 12, 2017 at 8:07 AM, Jerzy Kozera wrote: >> This fixes the issue with newlines being \r\n and not being displayed >> correctly when using gpg2 for Windows, as reported at >>

Re: [add-default-config 2/5] adding default to color

Jeff King writes: >> @@ -47,6 +48,7 @@ static int show_origin; >> #define ACTION_GET_COLOR (1<<13) >> #define ACTION_GET_COLORBOOL (1<<14) >> #define ACTION_GET_URLMATCH (1<<15) >> +#define ACTION_GET_COLORORDEFAULT (1<<16) > > I'm not sure I understand this part, though.

Re: should "git bisect" support "git bisect next?"

Theodore Ts'o writes: > On Sun, Nov 12, 2017 at 03:21:57PM +0100, Christian Couder wrote: >> >> Yeah I agree that it might be something interesting for the user to do. >> But in this case the sequence in which you give the good and the bad >> commits is not important. >> Only the

Re: [PATCH] bisect run: die if no command is given

Stephan Beyer writes: > It was possible to invoke "git bisect run" without any command. > This considers all commits as good commits since "$@"'s return > value for empty $@ is 0. > > This is most probably not what a user wants (otherwise she would > invoke "git bisect run

Re: [PATCH] doc: Remove explanation of "--" from several man pages

"Robert P. J. Day" writes: > There is no value in individual man pages explaining the purpose of > the "--" separator. > > Signed-off-by: Robert P. J. Day > > --- > > unless every man page explains that option, it's pointless to have > just *some*

Re: [PATCH v16 Part II 5/8] bisect--helper: `bisect_next_check` shell function in C

Stephan Beyer writes: > Hi again ;) > ... > In both of the above "error" calls, you should drop the final "\n" > because "error" does that already. > > On the other hand, you have dropped the "\n"s of the orginal error > messages. So it should probably be > > _("You need to

Re: [add-default-config 2/5] adding default to color

On Mon, Nov 13, 2017 at 12:40:16PM +0900, Junio C Hamano wrote: > As an aside. Over time we accumulated quite a many actions that are > all mutually exclusive by nature. I have a feeling that we might be > better off to move away from this implementation. The only thing > that we are getting

Re: [PATCH 1/4] sequencer: Warn when internal merge may be suboptimal due to renameLimit

Elijah Newren writes: > Subject: Re: [PATCH 1/4] sequencer: Warn when internal merge may be > suboptimal due to renameLimit Style: please downcase s/Warn/warn/ to fit this better in "shortlog --no-merges" output. > Having renamed files silently treated as deleted/modified

Re: [PATCH v1 1/2] checkout: factor out functions to new lib file

Thomas Gummerer writes: > Factor the functions out, so they can be re-used from other places. In > particular these functions will be re-used in builtin/worktree.c to make > git worktree add dwim more. > > While there add a description to the function. > > Signed-off-by:

Re: [PATCH] Make t4201-shortlog.sh test more robust

Jeff King writes: > You're also really doing two things to fix the problem here, either one > of which would have been sufficient: increasing the abbreviation size > and using test_tick to get a deterministic run. > ... > Doing it once is enough to make the test deterministic, and

Re: [add-default-config 5/5] fix return code on default + add tests

On Sun, Nov 12, 2017 at 03:00:40PM +, Soukaina NAIT HMID wrote: > diff --git a/builtin/config.c b/builtin/config.c > index eab81c5627091..29c5f55f27a57 100644 > --- a/builtin/config.c > +++ b/builtin/config.c > @@ -261,9 +261,12 @@ static int get_value(const char *key_, const char > *regex_)

Re: [PATCH] Make t4201-shortlog.sh test more robust

On Sun, Nov 12, 2017 at 03:25:23PM +, Charles Bailey wrote: > From: Charles Bailey > > The test for '--abbrev' in t4201-shortlog.sh assumes that the commits > generated in the test can always be uniquely abbreviated to 5 hex digits > but this is not always the case.

[PATCH] Fix NO_LIBPCRE1_JIT to fully disable JIT

From: Charles Bailey If you have a pcre1 library which is compiled with JIT enabled then PCRE_STUDY_JIT_COMPILE will be defined whether or not the NO_LIBPCRE1_JIT configuration is set. This means that we enable JIT functionality when calling pcre_study even if

Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments

On Mon, 2017-11-06 at 11:06 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > From: Kaartic Sivaraam > > > > The ad-hoc patches to add new arguments to a function when needed > > resulted in the related arguments not being

[PATCH v1 2/2] worktree: make add dwim

Currently git worktree add creates a new branch, that matches the HEAD of whichever worktree we were on when calling "git worktree add". Add a --guess flag to git worktree add, that makes it behave like the dwim machinery in 'git checkout ', i.e. check if the new branch name uniquely matches the

[PATCH v1 1/2] checkout: factor out functions to new lib file

Factor the functions out, so they can be re-used from other places. In particular these functions will be re-used in builtin/worktree.c to make git worktree add dwim more. While there add a description to the function. Signed-off-by: Thomas Gummerer --- I'm not sure

[add-default-config 3/5] add same test for new command format with --default and --color

From: Soukaina NAIT HMID Signed-off-by: Soukaina NAIT HMID --- t/t4026-color2.sh | 129 ++ 1 file changed, 129 insertions(+) create mode 100755 t/t4026-color2.sh diff --git

[add-default-config 1/5] add --color option to git config

From: Soukaina NAIT HMID Signed-off-by: Soukaina NAIT HMID --- Documentation/git-config.txt | 4 builtin/config.c | 1 + 2 files changed, 5 insertions(+) diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt

[PATCH v2] gpg-interface: strip CR chars for Windows gpg2

This fixes the issue with newlines being \r\n and not being displayed correctly when using gpg2 for Windows, as reported at https://github.com/git-for-windows/git/issues/1249 Issues with non-ASCII characters remain for further investigation. Signed-off-by: Jerzy Kozera

Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation

On Mon, 2017-11-06 at 11:24 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > We usually use the word "gently" to when we enhance an operation > that used to always die on failure. When there are tons of callsite > to the original operation F(), we

Re: [PATCH] config: added --expiry-date type support

On Sun, Nov 12, 2017 at 12:19:35PM +, Haaris wrote: > --- > builtin/config.c | 11 ++- > config.c | 9 + > config.h | 1 + > t/t1300-repo-config.sh | 25 + > 4 files changed, 45 insertions(+), 1 deletion(-) > > diff

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Mon, 2017-11-06 at 11:30 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > No {} around a single statement block of "if", especially when there > is no "else" that has multi-statement block that needs {}. > The code has changed a little since v3 so this

Re: should "git bisect" support "git bisect next?"

On Sun, Nov 12, 2017 at 2:43 AM, Junio C Hamano wrote: > Theodore Ts'o writes: > >> On Sat, Nov 11, 2017 at 11:38:23PM +0900, Junio C Hamano wrote: >>> >>> Thanks for saving me time to explain why 'next' is still a very >>> important command but the end users do

Re: [PATCH] config: added --expiry-date type support

On Sun, Nov 12, 2017 at 02:55:53PM +0100, Kevin Daudt wrote: > What I'm also missing is a motivation on why you added this option, > which should be part of your commit message. As far as I know, there is > currently no config setting that expects a date format. This patch came from submitGit,

Re: [PATCH] config: added --expiry-date type support

On Sun, Nov 12, 2017 at 12:19:35PM +, Haaris wrote: > --- Hi, and welcome to the list. Thanks for working on this (for those of you on the list, this was one of the tasks at the hackathon this weekend). Kevin already mentioned a few things about the commit message, which I agree with. >

[add-default-config 5/5] fix return code on default + add tests

From: Soukaina NAIT HMID Signed-off-by: Soukaina NAIT HMID --- builtin/config.c | 9 ++- t/t9904-default.sh | 232 + 2 files changed, 238 insertions(+), 3 deletions(-) create mode 100755

[add-default-config 2/5] adding default to color

From: Soukaina NAIT HMID Signed-off-by: Soukaina NAIT HMID --- builtin/config.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/builtin/config.c b/builtin/config.c index 124a682d50fa8..9df2d9c43bcad 100644 ---

[add-default-config 4/5] add defaults for path/int/bool

From: Soukaina NAIT HMID Signed-off-by: Soukaina NAIT HMID --- builtin/config.c | 12 - t/t4026-color2.sh | 129 -- 2 files changed, 11 insertions(+), 130 deletions(-) delete mode

Re: [PATCH] mru: Replace mru.[ch] with list.h implementation

On Sun, Nov 12, 2017 at 12:49:17PM +, Gargi Sharma wrote: > > Sort of a side note, but seeing these two list pointers together makes > > me wonder what we should do with the list created by the "next" pointer. > > It seems like there are three options: > > > > 1. Convert it to "struct

TO CLAIM YOUR FUNDS IS FREE OF CHARGE

Attention:Sir/Madam THIS OFFICIAL UN GUARANTEE LETTER COVER, You have been selected to receive (950,000.00 EURO) as charity donations / aid from the Qatar Foundation. Please kindly provide the below information details mention. Therefore contact our Agent Mrs.Linda Hall Inspector Admin -(QF)

Re: [PATCH 2/2] stash: implement builtin stash helper

Thanks for your comments! I've incorporated them all for the next patch set.

Re: should "git bisect" support "git bisect next?"

On Sat, 11 Nov 2017, Theodore Ts'o wrote: > On Sat, Nov 11, 2017 at 11:38:23PM +0900, Junio C Hamano wrote: > > > > Thanks for saving me time to explain why 'next' is still a very > > important command but the end users do not actually need to be > > strongly aware of it, because most commands

Re: [PATCH] mru: Replace mru.[ch] with list.h implementation

On Sun, Nov 12, 2017 at 9:54 AM, Jeff King wrote: > On Sat, Nov 11, 2017 at 01:06:46PM -0500, Gargi Sharma wrote: > >> Replace custom allocation in mru.[ch] with generic calls >> to list.h API. >> >> Signed-off-by: Gargi Sharma > > Thanks, and welcome to the

Re: [PATCH] mru: Replace mru.[ch] with list.h implementation

On Sat, Nov 11, 2017 at 01:06:46PM -0500, Gargi Sharma wrote: > Replace custom allocation in mru.[ch] with generic calls > to list.h API. > > Signed-off-by: Gargi Sharma Thanks, and welcome to the git list. :) This looks like a good start on the topic, but I have a few

[no subject]

subscribe git

more pedantry ... what means a file "known to Git"?

apologies for more excruciating nitpickery, but i ask since it seems that phrase means slightly different things depending on where you read it. first, i assume that there are only two categories: 1) files known to Git 2) files unknown to Git and that there is no fuzzy, grey area

Re: "git bisect" takes exactly one bad commit and one or more good?

On Sat, 2017-11-11 at 10:27 -0500, Robert P. J. Day wrote: > > i realize that one of each commit is the simplest use case, but the > scenario that occurred to me is a bunch of branches being merged and, > suddenly, you have a bug, and you're not sure where it came from so > you identify a

Re: should "git bisect" support "git bisect next?"

"Robert P. J. Day" writes: >> This reminds me; is there a way to suppress it because I'm about to >> give a large set of good and bit commits (perhaps because I'm > >> replaying part of a git biset log, minus one or two lines that

Re: [PATCH v3] bisect: mention "view" as an alternative to "visualize"

On Sun, 12 Nov 2017, Junio C Hamano wrote: > "Robert P. J. Day" writes: > > > To see the currently remaining suspects in 'gitk', issue the following > > -command during the bisection process: > > +command during the bisection process (the subcommand `view` can, in all > >

[PATCH v4] bisect: mention "view" as an alternative to "visualize"

Tweak a small number of files to mention "view" as an alternative to "visualize". Signed-off-by: Robert P. J. Day --- ok, let's see if this one is getting close ... Documentation/git-bisect.txt | 13 ++--- builtin/bisect--helper.c | 2 +- git-bisect.sh

Re: [PATCH] mru: Replace mru.[ch] with list.h implementation

On Sun, Nov 12, 2017 at 09:54:35AM +, Jeff King wrote: > > @@ -1566,6 +1566,7 @@ struct pack_window { > > > > extern struct packed_git { > > struct packed_git *next; > > + struct list_head mru; > > struct pack_window *windows; > > off_t pack_size; > > const void

[PATCH] link_alt_odb_entries: make empty input a noop

On Sat, Nov 11, 2017 at 11:13:21AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > So totally orthogonal to your bug, I wonder if we ought to be doing: > > > > diff --git a/sha1_file.c b/sha1_file.c > > index 057262d46e..0b76233aa7 100644 > > --- a/sha1_file.c > > +++

Re: NO_MSGFMT

On Sun, Aug 13, 2017 at 12:58:13AM -0400, Jeff King wrote: > On Sat, Aug 12, 2017 at 03:44:17PM +0200, Dominik Mahrer (Teddy) wrote: > > > Hi all > > > > I'm compiling git from source code on a mashine without msgfmt. This leads > > to compile errors. To be able to compile git I created a patch

[PATCH] config: added --expiry-date type support

--- builtin/config.c | 11 ++- config.c | 9 + config.h | 1 + t/t1300-repo-config.sh | 25 + 4 files changed, 45 insertions(+), 1 deletion(-) diff --git a/builtin/config.c b/builtin/config.c index

Re: [PATCH] Reduce performance penalty for turned off traces

On Sat, Nov 11, 2017 at 07:28:58PM +, gennady.kup...@gmail.com wrote: > From: Gennady Kupava > > Signed-off-by: Gennady Kupava Thanks, and welcome to the list. > --- > One of the tasks siggested in scope of 'Git sprint weekend'. > Couple of

Re: [add-default-config 3/5] add same test for new command format with --default and --color

On Sun, Nov 12, 2017 at 03:00:40PM +, Soukaina NAIT HMID wrote: > --- > t/t4026-color2.sh | 129 > ++ > 1 file changed, 129 insertions(+) > create mode 100755 t/t4026-color2.sh I'll skip reviewing this one, since the file goes away later

Re: [add-default-config 1/5] add --color option to git config

On Sun, Nov 12, 2017 at 03:00:40PM +, Soukaina NAIT HMID wrote: > From: Soukaina NAIT HMID > > Signed-off-by: Soukaina NAIT HMID Hi Soukaina, and welcome to the list! Thanks for working on these patches. I'll go through and make inline

Re: [PATCH 2/2] stash: implement builtin stash helper

On 11/10, Joel Teichroeb wrote: > Start moving stash functions over to builtin c code and call > them in the shell script, instead of converting it all at > once. > > Signed-off-by: Joel Teichroeb > --- Thanks for working on this! I like the approach of converting this one

[PATCH] Make t4201-shortlog.sh test more robust

From: Charles Bailey The test for '--abbrev' in t4201-shortlog.sh assumes that the commits generated in the test can always be uniquely abbreviated to 5 hex digits but this is not always the case. If you were unlucky and happened to run the test at (say) Thu Jun 22

Re: [add-default-config 2/5] adding default to color

On Sun, Nov 12, 2017 at 03:00:40PM +, Soukaina NAIT HMID wrote: > diff --git a/builtin/config.c b/builtin/config.c > index 124a682d50fa8..9df2d9c43bcad 100644 > --- a/builtin/config.c > +++ b/builtin/config.c > @@ -30,6 +30,7 @@ static int end_null; > static int respect_includes_opt = -1; >

Re: [add-default-config 4/5] add defaults for path/int/bool

On Sun, Nov 12, 2017 at 03:00:40PM +, Soukaina NAIT HMID wrote: > @@ -256,8 +258,15 @@ static int get_value(const char *key_, const char > *regex_) > fwrite(buf->buf, 1, buf->len, stdout); > strbuf_release(buf); > } > - free(values.items); > >

Re: NO_MSGFMT

On Sun, Nov 12, 2017 at 12:57 PM, Jeff King wrote: > On Sun, Aug 13, 2017 at 12:58:13AM -0400, Jeff King wrote: > >> On Sat, Aug 12, 2017 at 03:44:17PM +0200, Dominik Mahrer (Teddy) wrote: >> >> > Hi all >> > >> > I'm compiling git from source code on a mashine without msgfmt. This

Re: [PATCH v2] gpg-interface: strip CR chars for Windows gpg2

Thanks for the re-roll... On Sun, Nov 12, 2017 at 8:07 AM, Jerzy Kozera wrote: > This fixes the issue with newlines being \r\n and not being displayed > correctly when using gpg2 for Windows, as reported at > https://github.com/git-for-windows/git/issues/1249 It's still

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote: > From: Kaartic Sivaraam > > When trying to rename an inexistent branch to with a name of a branch This sentence does not read well. Probably s/with a/the/ helps. > that already exists the rename

Re: should "git bisect" support "git bisect next?"

On Sun, Nov 12, 2017 at 03:21:57PM +0100, Christian Couder wrote: > > Yeah I agree that it might be something interesting for the user to do. > But in this case the sequence in which you give the good and the bad > commits is not important. > Only the last bad commit and the set of good commits

[PATCH v3 2/4] Add structure representing hash algorithm

Since in the future we want to support an additional hash algorithm, add a structure that represents a hash algorithm and all the data that must go along with it. Add a constant to allow easy enumeration of hash algorithms. Implement function typedefs to create an abstract API that can be used

[PATCH v3 3/4] Integrate hash algorithm support with repo setup

In future versions of Git, we plan to support an additional hash algorithm. Integrate the enumeration of hash algorithms with repository setup, and store a pointer to the enumerated data in struct repository. Of course, we currently only support SHA-1, so hard-code this value in

[PATCH v3 4/4] Switch empty tree and blob lookups to use hash abstraction

Switch the uses of empty_tree_oid and empty_blob_oid to use the current_hash abstraction that represents the current hash algorithm in use. Signed-off-by: brian m. carlson --- builtin/am.c | 2 +- builtin/checkout.c | 2 +- builtin/diff.c | 2 +-

[PATCH v3 1/4] setup: expose enumerated repo info

We enumerate several different items as part of struct repository_format, but then actually set up those values using the global variables we've initialized from them. Instead, let's pass a pointer to the structure down to the code where we enumerate these values, so we can later on use those

[PATCH v3 0/4] Hash abstraction

This is a series proposing a basic abstraction for hash functions. The full description of the series can be found here: https://public-inbox.org/git/20171028181239.59458-1-sand...@crustytoothpaste.net/ At the bottom of this message is the output of git tbdiff between v2 and v3. Changes from

[PATCH v2 2/2] Documentation: convert SubmittingPatches to AsciiDoc

The SubmittingPatches document is often cited by outside parties as an example of good practices to follow, including logical, independent commits; patch sign-offs; and sending patches to a mailing list. Currently, people who want to cite a particular section tend to either refer to it by name and

[PATCH v2 1/2] Documentation: enable compat-mode for Asciidoctor

Asciidoctor 1.5.0 and later have a compatibility mode that makes it more compatible with some Asciidoc syntax, notably the single and double quote handling. While this doesn't affect any of our current documentation, it would be beneficial to enable this mode to reduce the differences between

[PATCH v2 0/2] Convert SubmittingPatches to AsciiDoc

This series converts SubmittingPatches into AsciiDoc and builds it as part of the technical documentation. The goal is to provide a format that is more easily linkable both from our website and by others, as the Git Project's patch submission standards are widely referenced and used as examples.

Re: [PATCH v16 Part II 5/8] bisect--helper: `bisect_next_check` shell function in C

> @@ -21,6 +22,7 @@ static const char * const git_bisect_helper_usage[] = { > N_("git bisect--helper --bisect-reset []"), > N_("git bisect--helper --bisect-write > []"), > N_("git bisect--helper --bisect-check-and-set-terms > "), > + N_("git bisect--helper

Re: should "git bisect" support "git bisect next?"

Hi, On 11/11/2017 03:38 PM, Junio C Hamano wrote: > Christian Couder writes: > >> On Sat, Nov 11, 2017 at 12:42 PM, Robert P. J. Day >> wrote: >>> >>> the man page for "git bisect" makes no mention of "git bisect next", >>> but the script

Re: [PATCH v2 1/1] Introduce git add --renormalize .

On Fri, Nov 10, 2017 at 09:22:10AM +0900, Junio C Hamano wrote: > > Taking these altogether, perhaps > > Apply the "clean" process freshly to all tracked files to > forcibly add them again to the index. This is useful after > changing `core.autocrlf` configuration or the `text`

aesthetic standard for synopsis line of man pages?

yet more aesthetic nitpickery ... was just perusing the man pages of both "git clean" and "git rm", and noticed some striking inconsistency. from "man git-clean": SYNOPSIS git clean [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] ... note how, in that sypnosis, even those options

Re: [PATCH v16 Part II 5/8] bisect--helper: `bisect_next_check` shell function in C

Hi, another minor: On 10/27/2017 05:06 PM, Pranit Bauva wrote: > @@ -264,6 +271,79 @@ static int check_and_set_terms(struct bisect_terms > *terms, const char *cmd) > return 0; > } > > +static int mark_good(const char *refname, const struct object_id *oid, > + int flag,

Re: [PATCH] config: added --expiry-date type support

On 2017-11-12 14:55, Jeff King wrote: Hi, and welcome to the list. Thanks for working on this (for those of you on the list, this was one of the tasks at the hackathon this weekend). It was a pleasure meeting everyone and a great experience! Kevin already mentioned a few things about the

Re: [PATCH v16 Part II 5/8] bisect--helper: `bisect_next_check` shell function in C

Hi again ;) On 10/27/2017 05:06 PM, Pranit Bauva wrote: > @@ -44,6 +46,11 @@ static void set_terms(struct bisect_terms *terms, const > char *bad, > terms->term_bad = xstrdup(bad); > } > > +static const char *voc[] = { > + "bad|new", > + "good|old" > +}; > + > /* > * Check

Re: [PATCH v2] gpg-interface: strip CR chars for Windows gpg2

On Sun, Nov 12, 2017 at 01:07:10PM +, Jerzy Kozera wrote: > This fixes the issue with newlines being \r\n and not being displayed > correctly when using gpg2 for Windows, as reported at > https://github.com/git-for-windows/git/issues/1249 > > Issues with non-ASCII characters remain for

Re: [PATCH] Fix NO_LIBPCRE1_JIT to fully disable JIT

On Sun, Nov 12 2017, Charles Bailey jotted: > From: Charles Bailey > > If you have a pcre1 library which is compiled with JIT enabled then > PCRE_STUDY_JIT_COMPILE will be defined whether or not the > NO_LIBPCRE1_JIT configuration is set. > > This means that we enable

[PATCH] bisect run: die if no command is given

It was possible to invoke "git bisect run" without any command. This considers all commits as good commits since "$@"'s return value for empty $@ is 0. This is most probably not what a user wants (otherwise she would invoke "git bisect run true"), so not providing a command now results in an

[PATCH] doc: Remove explanation of "--" from several man pages

There is no value in individual man pages explaining the purpose of the "--" separator. Signed-off-by: Robert P. J. Day --- unless every man page explains that option, it's pointless to have just *some* man pages explaining it, so might as well remove it from all of

Re: "git bisect" takes exactly one bad commit and one or more good?

On 11/11/2017 03:34 PM, Junio C Hamano wrote: > Christian Couder writes: > >>> "You use it by first telling it a "bad" commit that is known to >>> contain the bug, and a "good" commit that is known to be before the >>> bug was introduced." >> >> Yeah, 'and at least a

Re: [PATCH] Reduce performance penalty for turned off traces

Hi Jeff, thanks for such detailed review and additional testing. Below are just some discussion related review comments, Please expect patch itself on some evening during coming week. On 12 November 2017 at 14:17, Jeff King wrote: > > On Sat, Nov 11, 2017 at 07:28:58PM +,