pack-objects and rev-list status updates
- From
Junio C Hamano <junkio@cox.net>
- Date
- Sep 6, 2006, 09:38 UTC
- Message-ID
- <7vveo172t3.fsf@assigned-by-dhcp.cox.net>
Tonight's "master" has an update to teach git-rev-list to read list of rev arguments from its standard input. We owe Andy Whitcroft a big credit for starting this topic.
This required splitting out part of setup_revision() and make it callable from the side. Thanks to this split, it got a lot easier to teach pack-objects to do a similar trick. I did a few:
- Earlier patch I sent to give command line parameters similar to rev-list to pack-objects was reworked on. I chose to feed rev arguments from its standard input; so
echo master..next | pack-objects --revs --stdout
would do what you would expect.
- A patch before that one to add --unpacked=<existing pack> option was resurrected and further reworked on. Now you can say,
rev-list --objects --unpacked=$active --all |
pack-objects $newand/or
pack-objects --unpacked=$active --all $new </dev/null
The </dev/null at the end is ugly but the command always reads from its standard input. Unlike the "something like this?" patch, this version can take more than one such "pretend things in these packs are unpacked" arguments.
- I also told pack-objects to understand --thin, so you can do a thin pack this:
echo master..next | pack-objects --thin --stdout
The equivalent expressed in the old way is:
rev-list --objects-edge master..next |
pack-objects --stdoutNote that --thin is only usable with --stdout, as before.
Andy has a patch to use "rev-list --stdin" to lift the exec arguments limit from send-pack; I tweaked it slightly and tested it minimally. I think the logical next step would be to use "pack-objects --stdin" there and lose another pipe and a process.
We also should be able to do the same for upload-pack. Now the groundwork is more or less done, I think this is a good exercise for a wannabe git hacker. Hint hint...
I do not expect to be working on git tomorrow (Wednesday my time), so I will not be merging any of the above (except the "rev-list --stdin" change) in "next" tonight (eh, it is already Wednesday wee morning), but they will appear in "pu".