Deprecating git diff ..; dealing with other ranges
- Date: Mon, 11 Mar 2019 02:37:51 -0700
- From: Denton Liu <liu.denton@xxxxxxxxx>
- Subject: Deprecating git diff ..; dealing with other ranges
I was in the process of deprecating `git diff <commit>..<commit>` as
discussed here. However, I ran into a weird case that I'm not sure
how to deal with.
In t3430-rebase-merges.sh:382, we have the following test case which
invokes git diff:
test_expect_success 'with --autosquash and --exec' '
git checkout -b with-exec H &&
echo Booh >B.t &&
git commit --fixup B B.t &&
write_script show.sh <<-\EOF &&
subject="$(git show -s --format=%s HEAD)"
=> content="$(git diff HEAD^! | tail -n 1)"
echo "$subject: $content"
git rebase -ir --autosquash --exec ./show.sh A >actual &&
grep "B: +Booh" actual &&
grep "E: +Booh" actual &&
grep "G: +G" actual
It gets caught in my attempt to only deprecate ..'s. Technically, it's
undocumented behaviour and it only happens to work because git-diff
accept ranges but it doesn't operate in an intuitive way.
I was just wondering what we should do about this case? Should we
deprecate all invocations of `git diff <range>` except for the special
case of `git diff <commit>...<commit>`, or should we _only_ deprecate
`git diff <commit>..<commit>` and allow all other forms of ranges, even
though it was undocumented behaviour?