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 )
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.
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.
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.
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.
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
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.
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)
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 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.
> 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.
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.
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.
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.
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.
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.
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.
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!