I've made a single simple change to a large number of files that are version controlled in git and I'd like to be able to check that no other changes are slipping into this large commit.
The changes are all of the form
- "main()", + OOMPH_CURRENT_FUNCTION,
where "main()" could be the name of any function. I want to generate a diff of all changes that are not of this form.
The -G and -S options to git diff are tantalisingly close--they find changes that DO match a string or regexp.
Is there a good way to do this?
Another question describes how regexs can be negated, using this approach I think the command should be
git diff -G '^((?!OOMPH_CURRENT_FUNCTION).)*$'
but this just returns the error message
fatal: invalid log-grep regex: Invalid preceding regular expression
so I guess git doesn't support this regex feature.
I also noticed that the standard unix diff has the -I option to "ignore changes whose lines all match RE". But I can't find the correct way to replace git's own diff with the unix diff tool.
Try the following:
$ git diff > full_diff.txt $ git diff -G "your pattern" > matching_diff.txt
You can then compare the two like so:
$ diff matching_diff.txt full_diff.txt
If all changes match the pattern, full_diff.txt
and matching_diff.txt
will be identical, and the last diff
command will not return anything.
If there are changes that do not match the pattern, the last diff
will highlight those.
You can combine all of the above steps and avoid having to create two extra files like so:
diff <(git diff -G "your pattern") <(git diff) # works with other diff tools too
No more grep needed!
With Git 2.30 (Q1 2021), "git diff
"(man) family of commands learned the "-I<regex>
" option to ignore hunks whose changed lines all match the given pattern.
See commit 296d4a9, commit ec7967c (20 Oct 2020) by Michał Kępień (kempniu
).
(Merged by Junio C Hamano -- gitster
-- in commit 1ae0949, 02 Nov 2020)
diff
: add-I<regex>
that ignores matching changesSigned-off-by: Michał Kępień
Add a new diff option that enables ignoring changes whose all lines (changed, removed, and added) match a given regular expression.
This is similar to the-I
/--ignore-matching-lines
option in standalonediff
utilities and can be used e.g. to ignore changes which only affect code comments or to look for unrelated changes in commits containing a large number of automatically applied modifications (e.g. a tree-wide string replacement).The difference between
-G
/-S
and the new-I
option is that the latter filters output on a per-change basis.Use the 'ignore' field of
xdchange_t
for marking a change as ignored or not.
Since the same field is used by--ignore-blank-lines
, identical hunk emitting rules apply for--ignore-blank-lines
and-I
.
These two options can also be used together in the samegit
invocation (they are complementary to each other).Rename
xdl_mark_ignorable()
toxdl_mark_ignorable_lines()
, to indicate that it is logically a "sibling" ofxdl_mark_ignorable_regex()
rather than its "parent".
diff-options
now includes in its man page:
-I<regex>
--ignore-matching-lines=<regex>
Ignore changes whose all lines match
<regex>
.
This option may be specified more than once.
Examples:
git diff --ignore-blank-lines -I"ten.*e" -I"^[124-9]"
A small memleak in "diff -I<regexp>
" has been corrected with Git 2.31 (Q1 2021).
See commit c45dc9c, commit e900d49 (11 Feb 2021) by Ævar Arnfjörð Bjarmason (avar
).
(Merged by Junio C Hamano -- gitster
-- in commit 45df6c4, 22 Feb 2021)
diff
: plug memory leak from regcomp() on{log,diff} -I
Signed-off-by: Ævar Arnfjörð Bjarmason
Fix a memory leak in 296d4a9 ("
diff
: add -I that ignores matching changes", 2020-10-20, Git v2.30.0-rc0 -- merge listed in batch #3) by freeing the memory it allocates in the newly introduceddiff_free()
.This memory leak was intentionally introduced in 296d4a9, see the discussion on a previous iteration of it.
At that time freeing the memory was somewhat tedious, but since it isn't anymore with the newly introduced
diff_free()
let's use it.Let's retain the pattern for
diff_free_file()
and add adiff_free_ignore_regex()
, even though (unlike"diff_free_file")
we don't need to call it elsewhere.
I think this will make for more readable code than gradually accumulating a giantdiff_free()
function, sharing "int i
" across unrelated code etc.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With