[HN Gopher] Bit (1.0) - a modern Git CLI in Go
___________________________________________________________________
Bit (1.0) - a modern Git CLI in Go
Author : chriswalz
Score : 183 points
Date : 2021-02-27 03:00 UTC (20 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| srich36 wrote:
| 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.
| waynesonfire wrote:
| 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.
| geraldcombs wrote:
| People seem to be able to use Time Machine, which adds a time
| dimension to macOS' hierarchical file structure, just fine.
| mbirth wrote:
| 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
| minot wrote:
| > "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?
| Quekid5 wrote:
| 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
| indymike wrote:
| Google docs?
| eveningsteps wrote:
| lazygit was one of the greatest discoveries for me (just see
| their example workflow in GIF!):
| https://github.com/jesseduffield/lazygit
| ibraheemdev wrote:
| 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
| Igelau wrote:
| 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.
| shakow wrote:
| > 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.
| RupertEisenhart wrote:
| 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?
| alkonaut wrote:
| 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.
| TravelPiglet wrote:
| 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.
| Spivak wrote:
| Huh? There's version control for designers. The leader in
| the space is called Abstract.
| chriswalz wrote:
| 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!
| kortex wrote:
| 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.
| chriswalz wrote:
| After a user runs `bit checkout <branch-name>` bit will run
| `git pull --ff-only` behind the scenes
| kortex wrote:
| Neat! That is exactly what I am looking for!
| archseer wrote:
| > 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`?
| chriswalz wrote:
| That's a good question. I'm not 100% sure but you may be right.
| I'll have to do some investigating
| cosmotic wrote:
| What does modern mean in this context?
| chriswalz wrote:
| 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`.
| lanstin wrote:
| Sadly there are actually people that like useless merge
| commits.
| cosmotic wrote:
| 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.
| swagonomixxx wrote:
| I'm eagerly awaiting the postmodern Git CLI's in Go 2.
| jzer0cool wrote:
| 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.
| [deleted]
| stiray wrote:
| 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.
| asdjlkadsjklads wrote:
| 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?
| lanstin wrote:
| also an undo for undo?
| j1elo wrote:
| > 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.
| purerandomness wrote:
| 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.
| j1elo wrote:
| D'Oh! It took me with the trolling detector off and I
| thought it really was talking about something! Nice one.
| [deleted]
| lambda_dn wrote:
| 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.
| qmmmur wrote:
| Care to share?
| lambda_dn wrote:
| 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
|
| 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.
| riyadparvez wrote:
| There's also lazygit[1], which is written in Go.
|
| [1] https://github.com/jesseduffield/lazygit
| technics256 wrote:
| How did you do the autocomplete previews? Is that a feature of
| cobra?
| chriswalz wrote:
| Bit uses cobra a little but for the autocomplete it uses
| https://github.com/c-bata/go-prompt
| gcarvalho wrote:
| 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?")
| kevsim wrote:
| 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.
| lanstin wrote:
| 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.
| spockz wrote:
| 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.
| chriswalz wrote:
| Yes, I think something like this could be done. Feel free to
| file a feature request
| waynesonfire wrote:
| 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.
| yewenjie wrote:
| Does this support bare git repos? That is the only feature I miss
| from Emacs magit - my favorite Git client.
| dlkmp wrote:
| 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.
| eptcyka wrote:
| 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.
| revskill wrote:
| 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 ?
| globular-toast wrote:
| > 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.
| lanstin wrote:
| 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.
| hit8run wrote:
| These changes should be ported to the original git cli command.
| Really good stuff here!
| chriswalz wrote:
| It'd be an honor to collaborate with them :)
| vardaro wrote:
| 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
| iamatologist wrote:
| This is not really an abstraction.
| acemarke wrote:
| 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.
| scns wrote:
| 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.
| oxinabox wrote:
| 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
| cturtle wrote:
| 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)
| bsoft16385 wrote:
| +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.
| skrebbel wrote:
| Yeah a mouse would be a terrible way to interact with a graph!
| ashneo76 wrote:
| 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.
| whycombagator wrote:
| > --- Coming Soon ---
|
| > bit anticipates when you'll need to type git status and will
| display it proactively
|
| huh?
| codetrotter wrote:
| 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
| nathias wrote:
| 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.
| tbrock wrote:
| 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.
| waheoo wrote:
| 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.
| jhh wrote:
| I think this can enable experimentation. Enthsiasts may use
| this and the things that work best can be brought upstream.
| chriswalz wrote:
| Agreed. There can be tighter integration with third party
| tools as well like GitHub and Gitlab among others
___________________________________________________________________
(page generated 2021-02-27 23:03 UTC)