diff options
| author | Junio C Hamano <junkio@cox.net> | 2006-03-31 07:59:19 (GMT) |
|---|---|---|
| committer | Junio C Hamano <junkio@cox.net> | 2006-03-31 07:59:19 (GMT) |
| commit | 4c0fea0f1116a4c782696a3e4cf2db31a4aa8adc (patch) | |
| tree | fae5649e9530a45686568431bc49871f509dd4a3 /mktag.c | |
| parent | b4a081b428c607f98c5d0a0eec8d543dc1f2abcd (diff) | |
| download | git-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 'mktag.c')
0 files changed, 0 insertions, 0 deletions