Method to write messages to git client #10

Open
wants to merge 4 commits into
from

Projects

None yet

6 participants

@dz0ny
dz0ny commented Aug 19, 2012 edited

This change is Reviewable

@travisbot

This pull request passes (merged 272bb8a into 582528b).

@travisbot

This pull request passes (merged d3603d1 into 582528b).

@substack
Owner

I like this functionality but am not quite set on the api proposed here. I'm particularly weary that 'push' is getting too many parameters. How about this:

repos.on('push', function (push) {
    console.log([ push.repo, push.commit, push.branch ].join('/'));
    push.write('beep boop\n');
    push.end();
})
@dz0ny
dz0ny commented Aug 20, 2012

Hm that would be mixing two things together (info about push, and server interface). How about

repos.on('push', function (push, res) {
    console.log([ push.repo, push.commit, push.branch ].join('/'));
    if(something not right){
      res.write('beep boop'); // newline is not needed, because git client won't respect it.
      res.end();  // or res.end("master power");
    }else{
      res.error("you can't do this");
    }

})

This would be similar to "connect" way of handling of the requests. Also developer might want to write error message(packed differently), or some custom implementation of git client. What do you think?

res object

{
  stream // raw connect stream
  write(string){...} //helper method, write message
  error(string){...} //helper method, write error message and terminate connection
  end(string){...}  //helper method, write message and terminate connection
}

Git defines three types of "Smart git protocol" packets see https://github.com/git/git/blob/master/sideband.c

  • \1 is used by git itself for c&c
  • \2 verbose messages (currently used)
  • \3 error messages (not implemented)
@travisbot

This pull request passes (merged 31dbab1 into 582528b).

Janez Troha fixing docs 76e95f5
@travisbot

This pull request passes (merged 76e95f5 into 582528b).

@travisbot

This pull request passes (merged 68055893 into 582528b).

@travisbot

This pull request passes (merged 8cf0b36 into 582528b).

@substack
Owner

I just did a big refactor to split out the push events from the fetches from the infos for more granularity in accepting or rejecting requests. After toying with this patch some it would be nice for the messages on the duplexed objects to go through this serialization routine and the pieces that need raw access can skip ahead to the dup.response object for unfiltered writes. I will experiment more with this after I implement subdirectories.

@contra
contra commented Dec 12, 2012

bump - does anybody have a solution for this on the latest version?

@contra
contra commented Dec 13, 2012

@substack @dz0ny - I ended up implementing this myself but I'm running into issues. The first few messages get sent fine but once I .accept() something in process.nextTick is closing the stream. Blocking out "0000" from buffers coming from the git process causes the git client to stay open but any messages sent after it should have closed are still ignored. Any ideas why .accept() is messing up outbound writes? I haven't tested this version but I suspect if you setTimeout(writeAMessage, 1000) after doing an accept you'll notice the same thing.

@qrpike
qrpike commented Apr 22, 2013

Any updates on this?

@substack
Owner

This side channel logic has been ported into git-http-backend. Once I get pushover using git-http-backend this should be fixed.

@rmg rmg referenced this pull request in strongloop/strong-pm Oct 31, 2014
Closed

Clarification on Strong-PM Config #45

@mindeavor

Any updates on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment