Chapter 2.2, Ignoring Files, concerning data lost due to ".gitignore" #1887
Comments
|
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. |
|
git@vger.kernel.org mailing list mirror (one of many) Good day.
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 In ideal case for directory tree like "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
2.3 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: Changes not staged for commit: Untracked files: Ignored files: 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 not a user work 2.5 But in status list, if option "status --ignored" was not used, it could be useful to warn users by message like this: instead of full list, if option "status --ignored" was used 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.
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 I removed the names from ".gitignore" file and completed repo about 217 files. At last the git repo was in work. Creepy. 4.2 I got
Ignored files: 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: ############################################################################### Set default behavior to automatically normalize line endings.############################################################################### PPS: Best regards, Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top You may reply publicly to this message via plain-text email
This is a public inbox, see mirroring instructions |
|
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. |
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. |
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
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.
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 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. |
General overview of your idea.
It should be explicitly warned in the "Pro Git book, Chapter 2.2, Ignoring Files" (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", but in real there are files "lost for stage".
What problem will this solve?
Enabled ".gitignore" every time creates danger to lost files for indexing and for commit by error ".gitignore" pattern.
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 (for the price of extra files will be included into commit by error).
But for some reasons of real life, ".gitignore" will exist (for the price of required data files will not be included into commit by error).
There are some visible solutions to relax the data lost danger due to ".gitignore": (more examples) https://public-inbox.org/git/3957861622848346@myt5-a5512e99e394.qloud-c.yandex.net/
Have you thought about other solutions?
by the way, for "git program" itself (not for Pro Git book).
We realize that "Ignored files" was invented exactly in intention to be skipped from repo and from status list.
But in status list, even if option "status --ignored" was not used, it could be useful to warn users by simple message like this:
and in addition, list of all ignored files will be shown if option "status --ignored" was used
Do you want to help with this enhancement idea?
No
The text was updated successfully, but these errors were encountered: