# rm and add, but not rename, of identical files 5 messages from 2012-10-10 to 2012-10-11. Participants: Drew Northup, Andreas Schwab, Junio C Hamano. Thread: https://gitlist.dev/t/31783 ## Drew Northup, 2012-10-10 18:39 Subject: rm and add, but not rename, of identical files Message-ID: <1349894347.32696.10.camel@drew-northup.unet.maine.edu> URL: https://gitlist.dev/e/1349894347.32696.10.camel%40drew-northup.unet.maine.edu ``` I use etckeeper on some of my systems, backed by Git. On a system still using a SYSV style init I recently modified my iptables settings, changing which runlevels would stop/start the firewall. [root@drew-northup ~]# etckeeper vcs status # On branch master # Changes not staged for commit: # (use "git add/rm ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: inittab # deleted: rc.d/rc2.d/K92iptables # deleted: rc.d/rc3.d/K92iptables # deleted: rc.d/rc4.d/K92iptables # deleted: rc.d/rc5.d/K92ip6tables # modified: sysconfig/ip6tables # # Untracked files: # (use "git add ..." to include in what will be committed) # # rc.d/rc2.d/S08iptables # rc.d/rc3.d/S08iptables # rc.d/rc4.d/S08iptables # rc.d/rc5.d/S08ip6tables no changes added to commit (use "git add" and/or "git commit -a") It detects the changes as renames however—which in this case isn't appropriate: [root@drew-northup ~]# etckeeper vcs status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # renamed: rc.d/rc2.d/K92iptables -> rc.d/rc2.d/S08iptables # renamed: rc.d/rc3.d/K92iptables -> rc.d/rc3.d/S08iptables # renamed: rc.d/rc4.d/K92iptables -> rc.d/rc4.d/S08iptables # renamed: rc.d/rc5.d/K92ip6tables -> rc.d/rc5.d/S08ip6tables # # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: inittab # modified: sysconfig/ip6tables # Is there something I should be doing to suppress rename detection in this case? (I presume changing the default—detecting as a rename—isn't such a bright idea.) [root@drew-northup ~]# etckeeper vcs --version git version 1.7.11.3 -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 ``` ## Andreas Schwab, 2012-10-10 20:09 Subject: Re: rm and add, but not rename, of identical files Message-ID: URL: https://gitlist.dev/e/m2wqyyw0l0.fsf%40igel.home In-Reply-To: <1349894347.32696.10.camel@drew-northup.unet.maine.edu> ``` Drew Northup writes: > It detects the changes as renames however—which in this case isn't > appropriate: Why is that a problem? A rename is just something which is computed on the fly for display purpose, the repository only stores a snapshot of the resulting tree. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ``` ## Junio C Hamano, 2012-10-10 21:47 Subject: Re: rm and add, but not rename, of identical files Message-ID: <7v1uh6atjl.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v1uh6atjl.fsf%40alter.siamese.dyndns.org In-Reply-To: <1349894347.32696.10.camel@drew-northup.unet.maine.edu> ``` Drew Northup writes: > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # rc.d/rc2.d/S08iptables > # rc.d/rc3.d/S08iptables > # rc.d/rc4.d/S08iptables > ... > no changes added to commit (use "git add" and/or "git commit -a") > > It detects the changes as renames however―which in this case isn't > appropriate: > > [root@drew-northup ~]# etckeeper vcs status > # On branch master > # Changes to be committed: > # (use "git reset HEAD ..." to unstage) > # > # renamed: rc.d/rc2.d/K92iptables -> rc.d/rc2.d/S08iptables > # renamed: rc.d/rc3.d/K92iptables -> rc.d/rc3.d/S08iptables > # renamed: rc.d/rc4.d/K92iptables -> rc.d/rc4.d/S08iptables > #... Given that all of these six files have the same contents, I actually am slightly impressed how well Git matched them up ;-). But more seriously, why do you have rc.d/rc2.d/S08iptables untracked in the working tree but in the index to be committed? ``` ## Drew Northup, 2012-10-11 15:10 Subject: Re: rm and add, but not rename, of identical files Message-ID: <1349968240.32696.22.camel@drew-northup.unet.maine.edu> URL: https://gitlist.dev/e/1349968240.32696.22.camel%40drew-northup.unet.maine.edu In-Reply-To: <7v1uh6atjl.fsf@alter.siamese.dyndns.org> ``` On Wed, 2012-10-10 at 14:47 -0700, Junio C Hamano wrote: > Drew Northup writes: > > > # Untracked files: > > # (use "git add ..." to include in what will be committed) > > # > > # rc.d/rc2.d/S08iptables > > # rc.d/rc3.d/S08iptables > > # rc.d/rc4.d/S08iptables > > ... > > no changes added to commit (use "git add" and/or "git commit -a") > > > > It detects the changes as renames however―which in this case isn't > > appropriate: > > > > [root@drew-northup ~]# etckeeper vcs status > > # On branch master > > # Changes to be committed: > > # (use "git reset HEAD ..." to unstage) > > # > > # renamed: rc.d/rc2.d/K92iptables -> rc.d/rc2.d/S08iptables > > # renamed: rc.d/rc3.d/K92iptables -> rc.d/rc3.d/S08iptables > > # renamed: rc.d/rc4.d/K92iptables -> rc.d/rc4.d/S08iptables > > #... > > Given that all of these six files have the same contents, I actually > am slightly impressed how well Git matched them up ;-). > > But more seriously, why do you have rc.d/rc2.d/S08iptables untracked > in the working tree but in the index to be committed? Missing steps in the mail body: etckeeper vcs add & etckeeper vcs rm commands. I pared it back to the absolute minimum. Is that what you're asking about? -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 ``` ## Junio C Hamano, 2012-10-11 16:53 Subject: Re: rm and add, but not rename, of identical files Message-ID: <7v4nm17xxj.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v4nm17xxj.fsf%40alter.siamese.dyndns.org In-Reply-To: <1349968240.32696.22.camel@drew-northup.unet.maine.edu> ``` Drew Northup writes: > On Wed, 2012-10-10 at 14:47 -0700, Junio C Hamano wrote: >> Drew Northup writes: >> >> > # Untracked files: >> > # (use "git add ..." to include in what will be committed) >> > # >> > # rc.d/rc2.d/S08iptables >> > # rc.d/rc3.d/S08iptables >> > # rc.d/rc4.d/S08iptables >> > ... >> > no changes added to commit (use "git add" and/or "git commit -a") >> > >> > It detects the changes as renames however―which in this case isn't >> > appropriate: >> > >> > [root@drew-northup ~]# etckeeper vcs status >> > # On branch master >> > # Changes to be committed: >> > # (use "git reset HEAD ..." to unstage) >> > # >> > # renamed: rc.d/rc2.d/K92iptables -> rc.d/rc2.d/S08iptables >> > # renamed: rc.d/rc3.d/K92iptables -> rc.d/rc3.d/S08iptables >> > # renamed: rc.d/rc4.d/K92iptables -> rc.d/rc4.d/S08iptables >> > #... >> >> Given that all of these six files have the same contents, I actually >> am slightly impressed how well Git matched them up ;-). >> >> But more seriously, why do you have rc.d/rc2.d/S08iptables untracked >> in the working tree but in the index to be committed? > > Missing steps in the mail body: etckeeper vcs add & etckeeper vcs > rm commands. I pared it back to the absolute minimum. > > Is that what you're asking about? Yes. Without the "add" step, detecting the K92iptables that has been moved to an untracked S08iptables as rename looked like a magic (read: bug) to me, and that was why I asked. Aren't K92iptables and S08iptables the same script with case "$1" in start) ... start thing ...;; stop) ... stop thing ...;; esac in it? On Debian, these S/K files appear directly under /etc without intermediate rc.d level, and they are symbolic links to real files in /etc/init.d/, so extrapolating from that knowledge and with a bit of imagination that some systems might keep copies of these files instead of linking to the same thing, I would actually find it desireable to call the move from K92iptables to S08iptables a rename, rather than reporting a removal and a addition of unrelated files. ```