3 ms·

This is tangential, but given the increasing functionality and maturity of libgit2, I wonder if it would yet be feasible to replace the Git command-line program

This is tangential, but given the increasing functionality and maturity of libgit2, I wonder if it would yet be feasible to replace the Git command-line program with a new one based on libgit2, and written to be as portable as libgit2. Then there would be just one Git implementation, across the command line, GUIs, and web-based services like GitHub. Also, the new CLI could run natively on Windows, without MSYS.

solutionyogi 11y ago
That is my dream. Right now, many Windows GUIs (SmartGit/SourceTree) use 'git.exe' to manage the actual Git repositories. If libgit2 is fully mature, I can imagine more GUIs/tools will be built to manage/analyze the git repositories.
- leonardinius 11y ago
  I believe github windows client is going that route https://github.com/blog/1127-github-for-windows https://github.com/blog/1127-github-for-windows. I also remember some blog post going into sync/async details of git.exe vs libgit2 stuff. Will try to google it.
  - MarkSweep 11y ago
    This is the article you speak of: http://githubengineering.com/git-concurrency-in-github-desktop/ http://githubengineering.com/git-concurrency-in-github-deskt... The AsyncReaderWriterLock mentioned in blog does not directly show up in Google, but it appears to be based on the one in this blog post: http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/building-async-coordination-primitives-part-7-asyncreaderwriterlock.aspx http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/building-...
- dan15 11y ago
  > Right now, many Windows GUIs (SmartGit/SourceTree) use 'git.exe' to manage the actual Git repositories. For what it's worth, all of the Git functionality in Visual Studio uses libgit2.
shazow 11y ago
While I think the libgit2 initiative is fantastic, I don't think there needs to be just one Git implementation. One of my favourite things about git is that the underlying storage and protocol is really simple and straight-forward to implement. You could do a lot of it in shell scripts, if you wanted to. The stateless storage is simple and consistent, but the thing that does vary is the various operating algorithms: diff, merge, garbage collection, etc. This creates a really interesting ecosystem where you could potentially have third-party tools that have some secret sauce producing more efficient diffs or fewer conflicting merges but still base it entirely on the open git ecosystem and remain completely backwards-compatible with all the other tooling.
- s73v3r 11y ago
  No matter how simple and straight-forward it is, someone is going to fuck it up. And they're going to do so in a way that isn't immediately detectable, but screws the rest of the company because now they have to support something using the screwed up implementation.
  - simoncion 11y ago
    Git has a bunch of tests [0]. I expect that not all of them are git-the-official-CLI-specific. > And they're going to do so in a way that isn't immediately detectable, but screws the rest of the company because now they have to support something using the screwed up implementation. eeeeeeeeeh. Sensible companies will figure out how to massage the broken data into the correct form, then go on using the correct software. [0] https://github.com/git/git/tree/master/t https://github.com/git/git/tree/master/t
sytse 11y ago
At GitLab we're very grateful for all the work that has been done on libgit2 by GitHub and others, and we plan to move to it completely.

solutionyogi 11y ago

That is my dream. Right now, many Windows GUIs (SmartGit/SourceTree) use 'git.exe' to manage the actual Git repositories. If libgit2 is fully mature, I can imagine more GUIs/tools will be built to manage/analyze the git repositories.

leonardinius 11y ago
I believe github windows client is going that route https://github.com/blog/1127-github-for-windows https://github.com/blog/1127-github-for-windows. I also remember some blog post going into sync/async details of git.exe vs libgit2 stuff. Will try to google it.
- MarkSweep 11y ago
  This is the article you speak of: http://githubengineering.com/git-concurrency-in-github-desktop/ http://githubengineering.com/git-concurrency-in-github-deskt... The AsyncReaderWriterLock mentioned in blog does not directly show up in Google, but it appears to be based on the one in this blog post: http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/building-async-coordination-primitives-part-7-asyncreaderwriterlock.aspx http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/building-...
dan15 11y ago
> Right now, many Windows GUIs (SmartGit/SourceTree) use 'git.exe' to manage the actual Git repositories. For what it's worth, all of the Git functionality in Visual Studio uses libgit2.

shazow 11y ago

While I think the libgit2 initiative is fantastic, I don't think there needs to be just one Git implementation. One of my favourite things about git is that the underlying storage and protocol is really simple and straight-forward to implement. You could do a lot of it in shell scripts, if you wanted to. The stateless storage is simple and consistent, but the thing that does vary is the various operating algorithms: diff, merge, garbage collection, etc. This creates a really interesting ecosystem where you could potentially have third-party tools that have some secret sauce producing more efficient diffs or fewer conflicting merges but still base it entirely on the open git ecosystem and remain completely backwards-compatible with all the other tooling.

s73v3r 11y ago
No matter how simple and straight-forward it is, someone is going to fuck it up. And they're going to do so in a way that isn't immediately detectable, but screws the rest of the company because now they have to support something using the screwed up implementation.
- simoncion 11y ago
  Git has a bunch of tests [0]. I expect that not all of them are git-the-official-CLI-specific. > And they're going to do so in a way that isn't immediately detectable, but screws the rest of the company because now they have to support something using the screwed up implementation. eeeeeeeeeh. Sensible companies will figure out how to massage the broken data into the correct form, then go on using the correct software. [0] https://github.com/git/git/tree/master/t https://github.com/git/git/tree/master/t

sytse 11y ago

At GitLab we're very grateful for all the work that has been done on libgit2 by GitHub and others, and we plan to move to it completely.