git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Clemens Buchacher <drizzd@gmx.net>
To: "Duy Nguyen" <pclouds@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>,
	Per Lundberg <per.lundberg@hibox.tv>,
	Steffen Jost <jost@tcs.ifi.lmu.de>,
	Joshua Jensen <jjensen@workspacewhiz.com>,
	Matthieu Moy <git@matthieu-moy.fr>,
	Holger Hellmuth <hellmuth@ira.uka.de>,
	Kevin Ballard <kevin@sb.org>
Subject: Re: [PATCH 1/1] Introduce "precious" file concept
Date: Wed, 20 Feb 2019 12:11:12 +0100	[thread overview]
Message-ID: <B168DCB1-7A69-4729-89C7-B513464DD468@gmx.net> (raw)
In-Reply-To: <CACsJy8B15hORnaOdYW8TNE3Gniv9NBJopyLYmHR5iF0U3beq6g@mail.gmail.com>



On February 20, 2019 10:41:51 AM GMT+01:00, Duy Nguyen <pclouds@gmail.com> wrote:
>Making "git checkout/merge" abort while it's working before breaks
>scripts.

Change is always a trade-off. We should not reject change without considering the merits. Once we agree on the desired state, we can think about the migration strategy. 

>And requiring to mark trashable files manually duplicates a
>lot of ignore patterns. Have a look at any .gitignore file, the
>majority of them is for discardable files because "ignored" class was
>created with those in mind (*.o and friends). So now you would need to
>add more or less the same set of ignore rules in .gitattributes to
>mark them trashable, and gitignore/gitattributes rules are not exactly
>compatible, you can't just blindly copy them over. Every time you add
>one more .gitignore rule, there's a good chance you need to add a
>similar rule for trashable attribute.

I agree that ignored precious files are typically a small subset of the ignore files. Maintaining separate rules for ignored files and for trashable files would result in a lot of duplication.

On the other hand, how frequently do we really have to trash ignored files? Trashing a file should only be necessary if a tracked file overwrites an ignored file. When does this happen? I don't think it will happen for *.o files. So in most cases, there is simply no need to specify which files are precious. The default could simply be that all files are precious.

To support more complex use cases, we could specify precious files in addition to ignored files. Only if we specify precious files (and/or enable the ignored-are-trashable config option on a repository level), all other files become trashable.

Functionally this is equivalent the newbie option which you suggest, but I think it is not an issue of newbie vs experienced users but an issue of common vs special use cases.

>Maybe we just add a new "newbie" config knob and turn on the safety
>nets on. Leave the knob on by default. And I will turn it off in my
>~/.gitconfig as soon as it's real.

  parent reply	other threads:[~2019-02-20 11:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-16 11:49 [PATCH 0/1] Introduce "precious" file attribute Nguyễn Thái Ngọc Duy
2019-02-16 11:49 ` [PATCH 1/1] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2019-02-16 19:36   ` Ævar Arnfjörð Bjarmason
2019-02-17  9:31     ` Duy Nguyen
2019-02-18  9:53       ` Ævar Arnfjörð Bjarmason
2019-02-18 10:14         ` Duy Nguyen
2019-02-19 18:08       ` Junio C Hamano
2019-02-20  1:35         ` Duy Nguyen
2019-02-20  8:31           ` Clemens Buchacher
2019-02-20 22:32           ` Junio C Hamano
2019-02-20  9:19         ` Ævar Arnfjörð Bjarmason
2019-02-20  9:36           ` Steffen Jost
2019-02-20  9:41           ` Duy Nguyen
2019-02-20 10:46             ` Ævar Arnfjörð Bjarmason
2019-02-20 11:11             ` Clemens Buchacher [this message]
2019-02-22  9:46               ` Duy Nguyen
2019-02-20 22:39             ` Junio C Hamano
2019-02-22  9:35               ` Duy Nguyen
2019-02-22 18:07                 ` Junio C Hamano

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=B168DCB1-7A69-4729-89C7-B513464DD468@gmx.net \
    --to=drizzd@gmx.net \
    --cc=avarab@gmail.com \
    --cc=git@matthieu-moy.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hellmuth@ira.uka.de \
    --cc=jjensen@workspacewhiz.com \
    --cc=jost@tcs.ifi.lmu.de \
    --cc=kevin@sb.org \
    --cc=pclouds@gmail.com \
    --cc=per.lundberg@hibox.tv \
    /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).