git difftool: cannot create directory at '' #1124
Assignees
Milestone
Comments
|
Depends on the current commit (HEAD): |
|
Since '^' is a Windows path escape character, can you try '~' for the same effect? Does that work around the issue? |
|
No. |
|
It's more about commits than refspecs: And it depends on the HEAD ref: Same with the branch: |
|
@Radrik5 since this is a private repository, can you try to anonymize it? Effectively, what you would do is to call Of course, you could also spend some time to try to wiggle down the test case you have:
In essence, reduce the problem to a manageable size. Ideally we will end up with a new test case in |
|
Anonymized repo didn't have the exact same problem but I've found several buggy commits in the Top 24 commits: You can use any of them for testing. The interesting thing here is that difftool fails to create folders for commit changes (from parent to commit) but it can successfully create folders for reverted changes (from commit to parent). The error messages are different but probably the root cause is the same. MCVE: |
If you're willing to debug this then you can give Compiling Git with Visual Studio a try. You only need Visual Studio and Git for Windows, and you will be able to build and debug git. I would recommend VS2015, because the projects are generated for that version. Note that I could not reproduce with the given MCVE. |
|
@kgybels could you run the script? Does it find anything in your repo? |
|
@Radrik5 I can reproduce the issue, excellent, thanks! |
dscho
added a commit
to git-for-windows/build-extra
that referenced
this issue
Apr 5, 2017
`git difftool -d` [no longer crashes randomly](git-for-windows/git#1124). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
I confirm that the issue is fixed in 2.12.2(2). |
|
@Radrik5 thank you for testing! |
git-for-windows-ci
pushed a commit
that referenced
this issue
Apr 12, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. Let's just copy the strings and be done with it. This fixes #1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
that referenced
this issue
Apr 12, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. Let's just copy the strings and be done with it. This fixes #1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Apr 13, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. Let's just copy the strings and be done with it. This fixes #1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Apr 13, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. Let's just copy the strings and be done with it. This fixes #1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/git
that referenced
this issue
Apr 13, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. A contrived test case shows the problem where a file with a long enough name to force the strbuf to grow is up-to-date (hence the code path is used where the work tree's version of the file is reused), and then a file that is not up-to-date needs to be written (hence the code path is used where checkout_entry() uses the previously recorded base_dir that is invalid by now). Let's just copy the base_dir strings for use with checkout_entry(), never touch them until the end, and release them then. This is an easily verifiable fix (as opposed to the next-obvious alternative: to re-set base_dir after every loop iteration). This fixes git-for-windows#1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fengguang
pushed a commit
to 0day-ci/git
that referenced
this issue
Apr 14, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. A contrived test case shows the problem where a file with a long enough name to force the strbuf to grow is up-to-date (hence the code path is used where the work tree's version of the file is reused), and then a file that is not up-to-date needs to be written (hence the code path is used where checkout_entry() uses the previously recorded base_dir that is invalid by now). Let's just copy the base_dir strings for use with checkout_entry(), never touch them until the end, and release them then. This is an easily verifiable fix (as opposed to the next-obvious alternative: to re-set base_dir after every loop iteration). This fixes git-for-windows#1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitster
pushed a commit
to git/git
that referenced
this issue
Apr 15, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. A contrived test case shows the problem where a file with a long enough name to force the strbuf to grow is up-to-date (hence the code path is used where the work tree's version of the file is reused), and then a file that is not up-to-date needs to be written (hence the code path is used where checkout_entry() uses the previously recorded base_dir that is invalid by now). Let's just copy the base_dir strings for use with checkout_entry(), never touch them until the end, and release them then. This is an easily verifiable fix (as opposed to the next-obvious alternative: to re-set base_dir after every loop iteration). This fixes git-for-windows#1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
dscho
added a commit
that referenced
this issue
Apr 26, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. A contrived test case shows the problem where a file with a long enough name to force the strbuf to grow is up-to-date (hence the code path is used where the work tree's version of the file is reused), and then a file that is not up-to-date needs to be written (hence the code path is used where checkout_entry() uses the previously recorded base_dir that is invalid by now). Let's just copy the base_dir strings for use with checkout_entry(), never touch them until the end, and release them then. This is an easily verifiable fix (as opposed to the next-obvious alternative: to re-set base_dir after every loop iteration). This fixes #1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-for-windows-ci
pushed a commit
that referenced
this issue
Apr 26, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. A contrived test case shows the problem where a file with a long enough name to force the strbuf to grow is up-to-date (hence the code path is used where the work tree's version of the file is reused), and then a file that is not up-to-date needs to be written (hence the code path is used where checkout_entry() uses the previously recorded base_dir that is invalid by now). Let's just copy the base_dir strings for use with checkout_entry(), never touch them until the end, and release them then. This is an easily verifiable fix (as opposed to the next-obvious alternative: to re-set base_dir after every loop iteration). This fixes #1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-for-windows-ci
pushed a commit
that referenced
this issue
May 10, 2017
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. A contrived test case shows the problem where a file with a long enough name to force the strbuf to grow is up-to-date (hence the code path is used where the work tree's version of the file is reused), and then a file that is not up-to-date needs to be written (hence the code path is used where checkout_entry() uses the previously recorded base_dir that is invalid by now). Let's just copy the base_dir strings for use with checkout_entry(), never touch them until the end, and release them then. This is an easily verifiable fix (as opposed to the next-obvious alternative: to re-set base_dir after every loop iteration). This fixes #1124 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
benpeart
pushed a commit
that referenced
this issue
Jan 18, 2018
The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. Let's just copy the strings and be done with it. This was reported at http://stackoverflow.microsoft.com/q/40758/23695 and at #1124
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Setup
Windows 7 64 bit
defaults?
to the issue you're seeing?
It doesn't depend on environment (see below).
Details
Git Bash
Minimal, Complete, and Verifiable example
this will help us understand the issue.
The problem is reproduced on this particular repo with this particular commits. Running the commands on another repo correctly opens Beyond Compare. Using commit hashes instead of HEAD in this repo gives the same error. Running the command with other commits works fine. Unfortunately, the repo is private, so I cannot provide MCVE.
URL to that repository to help us with testing?
The problem occurs with a specific repository but I cannot share it.
Is there something like GIT_TRACE=1 that can help to understand what causes the error?
The text was updated successfully, but these errors were encountered: