-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'git clean -fdx' returns errorlevel 1 #521
Comments
Before anyone asks, this does not happen with the linux Git cli |
@talcloudshare that is not at all the first question I have... my first question is: are you absolutely sure you do not want to describe this issue in substantially more detail, including Git for Windows version, exact paste of the output of the command, URL to a repository with which this issue can be reproduced reliably? |
I am using the latest version of git for windows (2.6.2) When running 'git clean -xfd' there's no output other than the removed folders/files, running 'echo %errorlevel%' returns 1
Unfortunately the repository is private and cannot be shared, however I will attempt to debug this myself and try to narrow down the problem so that I can provide more information. Will be helpful if you could guide me, currently following https://github.com/git-for-windows/git/wiki/Debugging-Git |
@dscho I can reproduce if I create long paths:
@talcloudshare Can you check for long paths in your case? |
@talcloudshare Enabling Can you try with it enabled? |
Thanks, this works for me |
So the issue is the missing error message. The next steps would be:
|
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When a too-long path is encountered, `git clean -dfx` [no longer aborts quietly](git-for-windows/git#521). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when `lstat()` failed, `git clean` would abort without an error message, leaving the user quite puzzled. In particular on Windows, where the default maximum path length is quite small (yet there are ways to circumvent that limit in many cases), it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported this issue: git-for-windows#521 Note that we temporarily set `core.longpaths = false` in the regression test; This ensures forward-compatibility with the `core.longpaths` feature that has not yet been upstreamed from Git for Windows. Helped-by: René Scharfe <l.s.r@web.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When `lstat()` failed, `git clean` would abort without an error message, leaving the user quite puzzled. In particular on Windows, where the default maximum path length is quite small (yet there are ways to circumvent that limit in many cases), it helps to give users an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported this issue: git-for-windows#521 Note that we temporarily set `core.longpaths = false` in the regression test; this ensures forward-compatibility with the `core.longpaths` feature that has not yet been upstreamed from Git for Windows. Helped-by: René Scharfe <l.s.r@web.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When `lstat()` failed, `git clean` would abort without an error message, leaving the user quite puzzled. In particular on Windows, where the default maximum path length is quite small (yet there are ways to circumvent that limit in many cases), it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported this issue: git-for-windows#521 Note that we temporarily set `core.longpaths = false` in the regression test; this ensures forward-compatibility with the `core.longpaths` feature that has not yet been upstreamed from Git for Windows. Helped-by: René Scharfe <l.s.r@web.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
macOS release: publish dmg and pkg
Running 'git clean -fd' or 'git clean -fx' works properly (i.e., errorlevel is 0 at the end of the execution)
Seems to only happen with certain (large) repositories
The text was updated successfully, but these errors were encountered: