What makes Git so hard to use?(highflux.io)
highflux.io
What makes Git so hard to use?
https://www.highflux.io/blog/what-makes-git-hard-to-use
106 comments
I wouldn't say Google's VCS solves all problems. I worked there for years and was constantly looking toward git (or something like it) as a way of managing code I was developing before committing it to the monorepo.
Google's primary internal VCS was originally Perforce (https://www.perforce.com/) and when rewritten to scale to the size of their monorepo largely retained the same user experience. You can read about that here: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor.... Perforce's user experience isn't too different from svn. It is easy because it is a simpler model, and was available from Perforce as far back as the 1990s. You simply can't get into the same kinds of quagmires that git allows you to get into. It is also not a DVCS, which simplifies a lot of issues.
That said, Google's internal Perforce clone doesn't offer any sort of stack/queue of local commits that you can send off for review and continue building on. You've got one copy of your edits and that copy is not under any real version control. For a company that highly prizes code review there was always a tension between sending small-enough changes off for review and continuing to make progress on a larger feature. At the time I left a few years ago there was a staffed project building a Mercurial layer on top of the monorepo VCS that allowed for DVCS-like workflows, such as a local patch queue with multiple dependent changes out for review simultaneously. That little bit of exposure to Mercurial was enough for me to realize that being a DVCS doesn't necessarily require exposure to all the "bare metal" paper cuts that git exposes you to.
Google's primary internal VCS was originally Perforce (https://www.perforce.com/) and when rewritten to scale to the size of their monorepo largely retained the same user experience. You can read about that here: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor.... Perforce's user experience isn't too different from svn. It is easy because it is a simpler model, and was available from Perforce as far back as the 1990s. You simply can't get into the same kinds of quagmires that git allows you to get into. It is also not a DVCS, which simplifies a lot of issues.
That said, Google's internal Perforce clone doesn't offer any sort of stack/queue of local commits that you can send off for review and continue building on. You've got one copy of your edits and that copy is not under any real version control. For a company that highly prizes code review there was always a tension between sending small-enough changes off for review and continuing to make progress on a larger feature. At the time I left a few years ago there was a staffed project building a Mercurial layer on top of the monorepo VCS that allowed for DVCS-like workflows, such as a local patch queue with multiple dependent changes out for review simultaneously. That little bit of exposure to Mercurial was enough for me to realize that being a DVCS doesn't necessarily require exposure to all the "bare metal" paper cuts that git exposes you to.
I never really missed it. If you need it, you can always patch your workspace with edits from another workspace while it’s being reviewed. Or multiple workspaces.
I feel an engineer is incomplete without knowing their daily tools more than the basics.
I find it frustrating to work with people who don't make the effort to learn git. Urging them to relax and take some time to read up or go through guides. They are fine spending time learning new languages or frameworks on their spare time, that they then want to bring into work. But spending a weekend reading some blogs about git or the short manuals is somehow tedious. Many times they can't write a proper commit message, and when they get a merge conflict they kick and scream, and you have to solve it for them. It's not that hard to go from a beginner to an intermediate user of git. And the trade-off can be quite significant with the confidence in managing around git. Learn from the CLI first, then jump onto tools that fit you (shout-out to magit!)
I find this message hard to get because git is dramatically easier to use and more tolerant of mistakes than previous version control packages. It's certainly true that looking at the man pages could drive almost anybody insane but working from a cookbook it is very easy. (Most of the time I think it is a mistake to "Google" for answers but rather you should learn to look things up in the official docs. Git is a counterexample)
Visual Source Safe would outright die when your repository overflowed a 32 bit file.
Changing a wrong commit message was almost impossible with CVS.
I push into the wrong branch and make other mistakes like that sometimes with git and I have no fear about it at all and little stress because I can always look in the cookbook and find the recipe to fix it.
Git also is the basis for numerous tools such as GitHub that are accessible to non-technical users. Git is the only version control system I've seen that can be used like that.
Visual Source Safe would outright die when your repository overflowed a 32 bit file.
Changing a wrong commit message was almost impossible with CVS.
I push into the wrong branch and make other mistakes like that sometimes with git and I have no fear about it at all and little stress because I can always look in the cookbook and find the recipe to fix it.
Git also is the basis for numerous tools such as GitHub that are accessible to non-technical users. Git is the only version control system I've seen that can be used like that.
> It's certainly true that looking at the man pages could drive almost anybody the same
Some genius created a git man page generator that creates plausible-looking but completely nonsensical man pages for made-up git commands. The fact that they sort of look right is a testament to how arcane the actual man pages are.
https://git-man-page-generator.lokaltog.net/
Some genius created a git man page generator that creates plausible-looking but completely nonsensical man pages for made-up git commands. The fact that they sort of look right is a testament to how arcane the actual man pages are.
https://git-man-page-generator.lokaltog.net/
Git being better than predecessors, while still being really hard to use is not a contradiction.
In other words, there's still a big step forward needed. Do you disagree with some of the points in the post?
I don't disagree with the points so much as I disagree with the conclusion. Almost every analysis that concludes "Git is hard" seems to confuse deep and superficial attributes and also not understand why Git is successful or why the alternatives have been less so.
Specifically there are systems which are complicated because they are too complex and others which are complicated because they are too simple (a few simple ideas combine in ways that can get complex, people get confused because they don't see how the simple ideas are related to much more complex compositions of those ideas.) Git is fundamentally the latter.
To explain, Linus Torvalds created git in a very short time when they lost the license for the version control system they were using before. Linus was able to develop such a scalable system very quickly because it is based on simple ideas that are very similar to the ideas used in blockchains.
It has the appearance that it is complex because it has accreted many layers on top of that very simple conceptual core.
Some of the things that git critics universal complain are complex, such as the index, staging, etc. are keys to git's success. Because of that I have very little fear of screwing up. With other tools I would manually replicate that functionality by copying files when I was afraid of screwing up and probably screw up doing that. It is a small burden on the contributor but it relieves a large burden on the maintainer of the system who is not always cleaning up messes.
I find Git simple because I have a cookbook I work from. A better UI would put that cookbook on your fingertips. Look at the Github UI... A UI like that to make changes in a CVS repository would be like science fiction. Trouble integrating version control has been a persistent problem with "business rules engines" and other kinds of tools and Git makes it possible to make a simple interface to say, edit a Wiki that is managed in Git.
Specifically there are systems which are complicated because they are too complex and others which are complicated because they are too simple (a few simple ideas combine in ways that can get complex, people get confused because they don't see how the simple ideas are related to much more complex compositions of those ideas.) Git is fundamentally the latter.
To explain, Linus Torvalds created git in a very short time when they lost the license for the version control system they were using before. Linus was able to develop such a scalable system very quickly because it is based on simple ideas that are very similar to the ideas used in blockchains.
It has the appearance that it is complex because it has accreted many layers on top of that very simple conceptual core.
Some of the things that git critics universal complain are complex, such as the index, staging, etc. are keys to git's success. Because of that I have very little fear of screwing up. With other tools I would manually replicate that functionality by copying files when I was afraid of screwing up and probably screw up doing that. It is a small burden on the contributor but it relieves a large burden on the maintainer of the system who is not always cleaning up messes.
I find Git simple because I have a cookbook I work from. A better UI would put that cookbook on your fingertips. Look at the Github UI... A UI like that to make changes in a CVS repository would be like science fiction. Trouble integrating version control has been a persistent problem with "business rules engines" and other kinds of tools and Git makes it possible to make a simple interface to say, edit a Wiki that is managed in Git.
Mercurial with the Evolve extension gives the same kinds of guarantees, but with much (much) nicer porcelain. Where Mercurial fell down IMO is being too dogmatic about not allowing changes to the history/making it incredibly painful to make changes to the history for way too long. Git's decision to allow it all to be mutable was better for large-scale use. Git also was able to get a critical mindshare mass via Linux and Github.
Staging is a feature I've never really understood the point of (why stage when I can commit by hunk instead?), but if it works for your workflow, great. Clearly it worked for the creators of Git.
The magic of Git (and other DVCS) compared to CVS and its ilk is the DAG and reasonable conflict resolution on merge/rebase/cherry-pick. Everything else is window dressing.
Staging is a feature I've never really understood the point of (why stage when I can commit by hunk instead?), but if it works for your workflow, great. Clearly it worked for the creators of Git.
The magic of Git (and other DVCS) compared to CVS and its ilk is the DAG and reasonable conflict resolution on merge/rebase/cherry-pick. Everything else is window dressing.
>Because of that I have very little fear of screwing up.
I met an engineer or two that were always feeling like walking on eggshells around git, and every once and a while having to call in the expert to fix their git state, so they get unstuck.
I met an engineer or two that were always feeling like walking on eggshells around git, and every once and a while having to call in the expert to fix their git state, so they get unstuck.
[deleted]
Bazaar and Mercurial were both released at about the same time as Git and are both notoriously much easier to use.
Possibly, but rebase and the staging area are worth the extra complexity... you can really get by without using these features, if you want to.
I think you're misunderstanding the complaints. Nobody is complaining about git's underlying fundamentals. The problem is the inconsistent user-hostile interface for accessing its features.
Also, just for the record, both Mercurial and Bazaar support rebasing via extensions.
Also, just for the record, both Mercurial and Bazaar support rebasing via extensions.
Judging from the FB sapling thread, there are complaints about staging being a difficult concept on top of everything else to learn about git.
It can be, which is one thing that made Bazaar so great, because you get a choice. But that's never the major issue when people start complaining about git. You can get used to and even start to enjoy staging changes. There's nothing enjoyable about the git cli's uncaring inattentiveness to user experience.
People are complaining about the fundamentals... a lot. I don't know if I agree that the UI is THAT bad, and honestly don't see much need to fix it.
I will admit that things like different formatting and flags for different commands is very annoying.
I will admit that things like different formatting and flags for different commands is very annoying.
Mercurial's extension of changeset evolution is basically a safer, saner version of rebase and amending commits. Which makes it look like the extra complexity of the staging area in particular isn't actually necessary for their benefits.
I agree that git is very non-intuitive to learn when you first start working with it, and it's great to see a number of teams trying to make this better.
Gitless folks did some actual user research years ago, getting feedbacks on various tasks difficulty, and they have a nice theory of api misfit, I really recommend the read for more structured speculation of why git is hard: https://spderosso.github.io/oopsla16.pdf
I guess git seems complicated when you go deeper into it. I just learnt the basic stuff (add, commit, push, pull, checkout and create branch, status, stash and reset merge) and haven't gone beyond it. I remember seeing some post on HN on how to make git easier to use and the person had written some aliases of commands that I had never even seen/used before!
Disagree that git is hard to use. It's fairly complex, I'll admit, however it's pretty much all "necessary complexity".
Occasionally, I'll see articles talk about "fixing" git by eg. removing the staging area, or something like that... but the staging area is great! It's literally a feature I was dreaming about when I used Mercurial.
I definitely think there's room for a more intuitive solution. I would rate the git learning curve as "medium-easy"
Occasionally, I'll see articles talk about "fixing" git by eg. removing the staging area, or something like that... but the staging area is great! It's literally a feature I was dreaming about when I used Mercurial.
I definitely think there's room for a more intuitive solution. I would rate the git learning curve as "medium-easy"
Just the ergonomics of git are sometimes mind-boggling.
for instance: "git checkout" is used for 3 different things: “switch”, “create branch”, and “revert a file”.
Deleting a remote tag is “git push” but a deleting a local one is “git tag -d”. There are many such examples
It's just git's UI is based on operations on the underlying storage instead of workflow intent. From that perspective branch switching and reverting a file are actually similar operations.
For many cases this would be a wrong approach. But git's storage model is quite simple and elegant, and both gives unlimited freedom in adapting it to your needs and could be dangerous if you don't understand it.
When coaching junior devs on git usage I always start with merkle trees, not with a list of commands to remember. This detour takes 20 minutes, but actually gives intuition to fix even worst mistakes without my help when they happen. I can't imagine the same with any other VCS.
For many cases this would be a wrong approach. But git's storage model is quite simple and elegant, and both gives unlimited freedom in adapting it to your needs and could be dangerous if you don't understand it.
When coaching junior devs on git usage I always start with merkle trees, not with a list of commands to remember. This detour takes 20 minutes, but actually gives intuition to fix even worst mistakes without my help when they happen. I can't imagine the same with any other VCS.
yet one often has to google a command, to make sure what is the correct command, even if they know all about the mechanics of the underlying blob storage.
Honestly, the examples you gave seem to make sense when you understand how git works and the philosophy.
It seems most (all?) interaction with the remote is via sync commands: push/pull/fetch. So why bake it into a different command. Commands like "git tag" interact with your local.
Given the abstract concept of a checkout, as it works in git, none of that is surprising (save for maybe that you could create a branch); however, that seems like a desirable feature. Why would you want to do a branch create, then checkout after, when you just want it done right away?
EDIT/P.S. Regarding the git "abstract concept of checkout" that I mentioned, but forgot to define. This is a pretty simple concept: switch working copy to on pointed to by branch reference, and new commits will go on that branch (appended to the end of the branch), create new branch if it doesn't exist (but doesn't this require a flag?)... can't you still create with branch if you really want to?
It seems most (all?) interaction with the remote is via sync commands: push/pull/fetch. So why bake it into a different command. Commands like "git tag" interact with your local.
Given the abstract concept of a checkout, as it works in git, none of that is surprising (save for maybe that you could create a branch); however, that seems like a desirable feature. Why would you want to do a branch create, then checkout after, when you just want it done right away?
EDIT/P.S. Regarding the git "abstract concept of checkout" that I mentioned, but forgot to define. This is a pretty simple concept: switch working copy to on pointed to by branch reference, and new commits will go on that branch (appended to the end of the branch), create new branch if it doesn't exist (but doesn't this require a flag?)... can't you still create with branch if you really want to?
IMO push is quite coherent since it consistently updates remote refs. The variation in checkout is pretty bad though.
The perfect command for deleting remote tag would be "tag -d(elete) -r(emote) <tag>" The existence of "remote refs" is an implementation detail, and git bothers you with it unnecessarily. And if you really need a command to update all remote refs at once why not call it "git sync-refs"? The fact that you use "push" command to delete something is confusing as hell.
Right. The git porcelain is baffling, but the actual git data model doesn't need fixing; it's complex but necessarily so. I'd be more interested in an alternative porcelain than a totally different VCS like FB's Sapling.
> "git checkout" can is used for 3 different things: “switch”, “create branch”, and “revert a file”
Git v2.23 (released in August 2019) added "git switch" and "git restore" commands to straighten this up.
Git v2.23 (released in August 2019) added "git switch" and "git restore" commands to straighten this up.
Sorta.
If you started out from a blank slate then git's not too bad to learn; I've taught several non technical people to get to the point where they can at least read a git history and have some understanding of what's happening when.
At my current job though a lot of folks came in from CVS, SVN, and TFS and it's been a struggle for many. TFS for instance encourages committing large binaries so when they were migrated onto git, their repos were as large as 50 gigabytes because they have every binary from every release from way back when. I've found they actually need someone to explain why git does the things it does, otherwise they have a very wrong mental model of what's going on. And git's confusing terminology doesn't help at all.
Though once it clicks, it just clicks for the most part.
If you started out from a blank slate then git's not too bad to learn; I've taught several non technical people to get to the point where they can at least read a git history and have some understanding of what's happening when.
At my current job though a lot of folks came in from CVS, SVN, and TFS and it's been a struggle for many. TFS for instance encourages committing large binaries so when they were migrated onto git, their repos were as large as 50 gigabytes because they have every binary from every release from way back when. I've found they actually need someone to explain why git does the things it does, otherwise they have a very wrong mental model of what's going on. And git's confusing terminology doesn't help at all.
Though once it clicks, it just clicks for the most part.
I sometimes think that staging area could be represented as a special WIP commit instead. Non pushable, automatically squashing. This potentially could cut amount of commands to learn by third. But of course I'm missing something important.
That would certainly be simpler. You could also roll back to any commit.
That's actually doable and is what HighFlux is doing.
Yes. The staging area is for prepping the current commit set. I can pick or exclude which changes to go into the next commit. May be if it’s renamed to Change Set people would feel better.
It's hard because nobody thinks of it as a part of their job. Like coding is to some people, git is often a thing that you just have to do.
So then you don't learn how it really works, and you get weird problems because you never formed the right model in your mind.
It's also the case that there's a few commands you use a lot, but a lot of commands that you reach for only in specific cases. This creates the impression that it's too complicated, because as soon as you go off road you get stuck.
So then you don't learn how it really works, and you get weird problems because you never formed the right model in your mind.
It's also the case that there's a few commands you use a lot, but a lot of commands that you reach for only in specific cases. This creates the impression that it's too complicated, because as soon as you go off road you get stuck.
More interview questions about git rather than silly fizzbuzz puzzles.
Totally, which results in the "memorize this list" git XKCD. https://xkcd.com/1597/
They have classes for compilers in school, they should have a 1 week class on source control because git makes a lot of sense if you understand the underlying data structures.
They have classes for compilers in school, they should have a 1 week class on source control because git makes a lot of sense if you understand the underlying data structures.
My problem is that sometimes I have to "drop" things, sometimes I have to "delete" things, sometimes I have to "--delete" things, sometimes I have to "-d" things and sometimes I have to "-D" things.
There's nothing wrong with the architecture or model, it's the syntax for me.
There's nothing wrong with the architecture or model, it's the syntax for me.
The idea you somehow NEED to learn all the commands as a reason why it's hard is crazy.
Adding HighFlow on top will just add more commands because inevitably there'll be a point where some HighFlow abstraction fails and you have to go to Git anyway to fix it.
Also I can see that HighFlux runs as a daemon. That seems sub-optimal - sucking up my CPU all the time on the off chance I want to code something is not great.
It doesn't seem like HighFlow supports actual remote repositories except GitHub. Which is the entire point of a distributed version control system - to be distributed.
I think HighFlux is designed to solve a very limited subset of Git's usage and so they've stripped out a lot of useful commands they don't use and so they can ship a product.
But in the real world people will need this and their simple vision will crumble back to the complexity of Git (or close).
Adding HighFlow on top will just add more commands because inevitably there'll be a point where some HighFlow abstraction fails and you have to go to Git anyway to fix it.
Also I can see that HighFlux runs as a daemon. That seems sub-optimal - sucking up my CPU all the time on the off chance I want to code something is not great.
It doesn't seem like HighFlow supports actual remote repositories except GitHub. Which is the entire point of a distributed version control system - to be distributed.
I think HighFlux is designed to solve a very limited subset of Git's usage and so they've stripped out a lot of useful commands they don't use and so they can ship a product.
But in the real world people will need this and their simple vision will crumble back to the complexity of Git (or close).
One of the developers of HighFlux here.
The deamon is written in rust and was designed and written to have a minimal CPU+Memory footprint.
> I think HighFlux is designed to solve a very limited subset of Git's usage and so they've stripped out a lot of useful commands they don't use and so they can ship a product.
Yes and no. No - once you correlate the user intent with the git commands, you discover that to accomplish one "intent," such as "start working on a feature," - you only need one CLI/UI command: "create WIP". So naturally, many git commands are bundled into one user intent.
Yes - true - we're just starting, so naturally focusing on the most used scenarios, gradually covering more and more cases as we progress. The nice thing is that HighFlux is not only compatible with git but also inter-operable with it, so you can always "go back to git" - until we cover all of the scenarios.
> I think HighFlux is designed to solve a very limited subset of Git's usage and so they've stripped out a lot of useful commands they don't use and so they can ship a product.
Yes and no. No - once you correlate the user intent with the git commands, you discover that to accomplish one "intent," such as "start working on a feature," - you only need one CLI/UI command: "create WIP". So naturally, many git commands are bundled into one user intent.
Yes - true - we're just starting, so naturally focusing on the most used scenarios, gradually covering more and more cases as we progress. The nice thing is that HighFlux is not only compatible with git but also inter-operable with it, so you can always "go back to git" - until we cover all of the scenarios.
[deleted]
I am happy to see startups working on improving git usability. Git is so hard to use when things get out of the simple path.
The git UI built into JetBrains IDEs is the only thing that makes git work for me. It's very intuitive to use.
Cmd+K to commit changes. There's a list of all files changed, organized by file hierarchy. You can click any of them to get an embedded editor and you can edit right from there.
There's a VCS pane you can pop up to view commits from any of the branches you have pulled without switching, you can select commits and right click > cherry pick to pull them into your current branch.
And the diff resolver is perfect. 3 vertical panes with the incoming and local changes on the left and right, and center is the merged product. You can press arrows on each side to bring those changes into the center, it shows right where they'll go with colored highlighting before you even make any changes. And the center is once again an editor so you can just manually type in it to resolve conflicts too.
Git's mental framework is so visual for me, it just seems like a better experience in a GUI. Especially one as well-thought-out and intuitive as what JetBrains came up with.
Cmd+K to commit changes. There's a list of all files changed, organized by file hierarchy. You can click any of them to get an embedded editor and you can edit right from there.
There's a VCS pane you can pop up to view commits from any of the branches you have pulled without switching, you can select commits and right click > cherry pick to pull them into your current branch.
And the diff resolver is perfect. 3 vertical panes with the incoming and local changes on the left and right, and center is the merged product. You can press arrows on each side to bring those changes into the center, it shows right where they'll go with colored highlighting before you even make any changes. And the center is once again an editor so you can just manually type in it to resolve conflicts too.
Git's mental framework is so visual for me, it just seems like a better experience in a GUI. Especially one as well-thought-out and intuitive as what JetBrains came up with.
I've used git for a decade, 8 years in CLI and the last 2 in JetBrains. It's night and day, and mountains above even GitHub's own desktop client.
Is there some way to stage individual lines? I do this all the time, and `git gui` seems to be the only tool which does this in a sensible way (right-click a line or selection to stage/unstage it). `git add --patch` is far too much manual work, and IDEA seems to only work with chunks, not individual lines.
The Jetbrains IDEs work in a generic VCS way that doesn't match how git works which makes you productive but removed from how git actually works. I've found vscode IDE is just as easy to use, but the GUI matches git very closely so you learn how git works which makes switching command line git relatively easy.
That depends on if you use the 'VCS' menu commands or the 'Git' menu commands.
That menu changes depending on what the IDE finds in the project.
If its generic VCS, then you're seeing things like https://www.jetbrains.com/help/idea/version-control-integrat...
The git menu has options like 'manage remotes', 'merge', 'rebase', 'Reset HEAD' and so on.
Right clicking on the log in git log pane brings up things like Cherry Pick, interactively release from here, fixup, squash into.
That menu changes depending on what the IDE finds in the project.
If its generic VCS, then you're seeing things like https://www.jetbrains.com/help/idea/version-control-integrat...
The git menu has options like 'manage remotes', 'merge', 'rebase', 'Reset HEAD' and so on.
Right clicking on the log in git log pane brings up things like Cherry Pick, interactively release from here, fixup, squash into.
Good UI on top of git definitely makes using it more bearable day to day, but I don't think it "fixes" git's fundamental flaws (those talked about in the posted link). That said, to some degree git is just an assembly language for a DVCS without a truly usable high level interface on top of it (yet).
Same, but the issue is that you get so used to it that when you need to do something without it it's way harder.
And there are things you still can't do on their UI, personally the most missing feature is to remove from git without deleting (from when you need to ignore something already checked). And also a native git reflog, once I discovered it it has saved me on more than one occasion. Can't they add it on the current log as a "show deleted commits" filter or something like that?
And there are things you still can't do on their UI, personally the most missing feature is to remove from git without deleting (from when you need to ignore something already checked). And also a native git reflog, once I discovered it it has saved me on more than one occasion. Can't they add it on the current log as a "show deleted commits" filter or something like that?
I've been hoping for a JetBrains stand-alone git client for years, similar to Sublime Merge. [0] I'm sure there's quite a few people out there that would pay $10 to use their git client with another editor.
[0] https://www.sublimemerge.com/
[0] https://www.sublimemerge.com/
I've been following a suggestion for a standalone git client on their issue tracker for a while now, but it sounds like they're currently not interested in making it
https://youtrack.jetbrains.com/issue/IDEA-152437/Make-git-cl...
https://youtrack.jetbrains.com/issue/IDEA-152437/Make-git-cl...
Ahh :( Nice to know they've thought about it though! It sounds like since they offer their git features inside of their community edition IDEs (Android Studio, PyCharm, IntelliJ) they wouldn't be able to charge for it.
I know I probably would still pay for it, if it meant not opening up a whole IDE just to use one built-in plugin, but maybe there's something I'm missing.
> Dmitry Jemerov [JetBrains Employee] commented 22 Jun 2022 10:20
> This has been discussed internally a number of times and at this time we have no plans to work on this. This product would have to be free (because its functionality would be a subset of the free Community Edition), it would require significant design and development effort to repackage the functionality in the form that would be acceptable for a standalone client, and we don't believe the marketing value of this work would compensate the development costs. Of course, all the code is open source and anyone is welcome to do this work themselves as a third-party tool.
I know I probably would still pay for it, if it meant not opening up a whole IDE just to use one built-in plugin, but maybe there's something I'm missing.
> Dmitry Jemerov [JetBrains Employee] commented 22 Jun 2022 10:20
> This has been discussed internally a number of times and at this time we have no plans to work on this. This product would have to be free (because its functionality would be a subset of the free Community Edition), it would require significant design and development effort to repackage the functionality in the form that would be acceptable for a standalone client, and we don't believe the marketing value of this work would compensate the development costs. Of course, all the code is open source and anyone is welcome to do this work themselves as a third-party tool.
They really should, it's miles better than any standalone I've used.
> Git doesn't let us safely experiment
Isn’t this one of the main purposes of branching?
Also git is easy to use. You can ignore the non-basic commands as a small team or solo dev, and there are plenty of GUIs to help with UX
Isn’t this one of the main purposes of branching?
Also git is easy to use. You can ignore the non-basic commands as a small team or solo dev, and there are plenty of GUIs to help with UX
I think git is hard because 99% of the time it just works with little to no required understanding of what you are actually doing. That is to say that git is actually too easy... until it isn't. Once you hit a scenario where you get off the happy path, that is when git becomes hard.
There's a lot of truth to this. Every company I worked at before git, branching was an advanced operation and merging was a wizard operation. You'd have a few senior developers (not even all the senior developers) who were confident branching and merging, and everybody else would go to them to ask their permission (seriously!) to create a branch. Merges were planned days or weeks in advance. Then I went to a company that was using git, and all the developers regardless of seniority were working on their own branches, rebasing from develop, merging their own changes, and complaining about how hard it was!
This reminds me of when I consulted with a company that wanted to use Rails as their backend. Rails made it incredibly easy to get database results on a web page. Too easy. They spent the next several months certain that they could "wing it" and still keep developing features. The harsh truth is, they needed to understand what was going on underneath all that "magic". Thankfully they took my advice and hired some Ruby devs. Probably a lot of us can fall into this trap. We do the same 3 steps day in and day out and are lulled into the belief that we "know the system". Until, like you mention, we fall off the happy path.
> That is to say that git is actually too easy ... until it isn't.
100% true. I am one of those devs who never got any formal training on git or was never motivated to RTFM or even WTFYV (watch the f***g youtube video). I simply started using it and many times ended on StackOverflow when I was stuck.
For a very long time I didn't know that you can create a new branch anytime. I used to make a bunch of changes locally only to realize later that I was in the main develop branch. To "fix" it, I used to copy everything to a temp folder, do a "git stash", then do "git checkout -b newbranch" and redo my changes.
100% true. I am one of those devs who never got any formal training on git or was never motivated to RTFM or even WTFYV (watch the f***g youtube video). I simply started using it and many times ended on StackOverflow when I was stuck.
For a very long time I didn't know that you can create a new branch anytime. I used to make a bunch of changes locally only to realize later that I was in the main develop branch. To "fix" it, I used to copy everything to a temp folder, do a "git stash", then do "git checkout -b newbranch" and redo my changes.
> RTFM or even WTFYV (watch the f**g youtube video)
For anyone wondering, a great FV if you feel like you are using git without understanding the fundamentals is Git For Ages 4 and Up [0].
[0] https://www.youtube.com/watch?v=3m7BgIvC-uQ
For anyone wondering, a great FV if you feel like you are using git without understanding the fundamentals is Git For Ages 4 and Up [0].
[0] https://www.youtube.com/watch?v=3m7BgIvC-uQ
I can't tell you how many times I'd gzip a project before trying something in git just in case lol. Then I finally took the time and learned how to actually use it correctly
For me, there were a few weirdisms in the wording of some commands but they weren't show-stoppers. I think for people like me who came from centralised CVSs, it was that Git was actually more powerful so it seemed a bit overwhelming or un-necessarily complicated.
Once you realise why git is like that, I haven't found it that bad.
It's no different than someone who has only ever ridden a bicycle asking why a motorbike is so hard to use. Because it does more stuff.
Once you realise why git is like that, I haven't found it that bad.
It's no different than someone who has only ever ridden a bicycle asking why a motorbike is so hard to use. Because it does more stuff.
On top of all the other concepts being introduced at once, staging seems to be a difficult one.
> Git commands are too many, too low-level and hard to understand.
Most of these are 'plumbing' commands, not 'porcelain' commands. Perhaps the author should have read the book on the Git website¹, as it explains this.
> Git tracks 4 versions of files, instead of just "my" version and "the team's" version.
This is because it's a distributed version control system, not just a tool to upload files to GitHub.
It seems like the author hasn't even taken the time to understand the basics of Git, and its design goals, before writing this ignorant screed.
＿
¹ https://git-scm.com/book/en/v2
Most of these are 'plumbing' commands, not 'porcelain' commands. Perhaps the author should have read the book on the Git website¹, as it explains this.
> Git tracks 4 versions of files, instead of just "my" version and "the team's" version.
This is because it's a distributed version control system, not just a tool to upload files to GitHub.
It seems like the author hasn't even taken the time to understand the basics of Git, and its design goals, before writing this ignorant screed.
＿
¹ https://git-scm.com/book/en/v2
>This is because it's a distributed version control system, not just a tool to upload files to GitHub.
99.9% of git users use only one remote. Most of them (>85%?) use GitHub. It's like having your car be super complex to drive to work every day, but if you want, it could also dig a hole in the ground. You never use the damn drill, yet it bothers you every day on your way to work ;)
99.9% of git users use only one remote. Most of them (>85%?) use GitHub. It's like having your car be super complex to drive to work every day, but if you want, it could also dig a hole in the ground. You never use the damn drill, yet it bothers you every day on your way to work ;)
The article mentions a lack of "undo" with git. This is one of the reasons I use a GUI git tool - specifically I use Tower for Mac right now for most of my day to day git. I still CLI stuff now and then, and Tower still spits out messages that force me to command line when it gets itself in to a state (rebase/conflict resolution sometimes). I can't recall other GUI git tools having an undo, but maybe some do now?
tldr: the 'undo' in Tower has been really handy for me over the past few years. Really handy.
tldr: the 'undo' in Tower has been really handy for me over the past few years. Really handy.
Honestly, I have loved git ever since I started using it.
- I use sourcetree for committing, it is a great UI tool for seeing your commit graph and just entering commit messages / partial commits / selecting which files to commit
- I use command line for all pulling/merging/fetching/branching etc. Git command line is just so simple IMO (once you get a short intro to it).
- Repairing issues in git is honestly not difficult.
- The hardest part of git is branching, merge conflicts, and squashing. When you combine all 3 is where it gets challenging if you don't know how to avoid any gochas. But it does make for nice revision history.
So I guess if you are doing some crazy complicated git stuff, I can't speak to that. But in 8 years I can definitively say I have only enjoyed git, and have often been the person to debug issues with people using git, and it is always a fairly simple thing to un-screw things up.
Criticism: push -f is definitely a dangerous operation. I can see why the mercurial team said no history rewriting period.
- I use sourcetree for committing, it is a great UI tool for seeing your commit graph and just entering commit messages / partial commits / selecting which files to commit
- I use command line for all pulling/merging/fetching/branching etc. Git command line is just so simple IMO (once you get a short intro to it).
- Repairing issues in git is honestly not difficult.
- The hardest part of git is branching, merge conflicts, and squashing. When you combine all 3 is where it gets challenging if you don't know how to avoid any gochas. But it does make for nice revision history.
So I guess if you are doing some crazy complicated git stuff, I can't speak to that. But in 8 years I can definitively say I have only enjoyed git, and have often been the person to debug issues with people using git, and it is always a fairly simple thing to un-screw things up.
Criticism: push -f is definitely a dangerous operation. I can see why the mercurial team said no history rewriting period.
> Repairing issues in git is honestly not difficult.
Obligatory XKCD: https://xkcd.com/1597/
Obligatory XKCD: https://xkcd.com/1597/
absolutely 90% accurate
> Git has been trying to create less confusing commands (like splitting git checkout into git switch and git restore)
I really don't know why anyone would use these new "easy" commands. They don't feel that much better and their existence irks me because now there's even more ways to do the same thing.
I really don't know why anyone would use these new "easy" commands. They don't feel that much better and their existence irks me because now there's even more ways to do the same thing.
I think this is a positive change, but there will be a transition periood where all the docs and tutorials are out of sync.
Different isn't always better, but better is always different.
Different isn't always better, but better is always different.
My favorite thing about git is that it allows you to solve different processes in different ways but basically with the same logic. everything done affects a history and all one has to do is focus on the history.
One misunderstanding I had that about git was thinking that branches contained more than one commit, while actually they're kind of like a movable tag that points to a single commit.
Learning what rebase actually did and the difference between reset soft/hard/mixed along with using the reflog to get back to previous states made git a lot more understandable to me.
That said, if you want to see how insanely complex git is, try reading its many man pages.
Learning what rebase actually did and the difference between reset soft/hard/mixed along with using the reflog to get back to previous states made git a lot more understandable to me.
That said, if you want to see how insanely complex git is, try reading its many man pages.
It's always been a UX problem and it's gotten much better.
Here's something I posted 7 years ago over on a reddit comment thread about it
---8<---
I've been running a git hater twitter account for years and have had git use me, or me use it, for 8. (https://mobile.twitter.com/githater)
I "grok" the concepts. I do not however, get the broken command line interface. How is an error message like this at all helpful:
git push -u origin master
error: src refspec master does not match any.
That's not even a proper english sentence.
Here's an example of the three counterintuitive undiscoverable ways to do one common thing that everyone wants; be able to push and pull from a branch without specifying it each time.
git branch m
THEN
git checkout m
THEN
git push -u origin m
OR
git branch --set-upstream=m origin/m
Or if you want
git checkout --track -b m origin/m
How do you push to a branch?
git push origin m
how do you delete a REMOTE branch?! Same thing, but prefix it with a colon
git push origin :m
How do you delete a LOCAL branch? Use a different command, with a different option
git branch -d m
Show useful information about tags? What about sorting them, by date. Sounds typical, common if you dare say... If you think it's in git-tag, your princess is in another castle. You need git-for-each-ref. Here's the simple to remember magic:
git for-each-ref --format="%(taggerdate): %(refname)" --sort=-taggerdate --count=10 refs/tags
So easy to use, no wonder it's number 1.
how do you rebase? It's a simple task!
git rebate --onto something commit id that is one before where you actually start from [ space, not 2 dots like everything else ] commit id where you want to end at ...
Great, now you are in a "detached head" state. So the rebase onto didn't actually rebase on to it ... yeah ... about that...
---8<--- (from https://www.reddit.com/r/programming/comments/3qt28h/xkcd_15...)
So in conclusion, the documentation was full of arcane discussions in domain specific jargon. The interface was wildly inconsistent and asymmetrical and the errors were cryptic and unhelpful.
Here's a fun one. If you just git init and then have multiple users start pushing, you know, like the documentation encourages you to do, the objects database files get the ownership of the person pushing upstream and then can lead to wildly cryptic intermittent permission denied errors because the database is actually just a bunch of unix files. Yes there's many ways to fix this, but that's not the point. Why is a deep dive discovery process needed to make basic things work in obvious ways? It's a Heathkit when all you need is a calculator.
When you expressed these complaints people would respond with theoretical introductions to branching and ASCII art diagrams.
It was all no good. I even tried some futile attempts over 10 years ago to contribute to clean things up.
The problem was I was unable to convince people deeply intimate with the codebase that there were hostile user patterns that could be alleviated with a bit of expository writing. All the cryptic jargon was utterly clear, exact and concise to someone who's spent 1,000 hours on the source. "Many people find these interface patterns confusing" was met with "we have academic level documentation with diagrams". Alright. Useless.
It's gotten a lot better though.
Here's something I posted 7 years ago over on a reddit comment thread about it
---8<---
I've been running a git hater twitter account for years and have had git use me, or me use it, for 8. (https://mobile.twitter.com/githater)
I "grok" the concepts. I do not however, get the broken command line interface. How is an error message like this at all helpful:
git push -u origin master
error: src refspec master does not match any.
That's not even a proper english sentence.
Here's an example of the three counterintuitive undiscoverable ways to do one common thing that everyone wants; be able to push and pull from a branch without specifying it each time.
git branch m
THEN
git checkout m
THEN
git push -u origin m
OR
git branch --set-upstream=m origin/m
Or if you want
git checkout --track -b m origin/m
How do you push to a branch?
git push origin m
how do you delete a REMOTE branch?! Same thing, but prefix it with a colon
git push origin :m
How do you delete a LOCAL branch? Use a different command, with a different option
git branch -d m
Show useful information about tags? What about sorting them, by date. Sounds typical, common if you dare say... If you think it's in git-tag, your princess is in another castle. You need git-for-each-ref. Here's the simple to remember magic:
git for-each-ref --format="%(taggerdate): %(refname)" --sort=-taggerdate --count=10 refs/tags
So easy to use, no wonder it's number 1.
how do you rebase? It's a simple task!
git rebate --onto something commit id that is one before where you actually start from [ space, not 2 dots like everything else ] commit id where you want to end at ...
Great, now you are in a "detached head" state. So the rebase onto didn't actually rebase on to it ... yeah ... about that...
---8<--- (from https://www.reddit.com/r/programming/comments/3qt28h/xkcd_15...)
So in conclusion, the documentation was full of arcane discussions in domain specific jargon. The interface was wildly inconsistent and asymmetrical and the errors were cryptic and unhelpful.
Here's a fun one. If you just git init and then have multiple users start pushing, you know, like the documentation encourages you to do, the objects database files get the ownership of the person pushing upstream and then can lead to wildly cryptic intermittent permission denied errors because the database is actually just a bunch of unix files. Yes there's many ways to fix this, but that's not the point. Why is a deep dive discovery process needed to make basic things work in obvious ways? It's a Heathkit when all you need is a calculator.
When you expressed these complaints people would respond with theoretical introductions to branching and ASCII art diagrams.
It was all no good. I even tried some futile attempts over 10 years ago to contribute to clean things up.
The problem was I was unable to convince people deeply intimate with the codebase that there were hostile user patterns that could be alleviated with a bit of expository writing. All the cryptic jargon was utterly clear, exact and concise to someone who's spent 1,000 hours on the source. "Many people find these interface patterns confusing" was met with "we have academic level documentation with diagrams". Alright. Useless.
It's gotten a lot better though.
Yeah, Git's problem has always been that it exposes too much implementation complexity in inconsistent ways. The underlying concepts are not that hard, and they aren't inconsistent.
Git just chose to expose them inconsistently, making easy DAG operations hard to remember the syntax for.
I'm also not thrilled with the "everything is a pointer" model since that doesn't match how I've seen branches used in practice; Mercurial's concept of a branch as a named, linear sequence of commits seems to better match how I've seen it work at companies small (< 50 people) and large (>50K people). It's not a big issue, but it is yet another impediment that isn't necessary.
The reflog is useful, but not as ergonomic as Evolve's hidden commits that have been replaced.
Everything about Git's UI is like that. Poorly thought out, poorly integrated, causing unnecessary friction on top of what is a perfectly fine underlying implementation.
Git just chose to expose them inconsistently, making easy DAG operations hard to remember the syntax for.
I'm also not thrilled with the "everything is a pointer" model since that doesn't match how I've seen branches used in practice; Mercurial's concept of a branch as a named, linear sequence of commits seems to better match how I've seen it work at companies small (< 50 people) and large (>50K people). It's not a big issue, but it is yet another impediment that isn't necessary.
The reflog is useful, but not as ergonomic as Evolve's hidden commits that have been replaced.
Everything about Git's UI is like that. Poorly thought out, poorly integrated, causing unnecessary friction on top of what is a perfectly fine underlying implementation.
For things like this I've found it enlightening to browse .gitconfig files on github, like this maybe:
https://github.com/search?q=alias+filename%3A.gitconfig+exte...
You get some pretty wildly interesting ones like https://github.com/jorge-barreto/dotfiles/blob/7769df698f14c... or https://github.com/zerochae/dotfiles/blob/6f972916228cf13f3b...
Unrelated but also nice is looking at how people bring sanity to tmux https://github.com/search?q=filename%3A.tmux.conf&type= which is how I found out about https://github.com/tmux-plugins/list
https://github.com/search?q=alias+filename%3A.gitconfig+exte...
You get some pretty wildly interesting ones like https://github.com/jorge-barreto/dotfiles/blob/7769df698f14c... or https://github.com/zerochae/dotfiles/blob/6f972916228cf13f3b...
Unrelated but also nice is looking at how people bring sanity to tmux https://github.com/search?q=filename%3A.tmux.conf&type= which is how I found out about https://github.com/tmux-plugins/list
> What about sorting them, by date. Sounds typical, common if you dare say... If you think it's in git-tag, your princess is in another castle.
Since Git v2.0 (released in May 2014), you can do:
Since Git v2.0 (released in May 2014), you can do:
git tag --sort=taggerdateYep! As I said, many improvements and I'm thankful for them making them. Now if we can only get sendmail, openssl, apache modrewrite, jq, openldap, modemmanager, and pulseaudio on board we'd be good.
If I had a dollar for every time someone complains about how git is unfriendly, I'd have enough to buy Twitter.
I've been using version control systems since CVS and I've found git the easiest and most sensible thing to use. Admittedly, some of the commands reflect internal data structures and concepts rather than what a user would want to do but that's just a learning curve issue. To address specific points.
1. Of the 157 commands, there are maybe 10 or so that one would need on most days and maybe 5 or 6 others when things go awry. Perhaps another half dozen for specific workflows but that's it. How many times do people use git daemon or git instaweb or git fsck? Why are these listed there? I do git trainings and teach a handful of commands in half a day which are sufficient to get people started.
2. The index has been extremely useful to me when I code for a while and then later need to commit only some files or parts of files into separate commits. This is a "good thing". The workflow which the author is suggesting would be like a "git commit -am ... && git push" which is not ideal
3. There are two destructive commands. git checkout and git reset when you've not committed. These two can discard uncommitted code in the working tree and you'll lose them. Once you've committed, it's possible to undo almost anything using the reflogs. They're very useful and worth learning how to navigate and use. Even rebase --hard can be undone by switching to a previous reference.
I think this is a deliberate decision. git is a power tool that sacrifices protecting the user from mistakes to give the user fine grained power over a project. A tool that hides these things from a user and tries to wrap the whole thing in a veneer of user friendliness might be good if engineered properly but my feeling that is that it wouldn't be worth the sacrifice.
Highflux itself advertises several things like " Automatic commit on every editor save." which I'm not sure are good ideas. I hit save repeatedly while working. Each one of those saves is not meant to be a commit.
I've been using version control systems since CVS and I've found git the easiest and most sensible thing to use. Admittedly, some of the commands reflect internal data structures and concepts rather than what a user would want to do but that's just a learning curve issue. To address specific points.
1. Of the 157 commands, there are maybe 10 or so that one would need on most days and maybe 5 or 6 others when things go awry. Perhaps another half dozen for specific workflows but that's it. How many times do people use git daemon or git instaweb or git fsck? Why are these listed there? I do git trainings and teach a handful of commands in half a day which are sufficient to get people started.
2. The index has been extremely useful to me when I code for a while and then later need to commit only some files or parts of files into separate commits. This is a "good thing". The workflow which the author is suggesting would be like a "git commit -am ... && git push" which is not ideal
3. There are two destructive commands. git checkout and git reset when you've not committed. These two can discard uncommitted code in the working tree and you'll lose them. Once you've committed, it's possible to undo almost anything using the reflogs. They're very useful and worth learning how to navigate and use. Even rebase --hard can be undone by switching to a previous reference.
I think this is a deliberate decision. git is a power tool that sacrifices protecting the user from mistakes to give the user fine grained power over a project. A tool that hides these things from a user and tries to wrap the whole thing in a veneer of user friendliness might be good if engineered properly but my feeling that is that it wouldn't be worth the sacrifice.
Highflux itself advertises several things like " Automatic commit on every editor save." which I'm not sure are good ideas. I hit save repeatedly while working. Each one of those saves is not meant to be a commit.
There is a characteristic in software that there is no good word for, it's the quality of unfolding gracefully and allowing for a gentle learning curve. BASIC had it in the old days, some would say Perl and shell programming had it too. Git is emphatically not like this. The default use case is to teach a novice how to add/commit/pull/push and strand them there. If they are enterprising they will figure out the more advanced stuff on their own, or ask a more experienced user to apply the proper pedagogy and explain the hidden elegance of the SHA-1 + DAG data model. And it's no coincendence that these "more experienced users" are often the same ones who cut their teeth on command line at some point in the past (and probably know some Perl and shell, and maybe even learned BASIC in the distant past).
Oh, so much to rant about! Let me address specifically the "git is a power tool" part.
Actual dangerous power tools used in industry have a lot of safety requirements, and even may require license to operate. You do not put lathe in your lobby and expect everyone to know how to use it properly.
If there would be qualified git technicians, that would take care of all git related activities developers need, I don't think there would be so much complaining.
However, what actually is happening, is dev, still being absorbed in his project, suddenly needs to confront index, stage and cache (these three are one, yet are not the same), figure out whic of the soft hard mixed reset, no, revert to use.
So I want to put my local changes in new branch? Use "git checkout"! But checkout was the dangerous one!? And you "cp -a" your whole dir, because you are afraid to mess up...
If there would be qualified git technicians, that would take care of all git related activities developers need, I don't think there would be so much complaining.
However, what actually is happening, is dev, still being absorbed in his project, suddenly needs to confront index, stage and cache (these three are one, yet are not the same), figure out whic of the soft hard mixed reset, no, revert to use.
So I want to put my local changes in new branch? Use "git checkout"! But checkout was the dangerous one!? And you "cp -a" your whole dir, because you are afraid to mess up...
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - this quote of Bjarne sums it up.
GIT complainers should write their own DVCS :) let's see how many people will use it .. if it would really be better everyone would use it.
GIT complainers should write their own DVCS :) let's see how many people will use it .. if it would really be better everyone would use it.
Agree! Doing basic operations with git really isn't hard at all. For most people, they don't need to worry about how git actually works, they just need to learn how to clone, checkout, create branches, push, and rebase/merge (basic versions). It takes like an hour, tops, to learn virtually anything you need unless you're responsible for an organization's repositories.
Unless you're using submodules. Which is one big reason people hate them usually!
Unless you're using submodules. Which is one big reason people hate them usually!
If I had a dollar for every time someone complains about how git is unfriendly, I'd have enough to buy Twitter.
Worth to pause and consider the implication of this statement.
Worth to pause and consider the implication of this statement.
IMO got is intuitive and easy to use therefore the title is subjective and incorrect. Please update to be less of an opinion.
An underlying problem is git is a file system on top of a file system.
If every time the journal / write-ahead log was flushed, the files were rehashed, we wouldn't need index vs non-index so much.
We would use normal commands to sync two work trees one being what we have, and one being what we want to commit.
Instead of .gitignore we simply should have temp files elsewhere.
Basically the file system is a bad abstraction and all VCS is ad-hoc work around it.
If every time the journal / write-ahead log was flushed, the files were rehashed, we wouldn't need index vs non-index so much.
We would use normal commands to sync two work trees one being what we have, and one being what we want to commit.
Instead of .gitignore we simply should have temp files elsewhere.
Basically the file system is a bad abstraction and all VCS is ad-hoc work around it.
The lack of a `git undo` is the reason why I’m afraid to try git commands I haven’t yet needed. I can’t exactly “move fast and break things” if I’m always two errant commands away from receiving unwanted attention from my team.
The closest thing is to
git branch <temporarybranchname>
git checkout <originalbranchname>
git whatevertomfooleryyouwant
And if everything is foobar
git checkout <temporarybranchname>
Or, if you think the liklihood of messing stuff up is higher than the likelihood of success, make your changes to the temporary branch.
git branch <temporarybranchname>
git checkout <originalbranchname>
git whatevertomfooleryyouwant
And if everything is foobar
git checkout <temporarybranchname>
Or, if you think the liklihood of messing stuff up is higher than the likelihood of success, make your changes to the temporary branch.
There's only really ~5 day-to-day commands that you need to know to use it. Going past that is mostly unnecessary and frankly pretty pointless.
checkout, pull, commit, push and reset if you make a mistake. I'm not including one time commands like clone and init.
checkout, pull, commit, push and reset if you make a mistake. I'm not including one time commands like clone and init.
My biggest git gripe is that its cognitive load can get high pretty quickly, while really for a VCS you want it to be powerful but stupid easy all the time. For example, if you try to find info on best practices on non-trivial git stuff, you find compelling and well-articulated arguments that are diametrically opposed to each other (see: rebasing).
I use git constantly and hardly ever have problems with it, but only because I use a tiny fraction of it and I religiously follow an exact process every time. I've had people tell me all sorts of reasons why my approach is not good, and they're probably right, but it's really nice to not have to give my VCS very much thought 99% of the time.
I use git constantly and hardly ever have problems with it, but only because I use a tiny fraction of it and I religiously follow an exact process every time. I've had people tell me all sorts of reasons why my approach is not good, and they're probably right, but it's really nice to not have to give my VCS very much thought 99% of the time.
When I realised that branches were just labels pointing to a commit, instead of a an actual "branch" ie a group of commits, then everything made a lot more sense. I still kinda wish branches were more groups of commits, so that if you have multiple branches on top of each other they can automatically/more easily keep up to date.
I love writing hardcore C code full or pointers and cross-calls but for some reason I can't get bothered with semi-advanced Git.
There's a dread, a fatigue... I got burned merging (or was it rebasing?) and now I often just copy my folder to make a temp branch.
By the way, how do you extract a file from an old commit without checking out (and crushing your current files..) ? No hassle with the old folder-copy-tech !
There's a dread, a fatigue... I got burned merging (or was it rebasing?) and now I often just copy my folder to make a temp branch.
By the way, how do you extract a file from an old commit without checking out (and crushing your current files..) ? No hassle with the old folder-copy-tech !
Are you looking to replace the current version of the file (undoing changes to the file back to a past commit) or are you trying to make a new file containing the contents of the file at the time of the past commit?
For the former, there's git checkout <branch> -- <filepath>, which has been given it's own command as git restore --source <branch> filename.
For the latter, there's git show <ref>:<filepath>, which you then pipe into the file you want to write, like
git show master:src/main.js > temp_main_old.js
For the former, there's git checkout <branch> -- <filepath>, which has been given it's own command as git restore --source <branch> filename.
For the latter, there's git show <ref>:<filepath>, which you then pipe into the file you want to write, like
git show master:src/main.js > temp_main_old.js
I meant the latter. This is very helpful ! Thx a lot.
One thing I wish git did differently was to have an atomic commit-and-push operation. I'd like to prepare my commit as normal, but when its ready, it pushes that commit as well, but if that push fails, it undoes the commit.
Why? I recently configured my github to use a hidden email address. To this end, it required me to use a github.com email address it generated for my commits. I set it up and started pushing commits, everyone was happy.
Then I went to a different folder that had a separate clone of the same repo, and I forgot I had configured github this way. I made some changes and did the usual commit-and-push but github rejected it. I had used the wrong email. Oops.
But now I had a problem. My local repo had the commit with the wrong email address in place and I didn't know to change it. I couldn't make a new commit with the new email as the old one was still there. I looked up how to revert already committed commits and long story short I did it wrong and deleted all my recent changes.
Why? I recently configured my github to use a hidden email address. To this end, it required me to use a github.com email address it generated for my commits. I set it up and started pushing commits, everyone was happy.
Then I went to a different folder that had a separate clone of the same repo, and I forgot I had configured github this way. I made some changes and did the usual commit-and-push but github rejected it. I had used the wrong email. Oops.
But now I had a problem. My local repo had the commit with the wrong email address in place and I didn't know to change it. I couldn't make a new commit with the new email as the old one was still there. I looked up how to revert already committed commits and long story short I did it wrong and deleted all my recent changes.
Sorry this happened to you.
Next time, if you want to reset the latest commit to an unstaged state:
I don't blame you for not knowing this. I learned by trial and error and most importantly, good colleagues who showed me the way.
edit: Typo/grammar
Next time, if you want to reset the latest commit to an unstaged state:
git reset HEAD~
git reflog
I don't blame you for not knowing this. I learned by trial and error and most importantly, good colleagues who showed me the way.
edit: Typo/grammar
I think some of their 'issues' could be resolved by learning things like git reflog (e.g. the 'undo' command request)
Looks great. I will give it a try
With the amount of Git-skeptical articles that have been popping up recently, I'm starting to get worried that someones gonna come along, make some fancy and shiny centralised VCS, market it like the cure to cancer, and all the new developers will eat it up and 8 years after it'll be a bloated hellscape.
“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.”
— Isaac Wolkerstorfer
http://twitter.com/agnoster/status/44636629423497217
— Isaac Wolkerstorfer
http://twitter.com/agnoster/status/44636629423497217
Dev experience at Google kinda sucks for the most part, but one thing that works amazingly well is VCS. You never even have to think about it, it literally just works, and it works at very large scale (monorepo for all of Google).
It’s just: 1. Create a workspace 2. Submit the changes in your workspace
And that’s it. I hate going back to the mess that is Git.