Yeah, "undo the last thing I did" - There is no button / single command (as far as I know) - you google and get loads of "if this, do this, else this" - dang, I just want to undo and get on with what I need to do!
If the last thing you did was switch branches do you want to undo switching branches, or undo the last thing you did on the branch?
If the last thing you did was stage, do you want to unstage, or undo the last change outside the staging area?
If undoing the last thing you did is not compatible with the current state of the working copy, what happens?
If your last change was to discard or apply uncommitted changes, how can that be undone? If the answer is "do lots of hidden commits", how does that interact with undo?
Visual Studio, for example, switch, stage - it makes the option obvious (bring changes, or discard?), got no problems there, un-doing something that I have committed - that is what I am mentioning, no easy to undo... (is it local stage? do this, did you push? do this..., have other people in repo got the changes, do this, etc...), got shiz I need to be doing rather than reading these details ;)
I completely agree. Some commands are not intuitive at all. I always wanted git stage [file], git unstage [file] instead of add and reset.
I totally understand why those were chosen when the original code for git was written but I really think it's time to re-evaluate the CLI and do better.
I think the Git maintainers realise that and introduce commands like "restore", even though the action can be (and was for a long time) achieved with the original command set.
Because git commands are used in a bajillion scripts, it's very hard to remove "excessive" functionality from the old commands even when that would improve the orthogonality of the tools.
Git's documentation should somehow prominently teach people that:
- Git stores snapshots, not changes.
- Snapshots go into something called an index. "Git add" means to add to an index.
- A new commit is prepared by creating a new index based on the index of the HEAD commit. This new index is the "stage". The index holds a complete copy of the files. When you stage only certain changes with "git add --patch", that is still the case: you're making a version of the file which has only those selected changes and that goes into the index. A built-in tool that is external to the git representation did the text manipulation to separate those changes.
- When you commit, the uncommitted index you have created as a stage becomes a commit.
If you let git know about some file that was previously not indexed, and then do a "git reset --hard", that file is gone. (You can find it if you dig through the git object store with some obscure commands.)
"Consider the expression 1/3 + 25. In PL/I this expression has the value 5.33333333333. Why? One-third is computed to 15 digits of precision, 14 to the right of the decimal point. Then 25 is coerced to the same precision, losing the most significant digit 2! This does raise an error in PL/I, but the default is to ignore it."
Undo is one of many fundamental usability shortcomings of all (commonly used) CLIs. Also includes feedback, consistency, system status, discoverability, actionable error messages, etc.
See https://github.com/martinvonz/jj for a VCS that's compatible with Git and has a simpler CLI with undo functionality and first-class conflicts (you can rebase conflict resolutions, for example). It's what we're planning to replace Mercurial with at Google.
I've been trying to get people I work with to use git for years (technical, lots of light coding but not really software development) and this really resonates. I guess part of the problem is that we are very used to everything being centralized. People seem to think of git as a web service that my company has purchased a subscription to, not as a tool that exists and can be used regardless of whether there is any centralized company repository you can push your commits to.
When people ask me seemingly simple questions like "how do I delete a branch", I feel like I have to give them a lecture on the philosophy of git, which I then decide not to give, because it's going to make me sound like a smug neckbeard. However, the fact that such a lecture would actually be needed, is just a sign that centralized software has taken over the public mindset. Actually, the situation is sort of similar to when you try to explain people how to use IRC or Mastodon.
I struggle with the "required lectures no one wants to hear". I know that they need to hear the lecture but I also know they don't want a lecture, delivering unwanted lectures causes people to dislike me greatly and assume I'm a smug neckbeard when really all I want is for people to have the knowledge I have.
Simply not delivering said lectures has it's own downsides but seems to be the best strategy if you care primarily about how well liked you are.
Mind you this isn't everyone, it's maybe 50% of people and certain personality types really don't like receiving information in that format.
There are also those that think the same way and reciprocate in kind when you have a knowledge gap, I really appreciate those people. They also are better at communicating what they actually do know so you can reach a shared understanding with them faster.
Network effects for distributed VC are quite weak, it's one of the reasons git was able to displace alternatives relatively quietly, and why mercurial is able to soldier on despite git's visible dominance.
I'm sure it is. For the few people who use it. Once upon a time, it was the dominant versioning system out there. But it was supplanted by git. And it was supplanted for a reason. And network effects didn't protect it from being replaced by git.
It's unfair to consider network effects when it comes to SVN because it was a very different time on the internet with no major centralized code hosting SaaS like GitHub.
Nowadays even companies (that would in the past self-host) rely on SaaS and are thus swayed by network effects of whatever is popular.
Things take time. And nobody wants to get into some dead end for something that doesn't take off. But people did move from cvs/svn to git, so making the leap to something new can happen, even if it hasn't happened yet.
People in this industry think they're super duper extra rational instead of largely a bunch of cargo culters. "This tool meets the Linux kernel's hyperspecific needs that have approximately zero applicability to my piddly little centralized project, looks like I have found the tool for me!"
That's an interesting take. Having been in the midst of this, it wasn't at all clear Git would have won (against Mercurial and Bazaar, at least in the free software world).
There were two main factors contributing to it: Linux Kernel switching to Git, so open source people had to deal with it anyway, and an even bigger factor, GitHub offering a (free) streamlined UI for those most common GitHub operations (basically, making it not-hard). If you compare GitHub to Mercurial hosting web sites of the time, one was decidedly 90s/MySpace like, and another was modern, Facebook-like.
IMHO, without GitHub, git does not become the dominant VCS it is today.
Yeah that is certainly possible. We could have ended up in a world where GitHub was actually MercurialHub and git probably would have remained the VCS of the kernel and probably many C and C++ projects as a result but much of FOSS (especially the new at the time JS movement) could have ended up on Mercurial instead.
I wouldn't call it hard. Overwhelming when you're first learning, maybe. But that could be said for lots of powerful tools. This post feels like a veteran pilot talking about how new pilots are overwhelmed with how many buttons there are in the cockpit.
The only issue with that take is that there are equally — if not more — powerful tools that are not as overwhelming as Git. Mercurial and Bazaar spring to mind.
Git is an incredibly powerful abstraction for decentralized version control, with the absolute worst damn user interface. I am constantly required to be aware of its internal state and implementation details, which it fights so hard to hide.
I am not sure that's really correct: while Git is internally pretty powerful, it's by no means incredibly powerful.
Eg. one of the obvious missing features (for a distributed VCS) is nested history (i.e. in Bazaar/bzr, now brz, you'd keep "subcommits" when merging, without them overcrowding the main "bzr log").
Basically, while advertised as being distributed, you are forced to either rebase or squash-and-merge to keep a clean commit history, which is not how humans operate: basically, I want to have a gazillion tiny commits if it's a distributed system (iow, use it how I like it), but not have those show up for a single top-level change.
Also, internals do drive what UX you can have: this is evident even in web applications (eg. if you've got a particular backend REST API, you might not be able to achieve some UX workflows without reworking the backend too).
> I am not sure that's really correct: while Git is internally pretty powerful, it's by no means incredibly powerful.
Good thing neither "pretty powerful" nor "incredibly powerful" have formal definitions ;)
> Also, internals do drive what UX you can have
Yes, but that's not what I'm talking about. Git just has bad UX. There's no reason why creating a branch can't be part of `git branch` rather than `git checkout`, but that was an opinionated decision that every user just has to deal with now. Or, why does `git stash pop` immediately stage changes if there's a conflict, but not otherwise? Yes, there's always a reason behind these choices, but they prioritize some concept of "purity" over UX. The result is a tool that has spawned a thousand "learn git" tutorials because it's so user-hostile.
This is definitely the real question always underlying this topic, but maybe more charitably: how typical is a collaborative development experience vs. a single-step hierarchy with blessed releases? Is there really a practical argument to learn it, or only moral and aesthetic ones?
I don’t think of “naïve” being an uncharitable. It’s just the difference between the way a problem appears to someone unfamiliar with it to the model they form after they’ve worked it out.
As I wrote in my other comment, typical person's mental model is centralized. They expect there to be only one, centralized source of truth for everything
My impression is if you think in terms of it automating the process where developers email patches to Linus and his minors who then review and commit and merge it makes somewhat more sense.
That’s the beauty of git though. You can do any workflow you want locally (including with no internet) and slice and dice however you need to push your work back to the team.
The reason git is hard to learn is because people when starting think it should be easy to learn from the commands, which it isn't. The way to learn git is to understand its data handling. Then you can group the commands. Once you have a mental model that closely matches how git works, things fall into place. Of course the learning curve could be made easier by naming some commands closer to the data that it handles, but I prefer short commands for common operations.
The best way I learned git was by browsing the files and contents of those files in .git/. That way I had an idea of what's possible and what I wanted to do and could find the command to do it.
I hear similar difficulties from some who learn databases from using ORM syntax and don't have a mental model that matches how relational sets compose or how SQL is primarily declarative rather than imperative.
It's easy to forget how unintuitive the git model is after you have used it for a long time. It is quite unintuitive. Especially because many use it in conjunction with GitHub which centralizes the decentralized model (and causes impedance mismatches along the way).
But, it does feel like a big upgrade over the past iterations of version control like svn.
You’re not wrong, but I think it’s mostly a result of bad porcelain. I did 8 years of CVS and SVN at the beginning of my career, and I remember viscerally how within 6 months I understood the internal behavior of git better than I ever did after nearly a decade of Subversion and predecessor.
IMO the git model is an incredibly high power-to-weight ratio for what professional software engineers need, I just can’t get behind efforts to water it down for easier onboarding. No one would suggest professional chefs replace their knives with preformed vegetable slicers from late night TV.
This. If new users had the git model itself explained to them, rather than tell them to do their work and learn git as they go (giving them blind commands to type here and there), things would be much better off.
It's even more complicated now with github and IDEs having a UI that abstracts over git's abstractions.
Git is pretty hard, but the examples in the post are _terrible_. The specific cases are actually pretty easy to explain:
Undo the change: "The recommended approach is to make another change which undoes the original one and push it, using command AAA. If you want to un-push the change you made and pretend it never happened we can try it as well, but Git does not really expect published history to change, so but if someone else on your team has already pulled it, their machine will get pretty confused. It's like deleting email right from someone's inbox -- OK if they haven't seen it yet, but pretty confusing if they read it and already typing the reply"
Delete the branch: "Does that branch exist on a server?". Depending on the answer, you either delete remote branch + local tracking one, or just a local one.
The key idea is to have a workflow in mind, and steer users towards that workflow. Because sure, you can ask user if they want to "delete a local branch, and then just get it recreated when you pull again".. but that's terrible idea. Why would you want to do this _ever_ as part of any regular workflow?
There are certainly circumstances when you have to do advanced/unusual stuff, but there is no need to push that to novice users, unless you hate git and your goal is convince them that the git is hard.
> The key idea is to have a workflow in mind, and steer users towards that workflow. Because sure, you can ask user if they want to "delete a local branch, and then just get it recreated when you pull again".. but that's terrible idea. Why would you want to do this _ever_ as part of any regular workflow?
I've recently tried to guide someone to fix their bad branching strategy, and after a few of their bad attempts, just suggesting they remove their local branch and then refetch it from the published repo instead (just imagine how easy it is to figure out what commands-people-have-blindly-typed-in-from-the-internet have done, and then reverting that with git).
Going back to a known good state is the most common of all debugging tools (also part of more advanced tricks like bug bisection search — interestingly also present as `git bisect`), and with it being too easy to mess up your local repo, going back to a remote that's "clean" is sometimes the fastest approach.
> ...but Git does not really expect published history to change...
That's a weird statement for a tool which has had `rebase` as the very basic command from the get go.
Git does expect history to change, it's publicised as a solution to a bunch of issues: basically, there is no getting around understanding the Git internals, and even once you do, it's hard to remember how GIT cli commands tie into those internals for things you seldom use because of their arcane naming.
It‘s old, but my favorite way to think about it still is Git = MacGyver, Mercurial = James Bond. Seems you prefer the flexibility of "I get the job done with a paperclip and a lighter" over the bespoke Q-Branch gizmo— obviously, many people do!
IMO this is a fairly deep correspondence. Git and monads both side in the rare octant of "simple, hard, relevant to nearly every programmer's work even if they're not very aware of it". Most quotidian things are simple and easy, or complex and easy, or complex and hard. Most simple and hard things are at the foundations of fairly deep knowledge/skill stacks and obscured from most developers.
People in general are cultishly attracted towards instantiating centralized solutions to solve their problems. Simultaneously, they're blind to the long term negative effects that come from creating it, mainly:
- the developed overdependence on it for a particular service/function
- the societal mental lobotomization in terms of developing non-centralized solutions
- the incoming naivete of the next generation into assuming that it'll always exist & be there, and not planning for the worst case scenario
Referring back to Git, part of the reason could be that they assume a canonical "true" repository, which runs counter to how Git operates.
--------
Nevertheless, Git's UI could be cleaned up significantly: VS Code wise, Git Graph is a personal favorite of mine because of how well the plugin renders the commit graph for you.
Git has some really good ideas that are hard to translate into a good UI. There exists several companies that implement UIs for git that are great - Kraken, Github Desktop, etc. There's nothing better than magit but few people use emacs.
The author mentions this near the bottom but there's already some great porcelains for git.
This seems to be a somewhat unpopular opinion here because everyone who visits this site is a l33t hax0r 100x rockstar programmer who can code the entire functionality of Facebook in a weekend and would go on a personal John Wick vendetta against you if you insulted them with a salary offer of less than ten million dollars a year but I really think, especially when you're starting out, most people should just use a graphical git client like Sublime Merge, Git Kraken etc. I struggled with git for a while and found that using Sublime Merge made my life a lot easier and later improved my comprehension of git at the command line because I had a better feel for what was going on. The majority of people prefer visuals to symbols, it's a bit odd that most beginner tutorials insist on teaching git via the terminal.
Maybe unpopular, definitely couched in unnecessary hyperbole, but otherwise I agree. Whenever any dev has ever come to me with any git problem, my first suggestion is to try a GUI. They all only expose a subset of git functionality, but IME that’s almost always a good thing: the happy path is narrow, and going off the happy path is frictionful. But if you absolutely need to, the CLI is still there for whatever you need to do.
I'd like to see a graphical educational program, mainly for adults, that takes an arbitrary git repo and shows you what different git commands actually do as you're doing them. Having an interactive visual aid would alleviate most confusion IMO.
Git is a tool that can do so many amazing things, things that might even seem impossible the first time you learn of them:
- not only saving changes to files as an ordered log, but being able to reorder those changes as if you'd made them at a different time (git rebase)
- merging multiple, conflicting changes to files made by different people (git merge)
- homing in on a specific change in which a bug or a feature was introduced (git bisect)
It's not unreasonable that such a powerful tool might come with a cost. Considering the time that it takes in other professions to learn the tools of the trade, I consider Git to be a pretty good deal!
Personally, I found my understanding of and proficiency in using Git improved dramatically when I decided to resist the temptation to delete the repository and start again whenever I had a 'merge conflict', a 'missing remote' or a 'detached head' (yikes). Instead, I tried to work through the problem step-by-step, learning about such things as ref logs and branch tracking and the distinction between the work tree and the index. It was fun, informative and didn't even take that long in my opinion :)
I think that for such a widely-applicable task as distributed version control, Git is a fantastic piece of software, and would recommend every software developer take the time to learn it, keeping in mind that only a few centuries ago, a stone-mason might spend years learning to use a chisel, or just in the last century learning how to use a powered lathe. I see Git as the programming equivalent of the lathe or chisel - equally fundamental to the trade.
For those who aren't programmers (and thus don't feel the need to study Git in such depth) but still want to make use of version control, git-annex[1] provides one nice way to put binary files like MS Word documents into a repository and synchronise them across devices.
Hey! This resonates :) My friends and I are trying to make it less hard - with a UX tailored to workflow at big tech companies (trunk-based development): https://www.trunkflow.com/ - would appreciated any feedback!
One main misconception that leads people astray (sometimes) is the belief that commits track changes. You have to understand that commits are snapshots.
All activities involving diffing, merging and conflicts and such are operations built on snapshots; they are external to the core git representation.
At the very least, from the top of my head: add, clone, checkout, diff, log, tag, show, status.
But it's not really about the number of subcommands, but rather how complex some of these subcommands are. e.g. git-commit(1) is 655 lines (and references other pages, too). hg's "help commit" is 59 lines, or 98 with --verbose (this also references some other pages, so it's not all you need, but it's indicative of the relative complexity).
Thats what 95% of people are doing with git but the fact that git has so much more complexity built into it to get to those simple operations is what the author is talking about. Although that tech is cool, it does have a lot of complications.
Anything more complex than the trivial pull/commit/push workflow forces you to google stackoverflow or read a long manual page for a command with tens of options, and the lingo there is full of weird stuff like “refspec”, “reflog” and “detached head”.
> Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.
I'm not quite sure what is safe and what is risky.
My brother in Christ, why should I put in the time and effort to learn an auxiliary tool to my job?
Also, let me tell you from first hand experience: I disagree with you. Let me tell you a few things about myself, just to paint a picture... I managed to gain admittance to a special math high school class with like ten kids fighting for every seat. Later I got a math teacher masters. I have been a member of Mensa for a few years. I learned Z80 assembly when I was 12 years old. Prolog when I was 15. When git came ... it was an absolute impenetrable brick wall and let me emphasize, a directed acyclic graph is not exactly an alien concept to me. It was not until Charles Duan's git tutorial that I felt I am comfortable with it. https://www.cduan.com/technical/git/ All this to say: it is hard.
> why should I put in the time and effort to learn an auxiliary tool to my job?
Auxiliary? I can’t speak for everyone, but VCS has to be up there as the most important development tool on my machine. I’d sooner uninstall my IDE than git.
No doubt it’s hard, but sitting down and making a concerted effort for a few hours does wonders. That’s not much of an ask for something most devs use every day.
If git is an auxiliary tool, your entire programming environment and language are "auxiliary tools". Today being able to persist and distribute multiple versions of source code is table stakes for being a programmer. If we're really talking about "jobs", that's probably more central than writing code - a release manager might do nothing but manage git minutia and still provide value, a programmer that can't give anyone else the code they've written provides nothing.
Your comment comes off as arrogant and patronizing. I don't know if that's you you meant it, but I'm going to assume so because it's fitting with your other comments.
> My brother in Christ
disingenuous start, this will be interesting...
> why should I put in the time and effort to learn an auxiliary tool to my job?
if you think git (or version control) is auxiliary tool then you have not worked on real software. I'm not saying this is you, but IF it's you (or anyone else reading): Writing side scripts and minor modifications on an existing project is not building real software, it's hobby coding, which is fine but you don't get to act like a software engineer. You're as much an engineer as someone cooking a random meal once a week is a chef.
> I learned Z80 assembly when I was 12 years old. Prolog when I was 15. When git came ... it was an absolute impenetrable brick wall and let me emphasize
Did you consider maybe that your "learning" of z80 asm or prolog was not complete? or possibly faux, false, fake, or gasp you're might not be as smart as you think? Or that when you were a kid you had way more time on your hands than now? The possibilities are infinite for an explanation (that is if what you're saying is true). "OMG Git is hard" is not one of the first 100 reasons that come to mind.
> It was not until Charles Duan's git tutorial that I felt I am comfortable with it
That's a good tutorial, but you never get comfortable with Git (or any other technical subject matter imho) until you work with it, and it will take practice and -sorry to say- humbleness in that you (or anyone else) can have hard time understanding something that many others find simple. It doesn't automatically mean it's a hard subject because you find it hard.
Git is _not_ anymore hard that any other abstraction. You work hard you learn, you don't you won't.
Git is terribly complicated, and it's not easy to remember how to do things off the beaten path. But Git is also light years ahead of whatever we had before it.
git's not hard, it offers more power than the hypothetical user you're describing wants. and they dont have to use it but they'll be grateful its there
This blog entry is a gentle and accurate rant/observation on git usability: it's still not working, so why do we put up with it?
I would recommend the comment by edblarnes:
> Git is a brilliant data model that we hack into being a code repo.
> It was designed from the model backwards, not the use cases inwards
Git can do a million things no one uses it for. It practice, teams develop and teach a happy-path workflow, and then for other things they drag in the git expert. But users do random walks through git operations, wasting everyone's time.
Design-wise, it's 80/20 again: most teams mostly work with gitflow-style workflows, with various rules -- AND most have some tiny variations they work in, so there's minimal capture of workflow.
As an aside, my gripe with git is text diffs and commit histories. It's simply too hard to understand changes and to review code when you have no control over the granularity of the change and are forced into per-commit granularity of comments (and even those are lost in squash).
At the very same time that we want to increase code velocity, teams have to impose e.g., 500-line limits on diffs to keep code reviews manageable. This slows change to tiny incremental steps. But they're only undigestible because the actual change is lost in the details, and commit comments have to decide between high-level changeset overviews or low-level file change descriptions. We need to zoom in and out to different levels of comments and changes.
IBM's 1990's (closed-source) Visual Age saved code as an AST, and could do great diffs. But now with LLVM and LSP, we're much, much better at sharing underlying infrastructure of languages.
My minimal rule for next-git would be that any automatable refactoring should appear as the one tiny change it is (renames, extracting methods, hoisting members in the hierarchy, etc.) in any language.
The reason we don't is not technical, because logical diffs are achievable. It's the coordination costs of shifting everyone from git to something else.
Given that, one option now is to support text conventions for commit comments that bridge comment levels and incorporate AST-level descriptors. They might be readable by humans, but most humans would use tooling to fly over and dive in.
The path to designing that is to work out the main and troubling use-cases, propose some formats, build in evolution/compatibility, and make some prototypes.
If people want to make a name for themselves, this is a way to do it that could transform the industry.
If a company wanted to make code understandable to AI, this is the transformative way to do it. If you squint, metadata over change is a model of intelligence. There's a lot of headroom in the space of building systems to feed AI instead of feeding human garbage into AI at sufficient volume to compensate for noise.
I don't understand why people assume you need to rewrite the world to use ASTs!
Keep text, as it is most universal to consume, and generate AST on the fly. Or serialize ASTs to xml and commit them. git is certainly flexible enough to work with non-text formats (a random example from internet: https://www.diffplug.com/features/git )
In particular, "any automatable refactoring should appear as the one tiny change it is" is trivial to add from the git side, just set "diffcmd" to whatever script does the logic. The hard part is actual logic to compare ASTs and derive if this is a "trivial rename" or "trivial rename except usage in file X is unchanged" or "trivial rename but I also made everything const".
Case in point, we use a 3rd party review tool at work (Reviewable) which overrides default github pull request diff screen and shows its own diff in a different format.
git may be hard, and bad, and terrible. it’s not the only thing like this. it’s not even a prime example. welcome to software. infamously, this is fine.
overcome it. if you can beat git, you can beat anything.
perhaps you’ll run into aws next. like git, it grew organically, has way too many knobs, and is easy to screw up. like git, it’s the best we’ve got.
as with all things, experiment in a safe context where failure is ok. learn which knobs are important and tape over the rest.
practice until you can do it asleep or drunk or both. maybe write some bash functions so you can forget some of what you learned if it doesn’t matter.
Like, the question: "How do I undo 'git add'" shouldn't have over ELEVEN THOUSAND upvotes on StackOverflow: https://stackoverflow.com/questions/348170/how-do-i-undo-git...
That's just bullshit