public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Nicolas Schier <nicolas@fjasle.eu>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Overly aggressive .gitignore file?
Date: Tue, 4 Jul 2023 23:34:15 +0200	[thread overview]
Message-ID: <20230704213415.GA21872@1wt.eu> (raw)
In-Reply-To: <CAHk-=wjH4O6v_EwVB=t_6Haky2jOiejHbCkCTvgNQWo1ghy8-w@mail.gmail.com>

On Tue, Jul 04, 2023 at 02:20:36PM -0700, Linus Torvalds wrote:
> On Tue, 4 Jul 2023 at 14:15, Willy Tarreau <w@1wt.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

  reply	other threads:[~2023-07-04 21:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-04 19:49 Overly aggressive .gitignore file? Linus Torvalds
2023-07-04 21:15 ` Willy Tarreau
2023-07-04 21:20   ` Linus Torvalds
2023-07-04 21:34     ` Willy Tarreau [this message]
2023-07-04 21:44       ` Linus Torvalds
2023-07-04 21:56         ` Willy Tarreau
2023-07-04 22:14           ` Linus Torvalds
2023-07-04 22:27             ` Willy Tarreau
2023-07-05  0:41               ` Theodore Ts'o
2023-07-05 13:51                 ` Konstantin Ryabitsev
2023-07-07 18:51                 ` Nick Desaulniers
2023-07-07 19:11                   ` Linus Torvalds
2023-07-05  8:31       ` Bernd Petrovitsch
2023-07-05  1:59 ` Masahiro Yamada
2023-07-05 15:34   ` Theodore Ts'o
2023-07-05 16:28     ` Masahiro Yamada
2023-07-05  3:45 ` Nicolas Schier
2023-07-05  5:04   ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230704213415.GA21872@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolas@fjasle.eu \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox