Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitoxide: Pure Rust Implementation of Git

github.com

Post reply on HN
Print view View original

181–190 of 200 posts

Re: Gitoxide: Pure Rust Implementation of Git

#181

Post by [deleted] »

phoe-krk wrote: post #88
hmartins wrote: post #65

Earlier quoted context omitted.

CCL: Totals grouped by language (dominant language first): lisp: 336793 (84.60%) asm: 30410 (7.64%) ansic: 29862 (7.50%) sh: 718 (0.18%) objc: 299 (0.08%) java: 7 (0.00%) > Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. Yeah, right.

> Yeah, right. In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion. Do you have any arguments other than the unsubstantial "yeah, right"?

[deleted]

Re: Gitoxide: Pure Rust Implementation of Git

#182

Post by kazinator »

namKS wrote: post #55
phoe-krk wrote: post #21

Earlier quoted context omitted.

As a Lisp programmer, I don't dunk on everything that is not Rust; I instead dunk on everything that is C. The extensive use of this language has brought us countless pain via stack overflows, buffer overflows, memory corruption, and multiple other vulnerabilities that are literally baked into the language model. Dropping C for any sane alternative will be a massive boon.

Better do not use Lisp, since the interpreters have at least around 10% C.

Lisp implementations using C means that the implementations may have C-related vulnerabilities, not Lisp programs themselves. You're not facing the risk of creating new C-related vulnerabilities by writing new application code in Lisp, even if the Lisp you're using has substantial amounts of the run-time written in C.

Re: Gitoxide: Pure Rust Implementation of Git

#183

Post by ByronBates »

bluejekyll wrote: post #179
ByronBates wrote: post #63

I am the author, and will be here for a few hours in case there are any questions. (proof: https://keybase.io/byronbates )

I might have missed your attention to this thread, but I'll ask and hopefully you'll be able to check later. I have to deal with a monolithic codebase that is of excessive size (10's of millions of lines of code) and has a very large number of developers committing against it. I haven't looked at the internals of Git much, but performance becomes an issue with it in this context (we currently use a different vcs), an…

That sounds like such a project should definitely see improvements when using GitOxide. Even in projects of the size of the Linux Kernel checkouts can take time as those only reach about 3000 files per second. You will see only 70% of a single core being busy and a lot of kernel overhead. On my machine, using all the 4 cores, this number can be 7500 when checking out in parallel, something that `gitoxide` is definitely going to do from day one. After all, there is no value in just being as fast as git.

The same applies when checking for changes on disk - right now git does not do that in parallel. These are low hanging fruit that I plan to pick for my own sake.

There is another contributor who is very interested in increasing pack performance, which will directly impact fetch and pull speeds. Judging from my experience with packs thus far, I believe a lot of options are still to be tapped in that field as well. Rust will open it up for contributions and experiments to a greater audience, so I would hope that this will go way beyond of what I can do.

Even though this project is not very contributor friendly right now, I will be working on improving this so more people can join in (see https://github.com/Byron/gitoxide/issues/8).

Re: Gitoxide: Pure Rust Implementation of Git

#184

Post by ByronBates »

epage wrote: post #151
ByronBates wrote: post #63

I am the author, and will be here for a few hours in case there are any questions. (proof: https://keybase.io/byronbates )

Do you think you'd end up creating C APIs, to make this competitive with libgit2?

I am not interested in competing with libgit2, and have no plans in adding and maintaining C-bindings to the project. This doesn't mean, however, that other parties couldn't maintain them out-of repo at first, and once things stabilize, it just makes sense to make them part of an organization that maintains it along with the project. After all, C-bindings open it up to be used in interpreters, which might be especially interesting for users of `GitPython`. It has been around for a decade and is definitely in for an alternative (I am the author and maintainer of that one, too).

Re: Gitoxide: Pure Rust Implementation of Git

#185

Post by bluejekyll »

ByronBates wrote: post #183
bluejekyll wrote: post #179

Earlier quoted context omitted.

I might have missed your attention to this thread, but I'll ask and hopefully you'll be able to check later. I have to deal with a monolithic codebase that is of excessive size (10's of millions of lines of code) and has a very large number of developers committing against it. I haven't looked at the internals of Git much, but performance becomes an issue with it in this context (we currently use a different vcs), an…

That sounds like such a project should definitely see improvements when using GitOxide. Even in projects of the size of the Linux Kernel checkouts can take time as those only reach about 3000 files per second. You will see only 70% of a single core being busy and a lot of kernel overhead. On my machine, using all the 4 cores, this number can be 7500 when checking out in parallel, something that `gitoxide` is definite…

I’m excited. Thanks for the response. This is something I will try and find time to contribute to.

Re: Gitoxide: Pure Rust Implementation of Git

#186

Post by ztjio »

roca wrote: post #52
foota wrote: post #27

Earlier quoted context omitted.

Rusts good support for option and result types might help here.

Yes! Rust's error handling story is excellent. You can still swallow errors if you want to but you have to manually write unwrap() so it's much more visible.

Not to be overly pedantic but calling .unwrap() is about as far from swallowing an error as you can get. That's gonna panic right away if it's an error case.

Re: Gitoxide: Pure Rust Implementation of Git

#187

Post by ByronBates »

littlestymaar wrote: post #157
ByronBates wrote: post #63

I am the author, and will be here for a few hours in case there are any questions. (proof: https://keybase.io/byronbates )

Is native Windows support a goal?

Great point! Windows is already tested on CI, but I used the opportunity to make Windows support explicit in the project goals.

Re: Gitoxide: Pure Rust Implementation of Git

#188

Post by ByronBates »

brundolf wrote: post #141
letmeinhere wrote: post #77

Earlier quoted context omitted.

A stated goal is > a simple command-line interface is provided for the most common git operations, optimized for user experience. A simple-git if you so will. But an explicit non-goal is > replicate git command functionality perfectly git is git, and there is no reason to not use it. Our path is the one of simplicity to make getting started with git easy. a simple command-line interface is provided for the most commo…

Since some existing tooling - various scripts, GUIs, etc - use the git CLI as an API, it would be pretty cool if a subset of this implementation's commands matched the originals exactly, even if some convenience commands are added on top of that. That would allow it to be slotted-in in many more places

It's a project goal to make the API so accessible and easy to use, that's it's straightforward to quickly throw together your very own custom commands that do exactly what you need. This should allow building these slot-in commands as the need arises, and without breaking into sweat.

Re: Gitoxide: Pure Rust Implementation of Git

#189

Post by ByronBates »

littlestymaar wrote: post #173
ByronBates wrote: post #135

Earlier quoted context omitted.

Let me reply with the most tedious parts, as I wouldn't want to make the impression of labelling git as 'bad' - I have been fascinated by it for more than 10 years now and it's time to scratch my itch for good. Please note that everything I name can certainly be fixed by some tool that already exists, and that's great. It's just that I would like to have 'this one tool' that gets most things right and be happy with i…

Thanks! That's really interesting to see that only 2 of your list (around adding and pulling) were on my radar as git usability issue, and not even in my top five! The third one is a bit unclear to me: > looking at the commit history and copying individual commit hashes What do you mean exactly by that?

I frequently use `tig` to see the commit history, and pull out a single commit hash for use in `git checkout` or to reference it elsewhere. Probably it's just me not knowing all the `tig` hotkeys to make that easy, but it's my hope to have `gitoxide` as an obvious way to do things at least I need commonly.

Re: Gitoxide: Pure Rust Implementation of Git

#190

Post by pankajdoharey »

viraptor wrote: post #134
pankajdoharey wrote: post #122

Earlier quoted context omitted.

Trust me its way easier than you think and there are tons of free resource available you dont need a $36 book to build git.

I noticed you haven't linked any of them.

Here https://news.ycombinator.com/item?id=19386141

https://youtu.be/MYP56QJpDr4

Post reply on HN