3 ms·

This is a recipe for disaster. Especially if somebody else commits a gitignore in your repository. If you want an untracked list of files to not track, use .gi

This is a recipe for disaster. Especially if somebody else commits a gitignore in your repository. If you want an untracked list of files to not track, use .git/info/exclude, it's literally made for this. This is not a hidden feature, it is documented https://git-scm.com/docs/gitignore https://git-scm.com/docs/gitignore

rjmunro 4y ago
If someone else commits a .gitignore in your repository, .gitignore is in your repository and will stay there. .gitignore is only used in deciding if an untracked file should be added. It makes no difference to existing files.
- richardwhiuk 4y ago
  You'll get a conflict when you try and pull I think.
  - deleted 4y ago
    [deleted]
- acatton 4y ago
  If you do `echo .gitignore > .gitignore` and then somebody elses commit a git ignore, and you pull from that repository, your local .gitignore will be silently overriden, and you might add untracked files if you have the bad habit of `git commit -a`. $ for repo in alice bob; git init $repo $ git init --bare shared $ cd bob $ touch foo $ git add foo $ git commit -m "Initial commit" $ git push ../shared $ cd ../alice $ git pull ../shared $ echo bar > .gitignore $ git add .gitignore $ git commit -m "Add gitignore" $ git push ../shared $ cd ../bob $ echo .gitignore > .gitignore $ git pull ../shared remote: Enumerating objects: 4, done. remote: Counting objects: 100% (4/4), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), 272 bytes | 272.00 KiB/s, done. From ../shared * branch HEAD -> FETCH_HEAD Updating 343eb88..3701fae Fast-forward .gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 .gitignore $ cat .gitignore bar
  - ekimekim 4y ago
    nitpick: `git commit -a` does not add untracked files: -a, --all Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
    - acatton 4y ago
      You're right. My bad. I meant `git add -A . && git commit`.
  - eckza 4y ago
    Fair point but outside of the context of demonstrating this... _why would you actually ever `echo .gitignore > .gitignore`?_ Seems a bit like pointing out that running `sudo rm -rfv /` will let you watch your shell eat your whole system a file at a time. I could be wildly wrong here, though, and I'm interested in some clarification.
    - acatton 4y ago
      That's my point, that `echo .gitignore > .gitginore` as advertised as "a cool hack" in the article can lead to disasters.
      - 58x14 4y ago
        I can't see how you'd interpret this as "advertising a cool hack." The entire original article: I initialised a new Git repository, and added a .gitignore file instructing git to ignore .gitignore: git init . echo ".gitignore" > .gitignore git status And the result: On branch trunk No commits yet nothing to commit (create/copy files and use "git add" to track) Therefore, we can see Git ignores .gitignore because its in .gitignore, which means it didn’t ignore .gitignore for instructions. Is any of this informative, surprising, or useful? … Absolutely.
  - adrianmonk 4y ago
    This is true (and surprising! and TIL!), but it doesn't seem to have anything to do with the fact that .gitignore is the file being ignored. Instead, it appears that when merging, the --overwrite-ignore option[1] is the default. It doesn't get overwritten if (instead of "git pull") you do this: $ git fetch $ git merge FETCH_HEAD --no-overwrite-ignore Updating cc80208..0a917b9 error: The following untracked working tree files would be overwritten by merge: .gitignore Please move or remove them before you merge. Aborting $ I'm not sure I can see a good justification for this default, really. You could argue that many ignored files are junk or can be recreated, and that's why they got ignored in the first place, so it should be OK to overwrite them. (For example, when working in C, you might ignore *.o for object files.) But then, if it is something that needs to be merged, then that means somebody bothered to track it, which refutes the idea that it was unimportant or ephemeral or whatever. ---- [1] https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---overwrite-ignore https://git-scm.com/docs/git-merge#Documentation/git-merge.t...

rjmunro 4y ago

If someone else commits a .gitignore in your repository, .gitignore is in your repository and will stay there. .gitignore is only used in deciding if an untracked file should be added. It makes no difference to existing files.

richardwhiuk 4y ago
You'll get a conflict when you try and pull I think.
- deleted 4y ago
  [deleted]
acatton 4y ago
If you do `echo .gitignore > .gitignore` and then somebody elses commit a git ignore, and you pull from that repository, your local .gitignore will be silently overriden, and you might add untracked files if you have the bad habit of `git commit -a`. $ for repo in alice bob; git init $repo $ git init --bare shared $ cd bob $ touch foo $ git add foo $ git commit -m "Initial commit" $ git push ../shared $ cd ../alice $ git pull ../shared $ echo bar > .gitignore $ git add .gitignore $ git commit -m "Add gitignore" $ git push ../shared $ cd ../bob $ echo .gitignore > .gitignore $ git pull ../shared remote: Enumerating objects: 4, done. remote: Counting objects: 100% (4/4), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), 272 bytes | 272.00 KiB/s, done. From ../shared * branch HEAD -> FETCH_HEAD Updating 343eb88..3701fae Fast-forward .gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 .gitignore $ cat .gitignore bar
- ekimekim 4y ago
  nitpick: `git commit -a` does not add untracked files: -a, --all Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
  - acatton 4y ago
    You're right. My bad. I meant `git add -A . && git commit`.
- eckza 4y ago
  Fair point but outside of the context of demonstrating this... _why would you actually ever `echo .gitignore > .gitignore`?_ Seems a bit like pointing out that running `sudo rm -rfv /` will let you watch your shell eat your whole system a file at a time. I could be wildly wrong here, though, and I'm interested in some clarification.
  - acatton 4y ago
    That's my point, that `echo .gitignore > .gitginore` as advertised as "a cool hack" in the article can lead to disasters.
    - 58x14 4y ago
      I can't see how you'd interpret this as "advertising a cool hack." The entire original article: I initialised a new Git repository, and added a .gitignore file instructing git to ignore .gitignore: git init . echo ".gitignore" > .gitignore git status And the result: On branch trunk No commits yet nothing to commit (create/copy files and use "git add" to track) Therefore, we can see Git ignores .gitignore because its in .gitignore, which means it didn’t ignore .gitignore for instructions. Is any of this informative, surprising, or useful? … Absolutely.
- adrianmonk 4y ago
  This is true (and surprising! and TIL!), but it doesn't seem to have anything to do with the fact that .gitignore is the file being ignored. Instead, it appears that when merging, the --overwrite-ignore option[1] is the default. It doesn't get overwritten if (instead of "git pull") you do this: $ git fetch $ git merge FETCH_HEAD --no-overwrite-ignore Updating cc80208..0a917b9 error: The following untracked working tree files would be overwritten by merge: .gitignore Please move or remove them before you merge. Aborting $ I'm not sure I can see a good justification for this default, really. You could argue that many ignored files are junk or can be recreated, and that's why they got ignored in the first place, so it should be OK to overwrite them. (For example, when working in C, you might ignore *.o for object files.) But then, if it is something that needs to be merged, then that means somebody bothered to track it, which refutes the idea that it was unimportant or ephemeral or whatever. ---- [1] https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---overwrite-ignore https://git-scm.com/docs/git-merge#Documentation/git-merge.t...