# Tracking the untracked 7 messages from 2009-05-06 to 2009-05-07. Participants: Geoff Russell, Johannes Schindelin, Thomas Rast, Jakub Narebski. Thread: https://gitlist.dev/t/19193 ## Geoff Russell, 2009-05-06 01:19 Subject: Tracking the untracked Message-ID: <93c3eada0905051819l92dc7ey331d69f009cc9c8b@mail.gmail.com> URL: https://gitlist.dev/e/93c3eada0905051819l92dc7ey331d69f009cc9c8b%40mail.gmail.com ``` 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 ``` ## Johannes Schindelin, 2009-05-06 09:36 Subject: Re: Tracking the untracked Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0905061130340.14230%40intel-tinevez-2-302 In-Reply-To: <93c3eada0905051819l92dc7ey331d69f009cc9c8b@mail.gmail.com> ``` Hi, On Wed, 6 May 2009, Geoff Russell wrote: > 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. 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 ``` ## Thomas Rast, 2009-05-06 13:22 Subject: Re: Tracking the untracked Message-ID: <200905061522.56981.trast@student.ethz.ch> URL: https://gitlist.dev/e/200905061522.56981.trast%40student.ethz.ch In-Reply-To: <93c3eada0905051819l92dc7ey331d69f009cc9c8b@mail.gmail.com> ``` Geoff Russell wrote: > Bug or feature? I don't know. Feature. > 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. [...] > One solution would be to have a class of files that is "unversioned > but tracked". 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. > 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. 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. -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## Geoff Russell, 2009-05-07 07:58 Subject: Re: Tracking the untracked Message-ID: <93c3eada0905070058g7f619a56jfb9b49f02bb92f9b@mail.gmail.com> URL: https://gitlist.dev/e/93c3eada0905070058g7f619a56jfb9b49f02bb92f9b%40mail.gmail.com In-Reply-To: <200905061522.56981.trast@student.ethz.ch> ``` On 5/6/09, Thomas Rast wrote: > Geoff Russell wrote: > > Bug or feature? I don't know. > > > Feature. > > > > 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. > > [...] > > > One solution would be to have a class of files that is "unversioned > > but tracked". > > > 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. > > > > 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. > > > 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. > 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. > > -- > Thomas Rast > trast@{inf,student}.ethz.ch > > -- 6 Fifth Ave, St Morris, S.A. 5068 Australia Ph: 041 8805 184 / 08 8332 5069 ``` ## Jakub Narebski, 2009-05-07 08:22 Subject: Re: Tracking the untracked Message-ID: URL: https://gitlist.dev/e/m33abhnx01.fsf%40localhost.localdomain In-Reply-To: <93c3eada0905070058g7f619a56jfb9b49f02bb92f9b@mail.gmail.com> ``` Geoff Russell writes: > On 5/6/09, Thomas Rast wrote: > > Geoff Russell wrote: > > > Bug or feature? I don't know. > > > > > > Feature. [...] > 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. 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. -- Jakub Narebski Poland ShadeHawk on #git ``` ## Thomas Rast, 2009-05-07 09:16 Subject: Re: Tracking the untracked Message-ID: <200905071117.00162.trast@student.ethz.ch> URL: https://gitlist.dev/e/200905071117.00162.trast%40student.ethz.ch In-Reply-To: <93c3eada0905070058g7f619a56jfb9b49f02bb92f9b@mail.gmail.com> ``` 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 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 ``` ## Geoff Russell, 2009-05-07 10:54 Subject: Re: Tracking the untracked Message-ID: <93c3eada0905070354v2b8ff258m8db7b1d4968eb2ce@mail.gmail.com> URL: https://gitlist.dev/e/93c3eada0905070354v2b8ff258m8db7b1d4968eb2ce%40mail.gmail.com In-Reply-To: <200905071117.00162.trast@student.ethz.ch> ``` On 5/7/09, Thomas Rast wrote: > Geoff Russell wrote: > [...] > - 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. Understood. Upon reflection, I can't think of a better alternative. Cheers and thanks for the help, Geoff. ```