From: Duy Nguyen <firstname.lastname@example.org>
To: "Ævar Arnfjörð Bjarmason" <email@example.com>
Cc: Junio C Hamano <firstname.lastname@example.org>,
Git Mailing List <email@example.com>
Subject: Re: [PATCH] Introduce "precious" file concept
Date: Sat, 13 Apr 2019 17:19:47 +0700 [thread overview]
Message-ID: <CACsJy8AEZ-Lz6zgEsuNukvphB9TTa9FAC1gK05fhnie2xtfc9w@mail.gmail.com> (raw)
I've had enough. Please drop this nd/precious. I'm not updating it anymore.
On Sat, Apr 13, 2019 at 4:54 AM Ævar Arnfjörð Bjarmason
> On Tue, Apr 09 2019, Nguyễn Thái Ngọc Duy wrote:
> > Here's the replacement patch that keeps "git clean" behavior the same
> > as before and only checks 'precious' attribute when --keep-precous is
> > specified.
> Cool to have the expected interaction with -x. Thanks.
> > -'git clean' [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>...
> > +'git clean' [<options>] [-d] [-f] [-i] [-n] [-x | -X] [--] <path>...
> For e.g. git-status(1) we just say:
> git status [<options>...] [--] [<pathspec>...]
> And for git-add(1) we do:
> git add [--verbose | -v] <very long exhaustive list of options
> spanning 4 lines omitted>
> Seems we should do one or the other here, i.e. either just add
> --keep-precious to the list, or leave it at just:
> git clean [<options>...] [--] [<pathspec>...]
> > +This attribute is set on files to indicate that their content is
> > +valuable. Some commands will behave slightly different on precious
> > +files. linkgit:git-clean may leave precious files alone.
> As noted upthread I think it's better to start with "clean" and
> "--keep-noclean", we can always alias it to "precious" later without
> squatting on that more general term when we (IMO) don't have the full
> picture yet & know if we even want that...
> But anyway, with that out of the way and assuming this is kept-as is
> seems we could document this better if we're going to keep "precious",
> e.g. maybe:
> This attribute is set on files to indicate that they're important
> while not being tracked. This attribute is experimental and subject
> to future change as more commands are changed to support it.
> Now it's only supported by linkgit:git-clean which'll skip
> cleaning files marked ith `precious` when given the
> `--keep-precious` option. This can be useful in combination with
> linkgit:gitignore to e.g. mark `*.o` build assets as both ignored
> and precious.
> I.e. say it's still early days, that it's "experimental" (not insisting
> on that phrasing, but somehow signaling to users that if they set this
> now it may do new/unexpected things in the future), and briefly describe
> how it works with "clean" and what the main intended use-case is.
> > +test_expect_success 'git clean -xd --keep-precious leaves precious files alone' '
> > + git init precious &&
> > + (
> > + cd precious &&
> > + test_commit one &&
> > + cat >.gitignore <<-\EOF &&
> > + *.o
> > + *.mak
> > + EOF
> > + cat >.gitattributes <<-\EOF &&
> > + *.mak precious
> > + .gitattributes precious
> > + *.precious precious
> > + EOF
> > + mkdir sub &&
> > + touch one.o sub/two.o one.mak sub/two.mak &&
> > + touch one.untracked two.precious sub/also.precious &&
> > + git clean -fdx --keep-precious &&
> > + test_path_is_missing one.o &&
> > + test_path_is_missing sub/two.o &&
> > + test_path_is_missing one.untracked &&
> > + test_path_is_file .gitattributes &&
> > + test_path_is_file one.mak &&
> > + test_path_is_file sub/two.mak &&
> > + test_path_is_file two.precious &&
> > + test_path_is_file sub/also.precious
> > + )
> > +'
> AFAICT this is the first attribute intended purely to be set on files
> that aren't tracked. I wonder if we should test for setting it on files
> that are tracked, and whether we should e.g. warn about that? Maybe not,
> but just raising it since I don't think it was discussed already...
next prev parent reply other threads:[~2019-04-13 10:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 10:28 What's cooking in git.git (Apr 2019, #01; Thu, 4) Junio C Hamano
2019-04-04 11:08 ` Duy Nguyen
2019-04-04 21:29 ` Junio C Hamano
2019-04-06 20:28 ` Ævar Arnfjörð Bjarmason
2019-04-08 4:14 ` Junio C Hamano
2019-04-09 10:26 ` [PATCH] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2019-04-09 11:31 ` Junio C Hamano
2019-04-10 9:36 ` Duy Nguyen
2019-04-12 1:28 ` Junio C Hamano
2019-04-09 17:44 ` Eric Sunshine
2019-04-12 21:54 ` Ævar Arnfjörð Bjarmason
2019-04-13 10:19 ` Duy Nguyen [this message]
2019-04-05 1:05 ` What's cooking in git.git (Apr 2019, #01; Thu, 4) Todd Zullinger
2019-04-05 5:41 ` Junio C Hamano
2019-04-06 19:28 ` Ævar Arnfjörð Bjarmason
2019-04-08 4:18 ` Junio C Hamano
2019-04-06 19:57 ` Ævar Arnfjörð Bjarmason
2019-04-08 4:28 ` Junio C Hamano
2019-04-08 21:18 ` Josh Steadmon
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).