$ 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 -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.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.
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.
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.t...