The commit walker doesn't exist anymore

[iamwilhelm]

The repo commit walker doesn't exist anymore, and I had relied on it. Was this done because it was decided it doesn't belong in gitteh, or that simply we haven't gotten around to it after the refactor?

If it's the latter (that it simply hasn't been incorporated yet since the refactor), how tough is it to do? I was thinking I'd try my hand at it, if it didn't require knowing too much about native bindings (aka I could use the existing plumbing methods to write it).

Is there a particular signature the walker should support?

[samcday]

@iamwilhelm Closing as this is a duplicate of #26

As for implementing it yourself, I'd certainly welcome contributions for this! :) However note the implementation might be a little tricky, and would require some glue in the native (C++) code.

What I'm envisaging for the gitteh revwalk API is something like this:

You create a new RevWalker object using gitteh.revWalk().

RevWalker has the following methods available:

• push(ref) - accepts "HEAD" or a refname or an OID or a ref glob. returns the RevWalker instance called on.
• hide(ref) - accepts the same ref types as push(). returns the RevWalker instance called on.
• sort(type) - accepts the strings: "none" / "topological" / "time" / "reverse". Returns the RevWalker instance called on.
• start() - actually begins the revision walking.

At this point the RevWalker is active and the following methods may be called. Calling these when the RevWalker had not yet been start()ed would raise an Error.

• next() - returns the new walked OID.
• stop() - immediately aborts the rev walk. RevWalker is no longer usable and should be thrown away.

Internally the implementation is a little tricky, owing primarily to my (somewhat self-imposed) requirement to minimize calls into native code. I certainly do not want every call to next() calling into native code. Here's how I'd like to see it work:

Configuring the RevWalker (push/hide/sort) are all done in the userland CoffeeScript bridge. When start() is called the parameters are validated and finally we call into the native code.

The native code will allocate a new revwalker (acceptable for a first-pass implementation, but I will want to see allocated git_revwalk instances cached at some point), configure it with provided options, and then kick off the walk in the UV work pool. At this point though I want it to use UV threads. The idea is to walk the revisions in a tight-ish loop from the worker, using uv_async_send every so often to signal the main V8 loop that more data is available, at which point it's inserted into an array available to the RevWalk userland code internally.

^ ^ The above paragraph is a little hazy, I have to get to work and couldn't fully form my thoughts on this. The simple TLDR is I want no more than 1 call into native code for a rev-walk, at which point the rev walk kicks off asynchronously, sending oids to the main loop, and all remaining logic is encapulsated in the userland CoffeeScript code.

[iamwilhelm]

It seems like work is already being done on it, since #26 seems closed. Is that the case?

[samcday]

@iamwilhelm, @andreypopp has done some excellent looking work to provide a userland version of rev walking, but there are still plans to implement one using the native libgit2 provided functionality in gitteh itself.