summaryrefslogtreecommitdiff
path: root/revision.h
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2006-03-31 07:59:19 (GMT)
committerJunio C Hamano <junkio@cox.net>2006-03-31 07:59:19 (GMT)
commit4c0fea0f1116a4c782696a3e4cf2db31a4aa8adc (patch)
treefae5649e9530a45686568431bc49871f509dd4a3 /revision.h
parentb4a081b428c607f98c5d0a0eec8d543dc1f2abcd (diff)
downloadgit-4c0fea0f1116a4c782696a3e4cf2db31a4aa8adc.zip
git-4c0fea0f1116a4c782696a3e4cf2db31a4aa8adc.tar.gz
git-4c0fea0f1116a4c782696a3e4cf2db31a4aa8adc.tar.bz2
rev-list --boundary: fix re-injecting boundary commits.
Marco reported that $ git rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d misses these two boundary commits. c649657501bada28794a30102d9c13cc28ca0e5e eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4 Indeed, we can see that gitk shows these two commits at the bottom, because the --boundary code failed to output them. The code did not check to avoid pushing the same uninteresting commit twice to the result list. I am not sure why this fixes the reported problem, but this seems to fix it. Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'revision.h')
0 files changed, 0 insertions, 0 deletions