Hacker News Reader

Comment by rich_sasha | Hacker News Reader

Does this address the cryptic-ness of git commands? E.g. are the various commands we all know and love like `git reset HEAD`, `git co --track origin/branch` etc. made clearer?

Even after years of using git, this is for me a major pain point.

View on HN

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 common git operations, optimized for user experience. A simple-git if you so will.

So it depends. They may refine some parts of the UX, others may be identical, and other still will be left unimplemented because git still exists.

Git achieves that stated goal, to a degree, via git alias. You can define your own simple versions of the commands or shortcuts.

What you've done is awesome!

What I would love to see is a pure-Rust reproduction of the git commands we know, some simple-git flavor commands, a Git API we can call from Rust, and the ability to add new Rust written git commands. I would love to put my money where my mouth is and volunteer to help, but my job right now is consuming all of my time not spent on family.

Git alias is bittersweet to me, much the same as various GUIs on top of VCS, like magit in Emacs etc. They give you a simplified interface to a subset of the functionality. But when you need to escape out of that, suddenly you need to use the full complex solution, and without the constant training of using the 'real deal'. I see git aliases in the same category. Gitoxide sounds a lot more complete.

Furthermore, git aliases work on your machine. Then you ssh to a server and suddenly `git please-do-my-command-without-many-weird-options` don't work. Yes you can sync them, but not super-easily. Whereas a complete tool you can just distribute onto the machines you work on. Not entirely different, but not the same either.

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.

As this is part of the every-day workflow, I will think long and hard on how to make it as painless and user-friendly as possible. Having a more user-friendly experience on the command-line is one of the project goals, and it will also be me benefiting from it so the motivation will be high to achieve it. By then, that thinking process will hopefully be public enough to allow more people to chime in and get a better result that way. And yes, I think a lot is possible, and I can't wait to test some ideas of mine :)

I'm totally looking forward to that then! :)

Note that git itself is beginning to address this exact problem by introducing new, more intuitive commands such as "restore" and "switch".

I'd be interested to know what, according to you, are the worst part of git commands (I'm currently trying to figure out a better CLI on top of libgit2).

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 it alone.

That said, here is my list:

* adding individual files to the staging area/index

* looking at the commit history and copying individual commit hashes

* pulling while assuring no merge commit is created, or: simplified trunk-based development

* resumable clones

* seeing what's going on during all remote operations - here in China GitHub is incredibly slow most of the time and connections can be flaky

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.

Reply on news.ycombinator.com