git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Per Lundberg" <per.lundberg@hibox.tv>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"Steffen Jost" <jost@tcs.ifi.lmu.de>,
	"Joshua Jensen" <jjensen@workspacewhiz.com>,
	"Matthieu Moy" <git@matthieu-moy.fr>,
	"Clemens Buchacher" <drizzd@gmx.net>,
	"Holger Hellmuth" <hellmuth@ira.uka.de>,
	"Kevin Ballard" <kevin@sb.org>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [RFC PATCH] Introduce "precious" file concept
Date: Tue, 27 Nov 2018 16:08:34 +0100	[thread overview]
Message-ID: <87mupuzhfx.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqzhtwuhpc.fsf@gitster-ct.c.googlers.com>


On Mon, Nov 26 2018, Junio C Hamano wrote:

> Per Lundberg <per.lundberg@hibox.tv> writes:
>
>> How about something like this:
>> ...
>> Would this be a reasonable compromise for everybody?
>
> I do not think you'd need to introduce such a deliberately breaking
> change at all.  Just introduce a new "precious" class, perhaps mark
> them with the atttribute mechanism, and that would be the endgame.
> Early adopters would start marking ignored but not expendable paths
> with the "precious" attribute and they won't be clobbered.  As the
> mechanism becomes widely known and mature, more and more people use
> it.  And even after that happens, early adopters do not have to change
> any attribute setting, and late adopters would have plenty of examples
> to imitate.  Those who do not need any "precious" class do not have
> to do anything and you won't break any existing automation that way.

The patch I submitted in <87zhuf3gs0.fsf@evledraar.gmail.com>[1] changed
the behavior for read-tree & checkout & merge etc.

It was an RFC more in the spirit of showing what in our current tests
had to change to spur some discussion.

But I'm very sympathetic to this line of argument. I.e. in my patch I'm
changing the semantics of read-tree, which is plumbing.

What do you think about some patch like that which retains the plumbing
behavior for things like read-tree, doesn't introduce "precious" or
"trashable", and just makes you specify "[checkout|merge|...] --force"
in cases where we'd have clobbering?

This would give scripts which relied on our stable plumbing consistent
behavior, while helping users who're using our main porcelain not to
lose data. I could then add a --force option to the likes of read-tree
(on by default), so you could get porcelain-like behavior with
--no-force.

1. https://public-inbox.org/git/87zhuf3gs0.fsf@evledraar.gmail.com/

  reply	other threads:[~2018-11-27 15:08 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-17  5:21 git merge, .gitignore, and silently overwriting untracked files Joshua Jensen
2010-08-17 19:33 ` Junio C Hamano
2010-08-18 23:39   ` [PATCH] optionally disable overwriting of ignored files Clemens Buchacher
2010-08-19 10:41     ` Jakub Narebski
2010-08-20 18:48       ` Clemens Buchacher
2010-08-20 19:01         ` Joshua Jensen
2010-08-20 20:35     ` Junio C Hamano
2010-08-21  8:05       ` Clemens Buchacher
2010-08-22  7:25         ` Junio C Hamano
2010-08-22  8:20           ` Clemens Buchacher
2010-10-09 22:39         ` Kevin Ballard
2010-08-21 13:23       ` Clemens Buchacher
2010-10-09 13:52       ` [PATCH 0/5] do not overwrite untracked files in leading path Clemens Buchacher
2010-10-09 13:52       ` [PATCH 1/5] t7607: use test_commit and test_must_fail Clemens Buchacher
2010-10-10  6:35         ` Jonathan Nieder
2010-10-10  8:35           ` [PATCH 1/5 v2] t7607: use test-lib functions and check MERGE_HEAD Clemens Buchacher
2010-10-13 21:33             ` Junio C Hamano
2010-10-13 21:59             ` Junio C Hamano
2010-10-09 13:52       ` [PATCH 2/5] t7607: add leading-path tests Clemens Buchacher
2010-10-09 19:14         ` Johannes Sixt
2010-10-10  8:38           ` [PATCH 2/5 v2] " Clemens Buchacher
2010-10-09 13:52       ` [PATCH 3/5] add function check_ok_to_remove() Clemens Buchacher
2010-10-13 21:43         ` Junio C Hamano
2010-10-09 13:52       ` [PATCH 4/5] lstat_cache: optionally return match_len Clemens Buchacher
2010-10-09 13:53       ` [PATCH 5/5] do not overwrite files in leading path Clemens Buchacher
2010-10-13 21:57         ` Junio C Hamano
2010-10-13 22:34           ` Clemens Buchacher
2010-10-15  6:48             ` Clemens Buchacher
2010-10-15 18:47               ` Junio C Hamano
2010-08-20 20:46     ` [PATCH] optionally disable overwriting of ignored files Junio C Hamano
2010-08-21  6:48       ` [PATCH v2] " Clemens Buchacher
2010-08-23  8:33     ` [PATCH] " Matthieu Moy
2010-08-31 18:44       ` Heiko Voigt
2010-08-23  9:37     ` Matthieu Moy
2010-08-23 13:56       ` Holger Hellmuth
2010-08-23 15:11         ` Clemens Buchacher
2010-08-23 15:57           ` Junio C Hamano
2010-08-24  7:28             ` Clemens Buchacher
2010-08-24 16:19               ` Junio C Hamano
2018-10-16  9:10       ` Ignored files being silently overwritten when switching branches Ævar Arnfjörð Bjarmason
2018-10-16 15:05         ` Duy Nguyen
2018-10-18  1:55           ` Junio C Hamano
2018-11-06 15:12 ` Checkout deleted semi-untracked file Ævar Arnfjörð Bjarmason
2018-11-11  9:52   ` [RFC PATCH] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2018-11-11 12:15     ` Bert Wesarg
2018-11-11 12:59     ` Junio C Hamano
2018-11-26 19:38     ` [PATCH v2 0/2] Precios files round two Nguyễn Thái Ngọc Duy
2018-11-26 19:38       ` [PATCH v2 1/2] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2018-11-26 19:38       ` [PATCH v2 2/2] unpack-trees: support core.allIgnoredFilesArePreciousWhenMerging Nguyễn Thái Ngọc Duy
2018-11-11 12:33   ` [RFC PATCH] Introduce "precious" file concept Ævar Arnfjörð Bjarmason
2018-11-11 13:06     ` Ævar Arnfjörð Bjarmason
2018-11-12 16:14       ` Duy Nguyen
2018-11-11 15:41     ` Duy Nguyen
2018-11-11 16:55       ` Ævar Arnfjörð Bjarmason
2018-11-12  7:35       ` Per Lundberg
2018-11-12  9:08         ` Matthieu Moy
2018-11-12  9:49           ` Ævar Arnfjörð Bjarmason
2018-11-12 10:26             ` Junio C Hamano
2018-11-12 12:45               ` Ævar Arnfjörð Bjarmason
2018-11-12 13:02                 ` Junio C Hamano
2018-11-12 16:07           ` Duy Nguyen
2018-11-12 23:22     ` brian m. carlson
2018-11-26  9:30       ` Per Lundberg
2018-11-26 10:28         ` Ævar Arnfjörð Bjarmason
2018-11-26 12:49         ` Junio C Hamano
2018-11-27 15:08           ` Ævar Arnfjörð Bjarmason [this message]
2018-11-28  3:58             ` Junio C Hamano
2018-11-28 21:54               ` Ævar Arnfjörð Bjarmason
2018-11-29  5:04                 ` Junio C Hamano
2018-12-01  6:21                 ` Duy Nguyen
2018-11-26 15:26         ` Duy Nguyen
2018-11-26 15:34           ` Ævar Arnfjörð Bjarmason
2018-11-26 15:40             ` Duy Nguyen
2018-11-26 15:47               ` Ævar Arnfjörð Bjarmason
2018-11-26 15:55                 ` Duy Nguyen
2018-11-27  9:43                   ` Per Lundberg
2018-11-27 12:55                     ` Jacob Keller
2018-11-27 14:50                       ` Per Lundberg
2018-11-28  1:21                         ` brian m. carlson
2018-11-28  6:54                           ` Per Lundberg
2018-11-27 15:19                       ` Duy Nguyen
2018-12-06 18:39                       ` Duy Nguyen
2018-11-26 16:02       ` Eckhard Maaß
2018-10-15 13:01 Ignored files being silently overwritten when switching branches Per Lundberg
2018-10-16  6:40 ` Jeff King
2018-11-06 12:41 Checkout deleted semi-untracked file Steffen Jost

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=87mupuzhfx.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=drizzd@gmx.net \
    --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 \
    --cc=sandals@crustytoothpaste.net \
    /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).