reassign 410325 git-core thanks Dear git maintainer, it seems there can be leftover (untracked) files after a rename that happened during a recursive merge. Is this intentional? If so git_load_dirs would have to call 'git-clean' explicitly after the merge which looks strange (at least when merging to '.'). Example (based on input provided by Arnaud Cornet) below:
On Fri, Feb 09, 2007 at 11:13:45PM +0100, Arnaud Cornet wrote: > Hi Guido, > > On ven, fév 09, 2007 at 09:07:56 +0100, Guido Guenther wrote: > > Could you send me the git repo and the tarball via private mail or an > > URL to clone from to reproduce this? Removals do work fine here (tried > > that with dozens of packages). > > Actually I was a bit wrong in my bug: in the git repo everything is ok. > The problem is only in the workdir, in which a deleted file is still > present after git-import-orig. the problem seems to be in "git pull" itself. After merging the upstream branch to master the file 'src/mpi.c' gets renamed to 'src/bignum.c' by git as it should, but the old file (src/mpi.c) isn't being removed from the checked out copy. This is the shortest way to reproduce this (I commented all output and all comments with '#' so it can be used as a script): # preparation: apt-get source libxyssl-dev wget http://xyssl.org/code/download/xyssl-0.4.tgz # create a new repo 'xyssl' with 'master' and 'upstream' branch: git-import-dsc xyssl_0.3-1.dsc # umpack the new upstream version to import: tar zcf xyssl-0.4.tgz cd xyssl git-checkout upstream # this imports the new xyssl onto the 'upstream' branch. The file # 'src/mpi.c' is removed via 'git rm' and 'src/bignum.c' is added via # 'git add' (as can be seen from git_load_dirs output): git_load_dirs -v ../xyssl-0.4 git-status # nothing to commit ls src/bignum.c src/mpi.c #ls: src/mpi.c: No such file or directory #src/bignum.c # ...so mpi.c is gone on 'upstream' as it should be git checkout master ls src/bignum.c src/mpi.c #ls: src/bignum.c: No such file or directory #src/mpi.c # ...mpi.c still exists on 'master' git pull . upstream # rename src/{mpi.c => bignum.c} (67%) # ...so the recursive merge detects the rename, but: # Untracked files: # (use "git add" to add to commit) # # src/mpi.c So shouldn't 'git-pull' remove src/mpi.c after it detects the rename? Cheers, -- Guido > > I'm attaching a log of what to do to reproduce the bug. The two removed > files in the 0.4 tarball are mpi.c and mpi.h. > > See the log line 380, the file src/mpi.c is "renamed", where as > src/mpi.h is "deleted" (line 384). src/mpi.h is deleted in the workdir > but src/mpi.c is still here. > > I still think it's a small bug. > > Regards, > -- > Arnaud Cornet
