Tracking the untracked

Bug or feature? I don't know.

On the master branch I have some untracked files e.g., object modules, executables.

I create a branch B1 and add+commit the untracked files.

When I switch back to the master (git checkout master), the untracked files are no longer where I left them.

Basically, I'm trying to find a way of having a huge bunch of stuff in my repository and tracked, but which doesn't get pushed to the central program repository .. which has always just been source for us .. I figured I could stick it on a branch which doesn't get pushed. But that doesn't work for the reason mentioned.

One solution would be to have a class of files that is "unversioned but tracked".

Alternatively we could just bite the bullet and track everything.

Any ideas?

Cheers, Geoff Russell

Hi,

On Wed, 6 May 2009, Geoff Russell wrote:

This is exactly what Git is supposed to do. You were on branch B1, which has the files tracked, and you do not have the files tracked in master, so when switching to master, they should be removed.

Probably you have to rethink what you are trying to do.

Ciao, Dscho

Geoff Russell wrote:

Feature.

[...]

Note that "versioned" and "tracked" mean the same thing in Git -- both denote the class of files it cares about.

Your build products became tracked (w.r.t. the then-state of the repository, on branch B1) the second you added them to the index with 'git add'. Git then cares about them, and among many other things will look at them whenever you change branches. Since they're not present in the target branch 'master', they are removed from the work tree.

Most people just put their build products in .gitignore so that they stop showing up under "untracked files" in 'git status'. (They'll still be untracked!)

Of course this means the object files for source that actually changed between the branches have to be rebuilt. However, Git takes great care to not touch any source files that are the same, so that the builds are usually quite fast even after a branch switch.

On 5/6/09, Thomas Rast <trast@student.ethz.ch> wrote:

Ok, its clearly a policy choice. But suppose I have an untracked file and I do "git some-command" then I don't expect git to touch what it doesn't know about. I.e., "git add x" shouldn't delete the untracked file y. That seems sensible. But now "git checkout branch" behaves quite differently in just deleting stuff that it doesn't own (i.e., is untracked).

Anyway, I'll rethink.

Cheers, Geoff.

Geoff Russell <geoffrey.russell@gmail.com> writes:

[...]

First, did you consider just .gitignore'ing untracked files, and if they are compilation products use cc-cache instead?

Second, the way git treats untracked files is simple: do not lose information. If a file is tracked, or to be more exact specific contents of a file is in repository, then deleting it would not remove information.

Geoff Russell wrote:

Please keep the Cc list, it's customary around here and helps us find the mails addressed to us.

[...]

They weren't untracked!

This is roughly what Dscho said, but I'll try to explain it in more detail:

- In the first step, when switching from master to B1, your build
  products were indeed untracked (not part of either master or B1 or
  the index).  So Git leaves them alone.

- By adding (git add $file) your files to the index, you made them
  tracked.[1]

- By making a commit, you let the files "officially" belong to the
  current branch (B1).  So with respect to the _current_ branch B1,
  they _were_ tracked.

- When you switch branches in the last step, Git sees that B1 has
  these files, but master doesn't, so it removes them to bring the
  worktree into the state that master has.

- Consider what happens if you were to recompile at this point, so
  that you again have the _untracked_ (w.r.t. the 'master' branch)
  build products, and then check out B1 again.  Git faces the choice
  of either overwriting your worktree files (and losing them) or not
  overwriting (and not doing the checkout right), so it will abort.
  This is a corollary of what Jakub pointed out, Git will not lose
  information unless told to.

[1] If you were to switch branches at this point, without making a commit, Git tries to "carry over" the addition of files to the target branch, unless it conflicts with files in that target branch, so the index is in a slightly different position than the HEAD. Still, anything that is listed in the index is considered tracked.

On 5/7/09, Thomas Rast <trast@student.ethz.ch> wrote:

Understood. Upon reflection, I can't think of a better alternative.

Cheers and thanks for the help,

Geoff.