summaryrefslogtreecommitdiff
path: root/submodule.c
diff options
context:
space:
mode:
authorJens Lehmann <Jens.Lehmann@web.de>2010-03-12 21:23:52 (GMT)
committerJunio C Hamano <gitster@pobox.com>2010-03-13 06:17:24 (GMT)
commit85adbf2f751a91429de6b431c45737ba9d7e9e00 (patch)
tree26535fe961ff33d741746167c8fd6f851a0bd8a4 /submodule.c
parentae6d5c1b6f78ef48f606e5a267915fa31b37a679 (diff)
downloadgit-85adbf2f751a91429de6b431c45737ba9d7e9e00.zip
git-85adbf2f751a91429de6b431c45737ba9d7e9e00.tar.gz
git-85adbf2f751a91429de6b431c45737ba9d7e9e00.tar.bz2
git status: Fix false positive "new commits" output for dirty submodules
Testing if the output "new commits" should appear in the long format of "git status" is done by comparing the hashes of the diffpair. This always resulted in printing "new commits" for submodules that contained untracked or modified content, even if they did not contain new commits. The reason was that match_stat_with_submodule() did set the "changed" flag for dirty submodules, resulting in two->sha1 being set to the null_sha1 at the call sites, which indicates that new commits are present. This is changed so that when no new commits are present, the same object names are in the sha1 field for both sides of the filepair, and the working tree side will have the "dirty_submodule" flag set when appropriate. For a submodule to be seen as modified even when it just has a dirty work tree, some conditions had to be extended to also check for the "dirty_submodule" flag. Unfortunately the test case that should have found this bug had been changed incorrectly too. It is fixed and extended to test for other combinations too. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'submodule.c')
0 files changed, 0 insertions, 0 deletions