[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230704213415.GA21872@1wt.eu>
Date: Tue, 4 Jul 2023 23:34:15 +0200
From: Willy Tarreau <w@....eu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Overly aggressive .gitignore file?
On Tue, Jul 04, 2023 at 02:20:36PM -0700, Linus Torvalds wrote:
> On Tue, 4 Jul 2023 at 14:15, Willy Tarreau <w@....eu> wrote:
> >
> > I don't understand why your completion on "git am" should rely on
> > *tracked* files.
>
> It doesn't.
>
> Read that email again.
>
> It fails on *untracked* files that are hidden from "git status" and
> friends by our .gitignore pattern:
>
> *.mbx
>
> added by commit 534066a983df (".gitignore: ignore *.cover and *.mbx")
>
> So when I have those old stale mbx files around, I don't see them,
> because "git status" will happily say
>
> nothing to commit, working tree clean
>
> with no mention of those old turds.
But the git am completion rules should actually *not* rely on
git status output. At least in my opinion.
> Really. Try it.
I did and for me on this machine I don't have the problem:
willy@pcw:~/linux$ git status
On branch 20230702-nolibc-series1+2_2
Your branch is up to date with 'origin/20230702-nolibc-series1+2_2'.
nothing to commit, working tree clean
willy@pcw:~/linux$ echo blah > 2023-new-patch.mbx
willy@pcw:~/linux$ git status
On branch 20230702-nolibc-series1+2_2
Your branch is up to date with 'origin/20230702-nolibc-series1+2_2'.
=> .mbx is indeed ignored
nothing to commit, working tree clean
willy@pcw:~/linux$ git am -s --whitespace 2023-new-patch.mbx
^C
Here I pressed [Tab] after "2023" and it automatically completed.
By git completion is certainly quite old, as I really don't change
it often once I have a satisfying one. My git-completion.bash script
has this in case that helps:
_git_am ()
{
__git_find_repo_path
if [ -d "$__git_repo_path"/rebase-apply ]; then
__gitcomp "$__git_am_inprogress_options"
return
fi
case "$cur" in
--whitespace=*)
__gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
return
;;
--*)
__gitcomp_builtin am "--no-utf8" \
"$__git_am_inprogress_options"
return
esac
}
> > From a workflow perspective that makes no sense,
> > as by definition, git am will consume only *untracked* files.
>
> I don't think you actually read my email.
Yes I did and I neither experience your problem nor figure why it
should happen, because I don't see the relation between gitignore
and anything that git am should be allowed to consume :-/
Willy
Powered by blists - more mailing lists