Fix difftool problem with intent-to-add files
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v5 Latest2 patches 0 repliesNew
- v42 patches 10 repliesSuperseded
- v33 patches 0 repliesSuperseded
Earlier versions · 2
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v2 | 3 patches | 9 replies | Superseded | |
| v1 | 3 patches | 0 replies | Superseded |
Changes in v5 from the cover letter
* Improved both commit messages after feedback from Junio.
Patches in v5 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | diff-files --raw: show correct post-image of intent-to-add filesdiff-lib.c t/ | +3 | 0 replies | |
| 2/2 | difftool -d: ensure that intent-to-add files are handled correctlyt/ | +8 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v5 yet.
Cover letter [PATCH v5 0/2] Fix difftool problem with intent-to-add files
This problem was reported in
https://github.com/git-for-windows/git/issues/2677, but the problem actually lies with git diff --raw, and it seems that the bug has been with us ever since --intent-to-add was introduced.
Changes since v4:
* Improved both commit messages after feedback from Junio.
Changes since v3:
* Instead of showing the same OID in git diff-files --raw as in git diff-files -p for intent-to-add files, we now imitate the logic for modified (non-intent-to-add) files: we show the "null" OID (i.e. all-zero).
* As a consequence, we no longer just undo the inadvertent change where intent-to-add files were reported with the empty tree instead of the empty blob, but we fix the bug that has been with us since run_diff_files() was taught about intent-to-add files, i.e. we fix the original bug of 425a28e0a4e (diff-lib: allow ita entries treated as "not yet exist in index", 2016-10-24), at long last.
Changes since v2:
* Now we also drop the no-longer-used definition of hash_t in t2203.
Changes since v1:
* Rebased onto sk/diff-files-show-i-t-a-as-new.
* Verified that sk/diff-files-show-i-t-a-as-new does not completely resolve the issue (the --raw output still claims the empty blob as the post-image, although the difftool symptom "went away").
* Amended the central patch of this PR to include a fix for the regression test that was introduced in sk/diff-files-show-i-t-a-as-new: it expected the raw diff to contain the hash of the empty tree object (which is incorrect no matter how you turn it: any hash in any raw diff should refer to blob objects).
* Reordered the patches so that the central patch comes first (otherwise, the "empty tree" fix would cause a test failure in t2203).
Johannes Schindelin (2):
diff-files --raw: show correct post-image of intent-to-add files difftool -d: ensure that intent-to-add files are handled correctly
diff-lib.c | 3 +-- t/t2203-add-intent.sh | 5 ++--- t/t7800-difftool.sh | 8 ++++++++ 3 files changed, 11 insertions(+), 5 deletions(-)
base-commit: feea6946a5b746ff4ebf8ccdf959e303203a6011
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-654%2Fdscho%2Fdifftool-ita-v5
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-654/dscho/difftool-ita-v5
Pull-Request: https://github.com/gitgitgadget/git/pull/654
Range-diff vs v4:
1: 69256ab910 ! 1: 4392ae4be6 diff-files --raw: show correct post-image of intent-to-add files
@@ Commit message
[...] 0{40} if creation, unmerged or "look at work tree".
- This happens for example when showing modified, unstaged files.
+ on the right hand (i.e. postimage) side. This happens for files that
+ have unstaged modifications, and for files that are unmodified but
+ stat-dirty.
For intent-to-add files, we used to show the empty blob's hash instead. In c26022ea8f5 (diff: convert diff_addremove to struct object_id, 2017-05-30), we made that worse by inadvertently changing that to the hash of the empty tree.
- Let's make the behavior consistent with modified files by showing
+ Let's make the behavior consistent with files that have unstaged
+ modifications (which applies to intent-to-add files, too) by showing
all-zero values also for intent-to-add files.
Accordingly, this patch adjusts the expectations set by the regression
2: 9bb8d84ea9 ! 2: 5f933e852a difftool -d: ensure that intent-to-add files are handled correctly
@@ Commit message
In https://github.com/git-for-windows/git/issues/2677, a git difftool -d problem was reported. The underlying cause was a bug in `git
- diff-files --raw` that we just fixed.
+ diff-files --raw` that we just fixed: it reported intent-to-add files
+ with the empty _tree_ as the post-image OID, when we need to show
+ an all-zero (or, "null") OID instead, to indicate to the caller that
+ they have to look at the worktree file.
+
+ The symptom of that problem shown by git difftool was this:
+
+ error: unable to read sha1 file of <path> (<empty-tree-OID>)
+ error: could not write '<filename>'
Make sure that the reported difftool problem stays fixed.
Signature · 1 line
gitgitgadget