newbie question

[ravi567]

I have been using git for few months. I thought I had understood the behaviour of file changes within a branch in a certain way. I am seeing some different behavior. Could someone help clarify.

I have 2 branches master and dev.

1. I create a new file called test_file in dev branch. When I run git status, it shows me test_file is a untracked file now.

2. I run a git checkout master to switch to the master branch. When I run a git status, it shows me the test_file is a untracked file there as well.

Question: My assumption was a file created in one branch will not be seen in another branch, unless I have commited the branch (dev) and merged it with other branch (master). Is my understanding wrong?

1. If I add the test_file to index (git add test_file), commit the file in devl branch, I no longer see the file in master branch.

Question: does this mean the file will not be seen in other branches (master) only when it’s commited in a branch (dev).

Thanks

Ravi

[dtashley]

If I’m understanding your description correctly, the issue was likely that test_file was untracked, so git let it hang around in your sandbox while you switched branches.

I have not verified this behavior, but it makes sense if this is the case.

When you switch branches in your git, git’s only rule is not to destroy information.  This means that if a tracked file has been modified, it should refuse to do the switch.  However, if a tracked file has not been modified, it is free to bring a different revision into your sandbox or to delete it from your sandbox (the rationale for this is that you can get the file and its contents back by switching back to the original branch).

But with an untracked file, git’s designers likely had to decide between two options:

1)Refuse to do the switch until the user has disposed of the untracked file.

2)Do the switch, but leave the untracked file in place, unchanged.

Note that the following would NOT have been an option:

3)Delete the tracked file.  (Not an option because you could not recover the file.)

I’m guessing that git’s designers chose (2) because it is less obtrusive.  It would be a common use case that developers have extra untracked files in the sandbox when switching branches.

(*) One case that I would be curious about is if you are on a branch where test_file is not tracked, you create test_file, then try to switch to a branch where test_file IS tracked.  I’m betting git will refuse to let you switch branches.

Again, git’s priority would be to not destroy your data.  Leaving an untracked file in your sandbox while switching branches does not destroy data.

If you test (*), let me know the results.

[sfynx]

@dtashley wrote:

 

 

(*) One case that I would be curious about is if you are on a branch where test_file is not tracked, you create test_file, then try to switch to a branch where test_file IS tracked.  I’m betting git will refuse to let you switch branches.

 

 

Correct, it is blocked, stating the files that would have been overwritten so you know what to get to safety first.