Show HN: Pygit – Just enough git to push itself to GitHub(benhoyt.com)
benhoyt.com
Show HN: Pygit – Just enough git to push itself to GitHub
http://benhoyt.com/writings/pygit/
25 comments
I have a similar project, also using Haskell: https://github.com/federicotdn/hvc
The thing is, all of these details are implemented in the git command line tool, not in a library. So it is pretty difficult to write a tool that works exactly the same way the command line tool does, or if you do manage to do it, it'll be fragile since the command line tool could change behavior at any time.
> It was eye-opening how simple the concepts of git are.
Exactly! Sometimes I'm bewildered how complex git porcelain (CLI interface) is compared to the basic building blocks.
Usually when I want to do something complex in git I think of how I want the structure to look like and then figure out which command does that ("was it git reset --soft or git stash --keep-index that did X?"). Now when I'm thinking about it I usually imagine states (like DOM trees). I see current state and the state I want to have the repo in (commits, working directly, index). What I'm missing here is a React-like reconciler that will transform one into other.
Exactly! Sometimes I'm bewildered how complex git porcelain (CLI interface) is compared to the basic building blocks.
Usually when I want to do something complex in git I think of how I want the structure to look like and then figure out which command does that ("was it git reset --soft or git stash --keep-index that did X?"). Now when I'm thinking about it I usually imagine states (like DOM trees). I see current state and the state I want to have the repo in (commits, working directly, index). What I'm missing here is a React-like reconciler that will transform one into other.
Nice work!
I love projects like this, because I think most of us would benefit from re-implementing our dev tools (at least partially) to develop a better understanding of how they work.
I love projects like this, because I think most of us would benefit from re-implementing our dev tools (at least partially) to develop a better understanding of how they work.
Traditionally some of the trade apprenticeships started with the new apprentice making their own tools.
When I took a molecular cell biology class in college, the first series of labs involved disassembling and reassembling the bench microscopes that we would be using for the rest of the course (they were close to maxing out on optical resolution, the faculty couldn't afford to replace a broken one)
As an engineer I enjoy making my own tools, sometimes a little too much
When I took a molecular cell biology class in college, the first series of labs involved disassembling and reassembling the bench microscopes that we would be using for the rest of the course (they were close to maxing out on optical resolution, the faculty couldn't afford to replace a broken one)
As an engineer I enjoy making my own tools, sometimes a little too much
Similarly, when I got my first job as a PC tech at a locally-owned computer shop, my first task was to assemble my own "bench" PC for testing various components.
Agreed, it looks great.
More in that vein, for Python bytecode compiling and running: https://github.com/darius/tailbiter -- I can't quite resist mentioning it since I gave it a similar tag line, "just enough Python to Python in Python".
More in that vein, for Python bytecode compiling and running: https://github.com/darius/tailbiter -- I can't quite resist mentioning it since I gave it a similar tag line, "just enough Python to Python in Python".
Related: http://gitlet.maryrosecook.com/
Gitlet is an implemention of Git in JavaScript.
https://maryrosecook.com/blog/post/git-from-the-inside-out
Gitlet is an implemention of Git in JavaScript.
https://maryrosecook.com/blog/post/git-from-the-inside-out
Super cool project!
I hope this isn't taken as a frivolous or mean-spirited comment, but the code samples on the blog would be much more readable with some kind of syntax highlighting.
I hope this isn't taken as a frivolous or mean-spirited comment, but the code samples on the blog would be much more readable with some kind of syntax highlighting.
Good call! Thanks to Jekyll and Rouge, I added some light syntax highlighting.
Great article! An equally educational one for a torrent client in C# https://news.ycombinator.com/item?id=12035568
I'd reconsider the name, I'm sure pretty it will cause confusion with pygit2.
This feels like the most appropriate way to make a quine of a VCS tool.
[deleted]
Neat!
My local Python group had a talk on something like this last year: https://github.com/glenjarvis/explore_git_internals
My local Python group had a talk on something like this last year: https://github.com/glenjarvis/explore_git_internals
See also Dulwich, a pure-Python Git implementation https://github.com/jelmer/dulwich
I wonder how fast it would propagate if it was able to inject itself into existing repos and hook itself to package.json and other installer scripts.
Nice. I wonder if anyone tried doing the same in rust?
https://github.com/libgit2/libgit2/pull/3540 might be of interest (note that it's over a year old at this point)
I don't think it would be of any strategic advantage? The promise of Rust is to be once better than C not better than Python. Nit to mention all the needed libraries.
I'm a bit confused by this logic; git is written in C, so if Rust is supposed to be "better then C", then wouldn't it make perfect sense to write it in Rust?
[deleted]
In general yes, it would benefit Rust, long term. But for the purpose of this article, no. The result would at this moment be much bigger than 500 lines, which wouldn't have any power of a short example.
Nice work! This seems like it could be a fun weekend project.
Some time ago I did a similar exercise in Haskell: https://github.com/EarlGray/omit (it also took about 500 lines of unnecessarily dense Haskell), implementing barebone functionality of `git log`, `git add`, `git commit`, `git status`, `git diff` (using an existing Haskell diff library). It was eye-opening how simple the concepts of git are.
On the other hand, the most interesting parts of git are still left out: branches, merges, conflict resolution, remote sync. I'm wondering how many more lines are needed for this.