git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Sebastian Thiel <sebastian.thiel@icloud.com>,
	git@vger.kernel.org, Josh Triplett <josh@joshtriplett.org>,
	Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [RFC] Define "precious" attribute and support it in `git clean`
Date: Fri, 13 Oct 2023 13:25:45 +0200	[thread overview]
Message-ID: <ZSkpOc/dcGcrFQNU@ugly> (raw)
In-Reply-To: <xmqqttqvg4lw.fsf@gitster.g>

On Thu, Oct 12, 2023 at 09:58:19AM -0700, Junio C Hamano wrote:
>I do not think it will be the end of the world if we don't do so,
>but it would be really really nice if we at least explored a way (or
>two) to make a big enough hole in the syntax to not just add
>"precious", but leave room to later add other traits, without having
>to worry about breaking the backward compatibility again.
>
that would invariably make the syntax more verbose, for dubious gain.

that the extension we're deliberating now (again) was coming (in some 
form) was clear for quite a while, while i'm not aware of anything else 
that would semantically fit gitignore (*). "other traits" sounds awfully 
like scope creep, and would most likely fit gitattributes better.

anyway, such a hypothetical "breaking" change wouldn't have much impact, 
because versioned files aren't affected by gitignore. and for the 
misclassification to be actually harmful, the user would have to be 
unable to notice or correct it.

(*) this got me thinking about things that would fit, and i came up with 
a modification of the proposal: one might want to specify just *how* 
precious a file is (which i guess would translate to how many times the 
extra override option would have to be passed to git-clean). (**)

i guess a suitable syntax for that would be

   2>.config

note that even though using the dollar sign to denote "precious" is kind 
of intuitive, i'm not using it for two reasons: a) it's not "crazy" 
enough to use it at not quite the beginning of a file name (note that 
traditionally it isn't even special on windows), and b) the visual 
separation of the prefix isn't as good as with the "arrow-like" 
character.

(**) actually, one would probably want proper type tagging (e.g., config 
files vs. autotools-generated files (which do not belong into a repo, 
but do into a tar-ball)). that really does sound a lot like 
gitattributes, only that the files aren't versioned.

regards

  parent reply	other threads:[~2023-10-13 11:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10 12:37 [RFC] Define "precious" attribute and support it in `git clean` Sebastian Thiel
2023-10-10 13:38 ` Kristoffer Haugsbakk
2023-10-10 14:10   ` Josh Triplett
2023-10-10 17:07     ` Junio C Hamano
2023-10-12  8:47       ` Josh Triplett
2023-10-10 19:10     ` Kristoffer Haugsbakk
2023-10-12  9:04       ` Josh Triplett
2023-10-10 17:02 ` Junio C Hamano
2023-10-11 10:06   ` Richard Kerry
2023-10-11 22:40     ` Jeff King
2023-10-11 23:35     ` Junio C Hamano
2023-10-12 10:55   ` Sebastian Thiel
2023-10-12 16:58     ` Junio C Hamano
2023-10-13  9:09       ` Sebastian Thiel
2023-10-13 16:39         ` Junio C Hamano
2023-10-14  7:30           ` Sebastian Thiel
2023-10-13 10:06       ` Phillip Wood
2023-10-14 16:10         ` Junio C Hamano
2023-10-13 11:25       ` Oswald Buddenhagen [this message]
2023-10-14  5:59   ` Josh Triplett
2023-10-14 17:41     ` Junio C Hamano
2023-10-15  6:44     ` Elijah Newren
2023-10-15  7:33       ` Sebastian Thiel
2023-10-15 16:31         ` Junio C Hamano
2023-10-16  6:02           ` Sebastian Thiel
2023-10-23  7:15           ` Sebastian Thiel
2023-10-29  6:44             ` Elijah Newren
2023-10-11 21:41 ` Kristoffer Haugsbakk

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=ZSkpOc/dcGcrFQNU@ugly \
    --to=oswald.buddenhagen@gmx.de \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=josh@joshtriplett.org \
    --cc=sebastian.thiel@icloud.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.
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 NNTP newsgroup(s).