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

more on "git bisect" ... the man page seems to make it clear that bisection takes *precisely* one "bad" commit, and one *or more* good commits, is that correct? seems that way, given the ellipses in the commands below: git bisect start [--term-{old,good}= --term-{new,bad}=]

should "git bisect" support "git bisect next?"

the man page for "git bisect" makes no mention of "git bisect next", but the script git-bisect.sh does: #!/bin/sh USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]' LONG_USAGE='git bisect help print

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

On Sat, Nov 11, 2017 at 12:22 PM, Robert P. J. Day wrote: > > more on "git bisect" ... the man page seems to make it clear that > bisection takes *precisely* one "bad" commit, and one *or more* good > commits, is that correct? Yeah, that's true. > seems that way, given

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

On Sat, Nov 11, 2017 at 11:31 AM, Robert P. J. Day wrote: > Tweak a number of files to mention "view" as an alternative to > "visualize". Good idea. > @@ -196,15 +196,14 @@ of `git bisect good` and `git bisect bad` to mark > commits. > Bisect visualize >

Re: [PATCH] bisect: clarify that one can select multiple good commits

On Sat, 11 Nov 2017, Kevin Daudt wrote: > On Sat, Nov 11, 2017 at 08:26:00AM -0500, Robert P. J. Day wrote: > > > > Current man page for "bisect" is inconsistent explaining the fact that > > "git bisect" takes precisely one bad commit, but one or more good > > commits, so tweak the man page in a

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

On Sat, 11 Nov 2017, 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

Re: [RFC PATCH 4/9] Add testcases for improved file collision conflict handling

On Fri, Nov 10, 2017 at 2:21 PM, Elijah Newren wrote: > Adds testcases dealing with file collisions for the following types of > conflicts: > * add/add > * rename/add > * rename/rename(2to1) > --- > t/t6036-recursive-corner-cases.sh| 8 +- The changes to t6036 were

[PATCH] bisect: clarify that one can select multiple good commits

Current man page for "bisect" is inconsistent explaining the fact that "git bisect" takes precisely one bad commit, but one or more good commits, so tweak the man page in a few places to make that clear. rday Signed-off-by: Robert P. J. Day --- i also exercised

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

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 git-bisect.sh does: Yeah the following patch was related:

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

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 git-bisect.sh does: > > Yeah the following patch was related:

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

This fixes the issue with newlines 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 --- The patch applies cleanly on top of maint as well as master.

Re: [PATCH 2/4] Remove silent clamp of renameLimit

Hi, On Fri, Nov 10, 2017 at 3:42 PM, brian m. carlson wrote: > On Fri, Nov 10, 2017 at 10:36:17AM -0800, Elijah Newren wrote: >> Further, the later patch used uint64_t instead of double. While >> double works, perhaps I should change the double here to uint64_t

( U.N.O/W.B.O/11/11/2017/1982/09/05 )

United Nations Compensation Unit, In Affiliation with World Bank Our Ref: U.N.O/W.B.O/11/11/2017/1982/09/05. Congratulations Beneficiary, We have been working closely with the INTERPOL, CIA, FBI and other foreign international organizations as well as Western Union and Money Gram regarding

Re: is there a stylistic preference for a trailing "--" on a command?

On Fri, Nov 10, 2017 at 10:12:39AM -0800, Stefan Beller wrote: > On Fri, Nov 10, 2017 at 5:57 AM, Robert P. J. Day > wrote: > > > > just noticed these examples in "man git-bisect": > > > > EXAMPLES > > $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good >

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

... snip ... ok, will rework. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter:

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

On Sat, 11 Nov 2017, 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

Subject: Compensation Unit file: IPOH

Subject: Compensation Unit file: IPOH United Nations Compensation Unit, In Affiliation with World Bank Our Ref: Ref: IPOH: ADO/OSHA/33/UN/OSHA/ADO/6410/10/2017 Congratulations Beneficiary, We have been working closely with the INTERPOL, CIA, FBI and other foreign international

Re: [PATCH 2/4] Remove silent clamp of renameLimit

On Sat, Nov 11, 2017 at 08:39:11AM -0800, Elijah Newren wrote: > Thanks for pointing out unsigned_mult_overflows; I was unaware of it. > I think I'd prefer to not use it though; the fact that I had a case > that genuinely needed a value greater than 2^31 (at least before my > performance patches)

Re: [PATCH] bisect: clarify that one can select multiple good commits

On Sat, Nov 11, 2017 at 08:26:00AM -0500, Robert P. J. Day wrote: > > Current man page for "bisect" is inconsistent explaining the fact that > "git bisect" takes precisely one bad commit, but one or more good > commits, so tweak the man page in a few places to make that clear. > > rday > >

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

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 "good" commit' would be better. Make it "at least one"

Re: [RFC PATCH 3/9] merge-recursive: New function for better colliding conflict resolutions

On Fri, Nov 10, 2017 at 2:21 PM, Elijah Newren wrote: > There are three conflict types that represent two (possibly entirely > unrelated) files colliding at the same location: > If the files are similar enough, the two-way merge is probably > preferable, but if they're not

Re: is there a stylistic preference for a trailing "--" on a command?

Jeff King writes: > On Fri, Nov 10, 2017 at 10:12:39AM -0800, Stefan Beller wrote: > >> On Fri, Nov 10, 2017 at 5:57 AM, Robert P. J. Day >> wrote: >> > >> > just noticed these examples in "man git-bisect": >> > >> > EXAMPLES >> > $ git bisect start

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

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 not actually need to be >> strongly aware of it, because most commands

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

Jerzy Kozera writes: > +/* Strip CR from the line endings, in case we are on Windows. */ > +static void strip_cr(struct strbuf *buffer, size_t bottom) { > + size_t i, j; > + for (i = j = bottom; i < buffer->len; i++) > + if (buffer->buf[i] != '\r') { >

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

Jerzy Kozera writes: One minor detail I missed: > Subject: Re: [PATCH] gpg-interface: Strip CR chars for Windows gpg2 Please downcase "Strip" (see "git shortlog --no-merges" for recent history to notice that it would make this commit sit better with the existing ones).

[no subject]

subscribe git

Re: [PATCH] apply: avoid out-of-bounds access in fuzzy_matchlines()

René Scharfe writes: > fuzzy_matchlines() uses a pointers to the first and last characters of > two lines to keep track while matching them. This makes it impossible > to deal with empty strings. It accesses characters before the start of > empty lines. It can also access

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

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 automatically invokes it > as their final step due to

Subject: Compensation Unit file: IPOH

Subject: Compensation Unit file: IPOH United Nations Compensation Unit, In Affiliation with World Bank Our Ref: Ref: IPOH: ADO/OSHA/33/UN/OSHA/ADO/6410/10/2017 Congratulations Beneficiary, We have been working closely with the INTERPOL, CIA, FBI and other foreign international

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

Replace custom allocation in mru.[ch] with generic calls to list.h API. Signed-off-by: Gargi Sharma --- builtin/pack-objects.c | 14 -- cache.h| 9 + mru.c | 27 --- mru.h | 40

( U.N.O/W.B.O/11/11/2017/1982/09/05 )

United Nations Compensation Unit, In Affiliation with World Bank Our Ref: U.N.O/W.B.O/11/11/2017/1982/09/05. Congratulations Beneficiary, We have been working closely with the INTERPOL, CIA, FBI and other foreign international organizations as well as Western Union and Money Gram regarding

[PATCH] Reduce performance penalty for turned off traces

From: Gennady Kupava Signed-off-by: Gennady Kupava --- One of the tasks siggested in scope of 'Git sprint weekend'. Couple of chioces made here: 1. Use constant instead of NULL to indicate default trace level, this just makes everything simpler.

MUTUAL COPERATION THANK YOU

Dear Friend, I know that this message will come to you as a surprise. I am the Auditing and Accounting section manager with African Development Bank, Ouagadougou Burkina faso. I Hope that you will not expose or betray this trust and confident that I am about to repose on you for the mutual

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

"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 > +cases, be used as an alternative to `visualize`):

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

Jerzy Kozera writes: > This fixes the issue with newlines reported at > https://github.com/git-for-windows/git/issues/1249 Do not omit the description of what you wanted to do completely and force readers of "git log" to visit an external website. You are already

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

Tweak a number of files to mention "view" as an alternative to "visualize". Signed-off-by: Robert P. J. Day --- ... converging slowly ... diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 6c42abf07..dde720552 100644 ---

[PATCH] apply: avoid out-of-bounds access in fuzzy_matchlines()

fuzzy_matchlines() uses a pointers to the first and last characters of two lines to keep track while matching them. This makes it impossible to deal with empty strings. It accesses characters before the start of empty lines. It can also access characters after the end when checking for trailing

Re: Invalid memory access in `git apply`

Am 08.11.2017 um 17:58 schrieb mqu...@neosmart.net: > **Resending as it seems that the attachments caused the last email to wind up > in a black hole** > > There seems to be bug in the `git apply` that leads to out-of-bounds memory > access when --ignore-space-change is combined with

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

Tweak a number of files to mention "view" as an alternative to "visualize". Signed-off-by: Robert P. J. Day --- Documentation/git-bisect.txt | 9 - Documentation/user-manual.txt | 3 ++- builtin/bisect--helper.c | 2 +-