git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: gitster@pobox.com, git@vger.kernel.org
Subject: Re: [PATCH] Introduce "precious" file concept
Date: Fri, 12 Apr 2019 23:54:56 +0200	[thread overview]
Message-ID: <875zriga8f.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20190409102649.22115-1-pclouds@gmail.com>


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

  parent reply	other threads:[~2019-04-12 21:55 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 [this message]
2019-04-13 10:19             ` Duy Nguyen
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=875zriga8f.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.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).