I support changing 3.0 (git) to use a bundle. Besides closing the bugs mentioned in this thread, a bundle consists of a simple header + a standard git pack. Since git packs are used as a wire format, this provides better assurance that future versions of git will retain compatability with the source packages. Also, being able to directly clone a bundle file is a great feature. The only thing I would miss from this version of the format is that when unpacked, it would not include remotes information, and so remotes would need to be manually added if you wanted to 'git pull' to get newer commits etc. I suppose that the remotes info could be added into the source format in some other way however. Johan Kiviniemi wrote: > git for-each-ref --format='%(refname)' | \ > grep -Ev '^refs/(remotes/|stash$)' | \ > xargs -d'\n' git bundle create ../PKG_VER.git-bundle HEAD You forgot to drop bisect refs. Also, if there are a *lot* of refs, xargs may run git-bundle repeatedly; subsequent runs will happily overwrite the bundle. So I suggest: git bundle create ../bundle $(git for-each-ref --format='%(refname)' | egrep -v '^refs/(remotes/|bisect/|stash$)') This still has the potential problem of failing if there are >20kb worth of ref information. Probably the right fix for that limit is to patch git-bundle so it can read the refs from stdin, as git-pack-objects already does. Russ Allbery wrote: > It is when package maintainers orphan packages and rm -rf all their Git > repositories, such as just happened recently with a pile of Debian > packages. If those packages had been 3.0 (git) packages, a new maintainer > would be in much better shape. Even when package orphaners are careful to preserve their git repos, it can be easy for them to be dropped in transition to the new maintainer. (See for example: uqm.) -- see shy jo
Attachment:
signature.asc
Description: Digital signature