Re: unexpected "unresolved merge conflict" for a new file
On Thu 24-05-18 13:11:20, Jeff King wrote:
> On Thu, May 24, 2018 at 01:36:57PM +0200, Michal Hocko wrote:
>
> > `git commit' fails on a newly added file with the following
> > *
> > * You have some suspicious patch lines:
> > *
> > * In Documentation/core-api/gfp_mask-from-fs-io.rst
> > * unresolved merge conflict (line 27)
> > Documentation/core-api/gfp_mask-from-fs-io.rst:27:===
>
> This message isn't generated by git itself, but rather by a pre-commit
> hook. You can skip the hook by running "git commit --no-verify".
>
> As for the false positive in the hook logic, I can't say more without
> having seen the hook source. :) Do you know where you got it from?
>
> (Googling for "suspicious patch lines" turns up some hits, but with
> varying provenance).
Ohh, I see. I must have installed this one loooong time ago. Attached
for reference. I will just drop it. Sorry about tht noise.
--
Michal Hocko
SUSE Labs
#!/bin/sh
#
# An example hook script to verify what is about to be committed.
# Called by git-commit with no arguments. The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.
#
# To enable this hook, make this file executable.
# This is slightly modified from Andrew Morton's Perfect Patch.
# Lines you introduce should not have trailing whitespace.
# Also check for an indentation that has SP before a TAB.
if git-rev-parse --verify HEAD 2>/dev/null
then
git-diff-index -p -M --cached HEAD --
else
# NEEDSWORK: we should produce a diff with an empty tree here
# if we want to do the same verification for the initial import.
:
fi |
perl -e '
my $found_bad = 0;
my $filename;
my $reported_filename = "";
my $lineno;
sub bad_line {
my ($why, $line) = @_;
if (!$found_bad) {
print STDERR "*\n";
print STDERR "* You have some suspicious patch lines:\n";
print STDERR "*\n";
$found_bad = 1;
}
if ($reported_filename ne $filename) {
print STDERR "* In $filename\n";
$reported_filename = $filename;
}
print STDERR "* $why (line $lineno)\n";
print STDERR "$filename:$lineno:$line\n";
}
while (<>) {
if (m|^diff --git a/(.*) b/\1$|) {
$filename = $1;
next;
}
if (/^@@ -\S+ \+(\d+)/) {
$lineno = $1 - 1;
next;
}
if (/^ /) {
$lineno++;
next;
}
if (s/^\+//) {
$lineno++;
chomp;
if (/\s$/) {
bad_line("trailing whitespace", $_);
}
if (/^\s* \t/) {
bad_line("indent SP followed by a TAB", $_);
}
if (/^([<>])\1{6} |^={7}$/) {
bad_line("unresolved merge conflict", $_);
}
}
}
exit($found_bad);
'
unexpected "unresolved merge conflict" for a new file
Hi, `git commit' fails on a newly added file with the following * * You have some suspicious patch lines: * * In Documentation/core-api/gfp_mask-from-fs-io.rst * unresolved merge conflict (line 27) Documentation/core-api/gfp_mask-from-fs-io.rst:27:=== $ git status --porcelain A Documentation/core-api/gfp_mask-from-fs-io.rst $ git --version git version 2.17.0 from debian. Btw. the suspicious line is $ sed -n '27p' Documentation/core-api/gfp_mask-from-fs-io.rst === I believe this is a bug because a new file cannot have a conflict by definition and also there are no <<<<< in the file so there is no unresolved conflict there. So I guess the heuristic should be more clever. Thanks! -- Michal Hocko SUSE Labs
feature request for cc-cmd
Hi,
currently I am using --cc-cmd for larger patch series which are of
interest of different parties (e.g. kernel tree wide stuff) and I do not
want to spam all of them by patches which are not of their interest but
I still want them to receive the cover letter because that is useful to
get a context of a change. In order to do that each particular commit
has
Cc: email
{Acked,Reported,Reviewed,...}-by: email
in the patch header and I use the following
$ cat cc-cmd.sh
!/bin/bash
if [[ $1 == *gitsendemail.msg* || $1 == *cover-letter* ]]; then
grep '<.*@.*>' -h *.patch | sed 's/^.*: //' | sort | uniq
else
grep '<.*@.*>' -h $1 | sed 's/^.*: //' | sort | uniq
fi
git send-email --cc-cmd ./cc-cmd.sh --to lkml patches...
which works reasonably well except I have to git format-patch the whole
series before posting. Quite often I do git send-email commit-range
though. This way is also little bit error prone because I have to make
sure no unrelated patch files are in the same directory. Would it be
possible that the cc script would get a list of all patch files for the
cover email? I have noticed that git send-email from the sha range will
use /tmp/$rand_dir/*.patch so this should be possible I guess. I would
update my script to
!/bin/bash
grep '<.*@.*>' -h $1 | sed 's/^.*: //' | sort | uniq
if [[ $1 == *gitsendemail.msg* || $1 == *cover-letter* ]]; then
shift
grep '<.*@.*>' -h $* | sed 's/^.*: //' | sort | uniq
fi
Would something like that make sense or there is an easier way
which I am just not aware of?
Thanks a lot!
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CC in git cover letter vs patches (was Re: [PATCH 0/19] get rid of superfluous __GFP_REPORT)
On Wed 13-04-16 16:51:37, Vineet Gupta wrote: > Trimming CC list + CC git folks > > Hi Michal, > > On Monday 11 April 2016 04:37 PM, Michal Hocko wrote: > > Hi, > > this is the second version of the patchset previously sent [1] > > I have a git question if you didn't mind w.r.t. this series. Maybe there's an > obvious answer... I'm using git 2.5.0 > > I was wondering how you manage to union the individual patch CC in just the > cover > letter w/o bombarding everyone with everything. I am using the following flow: $ rm *.patch $ for format-patch range $ git send-email [--to resp. --cc for all patches] --cc-cmd ./cc-cmd-only-cover.sh --compose *.patch $ cat ./cc-cmd-only-cover.sh #!/bin/bash # --compose with generate *gitsendemail.msg file # --cover-letter expects *cover-letter* file if [[ $1 == *gitsendemail.msg* || $1 == *cover-letter* ]]; then grep '<.*@.*>' -h *.patch | sed 's/^.*: //' | sort | uniq fi it is a little bit coarse and it would be great if git had a default option for that but this seems to be working just fine for patch-bombs where the recipients only have to care about their parts and the cover for the overal idea of the change. HTH -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git describe --contains doesn't work properly for a commit
Hi, I have just encountered an old kernel git commit: commit c854363e80b49dd04a4de18ebc379eb8c8806674 Author: Dave Chinner da...@fromorbit.com Date: Sat Feb 6 12:39:36 2010 +1100 xfs: Use delayed write for inodes rather than async V2 [...] which cannot be described properly: $ git describe --contains c854363e80b49dd04a4de18ebc379eb8c8806674 fatal: cannot describe 'c854363e80b49dd04a4de18ebc379eb8c8806674' but it seems to find a tag on which the commit is based: $ git describe c854363e80b49dd04a4de18ebc379eb8c8806674 v2.6.33-rc4-49-gc854363e80b4 if I follow parents sha=c854363e80b49dd04a4de18ebc379eb8c8806674; while true do parent=$(git show --format=%P $sha | head -1) echo $sha $parent git describe --contains $parent break sha=$parent done c854363e80b49dd04a4de18ebc379eb8c8806674 777df5afdb26c71634edd60582be620ff94e87a0 fatal: cannot describe '777df5afdb26c71634edd60582be620ff94e87a0' 777df5afdb26c71634edd60582be620ff94e87a0 d5db0f97fbbeff11c88dec1aaf1536a975afbaeb fatal: cannot describe 'd5db0f97fbbeff11c88dec1aaf1536a975afbaeb' d5db0f97fbbeff11c88dec1aaf1536a975afbaeb 388f1f0c346b533b06d8bc792f7204ebc3e4b7da v2.6.34-rc1~278^2~14 I am using: $ git --version git version 2.1.4 but the same seems to be the case with older git version (1.8.5.6). $ git rev-list c854363e80b49dd04a4de18ebc379eb8c8806674..v2.6.34 | wc -l 11648 So there seems to be a line between the two commits AFAIU. Is the history somehow broken or is it a bug in git? -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git describe --contains doesn't work properly for a commit
On Thu 26-02-15 14:35:34, Michal Hocko wrote: Hi, I have just encountered an old kernel git commit: commit c854363e80b49dd04a4de18ebc379eb8c8806674 Author: Dave Chinner da...@fromorbit.com Date: Sat Feb 6 12:39:36 2010 +1100 xfs: Use delayed write for inodes rather than async V2 [...] OK, I've managed to recreate this in a simple repo with 3 commits: $ git log --format=%H %cd ab0efec2b697f2f9f864bb0e2cd77308d1f04561 Thu Feb 26 15:18:36 2015 +0100 d63972e4e4e7eda0444e56739ad09bfbc476b9bd Wed Feb 26 15:18:30 2014 +0100 108a0d5972fd2e5f25b2f38cfd2fee73031ff9d3 Thu Feb 26 14:57:29 2015 +0100 The commit in the middle was ammended to have committer date in the past. $ git describe --contains d63972e4e4e7eda0444e56739ad09bfbc476b9bd tag~1 but $ git describe --contains 108a0d5972fd2e5f25b2f38cfd2fee73031ff9d3 fatal: cannot describe '108a0d5972fd2e5f25b2f38cfd2fee73031ff9d3' I guess this is the same issue reported previously here: http://git.661346.n2.nabble.com/git-describe-contains-fails-on-given-tree-td5448286.html Can this be fixed somehow or it would lead to other kind of issues? -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
