git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
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)
In-Reply-To: <875zriga8f.fsf@evledraar.gmail.com>

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
<avarab@gmail.com> wrote:
>
>
> 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[1] 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[1] which'll skip
>     cleaning files marked ith `precious` when given the
>     `--keep-precious` option. This can be useful in combination with
>     linkgit:gitignore[5] 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...



-- 
Duy

  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

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

  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 \
    --in-reply-to=CACsJy8AEZ-Lz6zgEsuNukvphB9TTa9FAC1gK05fhnie2xtfc9w@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).