I don’t expect my comment to somehow open the eyes of the writer of this piece, I have almost a resigned feeling posting this, as I have had this same interaction so many times…
I am not a smart man. I’ve been using git for about a decade and I won’t know how to do a checkout using CLI without asking chatgp. But at the same time I have none of the struggles the writer complains about. Because I use a GUI.
And before using git for the first time in 2016 - I used SVN for about a decade, also with a GUI.
The downside is it makes me a lot less cool than Neo-like hackers writing incantations in the dim glow of the monitor. Also if I wanted to write a blog post I would need to think of some other topic.
I use Gitkraken if you are curious, but I know you probably aren’t.
I should care more to learn Git fully, but I don’t.
I’m just not interested, but yet it’s a foundational tool to my workflow.
I just want it to work. I don’t want to have to learn commands for a system that I don’t have a love for.
As a reluctant developer I just can’t work with things I don’t like! (Reluctant because I’m too old, was never great, but yet people keep asking for things because apparently everyone else around skis just dreadful at delivering….)
My dislikes are often irrational on the surface, example:
I really do not like Python and 4 space indentation, and find it very hard to work with Django.
But people broadly seem to love Python!
Same with React and JSX. Have people gone mad!
Similarly with VSCode. How do people like this I think to myself?! It’s clunky and slow.
> I use Gitkraken if you are curious, but I know you probably aren’t.
I was, because gitkraken is good. At one point I was forced to use sourcetree, and it was awful. So I don't know if the argument is that guis are good for git so much as this one paid solution is good, and it rubs me the wrong way to think that something like the version control solution used becomes good if you pay for it.
I have similar thoughts to yours, except I exclusively use the Git CLI. I don't memorise all of the 'incantations' that the article suggest are required because if I ever use a command a few times, I make a Git alias for it. `git commit --amend --no-edit` => `g cmane`. I also have an alias for listing my aliases, which I can run through grep to jog my memory. That plus Ctrl+R for shell history means I very rarely type long commands. You'd have to be some kind of masochist to do that often.
So IMHO this article and the others that like to dunk on Git CLI seem to miss the point a bit.
Honestly git is too low level for regular day to day actions. I love using jujutsu [0] it makes handling changes and branches really easy and intuitive.
You can rebase a branch and it will actually save commits with conflicts so you can fix them later. You can do undo.
I learned on the CLI, so I’m a smug terminal user at heart, but now I almost exclusively use the Emacs magit module and I have to admit, it’s really, really nice.
I was reading the first part with instant buy in: simpler interface, "light" mode, yes, Yes, YES! We do not need 90% of the functionality, it can go into the expert mode.
And then I got to the main item of the proposal, removing decentralization, and my reaction was "oh, no! Decentralization is what makes git worth it for me"! So I guess while everyone does not need 90% of git functionality different users need different 10% of it. Which is a strong argument against a universal "light" mode. My 2c.
But isn't git decentralization just like all the other git features the article decries in the name of "simplicity" -- i.e, if you don't like those bits, just don't use them?
A merge only workflow with replacement log tools to only show merge commits, and a better solution for CI and web presentation would basically fix git.
People have a ton of opinions on merge commits but they stem from very few real issues: The log UI is bad, bisect handles merges badly. That's basically the crux of it. If you "hid" the railroad tracks as any higher level solution does then most of the problem goes away. Unsurprisingly the issue is that investment on this path disappeared when the rebase people won, and now we're stuck with the least capable merge tool that git has as the way that everyone does everything. We kneecapped git, and it was us that did it to ourselves.
Edit: and rerere still is no where near as capable as merge.
When commits from two or more parents have to interact in order to produce a bug, I don't think there is a bisect algorithm that can actually identify that bug. There isn't enough data to automatically merge prefixes of the merge history from respective parents in order to test them against each other. Also, the search space in this case becomes the product of the number of commits from the LCA to each parent. So I really don't understand how we messed up.
I'm just glad we have "--rebase-merges" now because when you have two git servers that are actually important enough not to rebase their history, you do need merges.
Pick a linearization strategy and walk it, this isn’t all that different from the “confusing history problem”, which is largely solved by —topo-order which is not the default because it’s slower
Is there a way to use this with bisect? Once you use merges, you aren't guaranteed to be able to apply the commits in the topo-order in a safe way. For instance if one parent changes the text of a file AA -> AB -> AC and one changes the text AA -> ABA -> ACA, the merge commit contains information to combine AC/ACA, but there is no information stored on how to resolve AB/ABA (or other combinations), so if intermediate states conflict, you can no longer bisect.
edit: and if you pick a specific order as you are suggesting to reduce the search space, then it's unclear how to resolve applying ABA on top of AC, for instance
IDK man. I'm kind of sad we don't used decentralized more. That was a vision of the infinite future lost to the past. Client/server symmetry is beautiful and maybe if GitHub goes down one day, we'll remember the glory and power of a million scattered copies to save the day. Plus all this hoopdy-doo about what we can and can't put on other people's servers? Self-host, self-speak, self-actualize. ;P
Every DMCA takedown notice in https://github.com/github/dmca is a net win for git as a decentralized version control system, especially for repositories that require signed commits. Unfortunately, some people upload only a snapshot of their repository working directory instead of... using git like it is supposed to be used I guess?
I am super interested in this, and would love to to hear if people have any user experience with the tool thus far. On paper, it hits all of the right notes: full git compatibility so I can silently use a superior tool, Rust so it is cross platform, deliberately thought out UI.
The one thing keeping me from taking the plunge is I (probably my bad workflow) really lean on editing a bunch of code and then selectively committing individual lines (eg I am editing foo(), but I see comment string for bar() is wrong. I tweak both, and when I get around to it will selectively make two commits from the edited lines). It seems like this workflow is a bit more painful to hit. At least, there is no visual tooling which is going to understand jj right now, so it is up to me to do that commit surgery.
I thought this[0] jj tutorial does a lot to sell the experience.
For things I do frequently there's alias or scripts. For things I do rarely there's ChatGPT/StackOverflow. I can't imagine liking or not liking git. It's just there. I guess it does everything I need it to do and so I like it. I like it better than CVS which is what I used before git.
If you add a "+" character, it becomes a force-push:
git push origin +HEAD:refs/heads/MY_NEW_BRANCH
Let's me work from master locally, but push my work to a new remote branch just for the PR. Saves a couple steps in his normal workflow as he describes it. I also tend to use the "Squash", "Rebase" and "Amend" buttons on the PR's web UI that makes a few of my common "post-push" operations even more convenient (thanks to a Bitbucket plugin).
Oh, and "git pull --rebase --autosquash" is also a big part of my workflow. Quite a miraculous "does exactly what you want without you even knowing you want it" command.
When would you want to autosquash things coming from another repo? Autosquash is for doing interactive rebases; you'd never want to publish commits that say "squash! ..." or "fixup! ...".
Yeah, "all branches are remote" is in fact the Objectively Best Workflow.
In point of fact I don't deal with local branches at all on 95%+ of days. Just "git reset --hard <remote>/<branch_to_work_on>", do whatever I want, and then "git push <remote> HEAD:refs/heads/<pull_request>" (or push -f if I'm reworking an existing one, yada yada). If I want to "pull" changes I just "git fetch <remote>" and don't ever bother checking anything out.
Local branches involve too much state that inevitably means I trip over it.
Heartily agree! I never thought of my workflow in this way, but it makes sense: by completely avoiding local branches, I reduce my cognitive load. I only ever work from "master", but my "master" is just whatever I happen to be working on that day.
Disagree with a bit in the article but particularly unpalatable to me is the idea that Git should be more than it is (e.g. PR support, web UI). Seemingly obscured in this idea is lock-in; if I don't like Git with email patch workflow, I can use Git with GitHub. If I don't like that, I can use Git with Forgejo. Good luck moving to more suitable tooling (because what is suitable often shifts over time) when you are stuck with the inertia of your entire VCS stack being one thing. Semi related: I was at an org recently who wouldn't migrate to Git because they didn't like the Git code review equivalent in Visual Studio, compared to how TFS code review looked in VS. That was seemingly the only possible way to review code - in VS.
I do love mercurial's tooling though. revsets, hg grep --all, hg absorb, hg fa --deleted, phases.. But, I've found svn is way easier to get a total novice up and running on, and for shared work servers, it's fine...
Totally agree with the OP's feelings about git except one small nitpick, for me push and pull are opposites seen as how i use them, so it feels intuitive enough. Except for the wording of pull request, which IMO concerns the point OP made about decentralisation.
i fully agree that we could take more advantage of the effectively centralized nature git is mostly used.
personally, i don't love using git, but i do love the advantages it brings, even for the smallest problems. it's pretty much an all in one backup and sync solution too in my workflow, so i'm using it for my whole system configuration and user dir too, even tried using it for my addressbook and calendar with xandikos (baikal ended up working better for me though).
it's just very unfriendly to use at times, and there's reasons the "meme" about copying out your changes, deleting the whole repo, and pulling again is actually a common thing to do.
like, it's easy to add everything with "git add .". But you realize one file doesn't belong in the commit, what do you do? git remove doesn't exist. git rm isn't it either. git unstage? nope. it's git restore --staged, but ... i don't want to restore anything? sure, the git version i'm currently using dislpays this every time i run git status, but... the whole fact that this needs to be displayed like this should tell you a lot already.
agreed that there is an unmet need for a version control that does the 99% of usecases in user-friendly ways.
edit: while we're at it, let's also ensure the next system we use makes it even harder to lose data. accidentally deleting a file that hasn't been added in git can happen, and i'd like my version control system to help with that too.
i'm sure there's lots of people who use a decentralized workflow, but... in the big picture, it seems it has to be a vanishingly small minority. unless i have a wrong idea about what decentralized means in this case?
the way i see it, pretty much every project has an "upstream" which is in effect a central location where the development of a codebase happens. and with how easy it is to set up a git server, with all the advantages that having a server for it brings, i just don't see why some people make such a big deal out of it.
don't get me wrong, things like being able to pull a repo to have it locally, and work on it independently from a server, without internet connection, is a vital point for any version control, and i see a lot of value in git-send-email (sr.ht's way of doing things), but in the end there usually does end up being a central location for the code, so why not embrace it?
> don't get me wrong, things like being able to pull a repo to have it locally, and work on it independently from a server, without internet connection, is a vital point for any version control, [...], but in the end there usually does end up being a central location for the code, so why not embrace it?
Yes, it's a vital point for any version control system. And that's exactly the reason why everyone moved to Git. Because every popular version control system at the time required an internet connection for everything. It was difficult to do any meaningful work offline, or even online for that matter. Server outages, performance issues, hard to scale, etc. So painful to work with for big projects in particular that Linus Torvalds threw their entire version control system in the trash and wrote his own, arguably better, decentralized version control system. I'm sure Microsoft employees, especially the ones working on Windows pre-git-migration, can tell you all about the drawbacks of centralized version control systems. For sure, go ahead and embrace the centralized workflow if you want to, grab a copy of more traditional version control system software, but it will be as painful to work with as it was back then.
> don't get me wrong, things like being able to pull a repo to have it locally, and work on it independently from a server, without internet connection
If you can do this, you already have decentralized version control.
That was bad enough, but the point where you really couldn't take it seriously was when, after having said he didn't want decentralised version control, he said he wanted "Pull Request as a first-class citizen". What would he need pull requests for in the first place, in his non-decentralised world with just a single centralised repository?!?
There is a sane third alternative: you add the dependency as an upstream directly to your repo and fetch its objects. You track it on a branch in which only that dependency exists (there is nothing else in the tree). You perform a rename which moves that dependency into the directory where you want it. Then you merge or cherry pick the renamed version of the dependency into your trunk.
The one advantage of a submodule is that you can maintain a separation if you locally hack the dependency. Your commits to the submodule are entirely separate from your project's stream, and could be published independently and possibly upstreamed by that submodule's project.
These activities are not impossible if you integrate like I recommend above, but they become more work.
There's so much wrong with this that it's hard to see if there's anything at all right with it.
> More specifically, it doesn't work offline.
??? Of fucking course it does! You mean Git Hub doesn't work offline, don't you?
> It relies on merge controls that aren't even a part of git with Pull Requests.
No, git doesn't "rely on merge controls that aren't even a part of git". Other things do. Things people nowadays confuse with git. People like, apparently, the author of TFA. (And no, the "F" doesn't stand for "fine" in this case.)
> Dump the decentralized model.
You can do that yourself: Just don't use it.
> Move a lot of the work server-side and on-demand.
Sure, just ssh into the server and run your search there. What's your problem?
> Pull Request as a first-class citizen.
A: Huh? But that's part of a decentralized workflow, and didn't you just say to "Dump the decentralized model"? Make up your mind.
> Why did SVN get dumped then? One word: branches.
Yeah, that is a bit ironic... Seeing as how git's killer feature was branches, and for the last ten years (or how long has it been; at least five?) everyone has been pooh-poohing them and going on about their "linear commit history", as if that were somehow so fucking important.
> I also think programmers love decentralized designs because it encourages the (somewhat) false hope of portability. Yes I am entirely reliant on GitHub actions, Pull Requests, GitHub access control
Who told you to make yourself dependant on all that shit? I sure didn't, and I'm pretty sure git didn't either. Sounds -- again -- like your problem is with GitHub, not with git.
> I could move the actual repo itself to a different provider.
Your problem is probably that you think you need a "provider" in the first place. Just put a fucking ordinary git repo somewhere, and use that.
I am not a smart man. I’ve been using git for about a decade and I won’t know how to do a checkout using CLI without asking chatgp. But at the same time I have none of the struggles the writer complains about. Because I use a GUI.
And before using git for the first time in 2016 - I used SVN for about a decade, also with a GUI.
The downside is it makes me a lot less cool than Neo-like hackers writing incantations in the dim glow of the monitor. Also if I wanted to write a blog post I would need to think of some other topic.
I use Gitkraken if you are curious, but I know you probably aren’t.