git bisect/checkout and changes to .gitignore

git bisect/checkout and changes to .gitignore

[Chris Angelico]

Greetings! I'm not certain if this list or the git-users group is more
appropriate; my apologies if I've picked wrong.

At my workplace we use git to manage all of our source code. Every now
and then, we decide that some particular file oughtn't to be
git-managed, and add it into .gitignore and remove it from the
repository (for instance, configuration files that become
per-developer).

Is there a way to checkout an old version of the repository (before
the file was added to .gitignore), then return to the current state,
without destroying these sorts of files? Currently, checking out the
old version quietly "takes control" of the file, and then checking out
a newer one deletes it.

I've read through the man pages for 'git checkout' and 'gitignore' and
searched the one for 'git config' (it's a little large to read all
of), without seeing an option to preserve files on checkout. Is there
a way to do this, and if so, where can I find it?

Thanks in advance!

Chris Angelico

Re: git bisect/checkout and changes to .gitignore

[Johannes Sixt]

Am 6/22/2012 9:51, schrieb Chris Angelico:
> At my workplace we use git to manage all of our source code. Every now
> and then, we decide that some particular file oughtn't to be
> git-managed, and add it into .gitignore and remove it from the
> repository (for instance, configuration files that become
> per-developer).
> 
> Is there a way to checkout an old version of the repository (before
> the file was added to .gitignore), then return to the current state,
> without destroying these sorts of files? Currently, checking out the
> old version quietly "takes control" of the file, and then checking out
> a newer one deletes it.
> 
> I've read through the man pages for 'git checkout' and 'gitignore' and
> searched the one for 'git config' (it's a little large to read all
> of), without seeing an option to preserve files on checkout. Is there
> a way to do this, and if so, where can I find it?

Files mentioned in .gitignore are considered garbage. But your file is
precious, hence, you should not list it in .gitignore.

Here is a thread that is worthwhile to read. I posted a patch

http://thread.gmane.org/gmane.comp.version-control.git/185724/focus=185733

but it was dismissed, see

http://thread.gmane.org/gmane.comp.version-control.git/185724/focus=185746

-- Hannes

Re: git bisect/checkout and changes to .gitignore

[Chris Angelico]

On Fri, Jun 22, 2012 at 8:31 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Files mentioned in .gitignore are considered garbage. But your file is
> precious, hence, you should not list it in .gitignore.

An important distinction! Thanks for the thread pointer.

The --no-overwrite-ignore flag is part of what I want. It at least
gives protection against accidentally losing things (on Wednesday, I
unwittingly disposed of several large binary files, and didn't even
know about it until a chance discovery of directory size). Is there a
way to specify that this flag always be used, even when the checkout
doesn't happen on the command line but through (eg) git bisect?

Chris Angelico

Re: git bisect/checkout and changes to .gitignore

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Here is a thread that is worthwhile to read. I posted a patch
>
> http://thread.gmane.org/gmane.comp.version-control.git/185724/focus=185733
>
> but it was dismissed, see
>
> http://thread.gmane.org/gmane.comp.version-control.git/185724/focus=185746

Thanks.

Two thoughts and a half.

 - For people who do not want to read the above, the patch in the
   former was not a change to the code, but was a demonstration to
   exploit a bug in .git/ignore/exclude handling.

 - The latter message above outlined a future direction to properly
   handle "ignored" vs "precious" distinction.

 - There probably are other "here is a way forward" messages in the
   list archive whose visions haven't been materialized. Is anybody
   collecting these? I suspect that such a collection would be far
   more useful than a typical bug tracker that nobody looks at.