4 ms·

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.

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.

Communitivity 6y ago
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.
- rich_sasha 6y ago
  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.
brundolf 6y ago
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
- ByronBates 6y ago
  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.

Communitivity 6y ago

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.

rich_sasha 6y ago
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.

brundolf 6y ago

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

ByronBates 6y ago
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.