git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Johannes Sixt <j.sixt@viscovery.net>,
	Taylor Hedberg <tmhedberg@gmail.com>,
	Bertrand BENOIT <projettwk@users.sourceforge.net>,
	git@vger.kernel.org
Subject: Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
Date: Mon, 21 Nov 2011 07:18:24 -0800	[thread overview]
Message-ID: <7vk46th5bz.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20111121081701.GA7985@do> (Nguyen Thai Ngoc Duy's message of "Mon, 21 Nov 2011 15:17:01 +0700")

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> If you want to keep this accident (which is a bug to me), you may want
> to add the reason: callers to unpack_trees() are supposed to also
> setup exclude rules in .git/info/exclude before calling
> unpack_trees(), which they don't.
>
> So .git/info/exclude is entirely dismissed.

Ohh, thanks for this and also for digging this through in your other
message.

I think it is the right thing to do to make sure .gitignore and
info/exclude behave the same way regardless of the original issue in this
topic.

In the medium term, I think one reasonable way forward solving the "TODO
that used to be tracked but now untracked and ignored" issue is to
introduce "info/exclude-override" that comes between command line and
in-tree patterns. The info/exclude file is designed as the fallback
definition to be used when all other sources are too lax, and comes near
the precedence stack; the "TODO" situation however calls for an override
that is stronger than the in-tree patterns.

In the longer term, we should carefully determine if we need "precious" in
the first place. The last time this was brought up there were people who
argued they are OK with having to remove the ignored file by hand when
checking out another branch (i.e. we switch the semantics of "ignored" so
that they are "not tracked but all precious").

I think it matters in two cases.

 (1) If you change an untracked "cruft" file on branch A into a directory
     with tracked files in it on another branch B. If you are on branch A,
     have that "cruft" file (perhaps it is a build product after running
     "make"), and try to checkout branch B, such an updated "git checkout"
     will start erroring out telling you that "cruft" will be lost.

 (2) If you have a directory on branch A, underneath of which there are
     untracked "cruft" files (e.g. think "build/" directory that is full
     of "*.o" files and ".gitignore" to mark object files as ignored but
     is otherwise empty), and another branch B that has the same path as a
     file. If you are on branch A, have "cruft" files in that directory,
     and try to checkout branch B, such an updated "git checkout" will
     start erroring out telling you that "cruft" will be lost.

If people are OK with such a behaviour, we can do without "precious".

Otherwise we would need to update excluded() in dir.c to return tristate
(ignored, precious or unspecified) instead of the current boolean (ignored
or unspecified), examine and decide for each caller what they want to do
to "precious" files.

  reply	other threads:[~2011-11-21 15:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-20 13:42 Bug report - local (and git ignored) file silently removed after checkout Bertrand BENOIT
2011-11-20 21:16 ` Junio C Hamano
2011-11-20 22:19   ` Taylor Hedberg
2011-11-21  3:36     ` Junio C Hamano
2011-11-21  7:23       ` [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude Johannes Sixt
2011-11-21  7:45         ` Philip Oakley
2011-11-21  7:59           ` Junio C Hamano
2011-11-21  7:50         ` Junio C Hamano
2011-11-21  8:52           ` Nguyen Thai Ngoc Duy
2011-11-21 17:27             ` Junio C Hamano
2011-11-23 11:31               ` Nguyen Thai Ngoc Duy
2011-11-21  8:17         ` Nguyen Thai Ngoc Duy
2011-11-21 15:18           ` Junio C Hamano [this message]
2011-11-21 15:44             ` Bertrand BENOIT
2011-11-23 11:40             ` Nguyen Thai Ngoc Duy
2011-11-23 17:16               ` Junio C Hamano
2011-11-24  1:35                 ` Nguyen Thai Ngoc Duy
2011-11-24  5:17                   ` Junio C Hamano
2011-11-24  5:39                     ` Nguyen Thai Ngoc Duy
2011-11-27 10:13             ` Nguyen Thai Ngoc Duy
2011-11-27 10:15               ` [PATCH 1/2] checkout,merge: loosen overwriting untracked file check based on info/exclude Nguyễn Thái Ngọc Duy
2011-11-27 10:15                 ` [PATCH 2/2] checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore Nguyễn Thái Ngọc Duy
2011-11-29 18:17                 ` [PATCH 1/2] checkout,merge: loosen overwriting untracked file check based on info/exclude 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=7vk46th5bz.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    --cc=pclouds@gmail.com \
    --cc=projettwk@users.sourceforge.net \
    --cc=tmhedberg@gmail.com \
    /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).