Comment by acatton | Hacker News Reader

Comment by acatton | Hacker News Reader

Parent Full thread

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

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

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.

That's my point, that `echo .gitignore > .gitginore` as advertised as "a cool hack" in the article can lead to disasters.

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.

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.

You're right. My bad. I meant `git add -A . && git commit`.

Reply on news.ycombinator.com