ent; what blame command did
you run?
But when I get log with -m flag for merge revision, I can't see that
file in the list of changed files.
Why?
The contents of 'delta.h' is identical in both parents of that merge:
$ git diff a9572072 294c695d delta.h
$
# no difference
t;> delta.h file.
> >
> > I'm not sure what you mean by this statement; what blame command did
> > you run?
> >
> >> But when I get log with -m flag for merge revision, I can't see that
> >> file in the list of changed files.
> >> Why?
is a merge based on pair of revisions a9572072 and 294c695d.
According to blame these parent revisions have different content for
delta.h file.
I'm not sure what you mean by this statement; what blame command did
you run?
But when I get log with -m flag for merge revision, I can't see t
ased on pair of revisions a9572072 and 294c695d.
> According to blame these parent revisions have different content for
> delta.h file.
I'm not sure what you mean by this statement; what blame command did
you run?
> But when I get log with -m flag for merge revision, I can't see tha
sions have different content for
delta.h file.
But when I get log with -m flag for merge revision, I can't see that
file in the list of changed files.
Why?
Hello My Dear,
Your Payment Compensation funds value the sum of USD $900.000.00 was forward to
the western union money transfer for immediate transfer it to you as soon as
you meet up with the Director of the Board Remittance Authority.
Contact Foreign Operation Manger Western Union Office.
Mrs
美好的一天
我以万能的耶和华的名，向你们问候一切善行的人。良好的一天和季节的赞美，我知道这是真的，这封信可能会来到你一个惊喜。然而，我谦恭地要求你给我注意，并听到我很好，但我恳求你花时间仔细阅读这个消息，因为你做出的决定将有很长的路要确定我的未来存在。我是Julian
Worker夫人，一个58岁的寡妇，来自美国拉斯维加斯，与联合国合作;我患有肺癌，目前住院在布基纳法索普通医院。我有一些资金，我继承了我已故的丈夫，总和（USD
$
14.5百万美元），我需要一个非常诚实和神害怕谁可以提取这笔钱，然后使用的资金用于慈善工作。我想把这些基金给你的慈善工作。我发现你的电子邮件地址从互联网
Jeff King writes:
> On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
>
>> How about changing "git show -p M" to output "diff -p M^ M" rather than
>> "diff-tree --cc M" for merge commits? It's really surprising specifying
&g
On Tue, Mar 26, 2019 at 3:20 PM Jeff King wrote:
>
> On Tue, Mar 26, 2019 at 03:07:42PM -0700, Elijah Newren wrote:
>
> > On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
> > >
> > > On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> > >
On Tue, Mar 26, 2019 at 03:07:42PM -0700, Elijah Newren wrote:
> On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
> >
> > On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> >
> > > How about changing "git show -p M" to output "diff -p M
On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
>
> > How about changing "git show -p M" to output "diff -p M^ M" rather than
> > "diff-tree --cc M" for merge commits? It&#
On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> How about changing "git show -p M" to output "diff -p M^ M" rather than
> "diff-tree --cc M" for merge commits? It's really surprising specifying
> -p has no visible effect.
That&#x
diately comes to mind is "git log -p" for a
>> merge commit. I doesn't currently (as of v2.10) show the first-parent
>> diff, for whatever reason. "git log -p -m --first-parent" is needed to
>> get the answer to most "obvious" question: what (merge) c
During the 'git switch' discusion, Phillip found out that staged changes
could be silently lost when doing 'git checkout -m'. The first attempt
[2] tries to fix it by warning and moving on, because t7201.10 would
fail if we simply die() when there are staged changes.
This
On Wed, Mar 20, 2019 at 09:38:57AM +0900, Junio C Hamano wrote:
> "git log -p --first-parent" that requires "-m" to show the single
> ball of wax diff for a merge is a separate matter. When the user
> explicitly says "log --first-parent", it is a clear indi
erge commit. I doesn't currently (as of v2.10) show the first-parent
> diff, for whatever reason. "git log -p -m --first-parent" is needed to
> get the answer to most "obvious" question: what (merge) commit did to my
> mainline? "git show" has its own issues.
to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commits, while
>> specifying '-m 1' fails on non-merge commits.
>
> Allowing "-m1" even when picking
N_("break complete rewrite changes into pairs of
delete and create"),
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
diff_opt_break_rewrites),
+ OPT_CALLBACK_F('M', "find-renames",
N_("break complete rewrite changes into pairs of
delete and create"),
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
diff_opt_break_rewrites),
+ OPT_CALLBACK_F('M', "find-renames",
"break complete rewrite changes into pairs of
delete and create"),
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
diff_opt_break_rewrites),
+ OPT_CALLBACK_F('M', "find-renames",
Since 0f086e6dca (checkout: print something when checking out paths -
2018-11-13), this command reports how many paths have been updated
from what source (either from a tree, or from the index). I forget
that there's a third source: when -m is used, the merge conflict is
re-created (granted,
"break complete rewrite changes into pairs of
delete and create"),
PARSE_OPT_NONEG | PARSE_OPT_OPTARG,
diff_opt_break_rewrites),
+ OPT_CALLBACK_F('M', "find-renames",
-merge.sh
@@ -40,12 +40,12 @@ test_expect_success 'cherry-pick -m complains of bogus
numbers' '
test_expect_code 129 git cherry-pick -m 0 b
'
-test_expect_success 'cherry-pick a non-merge with -m should fail' '
+test_expect_success 'cherry-p
+64,10 @@ test_expect_success 'merge setup' '
git checkout -b new A
'
-test_expect_success 'cherry-pick a non-merge with --ff and -m should fail' '
+test_expect_success 'cherry-pick explicit first parent of a non-merge with
--ff' '
g
Change from v2: t/t3502: disambiguation added to prevent failing on
case-insensitive file systems.
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
this method to force failure will stop to work.
Use '-m 4' instead as it's very unlikely we will ever have such an
octopus in this test setup.
Signed-off-by: Sergey Organov
---
t/t3510-ch
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch al
'
>>
>> -test_expect_success 'revert a non-merge with -m should fail' '
>> +test_expect_success 'revert explicit first parent of a non-merge' '
>>
>> git reset --hard &&
>> git checkout c^0 &&
>
sh
> index b160271..3259bd5 100755
> --- a/t/t3502-cherry-pick-merge.sh
> +++ b/t/t3502-cherry-pick-merge.sh
> @@ -40,12 +40,12 @@ test_expect_success 'cherry-pick -m complains of bogus
> numbers' '
> test_expect_code 129 git cherry-pick -m 0 b
> '
Junio C Hamano writes:
> Sergey Organov , Sergey Organov
> writes:
>
>> Hi Junio,
>>
>> What's the status of these patches?
>
> The status of these patches is "Just updated on the list", as far as
> I am concerned, and its cover letter would have described what's
> improved relative to the previ
/t/t3502-cherry-pick-merge.sh
index b1602718f8..3259bd59eb 100755
--- a/t/t3502-cherry-pick-merge.sh
+++ b/t/t3502-cherry-pick-merge.sh
@@ -40,12 +40,12 @@ test_expect_success 'cherry-pick -m complains of bogus
numbers' '
test_expect_code 129 git cherry-pick -m 0 b
'
-
Hi Junio,
What's the status of these patches?
Thanks,
-- Sergey
Sergey Organov writes:
> When cherry-picking multiple commits, it's impossible to have both
> merge- and non-merge commits on the same command-line. Not specifying
> '-m 1' results in cherry-pick ref
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch al
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
this method to force failure will stop to work.
Use '-m 4' instead as it's very unlikely we will ever have such an
octopus in this test setup.
Signed-off-by: Sergey Organov
---
t/t3510-ch
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch series a
-merge.sh
@@ -40,12 +40,12 @@ test_expect_success 'cherry-pick -m complains of bogus
numbers' '
test_expect_code 129 git cherry-pick -m 0 b
'
-test_expect_success 'cherry-pick a non-merge with -m should fail' '
+test_expect_success 'cherry-p
+64,10 @@ test_expect_success 'merge setup' '
git checkout -b new A
'
-test_expect_success 'cherry-pick a non-merge with --ff and -m should fail' '
+test_expect_success 'cherry-pick explicit first parent of a non-merge with
--ff' '
g
Sergey Organov writes:
> I came up with the following as a preparatory change. Looks acceptable?
>
> -- 8< --
>
> t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
>
> We are going to allow 'git cherry-pick -m 1' fo
aviour must be protected by a new test (or two) so
>> that we won't accidentally stop accepting "-m 1" for a single-parent
>> commit.
>
> I fixed most of the tests, but
>
> "t3510/4: cherry-pick persists opts correctly"
>
> is an offender for m
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commi
Sergey Organov writes:
> When cherry-picking multiple commits, it's impossible to have both
> merge- and non-merge commits on the same command-line. Not specifying
> '-m 1' results in cherry-pick refusing to handle merge commits, while
> specifying '-m 1'
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commi
ability track movement of code.
I have been testing git-blame -M -C and I found some behaviour
that seems incorrect. I have created a very simple repository
that I think showcases this problem:
https://github.com/dmgerman/testBlameMove
this repo have 4 commits (listed below in order of
Am 06.12.18 um 01:58 schrieb Junio C Hamano:
> Frank Schäfer writes:
>
>> Just to be sure that I'm not missing anything here:
>> What's your definition of "LF in repository, CRLF in working tree" in
>> terms of config parameters ?
> :::Documentation/config/core.txt:::
>
> core.autocrlf::
>
Frank Schäfer writes:
> Just to be sure that I'm not missing anything here:
> What's your definition of "LF in repository, CRLF in working tree" in
> terms of config parameters ?
:::Documentation/config/core.txt:::
core.autocrlf::
Setting this variable to "true" is the same as setting
be more
clever than the pager when it comes to presentation of text.
As far as I am concerned, I do not have any of my files marked as
eol=crlf, but I do *not* want to see ^M in the pager. I.e., having git
insert between CR and LF would do the wrong thing for me.
But doing the same thing in
f ?
> I have no strong opinions, other than that "LF in repository, CRLF
> in working tree" would make the issue go away (when it is solved for
> EOL=LF like the above, that is).
>
>> Keeping the current behavior of '-' lines is correct.
>> But shouldn&
t;
>
> Why? It is the pager's duty to highlight CR, IMO. If it doesn't, but
> the user wants to see them, then they are using the wrong pager or the
> wrong pager settings.
AFAIU Junios explanation it's not the pagers fault.
>
> As far as I am concerned, I do not have
away (when it is solved for
EOL=LF like the above, that is).
> Keeping the current behavior of '-' lines is correct.
> But shouldn't ^M now be suppressed in '+' lines for a consistent behavior ?
If "LF in repository, CRLF in working tree" is done, there would not
be ^M at the end of the line, not just for removed lines, but also
for added lines, no?
eeping the current behavior of '-' lines is correct.
But shouldn't ^M now be suppressed in '+' lines for a consistent behavior ?
That can be achieved with whitespace=cr-at-eol.
With other words:
"If CR comes immediately before a LF, do the following with *all* lines:
vior of '-' lines is correct.
But shouldn't ^M now be suppressed in '+' lines for a consistent behavior ?
With other words:
"If CR comes immediately before a LF, do the following with *all* lines:
after the CR if eol=lf but do not after the CR if eol=crlf."
Regards,
Frank
detect errors on "old" and "new"
lines), but I think we still should make an effort to help them be
visible to the users. Otherwise, next Frank will come and complain
after seeing
-something
some common thing
+something_new^M
With the suggested chan
Am 27.11.18 um 19:15 schrieb Johannes Sixt:
> Am 27.11.18 um 00:31 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>> ... this goes too far, IMO. It is the pager's task to decode control
>>> characters.
>>
>> It was tongue-in-cheek suggestion to
Am 27.11.18 um 00:31 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>> That does not sound right. I would understand it if both lines
>>> showed ^M at the end, and only the one on the postimage line had it
Am 27.11.18 um 00:31 schrieb Junio C Hamano:
Johannes Sixt writes:
Am 26.11.18 um 04:04 schrieb Junio C Hamano:
... this goes too far, IMO. It is the pager's task to decode control
characters.
It was tongue-in-cheek suggestion to split a CR into caret-em on our
end, but we'd get essentially t
Johannes Sixt writes:
> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>
>> That does not sound right. I would understand it if both lines
>> showed ^M at the end, and only the one on the postimage line had it
>> highlighted as a trailing-whitespace.
>
> I agree
Am 26.11.18 um 04:04 schrieb Junio C Hamano:
It appears to me that what Frank sees is not "^M highlighted for
whitespace breakage appears only on postimage lines, while ^M is
shown but not highlighted on preimage lines". My reading of the
above is "Not just without highlight,
All correct, but misses one point in Frank's original report, which
observed
-something
+something_new^M
with ^M highlighted for whitespace error. The highlighting is
correct. But notice lack of caret-em on the preimage line?
It turns out that we show something like thi
in both the old and the new, use
--ws-error-highlight or set diff.wsErrorHighlight.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
er highlighted in removed lines, why
should CR be an exception?
1) If CR+LF line termination is used in a file, changing the content of
a line (but not its termination) currently produces a diff like
-something
+something_new^M
which causes the user to think he has changed the line ending
LF line termination is used in a file, changing the content of
a line (but not its termination) currently produces a diff like
-something
+something_new^M
which causes the user to think he has changed the line ending (added a
CR) although he didn't.
2) If someone/something unintentionally changes
Am 24.11.18 um 15:51 schrieb Frank Schäfer:
Am 23.11.18 um 22:47 schrieb Johannes Sixt:
Am 23.11.18 um 19:19 schrieb Frank Schäfer:
The CR marker ^M doesn't show up in '-' lines of diffs when the ending
of the removed line is CR+LF.
It shows up as expected in '-' lin
On Sat, Nov 24, 2018 at 03:51:26PM +0100, Frank Schäfer wrote:
[]
>
> Hmm... is CR-only line termination supported at all ?
> E.g. 'eol' can be set to 'lf' or 'crlf' but not 'cr'...
>
No, CR-only is not supported, because:
Nobody was implementing it, and that is probably because
the only questio
Am 23.11.18 um 22:47 schrieb Johannes Sixt:
> Am 23.11.18 um 19:19 schrieb Frank Schäfer:
>> The CR marker ^M doesn't show up in '-' lines of diffs when the ending
>> of the removed line is CR+LF.
>> It shows up as expected in '-' lines when the ending
Am 23.11.18 um 19:19 schrieb Frank Schäfer:
The CR marker ^M doesn't show up in '-' lines of diffs when the ending
of the removed line is CR+LF.
It shows up as expected in '-' lines when the ending of the removed line
is CR only.
It also always shows up as expecte
The CR marker ^M doesn't show up in '-' lines of diffs when the ending
of the removed line is CR+LF.
It shows up as expected in '-' lines when the ending of the removed line
is CR only.
It also always shows up as expected in '+' lines.
These are the diffs of
--
Dear Partner.
Please forgive me if my proposal come to you as an embarrassment as I
had no previous correspondence with you before now, I got your email
contact from Asian Business Directory.
I am Akemi BAKER; I was born in 1987, from Fukushima, Japan.
Unfortunately my parent died in m
brian m. carlson wrote:
> On Mon, Sep 24, 2018 at 10:39:02AM -0700, Jonathan Nieder wrote:
>> brian m. carlson wrote:
>>> I think this commit message makes sense.
[...]
>> What would it take to make the patch make
>> sense, too? ;-)
On Mon, Sep 24, 2018 at 10:39:02AM -0700, Jonathan Nieder wrote:
> Hi,
>
> brian m. carlson wrote:
>
> > I think this commit message makes sense. I apparently still fail to
> > understand how the .mailmap format works, so I can't tell you if the
> > patch is
v2.18.0-rc0~70^2 (mailmap: update brian m. carlson's email address,
2018-05-08) changed the mailmap to map
sand...@crustytoothpaste.ath.cx
-> brian m. carlson
instead of
sand...@crustytoothpaste.net
-> brian m. carlson
That means the mapping
Brian M. Carlson
On Mon, Sep 17, 2018 at 11:18:00AM -0700, Jonathan Nieder wrote:
> v2.18.0-rc0~70^2 (mailmap: update brian m. carlson's email address,
> 2018-05-08) changed the mailmap to map
>
> sand...@crustytoothpaste.ath.cx
>-> brian m. carlson
>
> instead of
>
v2.18.0-rc0~70^2 (mailmap: update brian m. carlson's email address,
2018-05-08) changed the mailmap to map
sand...@crustytoothpaste.ath.cx
-> brian m. carlson
instead of
sand...@crustytoothpaste.net
-> brian m. carlson
That means the mapping
Brian M. Carlson
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commi
Sergey Organov writes:
> When cherry-picking multiple commits, it's impossible to have both
> merge- and non-merge commits on the same command-line. Not specifying
> '-m 1' results in cherry-pick refusing to handle merge commits, while
> specifying '-m 1'
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch al
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch al
On Tue, May 22, 2018 at 03:08:26PM -0700, Jonathan Nieder wrote:
> These commits use author Brian M. Carlson .
> Previously they matched
>
> brian m. carlson
>
>
> but now they don't match any line in the .mailmap file.
>
> Should we add a line
>
Hi,
brian m. carlson wrote:
> An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to
> individual persons", 2013-08-12), noted that there were two name
> spellings and two email addresses and mapped the crustytoothpaste.net
> address to the crustytoothpast
On 15.05.18 20:04, Frank Schäfer wrote:
> Am 14.05.2018 um 20:13 schrieb Torsten Bögershausen:
>> ^M is the representation of a "Carriage Return" or CR.
>> Under Linux/Unix/Mac OS X a line is terminated with a single
>> "line feed", LF.
>>
>&g
Am 14.05.2018 um 20:13 schrieb Torsten Bögershausen:
> ^M is the representation of a "Carriage Return" or CR.
> Under Linux/Unix/Mac OS X a line is terminated with a single
> "line feed", LF.
>
> Windows typically uses CRLF at the end of the line.
> "git
On 14.05.18 18:08, Frank Schäfer wrote:
> What does ^M at the end of lines in the output of 'git diff' mean ?
>
> Thanks,
> Frank
>
^M is the representation of a "Carriage Return" or CR.
Under Linux/Unix/Mac OS X a line is terminated with a single
"line
What does ^M at the end of lines in the output of 'git diff' mean ?
Thanks,
Frank
On Wed, May 09, 2018 at 12:33:59PM +0530, Kaartic Sivaraam wrote:
> On Wednesday 09 May 2018 05:49 AM, brian m. carlson wrote:
> > Correct, it doesn't. In my case, I was using --pretty='%aN <%aE>',
> > which is how I noticed it in the first place.
>
> So
On Wednesday 09 May 2018 05:49 AM, brian m. carlson wrote:
> Correct, it doesn't. In my case, I was using --pretty='%aN <%aE>',
> which is how I noticed it in the first place.
So, how about updating the commit message to avoid confusions to the
incidental future reade
`git log` output doesn't consider
> the mailmap file by default.
Correct, it doesn't. In my case, I was using --pretty='%aN <%aE>',
which is how I noticed it in the first place.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
On Tuesday 08 May 2018 07:28 AM, brian m. carlson wrote:
> An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to
> individual persons", 2013-08-12), noted that there were two name
> spellings and two email addresses and mapped the crustytoothpaste.n
"brian m. carlson" writes:
> An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to
> individual persons", 2013-08-12), noted that there were two name
> spellings and two email addresses and mapped the crustytoothpaste.net
> address to the crust
te address, while the former is current, so switch the order of
the addresses so that git log displays the correct address.
Signed-off-by: brian m. carlson
---
I intentionally avoided the use of the first person here, because I
wasn't sure what the preference of the list was on that. Hop
ing the output of git log, realized that it
was the wrong way around.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
ening here is
> that cdb6b5ac (".mailmap: Combine more (name, email) to individual
> persons", 2013-08-12) removed
>
> -Brian M. Carlson
>
> and then added these two lines
>
> +brian m. carlson Brian M. Carlson
>
> +brian m. carlson
>
>
> where *
On Sun, May 6, 2018 at 8:37 PM, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
>> The order of addresses in the mailmap file was reversed, leading to git
>> preferring the crustytoothpaste.ath.cx address, which is obsolete, over
>> the crustytoothp
"brian m. carlson" writes:
> The order of addresses in the mailmap file was reversed, leading to git
> preferring the crustytoothpaste.ath.cx address, which is obsolete, over
> the crustytoothpaste.net address, which is current. Switch the order of
> the addresses so tha
m. carlson
---
.mailmap | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.mailmap b/.mailmap
index 7c71e88ea5..df7cf6313c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -25,8 +25,8 @@ Ben Walton
Benoit Sigoure
Bernt Hansen
Brandon Casey
-brian m. carlson Brian M
Hi Larry,
On Tue, 6 Mar 2018, Larry Hunter wrote:
> The same ^M is shown in the output of tutorial
>
>
> https://www.geekality.net/2017/08/23/setting-up-gpg-signing-for-gitgithub-on-windows/
>
> at item "4. Verify commit was signed"
Please understand tha
The same ^M is shown in the output of tutorial
https://www.geekality.net/2017/08/23/setting-up-gpg-signing-for-gitgithub-on-windows/
at item "4. Verify commit was signed"
I confirm the output is right (no ^M characters) with commands
git verify-commit HEAD
git -p ver
PEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
Therefore, the GNU Privacy Guard version you use is not the one shipped
and supported by the Git for Windows project.
> that prints (with colors) an extra ^M (carriage return?) at the end of
> the gp
There is bug using "git log --show-signature" in my installation
git 2.16.2.windows.1
gpg (GnuPG) 2.2.4
libgcrypt 1.8.2
that prints (with colors) an extra ^M (carriage return?) at the end of
the gpg lines. As an example, the output of "git log --show-signature
H
"G. Sylvie Davies" writes:
> On Mon, Feb 5, 2018 at 3:46 AM, Sergey Organov wrote:
>> Hello,
>>
>> $ git help cherry-pick
>>
>> -m parent-number, --mainline parent-number
>>Usually you cannot cherry-pick a merge because you do not
>
On Mon, Feb 5, 2018 at 3:46 AM, Sergey Organov wrote:
> Hello,
>
> $ git help cherry-pick
>
> -m parent-number, --mainline parent-number
>Usually you cannot cherry-pick a merge because you do not
>know which side of the merge should be considered the
1 - 100 of 430 matches
Mail list logo
