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: Jeff King <peff@peff.net>
Cc: Per Lundberg <per.lundberg@hibox.tv>,
	"git\@vger.kernel.org" <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Matthieu Moy <git@matthieu-moy.fr>,
	Clemens Buchacher <drizzd@gmx.net>,
	Holger Hellmuth <hellmuth@ira.uka.de>,
	Kevin Ballard <kevin@sb.org>
Subject: Re: Ignored files being silently overwritten when switching branches
Date: Tue, 16 Oct 2018 11:10:18 +0200	[thread overview]
Message-ID: <871s8qdzph.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20181016064049.GB25933@sigill.intra.peff.net>


On Tue, Oct 16 2018, Jeff King wrote:

> On Mon, Oct 15, 2018 at 01:01:50PM +0000, Per Lundberg wrote:
>
>> Sorry if this question has been asked before; I skimmed through the list
>> archives and the FAQ but couldn't immediately find it - please point me
>> in the right direction if it has indeed been discussed before.
>
> It is a frequently asked question, but it doesn't seem to be in any FAQ
> that I could find. The behavior you're seeing is intended. See this
> message (and the rest of the thread) for discussion:
>
>   https://public-inbox.org/git/7viq39avay.fsf@alter.siamese.dyndns.org/
>
>> So my question is: is this by design or should this be considered a bug
>> in git? Of course, it depends largely on what .gitignore is being used
>> for - if we are talking about files which can easily be regenerated
>> (build artifacts, node_modules folders etc.) I can totally understand
>> the current behavior, but when dealing with more sensitive & important
>> content it's a bit inconvenient.
>
> Basically: yes. It would be nice to have that "do not track this, but do
> not trash it either" state for a file, but Git does not currently
> support that.

There's some patches in that thread that could be picked up by someone
interested. I think the approach mentioned by Matthieu Moy here makes
the most sense:
https://public-inbox.org/git/vpqd3t9656k.fsf@bauges.imag.fr/

I don't think the rationale mentioned by Junio in
https://public-inbox.org/git/7v4oepaup7.fsf@alter.siamese.dyndns.org/ is
very convincing.

The question is not whether .gitignore is intended to be used in some
specific way, e.g. only ignoring *.o files, but whether we can
reasonably suspect that users use the combination of the features we
expose in such a way that their precious data gets destroyed. User data
should get the benefit of the doubt.

Off the top of my head, I can imagine many ways in which this'll go
wrong:

 1. Even if you're using .gitignore only for "trashable" as as Junio
    mentions, git not trashing your data depends on everyone who
    modifies .gitignore in your project having enough situational
    awareness not to inadvertently add a glob to the file which
    *accidentally* ignores existing files, and *nothing warns about
    this*.

    Between the caveat noted in "It is not possible to re-include[...]"
    in gitignore(5) and negative pathspecs it can be really easy to get
    this wrong.

    So e.g. in git.git I can add a line with "*" to .gitignore, and
    nothing will complain or look unusual as long as I'm not introducing
    new files, and I'll only find out when some-new-file.c of mine gets
    trashed.

 2. Related, the UI "git add <ignored>" presents is just "Use -f if you
    really want to add them". Users who aren't careful will just think
    "oh, I just need -f in this case" and not alter .gitignore, leaving
    a timebomb for future users.

    Those new users will have no way of knowing that they've cloned a
    repo with a broken overzealous .gitignore, e.g. there's nothing on
    clone that says "you've just cloned a repo with N files, all of
    which are ignored, so git clean etc. will likely wipe out anything
    you have in the checkout".

 3. Since we implictly expose this "you need a one-off action to
    override .gitignore" noted in #2 users can and *do* use this for
    "soft" ignores.

    E.g. in a big work repo there's an ignore for *.png, even though the
    repo has thousands of such files, because it's not considered good
    practice to add them anymore (there's another static repo), and
    someone thought to use .gitignore to enforce that suggestion.

    I have a personal repo where I only want *.gpg files, and due to the
    inability to re-include files recursively (noted in #1) I just
    ignore '*' and use git veeery carefully. I was only worried about
    'git clean' so far, but now I see I need to worry about "checkout"
    as well.

But maybe the use-cases I'm mentioning are highly unusual and the repos
at work have ended up in some bizarre state and nobody else cares about
this.

It would be interesting if someone at a big git hosting providers (hint:
Jeff :) could provide some numbers about how common it is to have a
repository containing tracked files ignored by a .gitignore the
repository itself carries. This wouldn't cover all of #1-3 above, but is
probably a pretty good proxy metric.

I thought this could be done by:

    git ls-tree -r --name-only HEAD  | git check-ignore --no-index --stdin

But I see that e.g. on git.git this goes wrong due to
t/helper/.gitignore. So I don't know how one would answer "does this
repo have .gitignored files tracked?" in a one-liner.

  parent reply	other threads:[~2018-10-16  9:10 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       ` Ævar Arnfjörð Bjarmason [this message]
2018-10-16 15:05         ` Ignored files being silently overwritten when switching branches 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
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=871s8qdzph.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=kevin@sb.org \
    --cc=peff@peff.net \
    --cc=per.lundberg@hibox.tv \
    --subject='Re: Ignored files being silently overwritten when switching branches' \
    /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

Code repositories for project(s) associated with this 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).