1

I have not decided if I like the following behavior regarding files / folders that are not under version control.

In particular, it seems strange that un-versioned files seem to follow you when you checkout different branches. It seems like said files should only exist in the branch they were created in.

Can someone please help me understand why / if this is desirable behavior?

For example:

shopkins@shax:~/tmp/test$ ls hello.txt shopkins@shax:~/tmp/test$ git branch - * master my_branch shopkins@shax:~/tmp/test$ shopkins@shax:~/tmp/test$ git checkout my_branch Switched to branch 'my_branch' shopkins@shax:~/tmp/test$ mkdir adir shopkins@shax:~/tmp/test$ touch adir/my_branch.txt shopkins@shax:~/tmp/test$ git add adir/ shopkins@shax:~/tmp/test$ git commit -a -m "added adir with my_branch.txt" [my_branch d36964c] added adir with my_branch.txt 0 files changed, 0 insertions(+), 0 deletions(-) shopkins@shax:~/tmp/test$ git checkout my_branch Switched to branch 'my_branch' shopkins@shax:~/tmp/test$ tree . |-- adir | |-- my_branch.txt | `-- orphan.txt `-- hello.txt 1 directory, 3 files create mode 100644 adir/my_branch.txt shopkins@shax:~/tmp/test$ touch adir/orphan.txt shopkins@shax:~/tmp/test$ git checkout master Switched to branch 'master' shopkins@shax:~/tmp/test$ ls adir hello.txt shopkins@shax:~/tmp/test$ tree . |-- adir | `-- orphan.txt `-- hello.txt 1 directory, 2 files

EDIT As it turns out, nothing was changed in the files between the branches in the following first edit. Thanks for the help everyone!

EDIT It seems that git does not write modification of versioned files when checkouts occur. In the following example, another.txt is not under version control:

shopkins@shax:~/tmp/test$ ls -l total 4 drwxr-xr-x 2 shopkins shopkins 4096 2011-02-21 21:49 adir -rw-r--r-- 1 shopkins shopkins 0 2011-02-21 21:47 another.txt -rw-r--r-- 1 shopkins shopkins 0 2011-02-21 21:49 hello.txt shopkins@shax:~/tmp/test$ git checkout my_branch Switched to branch 'my_branch' shopkins@shax:~/tmp/test$ ls -l total 4 drwxr-xr-x 2 shopkins shopkins 4096 2011-02-21 21:49 adir -rw-r--r-- 1 shopkins shopkins 0 2011-02-21 21:47 another.txt -rw-r--r-- 1 shopkins shopkins 0 2011-02-21 21:49 hello.txt shopkins@shax:~/tmp/test$
Improve this question

3 Answers 3

Reset to default
4

Git doesn't even know that the un-versioned files exist. Technically they aren't even part of the repository. That is why they are called "un-versioned files." Git does not modify, delete, store, or keep track of any file unless it is told to.

The classic situation where this is desirable is if your software generates temporary files as part of its build process, or if the compiled executables are left in the same directory as the source code. Obviously, if someone is cloning your repository so they can download your software from you, you would want all those files to be "left behind." But more importantly, you would not want them cluttering up the version history. It doesn't matter when these files change, only when the source code changes. So seeing diffs of these files with every commit will only make it harder to find the information you actually want.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Thanks for the input. I was worried about such temporary files (like compiled executables) causing problems if trying to re-compile between different branches. Say you switch to one branch and execute a make command, then switch to a different one and execute another make, will the compiler think everything is up to date because of the date-modified attrs of the files / executables?
I believe GIT writes the file modification time as the moment you do a branch switch (if an update to the file is required on the switch). This mean make will see any dependencies on this file as not met and recompile them. I can't speak for other build systems, but I believe they all work in a similar manner.
I tested what I think you mean. CAn you please take a look at the edit?
well nothing has actually changed between those two branches. You are looking at the same node on the git tree. You would need to have different content in some.file.
If the versioned files need not be changed in order to switch between branches, they won't be. If the branches actually contained different versions of the files, your results would have been different.
|
1

well this can make builds faster as un-added output hangs around between branch switches and you don't have your make output to some external directory.

Improve this answer

Comments

1

Why would git delete a file it can't restore? Git just leaves alone the files it doesn't know about.

Improve this answer

3 Comments

If I were to add the orphan.txt file to my_branch and commit the changes, then checkout back to master, 'adir' does no longer exist. I wonder why it will leave the directory in there until it has no un-versioned files?
Git will never delete files unless it is specifically told to. It will keep directories if they contain files it hasn't been told to delete.
@Max E. Yes. That was a rhetorical question. @Hersheezy My point is: git shouldn't delete untracked files, because it can't restore them.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.