Bit (1.0) – a modern Git CLI in Go | Hacker News Reader

Bit (1.0) – a modern Git CLI in Go

github.com

191 pointschriswalz74 comments

Hi all,

I'm the creator of Bit. Bit is all about making your life just a little bit easier. It helps you spend less time fiddling with Git and more time developing code.

Whether it's autocompletion at your finger tips, sorting branches by most recent, checking out PR's with ease or auto-fast-forwarding when possible - Bit has your back!

This looks great! Might not even wait till Monday to give it a shot.

What does auto FF mean? I notice myself using a very streamlined dev/rc/main approach, favoring rebase over merge, with lots of linear commits to rc, move the puck ahead, then move master, using merge --ff-only.

After a user runs `bit checkout <branch-name>` bit will run `git pull --ff-only` behind the scenes

This tool is amazing! Nice job, and keep up the excellent work!

Neat! That is exactly what I am looking for!

Thank you for working on this, and for providing it to everyone for free & open source! A better CLI for git would be an awesome thing, for sure.

Is there a bit vs. git comparison somewhere? I'm curious how close the two CLIs are.

(In fact - is there a list of bit commands/args? I couldn't quite find it after skimming the README.md a couple times)

In particular, are they 'close enough' that I could give this to freshman/sophomore college students (instead of git) as a starting point, and then help them transition to git later on?

(This looks awesome but they'll want experience with the straight 'git' on their resume / before they arrive at their first jobs, etc )

Git is what happens when a technology is born out of hardcore engineering. Most of the world could greatly benefit from its functionality but it’s too hard for non software-engineers to learn. I hope the next era of version control thinks about the problem from a less technically inclined user’s perspective. Out of curiosity, does anyone know of any good alternatives that make version control easy? I personally love git, but want to see it’s benefits brought to a wider base of people. Projects like Bit are a step in the right direction.

I disagree. "Most of the world" has a hard time understanding hierarchical structure like files and directories. Once you introduce git, which basically adds a time dimension to that hierarchical structure--good luck understanding that. It doesn't matter how user-friendly the tool is if the fundamental concepts cannot be understood.

> "Most of the world" has a hard time understanding hierarchical structure like files and directories.

That is an excellent point that I think deserves expanding.

I submit that files and directories ARE difficult concepts. Pretty much everything is difficult when you look into it enough.

I remember of the time they pointed the Hubble Telescope into a seemingly empty patch in the sky and with long exposure or something, we saw tens of thousands of galaxies from billions of years ago.

https://en.wikipedia.org/wiki/Hubble_Ultra-Deep_Field

Back to the subject at hand, I tried installing gentoo one time and it prompted me for something. I only vaguely remember the word "inode". Here is the first paragraph from the wikipedia from the article on inode:

The inode (index node) is a data structure in a Unix-style file system that describes a file-system object such as a file or a directory. Each inode stores the attributes and disk block locations of the object's data.[1] File-system object attributes may include metadata (times of last change,[2] access, modification), as well as owner and permission data.[3] Directories are lists of names assigned to inodes. A directory contains an entry for itself, its parent, and each of its children.

https://en.wikipedia.org/wiki/Inode

Files and directories may be an easy concept to understand if you have been exposed to them long enough (not sure how long is long enough) BECAUSE we have a good abstraction. I never had to learn what inodes are or how a filesystem works to use a computer. Can we accomplish something similar with version control?

I wouldn't say so. From watching non-dev people, I can say that they DO know about files/folders and they can very much add the time dimension to them. It just looks a bit different:

* project

* project_20201213

* project_20201215

* project_20201219

People seem to be able to use Time Machine, which adds a time dimension to macOS' hierarchical file structure, just fine.

lazygit was one of the greatest discoveries for me (just see their example workflow in GIF!): https://github.com/jesseduffield/lazygit

Any user who deals with a set of files that need to be coherent, such as a source tree, I'd argue is already most likely technical. Non-technical users are used to having the time dimension, but for individual documents. They understand the notion of revision A and revision B of a document. Most people also most likely understand that if two people edit revision A, they would create separate, conflicting revisions B.

but: most people also accept wihtout fuss, that it's OK that you make a phone call or email and just agree who throws their version out. Or that one user should simply lock the document for editing to prevent this from happening.

"Git for non technical users" (of single documents, not trees) seems pretty easy to build as a layer on top of git. 1) you use LFS and file locking. 2) You "check out" a file for editing which locks it exclusively 3) You completely hide the notion of "local repository" because zero nontechnical users, ever want to be bothered with distributed version control. Basically - you make a dumber but more robust verison of SVN on top of git-lfs.

Working with graphics people and their assets I can promise you that the idea of conflicts are completely foreign to them.

Scheduling pulls daily/hourly and reserved checkouts a la Clearcase would probably suit them better.

Huh? There’s version control for designers. The leader in the space is called Abstract.

> Most of the world could greatly benefit from its functionality

*as long as the world is managing text files, which is, albeit not prohibitive, a big caveat.

Even just using text files surely? Even a single document can benefit from git-- or are you thinking that tree-history and other things which are sometimes provided by editors are enough?

If you can live with non-Git then Pijul[0] seems quite promising both in terms of UX, but also power relative to git. (It's probably still quite rough around the edges right now, though, it's 1.0.0-alpha).

There's also Fossil[1] which is stable and seems to have pretty good UX.

[0] https://pijul.org/ [1] https://fossil-scm.org

Unfortunately git is the easy one, but you're right about the accessibility. I headed a transition from svn to git once, and even though I think git is conceptually simpler overall, it quickly became apparent who paid attention to the graph theory portions of Discrete Math and who didn't.

Pijul [0] also claims to be "an intuitive VCS unlike git". The idea of composing patches is interesting, but I haven't got around to actually trying it yet.

[0]: https://pijul.org

Google docs?

I’m generally very skeptical of anything that abstracts away git with UIs. This looks really cool though and I like that you embedded common git workflows into the CLI

On the flip side, I'm a strong proponent of using a GUI for many Git tasks:

https://blog.isquaredsoftware.com/2021/01/coding-career-git-...

but I also use the CLI for other tasks as well.

For example, it's _way_ easier to add specific file chunks or individual lines to the staging area via a GUI, or do interactive rebasing.

Strong agree. I will use the command line for basics, commit, push, pull, simpler rebases.

But it I am going to be cherry picking a commit onto a backport branch, or splitting up one branch into two, or doing an interactive rebase, or (as said) committing some parts of s file but not others, I want a GUI

I almost always default to git add -p when staging (and git reset -p when needed). Git rebase -i also feels very quick to me as well.

When isolating just one line from many changes the gui is nice, but in the majority of cases the CLI is much faster (no need to scroll in long files to find the next hunk)

I concur. Intellijs git client alone makes it hard for me to even imagine using something else. Read a comment on HN where someone use only the git client from it.

+1 to this. I mostly use the CLI, but it's really nice in my IDE (JetBrains Rider) to be able to browse version history or resolve merge conflicts graphically.

Yeah a mouse would be a terrible way to interact with a graph!

This is not really an abstraction.

Bit needs just one single switch and everyone will gladly use it for its killer feature.

Undo with one single command, without strange additional arguments, weird naming, strange documentation[1] etc.

[1]https://git-man-page-generator.lokaltog.net

When anyone is doing the "next best thing after bread and butter" version control, please start with --undo switch.

Sometimes you just need a hammer, without any will or need to learn how to make hammers.

I'm writing a git-like, so i'm curious your thoughts on this. What would undo, do exactly?

Eg would it make a new commit, reverting the previous? Would it undo the last commit, dropping it from history? Would it undo the last commit, putting the contents into staging/unchecked?

My git-like is for structured data and is very very different from git. Conceptually though, it's similar in that it's a hash tree of content addresses. So it'll conceptually suffer the same problems, if i wanted it to.

My plan, due to the nature of the project, is to for the most part avoid conflicts and be more forgiving in the primary flows. This makes sense (imo) because the nature of the application is about data retention moreso than it is strictly VCS. It just has VCS fundamentals to reach into, should they be needed.

But as i dive into the primary user flow - it feels like there are always a few cases that seem primary. Undo is a great example - making a new commit (revert), undoing the last and dropping it (hard reset), and undoing the last into staging all seem like primary UXs.

A lot of Git feels like the primary UX. I struggle to think of single concepts, like your undo example, where a simple path will be right to the user 90% of the time.

Thoughts?

IMO it's simple: with undo you want to 'go back in time' so you want to remove the commit and get the exact same list of staged/modified files that you had before (especially useful when you made a git commit -a which added too many files in the commit)

> https://git-man-page-generator.lokaltog.net

Reading the summary and the first paragraphs, I've just processed a bunch of words that I understand by themselves, but bear no meaning to me when placed together. I guess the target audience is a bunch of very power users who would probably not need explanations anyway.

It's satire. It generates gibberish using actual words from git man pages. Its purpose was to show how important technical documentation is, and how the git man pages could be improved.

D'Oh! It took me with the trolling detector off and I thought it really was talking about something! Nice one.

also an undo for undo?

> --- Coming Soon ---

> bit anticipates when you'll need to type git status and will display it proactively

huh?

I think that what they mean is that they plan on for example using inotify to watch for changes and to show git status automatically.

Personally I have my own set of commands that I wrote which call git and I have given them very short names, so the OP tool is not of use to me.

When I want git status, with my tools I type

st

I made alias of git to g, and git aliases for functionality, so you can use it in the same way just shorter, for example git status -> g s, git push -> g ps etc.

The git CLI definitely leaves room for improvement and thus for projects such as this one but I personally feel that the git plugin for your preferred shell and a custom set of git aliases adjusted to your personal workflow will get you most of the benefits an improved git CLI can provide. This also yields a better understanding of git itself which will be beneficial if you have to use git in an environment without any extras.

I think its hard to improve ones got workflow without discovering all the things git can do, and tools like this definitely help with discovery.

> bit fix for all the times you did something you really wish you didn't

Enlightenment is when you realise git is append-only and doesn't let you do anything you wish you hadn't.

The trouble is with any git "frontend" is it builds on top of git's existing abstractions. To make a good cli for git you would strip everything back to just the DAG manipulation functions and then invent a new language on top.

Immutable. Such a strong safety net. I wish people could trust it. Need reflog and never clean the local repo of course. I wish for reflog in the centralized repos also. I would like to trace branch ref history back thru the merges.

There's also lazygit[1], which is written in Go.

[1] https://github.com/jesseduffield/lazygit

What does modern mean in this context?

I'm using modern loosely as anything that improves upon the git CLI. Examples being: autocomplete suggestions, sorting branches by most recent, the ability to check out PR's from Github, and auto-fast-forwarding a branch when possible. In addition to some convenience commands like `bit info` and `bit save`.

That's setting modern at a pretty low bar. There are git tools that existed 10 years ago that satisfy that description. "Modern" is a go-to trendy term like cloud or web2.0. Try describing the tool like you did in your response there instead of using a non-descriptive term like modern.

Sadly there are actually people that like useless merge commits.

I'm eagerly awaiting the postmodern Git CLI's in Go 2.

These changes should be ported to the original git cli command. Really good stuff here!

It'd be an honor to collaborate with them :)

I think the developer did a great job with this project. It's really interesting looking at how the developer tries to reduce complexity out of git. However, I don't know how useful this is. It's another layer of abstraction which adds complexity. You now have to learn git _AND_ bit--and I'm not sure git is complex enough to me that it justifies this. The escape hatch out of bit is that it's "fully compatible with git allowing you to fallback to git if need be."

git alias is a form of abstraction and I use that to simplify my git workflow. I may even have a few scripts that do more complicated stuff. But it's limited. The feature list of bit is pretty significant. That's a lot of cognitive load and I'm wondering if / when did bit start to take on more complexity than it took away.

Looks very interesting, congrats!

A common mistake I have come across a few times (and seen others fall victim to as well) is forgetting to stage a file that's necessary for the new feature or fix they just committed.

Do you think that identifying these cases and suggesting to stage them is something in line with the project? (e.g. while trying to commit: "You imported file X in a file you staged, but it is currently being ignored, do you wish to stage it as well?")

I think I'd even take it a step further and not rely on the fact that it's been imported (which sounds a bit fragile and language specific). The number of times I have a new local that I don't want to add is far far smaller than the number of times I have a new local file that I forgot to add, so I'd want to be warned whenever I'm pushing with unstaged local files.

We use a git hook for this currently and it's super useful.

That does sound useful. I usually have a raft of local files with logs or different test scripts but not with the main extension of the repo (e.g ten .plan files and that one new .tf file , or seventeen config files but that one go file). And forgetting to add that new file is our top build failure I think.

Local files like that are fine, just keep them in your .gitignore

Would something along the lines of looking at the tokens in the stages commits and then searching whether there are changes that contain those tokens work? Maybe you also need to search for those tokens in files.

Something like an IDE might be better suited for detecting these because it knows which symbols refer to where.

Yes, I think something like this could be done. Feel free to file a feature request

Using a modern shell like fish and cli tools like fzf, sed, sort etc together to create abbreviations (not aliases in fish) give you 100x more features than this.

I type ck and get a fzf list of local and remote branches I can fuzzy search and select to checkout.

Care to share?

Sure! Using Fish shell run the code below. abbr creates and abbreviation (slightly different from an alias and imho much more useful), see https://fishshell.com/docs/current/cmds/abbr.html

My git checkout abbr requires git,fzf to be installed

To use just type ck and then you can narrow the branch list by typing some letters, then arrow keys to select the branch hit enter, boom.

This is awesome, thanks.

Does this support bare git repos? That is the only feature I miss from Emacs magit - my favorite Git client.

Yeah this is great but the power of git is kinda in its ubiquity like bash or cURL it’s everywhere and the lowest common denominator.

I can’t help another dev if they need this installed for me to be helpful, etc...

I really wish changes like this got upstreamed.

I think this can enable experimentation. Enthsiasts may use this and the things that work best can be brought upstream.

Agreed. There can be tighter integration with third party tools as well like GitHub and Gitlab among others

Yea, we should ditch go altogether, who needs it when we have C.

Better ditch all those bash aliases, git aliases, and toss zsh while we're at it.

You know what, bash should go to because you know, sh is everywhere.

> Automatic fetching & fast forwarding to keep your branches up to date and prevent merge conflicts

Doesn't that negate the advantages of `push --force-with-lease` over `--force`?

That's a good question. I'm not 100% sure but you may be right. I'll have to do some investigating

The most common workflow of git, to me, is when i want to move changes between branches (for staged and unstaged changes).

Is there example here ?

How did you do the autocomplete previews? Is that a feature of cobra?

Bit uses cobra a little but for the autocomplete it uses https://github.com/c-bata/go-prompt

love the autocomplete previews.

i love using CLI. curious what others here thing of this as well as any IDE's they prefer to use.

Great idea and looks pretty and useful. But, I am out because of the single binary and go. Dynamic linking allows better control of the system and security.

Reply on news.ycombinator.com