Note that I couldn't run the online tests, because lack of documentation (and, agreed, unwillingness to try). If someone has any pointers, I'm listening ;-). EDIT: especially since Travis hates me now.

I plan on working on push some more, so if someone provides me with a list of things to fix, that'll be a start. What I have on my mind at the moment is :

• look at progress reporting for local pushes,
• try to move the callbacks push uses back to git_remote_callbacks.

cc @carlosmn

This moves in a good direction, but I don't think it goes far enough. Since we're putting the push refspecs into the remote, we should get rid of the git_push object completely and make the workflow for pushing be adding push refspecs and calling git_remote_push(), analogous to how we perform a fetch. The callbacks would go to live in the same struct as the rest.

The reporting for the local "transport" should be part of a different PR, otherwise it's going to get confusing.

@tiennou take a look at the first few lines of script/cibuild which sets up the environment for pushing. All you need is a bare repository and a git-daemon serving it.

Heh, I wasn't sure how'd you react to a "public" API removal (especially since I wasn't sure what your point on refspecs meant on #2136).

Bringing git_push under the remote namespace is my "long-term" objective, but I planned to do that in little steps. I guess I'll do the local transport reporting once that's done (since it's already missing anyway). So do you prefer me to use that PR as the main "rework push" thing (meaning I'll keep on piling commits until git_push is no more) ?

The only thing I'm still curious about is the "refs/heads/master:" refspecs that were used in the tests; are those "standard", or a convenience thing that I kill when simplyfing refspec parsing ?

Yeah, you can do multiple commits that go towards removing git_push, but those should all go in together, and be part of this PR.

Refspecs allow for many shorthands. and they're asymmetrical on the fetch and push side. I don't recall off-hand what refs/heads/master: means, but it does look a bit off. A colon at the end does not look right, but we should make sure of how it got there and check git's documentation as well as its behaviour.

Tests "fixed". The quotes are there because even though I know what refs/heads/master: means now (means fetch the reference but don't create a tracking branch, and it's invalid for a push refspec), I've found one nugget that I can't grasp (and neither can Core Git), so I'm disabling that one test for now.

What's preferable ? Removing git_push entirely by moving its functions under the remote namespace, or just making it private ? I feel like the second one would be cleaner (akin to how fetch is done)...

Sorry, forgot to answer.

We can incrementally build towards the removal of git_push. As a first step, I'd say to remove git_push from the public API and make git_remote_push() use it by copying the configured push refspecs and setting the callbacks as they appear on the remote. Something like

int git_remote_push(git_remote *remote)
{
    git_push_new();
    git_push_add_refspec(<from git_remote_get_push_refspecs()>);
    git_push_set_callbacks(<from remote.callbacks>);
   git_push_finish();
}

We can then remove the git_push struct and make the code live under the remote directly.