Johannes Sixt [off-list ref] writes:
Since 19b2517f95a0 (diff-merges: move specific diff-index "-m" handling
to diff-index, 2021-05-21) git diff-index no longer accepts --cc.
Yep, this is expected, and I even put corresponding comment in the
source:
/*
* We need no diff for merges options, and we need to avoid conflict
* with our own meaning of "-m".
*/
This breaks gitk: it invokes
git diff-index --cached -p -C --cc --no-commit-id -U3 HEAD
to show the staged changes (when the line "Local changes checked in to
index but not committed" is selected).
The man page of git diff-index does not mention --cc as an option. I
haven't fully grokked the meaning of --cc, so I cannot tell whether this
absence has any significance (is deliberate or an omission).
Is gitk wrong to add --cc unconditionally? Should it do so only when
there are conflicts? Or not at all?
As far as I can tell, --cc had no effect on diff-index, it was just
silently consumed. If I'm right, this line in gitk never needed --cc.
Then either gitk is to be fixed, or we can "fix" diff-index to silently
consume --cc/-c again, for backward compatibility.
If --cc did affect diff-index, then my commit in question is wrong and
should be fixed.
Thanks,
-- Sergey Organov
On Mon, Aug 30, 2021 at 04:05:50PM +0300, Sergey Organov wrote:
quoted
Is gitk wrong to add --cc unconditionally? Should it do so only when
there are conflicts? Or not at all?
As far as I can tell, --cc had no effect on diff-index, it was just
silently consumed. If I'm right, this line in gitk never needed --cc.
Then either gitk is to be fixed, or we can "fix" diff-index to silently
consume --cc/-c again, for backward compatibility.
I think it does have an effect. Try this to generate a simple merge
conflict:
git init repo
cd repo
echo base >file
git add file
git commit -m base
echo main >file
git commit -am main
git checkout -b side HEAD^
echo side >file
git commit -am side
git merge main ;# maybe master here depending on your config
And then with pre-v2.33 Git, --cc does a combined diff:
$ git.v2.32.0 diff-index -p HEAD
diff --git a/file b/file
index 2299c37..81768df 100644
--- a/file
+++ b/file
@@ -1 +1,5 @@
+<<<<<<< HEAD
side
+=======
+main
+>>>>>>> main
$ git.v2.32.0 diff-index --cc HEAD
diff --cc file
index df967b9,2299c37..0000000
--- a/file
+++ b/file
@@@ -1,1 -1,1 +1,5 @@@
- base
++<<<<<<< HEAD
+ side
++=======
++main
++>>>>>>> main
Likewise, --raw will show a combined diff, though it's a bit less useful
because the unmerged entry has a null sha1:
$ git.v2.32.0 diff-index HEAD
:100644 100644 2299c37978265a95cbe835a4b0f0bbf15aad5549 0000000000000000000000000000000000000000 M file
$ git.v2.32.0 diff-index --cc --raw HEAD
::100644 100644 100644 df967b96a579e45a18b8251732d16804b2e56a55 2299c37978265a95cbe835a4b0f0bbf15aad5549 0000000000000000000000000000000000000000 MM file
-Peff
Am 30.08.21 um 15:05 schrieb Sergey Organov:
As far as I can tell, --cc had no effect on diff-index, it was just
silently consumed. If I'm right, this line in gitk never needed --cc.
Then either gitk is to be fixed, or we can "fix" diff-index to silently
consume --cc/-c again, for backward compatibility.
That latter would be much preferable. Gitk uses the combination -p --cc
for *all* diff commands when it requests patch output regardless of the
number of parents. It would be tedious to special-case diff-index to not
pass --cc.
-- Hannes