Text-command-first approaches lead to inferior and hard to understand APIs which are, at best, papered over with a GUI. Managing the source of the project should be a series of trivial visual operations.
Then of course it's possible I didn't give the many GUI frontends enough of a chance. Such is life, it's a resource limited game. Principally, I justify my position with the argument that the many GUIs will try to translate git into something visual by adding their own designs, and this can prove additionally misleading and difficult, if git wasn't rough enough already.
The only GUI bits I use for git are editor integrations such as the official one in VS Code, and only when I know it's adequate. Which you can only know if you know what's going on in the background.
This isn't even opinion. It's fact. Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this by an overwhelming majority such that I might as well call this fact.
I honestly don't mean to insult you but when you say things like this in a discussion where others obviously disagree with you, it makes you seem like either an overly enthusiastic beginner that hasn't learnt about tradeoffs yet, or a very stupid fanatic. You might be neither, but that is how it comes across.
>Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this
I and many others simply disagree with you. I have used those tools. They work okay in simple cases but break down in more complex ones. That is my opinion.
The mere fact you've even typed out the words "Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this" makes you look like a child. This is how children speak.
>You probably worked with a trashy gui and likely didn’t use it too much.
You don't seem to be able to encounter someone that disagrees with you without immediately assuming they must be doing something wrong, lack experience, or be stupid.
Again, how hard is it to accept that people have different preferences? You are like those people on forums in the 2000s that argued that anyone that liked Ruby/Python was an idiot and obviously Python/Ruby was the far superior language. Anyone that disagreed obviously had never used Python/Ruby properly, and was obviously just a fanatic. I thought we moved past that stupid shit years ago.
Yes. Not stupid though. More lack of experience. That’s my opinion about it and in my opinion the gui is better and that is a fact.
What I don’t understand is why my opinion about something as a fact no matter how extreme leads to you openly calling me a stupid fanatic and calling me a child?
I said you come off as stupider earlier with the additional statement of “not to be insulting”. I also said it to sort of illustrate to you and imitate you on what happens when you call someone stupid and then say the words “I don’t mean to be insulting” as if that negates what is in actuality an insult. It doesn’t and now you’ve openly called me a child. This ends here. Good day.
Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI. Highly recommend the jetbrains conflict resolver gui.
I can assure you ANYONE who regularly has experience with both the CLI and that GUI(jetbrains) will hands down say the GUI is superior for merge conflicts. It is NOT intrinsic to the nature of merge conflicts. Any disagreement in this area stems from lack of experience or knowledge.
If anyone has experience with both and they have a contrary opinion, feel free to tell me. I doubt such a person exists though.
I dunno, something about its keyboard-driven design (and in general being Emacs-based) makes it clearer in usage than the JetBrains offering. Although this is probably what one is used to.
Of course, the really important thing is that people set merge.conflictStyle = zdiff3. Maybe a bit opinionated, but it really makes proper merging a lot easier.
I also thing Ediff has some very annoying behaviors - the fact that it doesn't use intuitive names for the two buffers (especially because of Git's annoying nomenclature when rebasing vs merging), and the fact that there's no shortcut for inserting both the A and the B changes into the destination, which is a common operation.
I haven't really used the JetBrains merge UI, so I don't know if it's better or worse, but I don't think it's very hard to improve over ediff.
I'd dispute this, and more likely call it a TUI[0], unless of course one wants to go with the really pedantic point that all text is graphical.
It certainly isn't what I would associate with the words GUI merge editor, which feels to me more like what Sublime Merge for example does
> I also thing Ediff has some very annoying behaviors - the fact that it doesn't use intuitive names for the two buffers (especially because of Git's annoying nomenclature when rebasing vs merging), and the fact that there's no shortcut for inserting both the A and the B changes into the destination, which is a common operation.
Yeah, A, B, and C (and when doing the (z)diff3 thing, Ancestor) are certainly not the most intuitive names for the respective buggers (ours, theirs, result, and base in more Git-ish nomenclature) but it gets clear enough with practice. Not really a defence for bad UI, but eh, computer science is certainly known for that.
As for the "keep both" operation, yeah, that's lacking in ediff. There is one in SMerge mode (C-c ^ a) which of course activates when the buffer has any valid conflict markers, but at least in three-way merges, it also keeps the ancestor which is not usually what one wants.
Although at least when I was doing a lot of conflict resolution, a lot of the times it made sense to merge things by hand anyhow (it was a bunch of mega-merges related to a technology upgrade which had been half abandoned due to lack of time/focus from higher-ups), but I agree that the lack of "keep both" is problematic. Should probably file a bug report.
> I haven't really used the JetBrains merge UI, so I don't know if it's better or worse, but I don't think it's very hard to improve over ediff.
Probably not, but it also shouldn't be too difficult to improve on ediff either. And well, I at least like it better than the JetBrains resolution view or whatever VSCode has
[0]: <https://en.wikipedia.org/wiki/Text-based_user_interface>
For some reason there are a lot of subpar uis though. E.g. not showing three versions, only showing THEIRS and not the remote branch name, etc.
It's still free, too.
Not saying you are wrong, I used to only use VSC Gui for merge conflicts. Then at some point learned to edit myself and just use the CLI. After many many years I tried lazygit (TUI) for merge conflicts while still being in the terminal and I don’t think I can go back to do it manually anymore.
My point is, is this TUI considered graphical?
I would say that my opinion is shared by the overwhelming majority in such an overwhelming way that it’s indistinguishable from fact.
My take: don't play the game. learn your basic required workflow from the command line and use the decent documentation to look up everything else.
Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic.
Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.
With magit I've been able to do things I wouldn't bother before, like reverting small parts of hunks from past commits, doing partial staging of files (not including all changes), and dealing with stashes effectively.
For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.
I can then drill down to each file with the visual diff and see whether the changes are something I want to check in, or just debugging. If it's debugging code, I can click "Discard Changes" to drop all changes I've made to that file. Or I can selectively discard a hunk or discard lines.
When I show these features to command line purists, they always concede that this can't easily be done with the command line. So I don't see what's to gain if I'm losing those features, which I rely on constantly.
I've been working in SourceTree for a decade, so I know all the quirks by now, which I pass on to any new devs who want to use it.
git add -p
?All git add -p does is that last part from what I can tell. I'd still have to cd into each repo and run git status one by one (I've made changes to up to 10 repos before for one tweak), and then do a git add -p to the changes I do want, and a git stash to the changes I don't and then delete the stash.
Scrolling through changes and staging lines is just much nicer with a mouse.
It bothers me a lot that you can't discuss something like this without turning it into personal attacks. People can't just have different preferences than you. No it has to be "elitists" with "stockholm syndrome". This kind of rhetoric is unbecoming of this forum and destroys amicable discussion.
Have you considered that maybe people use the command line because it is better for them, and they recommend it to others because in their view, you'll need it eventually so why not learn now?
You can visualise a git history with a gui tool while still learning the command line interface btw. They aren't mutually exclusive. Do you just use scratch too? Or are you one of those elitists using textual programming languages? Must be stockholm syndrome...
At the same time, I'll go further than you, GP and GGP - I'd say that insisting on coding in plaintext, specifically on always directly reading and editing the same plaintext, single-source-of-truth representation of a program, is fundamentally limiting our ability to manage complexity, and makes people waste a lot of time on faux-problems like "lots of small vs. few big functions", or "exceptions vs. result types", etc.
FWIW, plaintext is still okay for most coding use cases - it's trying to fit everything into the same source code and somehow keep it readable that's an impossibility.
I also found LazyGit recently and think that's a good middleground for doing things from the CLI.
However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.
FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc
The fact there is a book on the subject speaks volumes about how bad it is.
The software analogue would be that in order to use the platform default List and Dictionary data structures you would need to manually manage the links between the data nodes.
Or to use text editor you would occasionally tweak the rope datastructure or equivalent. Etc.
Again, this is not to bash Git. It's a bash on the industry for selecting tool that requires engineers to spend time and effort on non-value adding part of their work rather than offering a solution so simple you would most of the time not even think about it.
Learning Git's infinity CLI options won't teach you that.
Something went very wrong here early on. But, lacking a time machine and a handgun, it's clearly unfixable.
I'm not sure I entirely agree with this. I could see how this could be the case for newcomers to git, but after learning how git works through visual means, I think the mental model of how one should think of git is pretty simple (pleasantly simple, imo). Any complexity that comes from it may be due to how it is used (especially in a team setting).
git log --oneline --graph
If you get tired of typing `git log --oneline --graph`, you can add a `git slog` alias[2] for it by adding the following in `~/.gitconfig`:
[alias]
slog = log --oneline --graph
[2] Or if you want to get fancy: https://github.com/rectang/dotfiles/blob/064b22c42846f8a3f18...
Although in fairness it's quite hard to find a good Git GUI because there are so many bad ones. The only good ones I've found all have some kind of flaw:
* GitX - the clearest design IMO, but it's one of those "gazillion forks" bits of software like TomatoUSB, and Mac only. Plus it has some annoying bugs.
* Git Extensions - I didn't even realise this was a Git GUI until relatively recently because it its terrible name. It's pretty decent, but Windows only.
* VSCode 'Git Graph' extension - my current favourite - it integrates into VSCode too which is much better than a standalone app, especially when using Remote SSH. However it is abandonware and although the source is available, the license doesn't let you republish it so it's not "open source" and nobody can take it over.
Disappointingly even these don't let you do things that a GUI obviously should let you do, like copy & pasting commits, dragging and dropping to rebase.
Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V?
But, they're still miles better than `git log --graph`.
With `--oneline`, it's not perfect but it's good enough to be useful — and by working within the constraints of the CLI, I didn't have to tell people to install software to get my point across.
And I already spoke approvingly of Gitlab's GUI for graph representation! I don't disapprove of GUIs; I use them all the time (particularly Github's). One you grok the data structures that underlie Git, you wind up seeing front ends as interchangeable.
Clunky? Sure, but it suffices to visualize simple branching patters. And no visualizer suffices for gnarly graphs (like a long-lived topic branch that has repeatedly merged in upstream), because the building a mental model of a complex history is difficult even if you can see it.
I basically never used Git command line unless fixing some problems other people created.
It is just insanity when people claim "only proper way is to use command line" - well yeah it is much faster if you work on your branch and just need to make quick series of commits. But as soon as you have to deal with collaboration with other people and organize project, coordinate features etc. I find GUI invaluable and Git Extensions of course.
git obeys $EDITOR, so you can get that like this with whatever text editor you want:
EDITOR=gedit git rebase -i fooYou can do this with lazygit.
Relied on gitk heavily when first started using git. People used to SVN and such will find git unfamiliar and scary.
Once I understood it as a series of revisions where even branches have little meaning, I never used gitk again…
The command line is actually very good if one gets in the habit of using something like “git log -oneline —reverse —no-merges origin/main..HEAD” to see where they are.
A combination of "--all" and "branchname.." shows all descendant commits, and "--graph" shows their relationships visually.
- not understanding branch pointers / staging / committing corrently. E.g. [add file] [modify file again] [commit] - what just happened? (IMO these things could have been named better). Also reset vs revert vs restore - easier to use these if you've internalised branch pointers etc
- git pull fails because it says it would overwrite a file you've never heard of - how is that file on your local? Is it ok to delete it?
- times when you (or your colleagues) need to rewrite history (rebase / squashing etc) - require a pretty good mental model of what is going on to both diagnose issues and to fix them
I agree with rebase on shared branches however, that requires coordination and understanding of everyone using the branch. Sometimes, long running shared branches are needed but it generally something to try to avoid.
I think much of the confusion comes from git log which is a lie. People want git log to be an accurate representation of what occurred.
* a solid understanding of interactive rebasing, including `fixup` and `reword`.
* `git add -p` for adding partial sections of files
* `git commit --amend` for patching the last commit
* `git commit --fixup [COMMIT_ID]` for attaching patches to commits further back in history.
* `git stash` for pausing progress while you fix up an old commit.
* `git rebase -i --autosquash [COMMIT_ID]~` to apply the fixups
* topic branches that never get too big or drift too far from the mainline, because rebasing often becomes infeasible when repo snapshots are too far apart.
* A low enough error rate that you don't screw everything up when rewriting history (which is a reasonable critique and argument for why you shouldn't attempt this in the first place).
I can usually manage this, and efficiently enough that it's worthwhile — and my colleagues appreciate that my PRs are easy to follow. But as a reviewer, I don't insist on other people putting in the same investment.
If you need to do exploratory work and need to share that with someone else, yeah, you will have lots of noise in these commits. Yes, maybe some of those commits wont even build depending on how long your build takes. One approach is to do a "clean room" style re-write with better quality commits (ideal) or likely some rebasing and cherry-picking might be needed - both of which are better than merging all of the noise to the repo.
Taken to the extreme, one could consider every character typed to be what "really happened" but of course no one wants that.
This scales for monorepos with thousands of engineers, too.
Which is precisely _not_ a "just memorise these commands" approach to git right?
Also re: your general snark - try a bit more empathy? I'm sure you are an experienced dev but we are talking about people LEARNING git, they don't have the same points of reference as you do today.
Today there is "git switch" which people say is good for beginners. I have too much git checkout muscle memory.
Do you know how to build a working computer from individual transistors or understand the physics behind it (I happen to know these things personally)? If not, better crack open your modern physics text and study particle in a box, along with the requisite differential equations, calculous and linear algebra just in case you might run into a problem one day.
I will say though that I get really nervous reverting sometimes, making sure I’m using the right command to reset etc can be confusing.
Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. But this is also one of these examples. If I remember correctly, there are other options to sync your remote after you did a rebase, but force push is just the easiest. So I rather take 5 seconds to make sure I typed exactly what I wanted and that everything is fine and that just works.
Edit: I was just brainstorming a bit about it and thought that probably some of the unknown magic git features were just implemented by a motivated dev that just wanted to explore what's possible. But on the other hand, there are most likely some very very obscure configurations and edge cases in the wild where people actually need those features. But most people will likely never need them, so I myself won't bother understanding "everything"
It sounds like you recognise that this is an irrational fear but in case you don't: this is an irrational fear.
I freed myself from the fear of losing data after a rebase when I learned to restore from a commit in `git reflog`. So long as your work made it into an actual commit at some point, everything is recoverable from the local repo's history[1].
[1] Ignoring giganto repos that actually trigger garbage collection.
If I was a beginner, I'll try to get some proficiency early on rather than having to learn the hard way when you're on the middle of a project. It's a good investment.
I've also found that learning crafting nice commits made me a better programmer. It seemed difficult at first but now it's second nature (and I assume that in most teams, one is expected to submit small and self-contained commits anyway).
Same here - I've been using it for a long time without any real deep understanding of it and still no issues. I _do_ believe that there's a "hidden" layer of collaborative functionality that I'm missing out on, but since everybody I work with uses git the same way I do, I suspect that if I did know what I was missing out on, I'd just be frustrated that I wasn't able to take advantage of it.
I’ve written an intro to it a couple weeks back[1] - I’ve been using it since, and so far haven’t had the need to switch back to git at any point.
[0]: https://jj-vcs.github.io/jj/latest/
[1]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...
Really, really good examples and walkthroughs with easy to understand, animated console sessions that show real-world-ish use cases including conflict resolution and why JJ's model makes it easier.
Really good read and easy to digest because of the animated session replays.
My main takeaway is that the missing pieces right now are IDE support for a world filled with detached heads and a foolproof upstream integration pattern on `push` (requires a bit of manual work to designate the target branch).
The Visual JJ extension (https://www.visualjj.com) is also good, but JjK feels more integrated to me.
So I naturally assumed I could teach a team of non-engineers enough Git to enable them to interact with and contribute to text-only repositories as their job required.
I was quite wrong. Git flummoxes some people, and even the best visual tutorials (the ones that helped me immensely), leave some more confused than when they started.
YMMV but explaining simple Git concepts over and over in the face of incomprehension made me a bit of a dick too.
The idiocy that is "staging" is the primary problem with Git. 99% of people do not need "staging" and yet Git inflicts it on everybody.
"Staging" (and "stash") makes Git modal, and that's a pain in the ass.
Having taught people both Mercurial and Git, I can tell you that teaching Git is simply a losing battle. Fortunately, jj operates just like Mercurial but can coexist in the Github ecosystem.
From what I can tell about JJ's split command, it seems like it does the same thing except you're working backwards to split out changes into another commit.
Both seems fine, I just don't see the complexity with the staging area (unless you're a beginner who's been told to only use the CLI at all costs).
Jujutsu's authors have pointed out that a simpler model (here, and with first-class merge conflicts) helps them move much quicker. There are many weird and exceptional states with Git that just don't occur, so new features are more straightforward to add.
Shame Git won so vehemently, most software projects don't need that much power (and guns to shoot their own feet), but cargo-culting after Linus was too strong a lure I presume.
Once you're done with the tutorial bit, the https://learngitbranching.js.org/?NODEMO version is good to try out commands and see what the tree looks like after each command.
W.I.T.A.F.
either way glad you got a laugh ;)
A funner part of the story, I was showing him how to setup VScode because programming using VScode...through RDP. That's right, he was programming remotely on the remote machine using RDP with VScode on the remote screen.
Sometimes just a couple of simple howto sessions can be incredibly useful, especially for teams just starting on a new project. I've given tutorials on Git basics, command line basics, workflow basics, and AWS terminology. Each time I've had engineers say it was like learning computing for the first time, because apparently newer engineers just don't get taught this stuff.
This is partly why I enjoy improving the developer "experience" (DevEx) alongside my normal DevOps duties.
Create a PR, self-approve the PR, then merge it to a develop branch. Then merge the develop branch into main. Then in main make a release branch, and tag it.
I think I treat "PRs" on my own projects as pretty much the same as tags or commits - they require pretty much the same amount of documentation and description as a PR to a third party if they are meant to be meaningful to myself in a few years time, after all.
Aside from that, you've more or less described my workflow for solo projects.
I just like to see the diffs on the github UI. <shrug>
Personally if I'm working by myself absolutely not, commit straight to main or a feature branch, life is way too short.
There's this whole class of capable engineers (some at senior/staff levels!) who just never had to build good Git habits or learn how to think about the different options that Git's command set provides, because their workflow didn't demand it.
Curious - do you think that's mostly a tooling/culture thing, or more of a learning gap, where they just never had a reason to dive deeper?
Part of why I'm making these tools is to explore if a more visual approach might make some of those concepts stick better. But curious what you've seen actually work in practice for helping people improve their Git skills.
It would be like not knowing about loops or how to print text to the screen or how to do I/O. People seem to think you can be clueless and somehow still deserve a programmer's salary. The entitlement baffles me (and I've experienced a lot of it from people throughout my career).
A staff SWE who can't send you a patch is simply unworthy of their title, the way I'm unworthy of the title "pilot" or "doctor" or "attorney".
From the outside, it feels like "low effort" all around. But to be honest, I can't really blame who does this. For some, it is just a 9-5 job anyway and they prefer not think about these stuff outside that 9-5 space. Deep diving into their tools might look like "wasted time" on their view.
A friend refered me to this great post a few days ago that touches on this subject: https://josvisser.substack.com/p/you-cant-teach-caring
In my company, we use mercurial so I can imagine that some SWEs aren't fluent in Git because they've used different tools. But apart from that, Git isn't rocket science. It takes a bit of practice like anything else but anybody should be able to know the basics in a few days, and become proficient after a few months of regular practice.
That handles 98% of what I need to do. For the remainder I sometimes stumble pretty badly, but figure things out.
I use Jujutsu for 100% of my version control at my day job, where all of our repos are in Bitbucket and all my coworkers are using Git. AFAIK most of my coworkers don't even know I'm doing anything different, other than those who I've "evangelized" so far :)
...I think my PRs have gotten noticeably cleaner and easier to review, though!
These tools have better CLI for sure, and some nice added features too. VCS-integrated collaboration tools in fossil is nice. But my point was more along the lines of "why don't we have a radically different architecture that is better matched to the problem domain?"
Even when using the Git backend, it's only commits and lower-level objects that are stored in the Git repo, and even some parts of the commits are stored outside Git (e g. the change ID). The operation log (which powers the undo feature) is also not stored in Git.
Commutativity of patches is neat, but it's just not that big a deal. I think Pijul's best feature is first-class conflicts, an idea that Jujutsu has also incorporated.
Torvalds dreamed up Git in a weekend, and it's radically different from the patch-tree stuff that came before it. It's not taken over the world for no reason.
We can do better though. Patch theory shows that we shouldn't even need to care about commit history, for example. If we could just get off the tree-of-diffs model.
That's exactly what Git's innovation was, though. It doesn't work with patches or diffs, it works with (essentially) snapshots of the tree, and how they are related to each other.
You need the commit history, because that's the fundamental point of the VCS. Linux devs need to be able to demonstrate the provenance of each piece of code in the tree. That's the problem that git exists to solve.
> it was a bad, but performant copy of monotone's DVCS UI/UX.
I don't think the UI is what makes git, git. AFAIK Torvalds didn't put much thought into workflow or UI design - that evolved later. It's what goes on inside .git/ that's the innovative bit.
What I believe the GP is referring to is commutativity of patches. Personally, as someone with many years of source control experience, I think commutativity is very far down the list of what I think needs fixing.
One of the main jobs of source control is to be able to answer discovery requests when lawyers come knocking. You really need an effectively immutable history of published work for this.
Not everyone is affected by this. I recognize that my use case isn't the median case. But it is a massive and entirely unnecessary burden.
The git CLI has some rough edges, but once you have concepts of work tree, index, commits and diffs down, it is extremely powerful. magit in Emacs is also incredible.
None of the concepts behind git are difficult to grasp, the problem is interface and leaky abstractions all over. Any person that mentions reflogs is actually saying I don't understand any of the points above.
Because learning how a software model a particular problem domain is a great step towards efficient use? You can hope it's magic, but that's a recipe for failure if you're a heavy user. Every professional learns the ins and outs of the tools he uses often.
> The problems with Git are many, though. Most of all, its infamously terrible command line interface results in a terrible user experience. In my experience, very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. The common rejoinder is that developers ought to learn how Git works internally — that everything will make more sense that way.
This is nonsense. Git’s internals are interesting on an implementation level, but frankly add up to an incoherent mess in terms of a user mental model. This is a classic mistake for software developers, and one I have fallen prey to myself any number of times. I do not blame the Git developers for it, exactly. No one should have to understand the internals of the system to use it well, though; that is a simple failure of software design. Moreover, even those internals do not particularly cohere. The index, the number of things labeled “-ish” in the glossary, the way that a “detached HEAD” interacts with branches, the distinction between tags and branches, the important distinctions between commits, refs, and objects… It is not that any one of those things is bad in isolation, but as a set they do not amount to a mental model I can describe charitably. Put in programming language terms: One of the reasons the “surface syntax” of Git is so hard is that its semantics are a bit confused, and that inevitably shows up in the interface to users.
There's no excuse. Either learn git, or stop using it. If you can do neither, stop complaining, because plenty of people use it just fine.
And no, you really don't have to understand the internals to use git, but you DO need a mental model of what's happening: what a commit is, what a ref is, what a branch is, what merging/rebasing does, etc. These don't involve knowing the internals, but they do involve maybe reading the manual and actually THINKING about what is happening.
Too many developers confuse not wanting to think about something with that thing being difficult. I learned git one summer during a college internship 15 years ago, and I've been fine ever since. I am really, truly, not that smart, and if I can do it, so can you.
Everyone needs to just quit their bitching and actually learn something for once.
Git exposes a great deal of unnecessary complexity. Any honest appraisal would recognize that.
Look at Jujutsu. That is a tool that is truly designed putting the user first, rather than just exposing the internals as the user interface and calling it a day.
> Do not tell me that it’s the developer’s responsibility to memorize a thousand strange exceptions and surprising behaviors. Yes, this is necessary in any system, because computers suck. That doesn’t mean there’s no upper limit for how much zaniness is acceptable in a system. PHP is nothing but exceptions, and it is not okay when wrestling the language takes more effort than actually writing your program. My tools should not create net positive work for me to do.
[0] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Then, suddenly: your stash pop has failed! Something has been left somewhere! You need to git add something! Output of git diff is empty! Why is it empty, did stash not apply at all? (you run git stash pop second time, and feel terror) It recomends you to run git restore --staged! Was restore not kinda reset that wipes your local changes? Stash was your safe space, the only git thing you felt sure about. You feel abandoned.
Next time, build script breaks only for you! No idea why! Turns out a day later the script cannot deal with worktrees you set up last year when you tried to "learn git"
Some time later lead emails about "scrubbing prod creds", "force pushing HEAD". You run attached commands with fear and awe.
Next month, you end up with a detached head! It sounds painful! Half stuff does not work!
Gradually you are being conditioned that git equals pain. Sure, other tools have it worse (hi ffmpeg!), but they don't spring it on you in a middle of a big change you are trying to keep in your head, only to be forced to take a sabbatical and learn seven circles of reset because a wild tag merge conflict has appeared, or your lead wants you to use rerere to rebase your branch after splitting one commit into three.
As you say, it is not unique to git. Bug trackers, system updates etc. also can "disrupt flow" and take a lot of attention away from the main work. But git is unique in the insidious way that it springs such hard problems on unsuspecting developers that are busy *actually working*
You could make the mental model easier to understand by centralising the state and switch to pessimistic locking instead of optimistic. But then you'd have to live with the downsides of those, like git's predecessors.
In practice most people use it as if it does - the remote is "preferred". Which isn't such a bad thing if you know how to use branches and resolve conflicts properly.
Best practice is to create a new branch for each feature, then create a PR into the proper branch.
Early on in development it can be very chaotic as so much code is changing so quickly. No revision system is going make up for a lack of communication and division of responsibilities.
It's brilliant for it's original purpose of managing diffs in an open source project.
For industrial projects that are not organized like an open source project it's a massive, massive footgun and it saddens me it remains some sort of badge of honour to memorize it's incomprehensible UI.
It saddens me even more it's the goto vcs system even for industrial projects.
I'm actually shocked to see this many comments on this site with this opinion. Maybe that's a sign that there's just a lot of charlatans here.
I do agree I’ve often wondered about my career choice after being forced to use git.
Any other VCS system I’ve used bar some old unix tools offer much better usability. For example Perforce and TFS were much better. Even Subversion and Mercurial offer better ergonomics.
Git is probably great for the type of distributed projects that spun it (ie Linux kernel).
Most industrial projects are far more centralized and streamlined. Hence git brings in added complexity that is usually not needed.
Luckily it’s not so b - oh damn I git pulled and now my colleague did something and git says ”fatal: Need to specify how to reconcile divergent branches”. Which is the type of clownshow level of VCS which incites these comments.
The merge tool works pretty well.
Also, my company has large repositories.
+ Lithium batteries
+ Battery management systems
+ Embedded coding
+ CAN-Bus communication
+ Inverters & DC DC converters
I made my own electric cars and am now sharing everything I learnt in a series of mini games & flashcard trainers. Duolingo for learning energy tech:
There are so many abstract concepts that could easily be taught with a string of 2-3 Minigames that don't have to be harder than the average balloon pop game or a portal2 puzzle.
A while ago I played a little game that taught you vim commands and let you traverse an RPG style landscape doing it.
Keeping the reader/user in the zone between being bored and overwhelmed while you teaching them, without knowing something about them (only data as feedback if they are using a tool that you built,rather than them raising eyebrows or nodding in a classroom).
I think it's hard but also fun. For the EV stuff that I look at there are a few problems compounding this:
+ Overwhelming buzzwords and complexity
+ Wrong intuition for HV systems
+ Unclear where to start
+ Capital requirements are high
+ Dangerous tech
Also, where did you get your battery(ies)?
Stack was leaf batteries, motor & inverter with our own gearbox modification (swapped direction), inverter with Openinverter.org Tesla model S A/C charger, Tesla DC/DC and then my own STM32 based control unit orchestrating all that.
Send me an email please, if you work in or with big auto I want to show you more of the app and get your opinion!
* pull
* push
* checkout / switch
* commit (ofcourse)
* merge
But I will end up needing
* log / log --stat
* stash
* diff
* show / show --stat
* blame
* revert
* cherry-pick
* reset
* git grep (can be replaced with rg / grep -rn)
I can't imagine not having these commands now.
If you use something frequently you should know it in-depth. It applies to tools (git, VSCode), frameworks (Spring, Django, whatever), infra (kubernetes, docker). otherwise you're missing out.
Git is definitely abstract and hard to get the hang of but totally worth it - pays dividends in terms of the options it puts at your disposal. And the stimulating nature of learning how it works so that you can think for yourself to figure out a solution, instead of just memorizing 3 commands and running to AI for help when you get a little stuck.
I prefer to remain oblivious to many things. Two views of the Mississippi and all that.
Git works reliably and achieves my humble expectations. Thanks git.
But in reality I use about the same set of commands. The exception being ‘cherry-pick’ which I avoid solely on disliking the name.
- pull
- push
- commit/checkout
- merge
Quality of life:
- stash
- diff
Asking for trouble:
- revert
- cherry-pick
Your definition matches my mine of a tight subset of git.
This was my approach for my first few years of git. I always tried to approach git via its commands, and I horribly failed - until I finally took a little bit of effort to understand how git actually works under the hood, which really made it click for me.
For anyone who has ever spent a modicum of time (e.g. while getting a CS degree) trying to understand datastructures, it's probably really straight-forward to "get git". The datastructure underneath is really quite simple. A branch is a pointer to a commit, a commit is a pointer to a tree, a tree is a list of pointers to other trees and files. That's already pretty much all there is to it.
Once the datastructure of git is understood, the commands start to "make sense" on their own - at least most of them. They still have tons of obscure options that one doesn't realistically need in a daily work flow, but the general idea what the commands do (and how to recover from screwups) was, at least for me, pretty simple after understanding the datastructure.
Would I like to know more about the underlying ideas of Git. Yes. But the time it would take me to do that is time I can spend on other things, like the stuff I am actually paid to do. If I become a git guru, I might get a pat on the back, but more likely no one would care. If I deliver more stuff, people who use my stuff actually appreciate it.
Maybe a lot of people don't care about that, and I guess everybody has their threshold, where as long as they know the minimum required to do their job they can stay in that comfort zone typing the same commands over and over.
Single executable you just download and put in your path. Sane, well-documented interface (CLI, API and web). Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code. Easy exports to git/github.
I think it's kind of a tragedy the dev world got so stuck on git.
I fixed it (PR coming) with some simple non-git directory traversal functions, which enables the cool features again.
But makes me wish the dev world knew git alternatives exist.
git add -A, git commit -m, git push
If there's an error because there are changes on the remote, type:
git pull, fix conflicts in case there are any, repeat previous commands
In all other cases, google/grok for the solution, doesnt happen often.
If you ever run into a case where something is broken (that you can measure, like a test or broken build) but it’s not obvious what change caused the fault, first go to a commit where you know the fault is present.
$ git bisect start
$ git bisect bad
$ git checkout abc123
$ git bisect good
It will keep jumping you to the mid point between the nearest bad commit and good commit till you end up at 1 precise commit that caused your fault.
This works extremely well for configuration changes specifically, where maybe it doesn’t break in CI, but on your local dev machine it does. You can also use this for non-text files like images to find out when 1 part of an image was changed for example.
—
Also if you just want to make normal SCM stuff easier,
$ git commit -Am "…"
One of the things I'm trying to explore with these visual and gamified tools is how to help newer Git folks or even users who mostly live in that commit/push/pull flow get a clearer mental model of what's actually happening under the hood.
Git has a really wide breadth of functionality that is kind of interesting on its own merit, but also useful for a plethora of different tasks. For better or worse even Git experts can always find ways to expand their knowledge :)
"commit all files and add a comment" = `cam`, "also push" = `camp`
> cam "fixed bug"
alias cam='git commit -am'
function camp() { git commit -am "$1" git push }
I acknowedge that the inconsistent argument style looks clumsy when remembering `git log --name-only --oneline`. However, I value the workflow afforded by the stage: I can keep work for several tasks in my workspace until I am ready to commit them.
I've checked Fossil, Jujutsu, and Mercurial. Each disavows the stage. I understand that it takes more discipline (and I occasionally fail to adhere to that discipline). But, I'm not interested in the other features of a vcs if it forces me to work on only one thing at a time.
For Jujutsu, there's two good options I know of:
1. Use "jj commit -i". This opens up a screen which lets you interactively select files/hunks/lines to commit. You can also pass in a "--tool" commit to use something like Meld.
2. Use the "squash workflow" - basically making your own staging area using jj's flexibility. I can't explain it better than Steve does: https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
It’s a shame there’s still nothing quite like GitHub for Mercurial (anymore), where anyone can just sign up and create repositories. Heptapod has a public instance for FOSS, but it requires approval to create projects. There’s also a separate hosted instance for basically anything, but it’s commercial and costs money. One can also self-host, but GitLab is not exactly lightweight, and other solutions aren’t as integrated with evolution features.
maybe if someone rewrote it in rust it would be sexy again? rurcurial?
They have and it's called jujutsu :-)
OK, it's not a Mercurial clone, but it did take some features from it, and using it will feel more like Mercurial than git. And you can use it on git repositories, so you can have your cake and eat it too.
Single executable you just download and put in your path. Sane, well-documented interface. Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code.
I think it's kind of a tragedy the dev world got so stuck on git. Maybe not too late!
I was using bitbucket and mercurial for a while! If fossil had something similar (which off the top of my head, I think they do? Something wiki-like for the SQLite project) I would be willing to mess around with it on a small team or something.
[0] https://www.oreilly.com/library/view/version-control-with/97...
But perhaps they'd a good reason to go the route they did. Very interesting concept, anyway.
Devlands can do so much more (it's can simulate, run, and visualize any command or scenario that can happen in Git within the context of any local repo) and in a much more intuitive way.
When I deliberately spent time to learn the foundations of it, it blew my mind how incredibly sophisticated it is and how intuitive it becomes once you understand the core ideas behind it
Highly encourage reading through the official documentation and Julia Evans blog posts on git.
There was nothing stressful about it : ))
I will often do multiple commits but they will be all at once as I go through and make a commit and include any relevant changes in the commit.
It's quite natural to wind up with a bunch of work that really needs to be in multiple commits. I don't think this ever changes for most of us.