The short answer is that you can't—well, not quite. Essentially, git bundle is the server half of a git fetch: it builds a file that you literally hand over to git fetch later, when you have transported that file from the server to the client. The client needs that file to contain the kind of data that the server would pass to the client.
The result is that the bundle file must contain:
- a list of reference names and their hash IDs, plus
- the objects that
git fetch would get based on those hash IDs, minus
- the objects that
git fetch would not need based on the client's "I already have ..." hash IDs.
When preparing the bundle, the arguments you supply are:
- the reference names, and
- the basis hash IDs that the client would have provided, had the client been able to connect directly.
Nowhere in this list of things-you-provide is there the ability to use rev^@-style references.
What you can do
What you can do is attach reference names to each of those heads:
for parent in $(git rev-parse ${rev}^@); do
git tag bundle-p$parent $parent
done
Now you have actual reference names (lightweight tags) pointing to each of the commits that you do want to include in the bundle. You can now supply --tags='bundle-p*' as a set of positive refs, assuming there are no other tags that begin with bundle-p. (You can delete the tags afterward to maintain this invariant. You can use branch names instead, with --branches='bundle-p*', if that's more convenient for you.)
(Be aware that ${rev}^@ will produce no output when applied to a root commit. This means there will be no bundle-p* tags for this case.)
If your particular stop-point is an ordinary (single-parent) commit, you can just attach a single reference name to ${rev}^. In all cases, you must attach a reference name to the end-point commits that you do want to have in the bundle.
