On Tue, Nov 27, 2018 at 1:56 PM Jacob Keller wrote:
> Personally, I would rather err on the side which requires the least
> interaction from users to avoid silently clobbering an ignored file.
>
> Either Duy's solution with a sort of "untracked" reflog, or the
> garbage/trashable notion.
The "unt
On Wed, Nov 28, 2018 at 10:54 PM Ævar Arnfjörð Bjarmason
wrote:
> But we must have some viable way to repair warts in the tools, and
> losing user data is a *big* wart.
>
> I don't think something like the endgame you've described in
> https://public-inbox.org/git/xmqqzhtwuhpc@gitster-ct.c.goo
Ævar Arnfjörð Bjarmason writes:
> I don't think something like the endgame you've described in
> https://public-inbox.org/git/xmqqzhtwuhpc@gitster-ct.c.googlers.com/
> is ever going to work. Novice git users (the vast majority) are not
> going to diligently update both .gitignore and some .gi
On Wed, Nov 28 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> 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|...] --for
On 11/28/18 3:21 AM, brian m. carlson wrote:
Thanks for the elaboration, Brian - good to get things down to a
practical, real-world level.
> [...]
>
> I point this out to underscore how fundamental this change is. People
> overwhelmingly do not read the release notes, so expecting people to
>
Ævar Arnfjörð Bjarmason writes:
> 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?
Whether
On Tue, Nov 27, 2018 at 02:50:34PM +, Per Lundberg wrote:
> I agree strongly with this personally; if we must choose between "might
> break automation" and "might delete non-garbage files", I would say the
> former is the lesser evil of the two.
>
> But, if I had 10 000 000 servers set up usin
On Tue, Nov 27, 2018 at 1:56 PM Jacob Keller wrote:
>
> On Tue, Nov 27, 2018 at 1:45 AM Per Lundberg wrote:
> >
> > On 11/26/18 5:55 PM, Duy Nguyen wrote:
> > > On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason
> > > wrote:
> > >> Some of the solutions overlap with this thing you want, but
On Mon, Nov 26 2018, Junio C Hamano wrote:
> Per Lundberg 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, p
On 11/27/18 2:55 PM, Jacob Keller wrote:
> Personally, I would rather err on the side which requires the least
> interaction from users to avoid silently clobbering an ignored file.
>
> [...]
>
> I don't like the idea of precious because it means people have to know
> and remember to opt in, an
On Tue, Nov 27, 2018 at 1:45 AM Per Lundberg wrote:
>
> On 11/26/18 5:55 PM, Duy Nguyen wrote:
> > On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason
> > wrote:
> >> Some of the solutions overlap with this thing you want, but I think it's
> >> worth keeping the distinction between the two in
On 11/26/18 5:55 PM, Duy Nguyen wrote:
> On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason
> wrote:
>> Some of the solutions overlap with this thing you want, but I think it's
>> worth keeping the distinction between the two in mind.
>
> On the other hand all use cases should be considered.
On Mon, Nov 12, 2018 at 11:22:09PM +, brian m. carlson wrote:
> This is going to totally hose automation. My last job had files which
> might move from tracked to untracked (a file that had become generated),
> and long-running CI and build systems would need to be able to check out
> one stat
On Mon, Nov 26, 2018 at 4:47 PM Ævar Arnfjörð Bjarmason
wrote:
> >> >> How about something like this:
> >> >>
> >> >> 1. Introduce a concept with "garbage" files, which git is "permitted to
> >> >> delete" without prompting.
> >> >>
> >> >> 2. Retain the current default, i.e. "ignored files are ga
On Mon, Nov 26 2018, Duy Nguyen wrote:
> On Mon, Nov 26, 2018 at 4:34 PM Ævar Arnfjörð Bjarmason
> wrote:
>>
>>
>> On Mon, Nov 26 2018, Duy Nguyen wrote:
>>
>> > On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg
>> > wrote:
>> >>
>> >> On 11/13/18 1:22 AM, brian m. carlson wrote:
>> >> > This is
On Mon, Nov 26, 2018 at 4:34 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Nov 26 2018, Duy Nguyen wrote:
>
> > On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote:
> >>
> >> On 11/13/18 1:22 AM, brian m. carlson wrote:
> >> > This is going to totally hose automation. My last job had files whi
On Mon, Nov 26 2018, Duy Nguyen wrote:
> On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote:
>>
>> On 11/13/18 1:22 AM, brian m. carlson wrote:
>> > This is going to totally hose automation. My last job had files which
>> > might move from tracked to untracked (a file that had become generate
On Mon, Nov 26, 2018 at 10:30 AM Per Lundberg wrote:
>
> On 11/13/18 1:22 AM, brian m. carlson wrote:
> > This is going to totally hose automation. My last job had files which
> > might move from tracked to untracked (a file that had become generated),
> > and long-running CI and build systems wo
Per Lundberg 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
On Mon, Nov 26 2018, Per Lundberg wrote:
> On 11/13/18 1:22 AM, brian m. carlson wrote:
>> This is going to totally hose automation. My last job had files which
>> might move from tracked to untracked (a file that had become generated),
>> and long-running CI and build systems would need to be
On 11/13/18 1:22 AM, brian m. carlson wrote:
> This is going to totally hose automation. My last job had files which
> might move from tracked to untracked (a file that had become generated),
> and long-running CI and build systems would need to be able to check out
> one status and switch to the
On Sun, Nov 11, 2018 at 01:33:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
> The users who need protection against git deleting their files the most
> are exactly the sort of users who aren't expert-level enough to
> understand the nuances of how the semantics of .gitignore and "precious"
> are going
On Sun, Nov 11, 2018 at 2:06 PM Ævar Arnfjörð Bjarmason
wrote:
> +Trashable files
> +~~~
> +
> +`trashable`
> +^^
> +
> +Provides an escape hatch for re-enabling a potentially data destroying
> +feature which was enabled by default between Git versions 1.5.2 and
> +2.20. See th
On Mon, Nov 12, 2018 at 10:09 AM Matthieu Moy wrote:
> May I remind an idea I sugested in an old thread: add an intermediate level
> where ignored files to be overwritten are renamed (eg. foo -> foo~ like Emacs'
> backup files):
>
> https://public-inbox.org/git/vpqd3t9656k@bauges.imag.fr/
>
>
Ævar Arnfjörð Bjarmason writes:
>> Or only selected "*.o" (vendor supplied binary blob) kept tracked
>> while everything else is built from the source.
>> ...
> But it also does get used for "mostly we don't want this file, but
> sometimes we do" use-case, so that's something we need to deal with
On Mon, Nov 12 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> What I'd add to your list is:
>>
>> * Some projects (I've seen this in the wild) add e.g. *.mp3 or whatever
>> else usually doesn't belong in the repo as a "soft ignore". This is
>> something we've never recom
Ævar Arnfjörð Bjarmason writes:
> What I'd add to your list is:
>
> * Some projects (I've seen this in the wild) add e.g. *.mp3 or whatever
> else usually doesn't belong in the repo as a "soft ignore". This is
> something we've never recommended, but have implicitly supported since
> the on
"Per Lundberg" wrote:
> On 11/11/18 5:41 PM, Duy Nguyen wrote:
> > On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason
> > wrote:
>
> >> That will lose no data, and in the very rare cases where a checkout of
> >> tracked files would overwrite an ignored pattern, we can just error out
> >> (a
On Mon, Nov 12 2018, Matthieu Moy wrote:
> "Per Lundberg" wrote:
>
>> On 11/11/18 5:41 PM, Duy Nguyen wrote:
>> > On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason
>> > wrote:
>>
>> >> That will lose no data, and in the very rare cases where a checkout of
>> >> tracked files would overwr
On 11/11/18 5:41 PM, Duy Nguyen wrote:
> On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason
> wrote:
>
>> That will lose no data, and in the very rare cases where a checkout of
>> tracked files would overwrite an ignored pattern, we can just error out
>> (as we do with the "Ok to overwrite"
On Sun, Nov 11 2018, Duy Nguyen wrote:
> On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason
> wrote:
>> The users who need protection against git deleting their files the most
>> are exactly the sort of users who aren't expert-level enough to
>> understand the nuances of how the semantics
On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason
wrote:
> The users who need protection against git deleting their files the most
> are exactly the sort of users who aren't expert-level enough to
> understand the nuances of how the semantics of .gitignore and "precious"
> are going to inter
Nguyễn Thái Ngọc Duy writes:
> Also while "precious" is a fun name, but it does not sound serious.
> Any suggestions? Perhaps "valuable"?
FWIW, I am reasonably sure that I was the first in Git circle who
used the term "precious" in discussions wrt .gitignore, i.e. "Git
has ignored but not preci
On Sun, Nov 11 2018, Ævar Arnfjörð Bjarmason wrote:
> [CC-ing some of the people involved in recent threads about this]
>
> On Sun, Nov 11 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> Since this topic has come up twice recently, I revisited this
>> "precious" thingy that I started four years ago and t
[CC-ing some of the people involved in recent threads about this]
On Sun, Nov 11 2018, Nguyễn Thái Ngọc Duy wrote:
> Since this topic has come up twice recently, I revisited this
> "precious" thingy that I started four years ago and tried to see if I
> could finally finish it. There are a coupl
On Sun, Nov 11, 2018 at 10:53 AM Nguyễn Thái Ngọc Duy wrote:
>
> Also while "precious" is a fun name, but it does not sound serious.
> Any suggestions? Perhaps "valuable"?
"precious" is also used by POSIX make:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
Bert
Since this topic has come up twice recently, I revisited this
"precious" thingy that I started four years ago and tried to see if I
could finally finish it. There are a couple things to be sorted out...
A new attribute "precious" is added to indicate that certain files
have valuable content and sh
37 matches
Mail list logo