author | Junio C Hamano <junkio@cox.net> | |
Fri, 31 Mar 2006 07:59:19 +0000 (23:59 -0800) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Fri, 31 Mar 2006 07:59:19 +0000 (23:59 -0800) | ||
commit | 4c0fea0f1116a4c782696a3e4cf2db31a4aa8adc | |
tree | fae5649e9530a45686568431bc49871f509dd4a3 | tree | snapshot |
parent | b4a081b428c607f98c5d0a0eec8d543dc1f2abcd | commit | diff |
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>
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>
revision.c | diff | blob | history |