Hi Denton, On Mon, 11 Mar 2019, Denton Liu wrote: > I was in the process of deprecating `git diff <commit>..<commit>` as > discussed here[1]. 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 && > test_tick && > 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" > EOF > test_tick && > 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 beg to differ. `git diff <commit>^!` does exactly what I want: it shows the diff between the commit's first parent and the commit. And I would not necessarily call this a "range". It is a short-hand. Can't you allow short-hands in `git diff`, and disallow only ranges that have an explicit `..` in them? You might need to record that somewhere, but I think that should be easy enough. Ciao, Johannes > > 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? > > Thanks, > > Denton > > [1]: https://public-inbox.org/git/xmqqmumy6mxe.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/ >
