It's a version control system, not a system restore point. Your directory will always need to contain files which you don't want to track (e.g. a node_modules directory).

Just like everything else in life, it's ultimately up to you to be careful with the tools provided to you. A hammer is dangerous if you swing it at your head.

from progit2.

[email protected] mailing list mirror (one of many)
help / color / mirror / code / Atom feed
From: grizlyk [email protected]
To: [email protected]
Subject: Pro Git book: concerning data lost due to ".gitignore"
Date: Sat, 05 Jun 2021 02:12:26 +0300 [thread overview]
Message-ID: [email protected] (raw)

Good day.

1. Summary.

It should be explicitly warned in the Pro Git book https://git-scm.com/book/en/v2 (and in git man also) that the ".gitignore" feature is very dangerous stuff and should be used with care.

Due to ".gitignore" usage, some data files in directory placed under git version control, can be lost for indexing and can be not placed into repo unexpectedly for user.

User will call "git add" and git will answer about "nothing to stage".

The problem grows up if the project was obtained from network with unknown ".gitignore" files or there are external tools (like Visual Studio IDE) that can in background setup and modify "./.gitignore" files by unknown for user way during project lifetime.

In follow text we list the problems, and git book editors will decide how to write about (esp. in english).

In ideal case ".gitignore" should be disabled at all, user should provide clean directory to be controlled by any VCS, any all dummy files must be moved out by generic OS tools.

But for some reasons ".gitignore" will exist.

There are some visible solutions to relax the data lost danger due to ".gitignore":

2.1
place files that no need to be staged into separate from repo subdirectories.

In ideal case for directory tree like "a\b\c":

• all subdirectories placed under git control must be staged ("git add src");
  "\src" + "a\b\c"

• all generated files must be outside of src source directory (possibly with the same subdir tree);
  "\var" + "a\b\c"

In the case you will treat ".gitignore" feature as workaround to projects that can not follow reliable repo rules (reliable here means files will not be omitted from stage by mistake).

2.2
provide trivial ".gitignore" file.

• rename all unknown to you foreign or autogenerated ".gitignore" into any kind of ".old-gitignore.old";
• manually create ".gitignore" file and place into it only the names, that you exactly know;
• always call "git status --ignored".

2.3
use "git status --ignored".

always use "--ignored" option of "git status" at least to complete daily commit but better for every commit.

Check ignored files list by "git status --ignored". You will see all 4 parts of status list (instead of 3 parts of the list without "--ignored" option):

example:
$ git status --ignored
On branch master
Changes to be committed:
(use "git restore --staged ..." to unstage)

Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)

Untracked files:
(use "git add ..." to include in what will be committed)

Ignored files:
(use "git add -f ..." to include in what will be committed)

If you follow rule "to separate output files", the "Ignored files" list will be very short and you will see here only known to you names.

2.4
visual tools to work with git should have separated tab to display "Ignored files" list.

not a user work

2.5
We realize that "Ignored files" was invented exactly in intention to be skipped from repo.

But in status list, if option "status --ignored" was not used, it could be useful to warn users by message like this:
"There are ignored files (%u) not placed into repo.\n\t(use git status --ignored to view)"

instead of full list, if option "status --ignored" was used
Ignored files:
(use "git add -f ..." to include in what will be committed)

not a user work

More explanations.

In the book one can read: "2.2 Ignoring Files. Tips: The Linux kernel source repository has 206 .gitignore files".

But in real the kernel source is not comprehensive list of ".gitignore" usage.

Any tool does not exist by itself, it works "in terms of task the tool implements". That means there are "tasks" the tool does.

Like any VCS, git has a valuable "task" named "every commit backup all files in the dir placed under version control". The task means "it is beter to include extra files into repo than to lose required files". If even only one file will be lost from stage git will fail the task.

In the task git works in "cp" level and should be the same trivial and reliable as "cp", here we even should not try more tricks with git, just because "enumerate files in directory without errors" is very easy work that any software from CP/M times should implement.

4. Example.

There is practical example of the git usage with errors due to ".gitignore".

I have a source "." directory.

In the directory i have some files (in my case 297 files, i was forced by git to count files in the directory, i have never tried to count files before git usage) and some levels of sub directories (in my case 9 or more levels of sub directories, i am not sure).

I called "git add ." but i was not able to add all files in the directory in git repo without any error messages by answer about "nothing to stage".

VS shows me that only 80 sacred files of 297 total files was blessed into repo by git in conjunction with VS without any error messages.

Though first time (when repo was created) VS tried to stage more files (all 297 files) into git repo, but git did not accept the gift by answer about "nothing to stage". Later VS does not offer more than 80 files to add.

I spent several hours to read git large mans, tens of flat git options, but i was still not able to add the directory in git repo.

Because "gnu in windows" has well known troubles with console and charsets (names can look like "f??df???.???"), the system was also under suspition and was also checked (as the system that is unable to enumerate files in directory).

4.1
looking into ".gitignore" file, created by several versions of VS, i found that some sub directories of the repo was marked to ignore.

I removed the names from ".gitignore" file and completed repo about 217 files.

At last the git repo was in work. Creepy.

4.2
After several days when the git repo was (as i believed) recovered i called "git status --ignored" by random event.

I got

git status --ignored

Ignored files:
(use "git add -f ..." to include in what will be committed)
.vs/
10
7
.../state/#bak/v02/
.../state/...reg_i.h

I found yet 2 extra names ignored by VS and by git due to ".gitignore" files. More creepy.

As you see by the real example: ".gitignore" feature has real ability to produce repo with lost files.

PS:
In Visual Studio related part it should be warned to do manual check ".gitattributes" file often to adjust (for example to comment out) record "* text=auto".

###############################################################################

Set default behavior to automatically normalize line endings.

###############################################################################
#* text=auto

PPS:
I also just have played in dice (no luck) to report the issue, not sure it can help to stage files.

Best regards,
Maksim.
next reply other threads:[~2021-06-04 23:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 23:12 grizlyk [this message]
2021-06-05 20:39 [Pro Git book: concerning data lost due to ".gitignore"](https://public-inbox.org/git/[email protected]/) Ævar Arnfjörð Bjarmason 2021-07-10 4:52 grizlyk
2021-07-10 8:23 ` Ævar Arnfjörð Bjarmason
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=[email protected]
  --to=[email protected]
  --cc=[email protected]
  /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).

from progit2.

I hear you, but I think "dangerous" is too strong a term for the situation you're describing. Yes, sometimes a user can be surprised that some of their files don't get controlled by Git. I'd argue that it's more dangerous for Git to be controlling files it shouldn't.

In the end, we're not going to tell people to avoid ignore files because they're "dangerous." They're useful, so we describe how to use them.

from progit2.

"dangerous" is too strong
we're not going to tell people

hist, don't seed panic in herd! the less knowledge is the more calm sleep. Strict info and mind control is the our way to expand holy colonies.

I see, but you even did not consider not only all but even any single argument that were posted, as if you have got empty paper. And did not explain your objections for them. The both actions are severe violations.

If the evil Microsoft will add any new similar to git stuffs into own development tools, we throw to them rotten tomatoes.

from progit2.

In ideal case ".gitignore" should be disabled at all, user should provide clean directory to be controlled by any VCS, any all dummy files must be moved out by generic OS tools.

There is no conditions for an ideal case. Every case is unique. And there is plenty cases where the working directory is too big to make a clean copy of it just because somebody don't want .gitignore to exist.

But for some reasons ".gitignore" will exist.

These reasons not "some" but particular and concrete. If you don't like it, then you may not use it. There is a principe to don't buy that you don't want.

There are some visible solutions to relax the data lost danger due to ".gitignore":

If you use Git UI like GitExtensions or something like that, then there would be no problem to see any untracked files including ignored in a standalone window without any git status.

If you are using a simple console window, then there is a risk to not use a command, which can show you much more details. So, does it mean we must print by default all details including miles of listing into tiny console window?

Use UI if you want to see more details at once without risk to forget to call a command with more details.

from progit2.