On 07/17, Brandon Williams wrote: > Signed-off-by: Brandon Williams <bmw...@google.com> > --- > > Since introducing protocol v2 and enabling fetch I've been thinking > about what its inverse 'push' would look like. After talking with a > number of people I have a longish list of things that could be done to > improve push and I think I've been able to distill the core features we > want in push v2. Thankfully (due to the capability system) most of the > other features/improvements can be added later with ease. > > What I've got now is a rough design for a more flexible push, more > flexible because it allows for the server to do what it wants with the > refs that are pushed and has the ability to communicate back what was > done to the client. The main motivation for this is to work around > issues when working with Gerrit and other code-review systems where you > need to have Change-Ids in the commit messages (now the server can just > insert them for you and send back new commits) and you need to push to > magic refs to get around various limitations (now a Gerrit server should > be able to communicate that pushing to 'master' doesn't update master > but instead creates a refs/changes/<id> ref). > > Before actually moving to write any code I'm hoping to get some feedback > on if we think this is an acceptable base design for push (other > features like atomic-push, signed-push, etc can be added as > capabilities), so any comments are appreciated. > > Documentation/technical/protocol-v2.txt | 76 +++++++++++++++++++++++++ > 1 file changed, 76 insertions(+)
Pinging this thread again to hopefully reach some more people for commentary. Looking back through the comments so far there are concerns that a server shouldn't be trusted rewriting my local changes, so to address that we could have the be a config option which is defaulted to not take changes from a server. Apart from that I didn't see any other major concerns. I'm hoping to get a bit more discussion going before actually beginning work on this. -- Brandon Williams
