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 bothering to write "issue with
"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`):
I'd drop ", in all cases,"
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 characters after the
subscribe git
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).
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') {
> + if
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 automatically invokes it
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 HEAD v1.2 -- # HEAD is bad, v1.2 is
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 t
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.
2. Move just enough from implementation to heade
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
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 ben
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
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 organizations
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) m
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 organizations
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
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 supposed to have b
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 similar, recording as s
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 for
>> consistency?
>
> I'm wonde
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.
gpg-interface.c | 25
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 a "good" commit' would be bet
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
> > ...
> > $ git bis
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 a "good" commit' would be bet
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:
>
> https://public-inbox.org/git/1460294354-7031-2-g
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" instead, perhaps?
I somehow
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
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 --inaccurate-
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:
https://public-inbox.org/git/1460294354-7031-2-git-send-email-s-be...@gmx.net/
You migh
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 f
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
>
> Signe
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
--- a/Documentation/git-bisect.txt
+++ b/Docume
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 literary license to reword an
... snip ...
ok, will rework.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitte
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
>
Maybe while at it th
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 the ellipses in the
> co
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 t
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}=]
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 +-
contrib/completion/git-completion
39 matches
Mail list logo