Re: [PATCH 1/1] clean: show an error message when the path is too long
- From
René Scharfe <l.s.r@web.de>
- Date
- Jul 16, 2019, 15:01 UTC
- Message-ID
- <a7fee3c7-8fd5-11ef-8b0d-ff8053987b0c@web.de>
- In-Reply-To
- <36677556a26cca9eafd859c88aa9b2c5a6cde309.1563285862.git.gitgitgadget@gmail.com>
Am 16.07.19 um 16:04 schrieb Johannes Schindelin via GitGitGadget:
Show 30 quoted lines
> From: 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. > > 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: > > https://github.com/git-for-windows/git/issues/521 > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- > builtin/clean.c | 3 ++- > t/t7300-clean.sh | 11 +++++++++++ > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/builtin/clean.c b/builtin/clean.c > index aaba4af3c2..7be689f480 100644 > --- a/builtin/clean.c > +++ b/builtin/clean.c > @@ -194,7 +194,8 @@ static int remove_dirs(struct strbuf *path, const char *prefix, int force_flag, > strbuf_setlen(path, len); > strbuf_addstr(path, e->d_name); > if (lstat(path->buf, &st)) > - ; /* fall thru */
I don't understand the "fall thru" comment here. It only makes sense in switch statements, doesn't it? And the code after this if/else-if/else block is only executed if we pass through here, so why was it placed way down in the first place? Perhaps for historical reasons.
dir.c::remove_dir_recurse() has such a comment as well, by the way.
Anyway, I'd keep that strange comment, as I don't see a connection to your changes. (Or explain in the commit message why we no longer "fall thru", whatever that may mean. Or perhaps I'm just thick.)
> + warning("Could not stat path '%s': %s",
> + path->buf, strerror(errno));The other warnings in that function are issued using warning_errno() (shorter code, consistency is enforced) and messages are marked for translation. That would be nice to have here as well, no?
Show 20 quoted lines
> else if (S_ISDIR(st.st_mode)) {
> if (remove_dirs(path, prefix, force_flag, dry_run, quiet, &gone))
> ret = 1;
> diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
> index 7b36954d63..aa08443f6a 100755
> --- a/t/t7300-clean.sh
> +++ b/t/t7300-clean.sh
> @@ -669,4 +669,15 @@ test_expect_success 'git clean -d skips untracked dirs containing ignored files'
> test_path_is_missing foo/b/bb
> '
>
> +test_expect_success MINGW 'handle clean & core.longpaths = false nicely' '
> + git config core.longpaths false &&
> + test_when_finished git config --unset core.longpaths &&
> + a50=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
> + mkdir -p $a50$a50/$a50$a50/$a50$a50 &&
> + touch $a50$a50/test.txt &&
> + touch $a50$a50/$a50$a50/$a50$a50/test.txt &&
> + test_must_fail git clean -xdf 2>.git/err &&
> + grep "too long" .git/errThe pattern "too long" is expected to be supplied by strerror(3), right? Depending on the locale it might return an message in a different language, so test_i18ngrep should be used here even if the warning above is not translated, right?
> +' > + > test_done >