Re: Tracking the untracked

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Geoff Russell wrote:
>

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

> On 5/6/09, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote:
> >  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.
[...]
> 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.

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.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]