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.
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 )
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.
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?")
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.
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.
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
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.
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)
+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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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)
76 comments
[ 0.16 ms ] story [ 111 ms ] threadI'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!
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.
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 )
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?")
Something like an IDE might be better suited for detecting these because it knows which symbols refer to where.
We use a git hook for this currently and it's super useful.
Doesn't that negate the advantages of `push --force-with-lease` over `--force`?
[1] https://github.com/jesseduffield/lazygit
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.
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
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)
> bit anticipates when you'll need to type git status and will display it proactively
huh?
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
i love using CLI. curious what others here thing of this as well as any IDE's they prefer to use.
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.
*as long as the world is managing text files, which is, albeit not prohibitive, a big caveat.
There's also Fossil[1] which is stable and seems to have pretty good UX.
[0] https://pijul.org/ [1] https://fossil-scm.org
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?
* project
* project_20201213
* project_20201215
* project_20201219
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.
Scheduling pulls daily/hourly and reserved checkouts a la Clearcase would probably suit them better.
[0]: https://pijul.org
I type ck and get a fzf list of local and remote branches I can fuzzy search and select to checkout.
My git checkout abbr requires git,fzf to be installed
abbr --add ck 'git branch -a | string replace -a \'origin/\' \'\' | string replace -a \'remotes/\' \'\' | sort -u | fzf | read branch; git checkout $branch'
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.
Is there example here ?
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.
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.
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.
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.
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.
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?