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.
*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
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)
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.
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?
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.
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?")
We use a git hook for this currently and it's super useful.
Something like an IDE might be better suited for detecting these because it knows which symbols refer to where.
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!
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 )
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.
> 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
stI 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.
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.
Doesn't that negate the advantages of `push --force-with-lease` over `--force`?
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.
Is there example here ?
i love using CLI. curious what others here thing of this as well as any IDE's they prefer to use.