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
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
>
Æ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
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|...]
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
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,
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,
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,
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
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
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
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
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
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
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
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
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
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
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
Æ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
"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
> >>
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
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
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
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
[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
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
36 matches
Mail list logo
