# 'typechange' in the git-status output 7 messages from 2011-03-14 to 2011-03-14. Participants: Alexei Sholik, Jeff King, Drew Northup, Jonathan Nieder, Junio C Hamano. Thread: https://gitlist.dev/t/26729 ## Alexei Sholik, 2011-03-14 18:29 Subject: 'typechange' in the git-status output Message-ID: URL: https://gitlist.dev/e/AANLkTimWR0avW6mBWGa0ArVB8oZUM7nuvc5AYf%3DwgU-W%40mail.gmail.com ``` Hi git, I cloned git mirror from github[1]. When I run git-status in it's working directory, I see no output. But then, after copying the whole directory with 'cp -r' and running git-status in the newly created directory, I get the following: > # On branch master > # Changed but not updated: > # (use "git add ..." to update what will be committed) > # (use "git checkout -- ..." to discard changes in working directory) > # > # typechange: RelNotes git-diff shows > diff --git a/RelNotes b/RelNotes > new file mode 100644 > index 0000000..56c3863 > --- /dev/null > +++ b/RelNotes > ... // the whole contents of the file Both copies of the repository are on the branch master with the latest commit 07873dc. Simply diffing copies of the RelNotes file gives no output. What happened with the copied repository? I've found a couple of instances of the word 'typechange' in the source, but no mention in the docs. What does it mean and what could be the cause of this change? [1]: git://github.com/git/git.git -- Best regards, Alexei Sholik ``` ## Jeff King, 2011-03-14 18:39 Subject: Re: 'typechange' in the git-status output Message-ID: <20110314183947.GA21070@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110314183947.GA21070%40sigill.intra.peff.net In-Reply-To: ``` On Mon, Mar 14, 2011 at 08:29:57PM +0200, Alexei Sholik wrote: > But then, after copying the whole directory with 'cp -r' and running > git-status in the newly created directory, I get the following: "cp -r" isn't an exact copy. You probably want "cp -a" or at least "cp -rs". > > # On branch master > > # Changed but not updated: > > # (use "git add ..." to update what will be committed) > > # (use "git checkout -- ..." to discard changes in working directory) > > # > > # typechange: RelNotes Right. RelNotes is a symlink. But "cp -r" dereferences the symlink and copies the file contents themselves. > What happened with the copied repository? I've found a couple of > instances of the word 'typechange' in the source, but no mention in > the docs. What does it mean and what could be the cause of this > change? It's the same as the "T" flag in "git diff --name-status". Namely, the type of the file changed (between a symlink and a regular file). -Peff ``` ## Alexei Sholik, 2011-03-14 18:39 Subject: Re: 'typechange' in the git-status output Message-ID: URL: https://gitlist.dev/e/AANLkTikkHWFrjmrPMP_poxrkCwE34jqaFDbU1Roouw--%40mail.gmail.com In-Reply-To: ``` On 14 March 2011 20:29, Alexei Sholik wrote: > Hi git, > > I cloned git mirror from github[1]. When I run git-status in it's > working directory, I see no output. > > But then, after copying the whole directory with 'cp -r' and running > git-status in the newly created directory, I get the following: > >> # On branch master >> # Changed but not updated: >> #   (use "git add ..." to update what will be committed) >> #   (use "git checkout -- ..." to discard changes in working directory) >> # >> #     typechange: RelNotes > > git-diff shows > >> diff --git a/RelNotes b/RelNotes >> new file mode 100644 >> index 0000000..56c3863 >> --- /dev/null >> +++ b/RelNotes >> ... // the whole contents of the file > > Both copies of the repository are on the branch master with the latest > commit 07873dc. Simply diffing copies of the RelNotes file gives no > output. > > What happened with the copied repository? I've found a couple of > instances of the word 'typechange' in the source, but no mention in > the docs. What does it mean and what could be the cause of this > change? > > >  [1]: git://github.com/git/git.git > > -- > Best regards, > Alexei Sholik > Right, I've figured out the root of the change. 'ls -l' on the original RelNotes outputs: lrwxr-xr-x 1 alco staff 32 Mar 14 20:35 RelNotes -> Documentation/RelNotes/1.7.5.txt 'ls -l' on the copied RelNotes outputs: -rw-r--r-- 1 alco staff 1810 Mar 14 20:10 RelNotes So the problem is with the cp, not git. But I wonder if it is mentioned anywhere in the docs? Probably, git-clone's or git-status' manpage would be a proper place? -- Best regards, Alexei Sholik ``` ## Drew Northup, 2011-03-14 18:59 Subject: Re: 'typechange' in the git-status output Message-ID: <1300129161.13980.4.camel@drew-northup.unet.maine.edu> URL: https://gitlist.dev/e/1300129161.13980.4.camel%40drew-northup.unet.maine.edu In-Reply-To: ``` On Mon, 2011-03-14 at 20:39 +0200, Alexei Sholik wrote: > On 14 March 2011 20:29, Alexei Sholik wrote: > > Hi git, > > > > I cloned git mirror from github[1]. When I run git-status in it's > > working directory, I see no output. > > > > But then, after copying the whole directory with 'cp -r' and running > > git-status in the newly created directory, I get the following: > Right, I've figured out the root of the change. > > 'ls -l' on the original RelNotes outputs: > lrwxr-xr-x 1 alco staff 32 Mar 14 20:35 RelNotes -> > Documentation/RelNotes/1.7.5.txt > > 'ls -l' on the copied RelNotes outputs: > -rw-r--r-- 1 alco staff 1810 Mar 14 20:10 RelNotes > > So the problem is with the cp, not git. But I wonder if it is > mentioned anywhere in the docs? Probably, git-clone's or git-status' > manpage would be a proper place? Quoting Jeff King : > "cp -r" isn't an exact copy. You probably want "cp -a" or at least "cp > -rs". ..... > Right. RelNotes is a symlink. But "cp -r" dereferences the symlink and > copies the file contents themselves. As has been said more than a few times (and is probably somewhere in the docs), if you really want to duplicate a git repo you should probably be using git to do it. No change to the manpages is required here. -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 ``` ## Jonathan Nieder, 2011-03-14 19:22 Subject: Re: 'typechange' in the git-status output Message-ID: <20110314192238.GA30378@elie> URL: https://gitlist.dev/e/20110314192238.GA30378%40elie In-Reply-To: <1300129161.13980.4.camel@drew-northup.unet.maine.edu> ``` Hi, Drew Northup wrote: > As has been said more than a few times (and is probably somewhere in the > docs), if you really want to duplicate a git repo you should probably be > using git to do it. FWIW I don't agree with this advice. "cp -a" works perfectly well and I think that's a valuable thing. On the other hand, if you want to _back up_ or sneakernet a git repo, I agree that "git bundle create /path/to/backup.bundle --all" is better. Perhaps the user manual could explain this somewhere. Hope that helps, Jonathan ``` ## Jeff King, 2011-03-14 19:27 Subject: Re: 'typechange' in the git-status output Message-ID: <20110314192723.GA22434@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110314192723.GA22434%40sigill.intra.peff.net In-Reply-To: <20110314192238.GA30378@elie> ``` On Mon, Mar 14, 2011 at 02:22:38PM -0500, Jonathan Nieder wrote: > Hi, > > Drew Northup wrote: > > > As has been said more than a few times (and is probably somewhere in the > > docs), if you really want to duplicate a git repo you should probably be > > using git to do it. > > FWIW I don't agree with this advice. "cp -a" works perfectly well and > I think that's a valuable thing. Agreed. Note that "cp -a" really _duplicates_ a repo: refs, config, unreferenced objects, current packed state, etc. Using git to copy makes a clone, which is subtly different. So I don't think there is any reason to dissuade people from "cp -a" (cp without "-a", on the other hand, can be problematic as shown here). -Peff ``` ## Junio C Hamano, 2011-03-14 19:44 Subject: Re: 'typechange' in the git-status output Message-ID: <7vhbb5cwse.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vhbb5cwse.fsf%40alter.siamese.dyndns.org In-Reply-To: <20110314192238.GA30378@elie> ``` Jonathan Nieder writes: > On the other hand, if you want to _back up_ or sneakernet a git repo, > I agree that "git bundle create /path/to/backup.bundle --all" is > better. > > Perhaps the user manual could explain this somewhere. I agree "bundle" documentation would be a good place to show that "better" way. ```