http-push updates
cover http-push updates
This series fixes a few http transport and http-push bugs, includes some refactoring, and adds functionality to update remote server info/refs.
I'm considering future support for initializing a remote repo if the remote url points to an empty directory and the --force arg is present. Any thoughts?
I'm also planning to add support for using packs to send updates, and for updating remote server objects/info/packs. I'm not sure whether it makes sense to always send packs or to only do so when enough objects need to be pushed.
Signature · 2 lines
For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.
Quoted 3 lines · Nick Hengeveld
I'm considering future support for initializing a remote repo if the remote url points to an empty directory and the --force arg is present. Any thoughts?
Repository maintenance tasks:
- create a new repository
- create new branch (and new tag) -- I think you can already do this
- remove an unneeded branch and tag
- (perhaps) running update-server-info
- running repack
Quoted 4 lines
I'm also planning to add support for using packs to send updates, and for updating remote server objects/info/packs. I'm not sure whether it makes sense to always send packs or to only do so when enough objects need to be pushed.
If you have repack support somehow, always sending packs (especially the thin kind) would make sense, but otherwise you probably would want some arrangements to make sure many small packs are periodically consolidated into larger smaller number of packs, so that they would not fragment the vma of git programs that run on the server side by mmap()ing them into their address spaces.
Quoted 5 lines · Junio C Hamano
Repository maintenance tasks:
- create a new repository
- remove an unneeded branch and tag
- running repack
In a DAV-only server environment, it seems like there are a few options for supporting these tasks:
- extend http-push with additional args and/or local config settings. This approach would be more efficient wrt packs than separate push and repack steps since packs will all need to be created locally and then sent; a combined repack/push operation would mean that new objects will only be sent once as part of a pack.
- add DAV versions of git-init-db/git-branch/git-repack
- extend git-init-db/git-branch/git-repack to be DAV-aware
I like option #1.
Quoted 1 line
- create new branch (and new tag) -- I think you can already do this
Right - you can create locally and then push that branch/tag or --all/--tags.
Quoted 1 line
- (perhaps) running update-server-info
http-push already updates info/refs if it existed before the push (perhaps that behavior should also be based on a local config setting.) I would plan to add support for updating objects/info/packs along with pack/repack support. That should be all the server-info there is to update, right?
Signature · 2 lines
For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.