-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve push command, kill the queue #104
Comments
How much data are we talking? More than an in-memory map and writing to disk with |
We may be good with just a simple key/value map. The key should be based on the filename. If a filename is queued again, we can just update that key's value. The last 3 items just depend on the ability to figure out what is being pushed, so we can look around for git media blobs. |
One other option: Change push so it requires the remote and branch (which should be provided by the pre-push hook. The pre-push hook gets this in STDIN:
We can get this easily with:
|
Easy, yes, but don't forget that |
It seems to me that instead of recording the filename, it would be more robust and easier to handle the SHA-1 of the blob representing the pointer file. If and only if that blob has to be pushed to the git server, then the corresponding git-media blob has to be pushed to the media server. |
Ok, I'm leveling up my git game here, want to check in to make sure I'm on the right track. Here's a scenario: I've got 3 commits I want to push and sync, Now, I want to figure out what objects it's about to push so I know what to sync. I know that I could do Does that sound legit? Is there a better way to get that list? |
then the hook script will get
and your (Actually, your command would fail because
. But you know what I mean.) AFAIK there is no way to get at the information you want (namely, the list of objects being newly pushed to the remote) without either hacking git or duplicating git's negotiation with the remote server 😦 Essentially you would need to know the value of all of the remote server's references before your push. Maybe @peff knows a trick. |
This should work, right?
If we're pushing a new branch, we'd want to find the nearest ref (probably master, but it'd depend on where the push originated from). @rubyist: Having a "dry run" option would be useful here. Have |
In the case of a new branch where git really is pushing all of the objects, we can only know whether or not we should sync a git media file by asking the git media server. The git media server should already prevent uploading a full blob it already knows about, so maybe it's OK to use the full list that We'll definitely add a |
There's not really a trick here. The closest simple thing is probably
You can get closer with:
That's still not quite right. The server side of a push may advertise slightly more refs than Git doesn't actually do any other fancy negotiation to find common refs during a push, like it does for a fetch. The assumption is that you're typically building on what the other side has, so one of their refs should be a subset of what you already have. That could change in the future, but I don't think anybody has ever proposed to make it so. |
@peff, does the server also report peeled versions of tags? It sounds like a Though really, it is a shame to have to run |
@mhagger Yeah, I never noticed that, but we don't advertise peeled tags for pushes. Another issue: I agree that |
It's time to beef up the queue.
These features are too much for the
queuedir
package. It'd be awesome to find a good Go based k/v store that'll work cross compiled to every platform.Fixes #82 and #99. /cc #102 (comment)
The text was updated successfully, but these errors were encountered: