rm and add, but not rename, of identical files

rm and add, but not rename, of identical files

[Drew Northup]

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 <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." 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 <file>..." 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 <file>..." 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 <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." 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

Re: rm and add, but not rename, of identical files

[Andreas Schwab]

Drew Northup <drew.northup@maine.edu> 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."

Re: rm and add, but not rename, of identical files

[Junio C Hamano]

Drew Northup <drew.northup@maine.edu> writes:

> # Untracked files:
> #   (use "git add <file>..." 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 <file>..." 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?

Re: rm and add, but not rename, of identical files

[Drew Northup]

On Wed, 2012-10-10 at 14:47 -0700, Junio C Hamano wrote:
> Drew Northup <drew.northup@maine.edu> writes:
> 
> > # Untracked files:
> > #   (use "git add <file>..." 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 <file>..." 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 <File> & etckeeper vcs
rm <File> 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

Re: rm and add, but not rename, of identical files

[Junio C Hamano]

Drew Northup <drew.northup@maine.edu> writes:

> On Wed, 2012-10-10 at 14:47 -0700, Junio C Hamano wrote:
>> Drew Northup <drew.northup@maine.edu> writes:
>> 
>> > # Untracked files:
>> > #   (use "git add <file>..." 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 <file>..." 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 <File> & etckeeper vcs
> rm <File> 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.