aboutsummaryrefslogtreecommitdiff
path: root/t
diff options
context:
space:
mode:
authorAndy Parkins <andyparkins@gmail.com>2007-01-22 10:56:27 +0000
committerJunio C Hamano <junkio@cox.net>2007-01-24 23:38:55 -0800
commit535514f1f3cd32dfe2cb4c70e97b41ea868d1134 (patch)
tree31c7c2c4e7799819fd4cf21baa1a471344ee3fb5 /t
parent5dee29ac0fc95999a42c5cbac767724a9ff73cfa (diff)
downloadgit-535514f1f3cd32dfe2cb4c70e97b41ea868d1134.tar.gz
git-535514f1f3cd32dfe2cb4c70e97b41ea868d1134.tar.xz
New files in git weren't being downloaded during CVS update
If a repository was checked out via git-cvsserver and then later a new file is added to the git repository via some other method; a CVS update wasn't fetching the new file. It would be reported as a new file as A some/dir/newfile.c but would never appear in the directory. The problem seems to be that git-cvsserver was treating these two cases identically, as "A" type results. 1. New file in repository 2. New file locally In fact, traditionally, case 1 is treated as a "U" result, and case 2 only is treated as an "A" result. "A", should just report that the file is added locally and then skip that file during an update as there is (of course) nothing to send. In both these cases there is no working revision, so the checking for "is there no working revision" will return true. The test for case 2 needs refining to say "if there is no working revision and no upstream revision". This patch does just that, leaving case 1 to be handled by the normal "U" handler. I've also updated the log message to more accurately describe the operation. i.e. that "A" means that content is scheduled for addition; not that it actually has been added. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 't')
0 files changed, 0 insertions, 0 deletions