10 ms·

Disagree strongly on git. On the surface the syntax is ugly, but the data model is brilliant. Once you wrap your mind around what commits, heads and remotes a

Disagree strongly on git. On the surface the syntax is ugly, but the data model is brilliant. Once you wrap your mind around what commits, heads and remotes are and learn to rebase you get an incredibly simple and fine-grained control. I never use stash because it's trivial to create a WIP commit and rebase later into the chunks I want to ship to permanent history. Git is like a chef's knife: extremely powerful tool that's dangerous in untrained hands.

millimeterman 6y ago
I think the best argument against git is to use mercurial for a few months. It has exactly the same functionality but a nicer and more streamlined interface, especially when it comes to branch management.
- nickpeterson 6y ago
  Yeah, when dvcs started becoming all the rage I tried mercurial first for some toy projects and really liked it. When I finally had to start using git I was absolutely baffled that it had won. I feel like git needs something that sits on top and does most the normal configuration and wraps the api. It reminds me of the problem with emacs, there is so much it’s just overwhelming to people.
  - smichel17 6y ago
    Technically this already exists; git commands are divided into two groups, plumbing and porcelain. Plumbing commands have stable interfaces and are intended for building alternative interfaces with; porcelain commands are intended to sit on top and be the actual user interface. They're what you're used to using.
- smichel17 6y ago
  Do you think mercurial has a better data model, or could git reach parity with just a better interface?
  - millimeterman 6y ago
    I don't know anything about mercurial's internal data model, so it's hard to say. In particular, it makes some fundamentally different choices (e.g. no staging area, the ability to use unnamed branches). I certainly think git could do a lot better with its interface though.
- dreamcompiler 6y ago
  I love mercurial but since I've gotten used to git I miss the lack of the staging area and stash in mercurial. I have to grudgingly admit they're very useful.
  - arp242 6y ago
    You can get the "git stash" with the shelve extension: https://www.mercurial-scm.org/wiki/ShelveExtension https://www.mercurial-scm.org/wiki/ShelveExtension
  - ptx 6y ago
    In some cases (all my usecases, but perhaps yours are different) the staging area can be replaced by some combination of "hg commit --amend" and "hg commit --interactive" - or in older versions "hg rollback" and "hg record".
- arp242 6y ago
  I think this point can be concisely summarized with: $ git help commit | wc -l 506 $ hg help commit | wc -l 59 $ hg help commit -v | wc -l 96 Also, git currently has 169 subcommands by default, vs. mercurial's 50 (more available as extensions though).
daenz 6y ago
I agree on these points, however many developers don't care enough to use it well, so you get screwed up shared histories, bad commits, mis-merged branches. I know that the nature of a shared tool, but it definitely negates a lot of the potential benefits of doing everything The Right Way if nobody else puts in the same effort.
- kubanczyk 6y ago
  How about putting some tought into not naming operations so that `pull` is not the opposite of `push`. Don't you think the merge histories of all the repos throughout the globe would be greatly improved if people didn't need to learn the hard way that if your colleague does `push` you need to `fetch`?
  - smichel17 6y ago
    Also, rm is not the opposite of add, `restore` is (and previously `checkout` was).
tryptophan 6y ago
Agree. I always hated git and thought it was so arbitrary and unhelpful. Then I sat down for 1-2 hours and read about how it works. It's not that complicated of a model that it operates on. Once you learn the model, the rest of the commands and how it works start making intuitive sense.
- vin047 6y ago
  I’ve yet to find a good intro doc that explains how git works conceptually. There are too few visual examples with authors assuming that users already understand the basic concepts like commits. To people who are completely new to version control, git can appear nonsensical. Funnily enough I think Atlassian/Bitbucket comes close to a good intro doc to git on their site complete with a visual guide. I still found it inaccessible to people totally new to the basic concepts though.
  - bacon_waffle 6y ago
    Have you seen this one? https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/
  - ohhhwell 6y ago
    I've found the git branching game to be quite helpful in building a visual mental model https://learngitbranching.js.org/ https://learngitbranching.js.org/
    - kubanczyk 6y ago
      No, this one is good (I'd say I regard it as canonical!), but only if you know how commit works on a conceptual level. It is not targeted at absolute beginners.
    - deleted 6y ago
      [deleted]
  - tryptophan 6y ago
    I found this one to be pretty good: https://www.sbf5.com/~cduan/technical/git/git-1.shtml https://www.sbf5.com/~cduan/technical/git/git-1.shtml
kevsim 6y ago
For me personally I find git to be relatively painless (after years of svn and P4). But working with people in less technical roles (PM/UX) who for whatever reason need to touch git occasion, I’m exposed to how inaccessible it is for the uninitiated. Not saying that’s a good reason to change the tool but maybe there’s room in the market for a more accessible tool.
y7 6y ago
I use git a lot, and I like the speed and decentralized nature. But I do think there's much to be improved. Named branches don't really exist in git: there's only a moving target name that refers to a leaf node. This means there's no "history" associated to a branch except for the parent commits. But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in. This information can be valuable in some cases. This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information. Also, there's no support for keeping two parallel views of the same repository (for example, an internal view with lots of subcommits, and a cleaner public view with more detailed messages, and perhaps fewer privacy-compromising names/timestamps). Finally, handling merge conflicts is still a PITA, especially on LaTeX documents.
- skeppy 6y ago
  What about a “git init-lite” option? So many times I want to VC a directory but don’t care about commit messages, branching, or other jazz more suited to collaborative work. With init-lite, all the power of Git is still there - and you can use any commit or command you want, but it’s default would be to simply VC for every file save. In other words, a file save IS a message-less commit.
  - sangnoir 6y ago
    The good news is that git is extensible enough to support this use-case. You would need to wrap git with a tool/script that watches for file changes
  - still_grokking 6y ago
    Sine decades I wish this would be a std. OS or FS feature!
    - vtbassmatt 6y ago
      VMS did it: https://wiki.vmssoftware.com/File_version https://wiki.vmssoftware.com/File_version
bmitc 6y ago
> Once you wrap your mind around what commits, heads and remotes are and learn to rebase you get an incredibly simple and fine-grained control. > Git is like a chef's knife: extremely powerful tool that's dangerous in untrained hands. Although, this is all part of the problem with Git. The problem is that it exposes this fine-grained control and knife's edge to the user by default. There isn't some simpler model that people can work with. I cut my teeth on source-code control with Perforce. Of course, Perforce has many complex features, including stuff like workspaces, which as far as I can tell, Git doesn't have something like that. Anyway, despite its complex feature set, Perforce can be explained in a few minutes. You have some code in the repository. If you want to work on it, you check it out and it gets added to a changelist. If you want exclusive change rights, you can lock it to prevent others. If you want others to see what you're working on, you can shelve your changes without submitting so that they can inspect. When you're done, you submit your changelist. All of this can be done via excellent visual tooling or the command line. I highlighted things with italics because these are the right words for the actions in how Perforce calls them. It's intuitive. For Git, it isn't that simple. You must first explain a wide swath of concepts. I've explained Git to people, even using the GitHub Desktop app. It is very confusing and intimidating to people, and rightfully so. It confuses me, and I did some pretty advanced things with Perforce (and thus source-code control) before. And there's no default visual tooling. Git also has many names for things that are confusing. Also, Git was invented for a very specific purpose: Linux kernel development. The vast majority of development does not need the same complexity that such a niche development process needs. When I recently wanted to do something in Git, I just could not figure it out. Probably simple for a Git expert, which is something I am not, but after searching many forum posts, I gave up because every answer was different and caveated in different ways and wasn't working for me. I installed GitKraken and solved my problem in seconds via a single right-click. Maybe I'm an idiot and I don't understand Git that well; both are likely true. But I am able to understand other complex things, so something is amiss. I think the primary issue is that Git requires me to study it just to use it in basic ways. I have an allergy to overly complex things, and so it's just a constant struggle for me. I tend to use visual tools for merging, diffing, managing commits, etc. so that I stay away from the Git CLI, which exposes the complexity in a non-usable way. Lastly, Git is very narrow minded when it comes to things it controls. It assumes everything should be text.
jerzyt 6y ago
I couldn't agree more. The fundamental design it's absolutely brilliant. The UI does take some getting used to. I frequently use Git as an interview question, but only when the candidate lists Git among the skill set. Specifically, I ask how does Git figure out when you've renamed a file. If you don't grok it, don't list it.
- monkpit 6y ago
  The ui doesn’t take any getting used to if you don’t use it ;)
  - jerzyt 6y ago
    That is so true. A lot of people use git as write only repository. Still better than nothing, or copying directories. Maybe at some point they'll figure out how to retrieve a previous version.
- agustamir 6y ago
  > how does Git figure out when you've renamed a file. If you don't grok it, don't list it. How does git figure it out?
  - Izkata 6y ago
    Percent similarity on display, not on commit. That second part is actually important from the user's perspective, not as details on the internals: every single new hire we've gotten who is still learning version control expects svn to detect automatically, and has to be told about "svn mv".
- kuang_eleven 6y ago
  Almost everyone would agree that listing 'git' as a skill implies knowing the operation of using git, not the specifics of how it works under the hood... Why ask such a gotcha question?
  - allarm 6y ago
nyanpasu64 6y ago
I understand Git, but for my rebase-based workflow, I don't like how Git doesn't understand commit identity when you rebase. Git doesn't know the old and new commits with the same name and contents mean the same thing, though rebase tries to skip commits it thinks match. When you rebase one branch, it doesn't move other branches and tags pointing along the history. You can't rewrite a repository and change your username in past commits, without completely rewriting all of history, creating two parallel histories, and merge conflicts. Git's mental model makes "moving a branch onto a different commit" (git branch -f) a natural operation. But no graphical tool I've used allows you to do that on a branch you're not checked out on.
- Stratoscope 6y ago
  > Git's mental model makes "moving a branch onto a different commit" (git branch -f) a natural operation. But no graphical tool I've used allows you to do that on a branch you're not checked out on. This is trivial in SmartGit, I do it all the time. Simply drag the branch marker to the commit you want it on. It doesn't matter if it's the checked-out branch or not. I've tried a few Git GUIs, but SmartGit continues to be my favorite. Pretty much every one of the recipes on https://ohshitgit.com/ https://ohshitgit.com/ is just a simple drag and drop or menu command in SmartGit. One of my favorite things is the way it handles the reflog. Just click the Recyclable Commits checkbox and every reflog commit becomes visible in the normal log view. You can see the commit's file contents without having to check it out, you can diff two reflog or normal commits, etc. https://www.syntevo.com/smartgit/ https://www.syntevo.com/smartgit/
- fulafel 6y ago
  Rebasing breaks a lot of what's good in git.
crispyambulance 6y ago
> On the surface the syntax is ugly, but the data model is brilliant. It's beyond ugly, it's needlessly incoherent. I use it because I have to and hate it. I've heard people say "the data model is a work of beauty". And I suppose that's true, but why have such a fucked up and confusing set of commands? Doesn't a "brilliant data model" deserve an equally brilliant command line? The thing that saves git is that it works, and by some miracle, it is popular. People just memorize what they need to do for their workflows and that's mostly fine. Sometimes there's a screw-up and you blow time googling around or looking up fixes. People won't publicly admit it but a lot of work gets trashed because finagling git intricacies is more painful than throwing away some work and starting over.
- arp242 6y ago
  > by some miracle, it is popular Probably because Linus Torvalds wrote it, and also because GitHub was actually quite a significant improvement over SourceForge. I know some people "love to hate" GitHub, but they made some really good "developer-first" UX improvements that many copied for good reasons. And lastly, Linus Torvalds wrote it. I still maintain that Mercurial is far better for most uses. Every time I mention this I get a flurry of technical replies about stuff most people don't even know about (HN is strongly biased like that, which is not a bad thing, just something to be aware of), but most people just want to commit, push, pull, and some related stuff like that. Git makes a lot of simple common stuff arcane to make the complex stuff easier, whereas mercurial makes the simple common stuff easy and keeps the complex stuff arcane. This strikes me as a much better design philosophy. Git and Mercurial are a tool designed to facilitate writing code (which is also a tool designed to solve problems). If you need to spend significant time to "get your head around it" then IMHO something, somewhere, has gone wrong. I still use git because it's just the pragmatical thing to do at this point in time, and to be fair there have been active efforts by the git team to make the common/simple stuff easier in recent times, but yeah, I'm not a fan.
  - namdnay 6y ago
    Yes! I love Mercurial, it feels like someone designed a proper interface, instead of just exposing the internal api calls
dreamcompiler 6y ago
Agree with everything in this post except I find stash extremely useful when a pull would disrupt my current working directory. "If I only had a VCS to temporarily hang on to my local changes while I merge the team's." Stash, pull, stash pop. Done. (I don't use rebase because I like my history to tell the truth rather than be fictional. Maybe stash is less necessary with rebase; IDK.)
- boring_twenties 6y ago
  You don't need stash for that though, you can just create a branch. git branch my_stash git commit -am WIP # instead of stash save git pull git cherry-pick -n WIP git branch -D my_stash
  - nemetroid 6y ago
    You don’t need to create a branch for that though, you can just use stash.
    - boring_twenties 6y ago
      And how is that better? You have to remember a second command with its own peculiar syntax and semantics, but don't gain any functionality. Stash is a superfluous misfeature.
      - cben 6y ago
        Behind the scenes, stashes _are_ branches! It's just UI on top of them, optimized for specific use case. You don't have to use it if you don't like it. Now staging (aka index) is special behind the scenes, making the model more complex for Al users.
      - nemetroid 6y ago
        99% of the time when I use stash, it’s ”stash” or ”stash pop”, usually with ten seconds or so between the two. It’s very easy to remember. Your alternative, on the other hand, uses an obscure flag to cherry-pick. What scenario would you use that flag for, except this particular one? How is remembering that flag any simpler? Also, I don’t think your sequence of commands is correct. First, ”git branch” doesn’t switch to the newly created branch, so ”WIP” would be committed on your original branch. Second, the argument to cherry-pick should be a reference to the commit rather than the commit message. I believe a correct version would be: git switch -c my_stash git commit -am WIP git switch - git pull git cherry-pick -n my_stash git branch -D my_stash

millimeterman 6y ago

I think the best argument against git is to use mercurial for a few months. It has exactly the same functionality but a nicer and more streamlined interface, especially when it comes to branch management.

nickpeterson 6y ago
Yeah, when dvcs started becoming all the rage I tried mercurial first for some toy projects and really liked it. When I finally had to start using git I was absolutely baffled that it had won. I feel like git needs something that sits on top and does most the normal configuration and wraps the api. It reminds me of the problem with emacs, there is so much it’s just overwhelming to people.
- smichel17 6y ago
  Technically this already exists; git commands are divided into two groups, plumbing and porcelain. Plumbing commands have stable interfaces and are intended for building alternative interfaces with; porcelain commands are intended to sit on top and be the actual user interface. They're what you're used to using.
smichel17 6y ago
Do you think mercurial has a better data model, or could git reach parity with just a better interface?
- millimeterman 6y ago
  I don't know anything about mercurial's internal data model, so it's hard to say. In particular, it makes some fundamentally different choices (e.g. no staging area, the ability to use unnamed branches). I certainly think git could do a lot better with its interface though.
dreamcompiler 6y ago
I love mercurial but since I've gotten used to git I miss the lack of the staging area and stash in mercurial. I have to grudgingly admit they're very useful.
- arp242 6y ago
  You can get the "git stash" with the shelve extension: https://www.mercurial-scm.org/wiki/ShelveExtension https://www.mercurial-scm.org/wiki/ShelveExtension
- ptx 6y ago
  In some cases (all my usecases, but perhaps yours are different) the staging area can be replaced by some combination of "hg commit --amend" and "hg commit --interactive" - or in older versions "hg rollback" and "hg record".
arp242 6y ago
I think this point can be concisely summarized with: $ git help commit | wc -l 506 $ hg help commit | wc -l 59 $ hg help commit -v | wc -l 96 Also, git currently has 169 subcommands by default, vs. mercurial's 50 (more available as extensions though).

daenz 6y ago

I agree on these points, however many developers don't care enough to use it well, so you get screwed up shared histories, bad commits, mis-merged branches. I know that the nature of a shared tool, but it definitely negates a lot of the potential benefits of doing everything The Right Way if nobody else puts in the same effort.

kubanczyk 6y ago
How about putting some tought into not naming operations so that `pull` is not the opposite of `push`. Don't you think the merge histories of all the repos throughout the globe would be greatly improved if people didn't need to learn the hard way that if your colleague does `push` you need to `fetch`?
- smichel17 6y ago
  Also, rm is not the opposite of add, `restore` is (and previously `checkout` was).

tryptophan 6y ago

Agree. I always hated git and thought it was so arbitrary and unhelpful. Then I sat down for 1-2 hours and read about how it works. It's not that complicated of a model that it operates on. Once you learn the model, the rest of the commands and how it works start making intuitive sense.

vin047 6y ago
I’ve yet to find a good intro doc that explains how git works conceptually. There are too few visual examples with authors assuming that users already understand the basic concepts like commits. To people who are completely new to version control, git can appear nonsensical. Funnily enough I think Atlassian/Bitbucket comes close to a good intro doc to git on their site complete with a visual guide. I still found it inaccessible to people totally new to the basic concepts though.
- bacon_waffle 6y ago
  Have you seen this one? https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/
- ohhhwell 6y ago
  I've found the git branching game to be quite helpful in building a visual mental model https://learngitbranching.js.org/ https://learngitbranching.js.org/
  - kubanczyk 6y ago
    No, this one is good (I'd say I regard it as canonical!), but only if you know how commit works on a conceptual level. It is not targeted at absolute beginners.
  - deleted 6y ago
    [deleted]
- tryptophan 6y ago
  I found this one to be pretty good: https://www.sbf5.com/~cduan/technical/git/git-1.shtml https://www.sbf5.com/~cduan/technical/git/git-1.shtml

kevsim 6y ago

For me personally I find git to be relatively painless (after years of svn and P4). But working with people in less technical roles (PM/UX) who for whatever reason need to touch git occasion, I’m exposed to how inaccessible it is for the uninitiated. Not saying that’s a good reason to change the tool but maybe there’s room in the market for a more accessible tool.

y7 6y ago

I use git a lot, and I like the speed and decentralized nature. But I do think there's much to be improved. Named branches don't really exist in git: there's only a moving target name that refers to a leaf node. This means there's no "history" associated to a branch except for the parent commits. But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in. This information can be valuable in some cases. This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information. Also, there's no support for keeping two parallel views of the same repository (for example, an internal view with lots of subcommits, and a cleaner public view with more detailed messages, and perhaps fewer privacy-compromising names/timestamps). Finally, handling merge conflicts is still a PITA, especially on LaTeX documents.

skeppy 6y ago
What about a “git init-lite” option? So many times I want to VC a directory but don’t care about commit messages, branching, or other jazz more suited to collaborative work. With init-lite, all the power of Git is still there - and you can use any commit or command you want, but it’s default would be to simply VC for every file save. In other words, a file save IS a message-less commit.
- sangnoir 6y ago
  The good news is that git is extensible enough to support this use-case. You would need to wrap git with a tool/script that watches for file changes
- still_grokking 6y ago
  Sine decades I wish this would be a std. OS or FS feature!
  - vtbassmatt 6y ago
    VMS did it: https://wiki.vmssoftware.com/File_version https://wiki.vmssoftware.com/File_version

bmitc 6y ago

> Once you wrap your mind around what commits, heads and remotes are and learn to rebase you get an incredibly simple and fine-grained control. > Git is like a chef's knife: extremely powerful tool that's dangerous in untrained hands. Although, this is all part of the problem with Git. The problem is that it exposes this fine-grained control and knife's edge to the user by default. There isn't some simpler model that people can work with. I cut my teeth on source-code control with Perforce. Of course, Perforce has many complex features, including stuff like workspaces, which as far as I can tell, Git doesn't have something like that. Anyway, despite its complex feature set, Perforce can be explained in a few minutes. You have some code in the repository. If you want to work on it, you check it out and it gets added to a changelist. If you want exclusive change rights, you can lock it to prevent others. If you want others to see what you're working on, you can shelve your changes without submitting so that they can inspect. When you're done, you submit your changelist. All of this can be done via excellent visual tooling or the command line. I highlighted things with italics because these are the right words for the actions in how Perforce calls them. It's intuitive. For Git, it isn't that simple. You must first explain a wide swath of concepts. I've explained Git to people, even using the GitHub Desktop app. It is very confusing and intimidating to people, and rightfully so. It confuses me, and I did some pretty advanced things with Perforce (and thus source-code control) before. And there's no default visual tooling. Git also has many names for things that are confusing. Also, Git was invented for a very specific purpose: Linux kernel development. The vast majority of development does not need the same complexity that such a niche development process needs. When I recently wanted to do something in Git, I just could not figure it out. Probably simple for a Git expert, which is something I am not, but after searching many forum posts, I gave up because every answer was different and caveated in different ways and wasn't working for me. I installed GitKraken and solved my problem in seconds via a single right-click. Maybe I'm an idiot and I don't understand Git that well; both are likely true. But I am able to understand other complex things, so something is amiss. I think the primary issue is that Git requires me to study it just to use it in basic ways. I have an allergy to overly complex things, and so it's just a constant struggle for me. I tend to use visual tools for merging, diffing, managing commits, etc. so that I stay away from the Git CLI, which exposes the complexity in a non-usable way. Lastly, Git is very narrow minded when it comes to things it controls. It assumes everything should be text.

jerzyt 6y ago

I couldn't agree more. The fundamental design it's absolutely brilliant. The UI does take some getting used to. I frequently use Git as an interview question, but only when the candidate lists Git among the skill set. Specifically, I ask how does Git figure out when you've renamed a file. If you don't grok it, don't list it.

monkpit 6y ago
The ui doesn’t take any getting used to if you don’t use it ;)
- jerzyt 6y ago
  That is so true. A lot of people use git as write only repository. Still better than nothing, or copying directories. Maybe at some point they'll figure out how to retrieve a previous version.
agustamir 6y ago
> how does Git figure out when you've renamed a file. If you don't grok it, don't list it. How does git figure it out?
- Izkata 6y ago
  Percent similarity on display, not on commit. That second part is actually important from the user's perspective, not as details on the internals: every single new hire we've gotten who is still learning version control expects svn to detect automatically, and has to be told about "svn mv".
kuang_eleven 6y ago
Almost everyone would agree that listing 'git' as a skill implies knowing the operation of using git, not the specifics of how it works under the hood... Why ask such a gotcha question?
- allarm 6y ago

nyanpasu64 6y ago

I understand Git, but for my rebase-based workflow, I don't like how Git doesn't understand commit identity when you rebase. Git doesn't know the old and new commits with the same name and contents mean the same thing, though rebase tries to skip commits it thinks match. When you rebase one branch, it doesn't move other branches and tags pointing along the history. You can't rewrite a repository and change your username in past commits, without completely rewriting all of history, creating two parallel histories, and merge conflicts. Git's mental model makes "moving a branch onto a different commit" (git branch -f) a natural operation. But no graphical tool I've used allows you to do that on a branch you're not checked out on.

Stratoscope 6y ago
> Git's mental model makes "moving a branch onto a different commit" (git branch -f) a natural operation. But no graphical tool I've used allows you to do that on a branch you're not checked out on. This is trivial in SmartGit, I do it all the time. Simply drag the branch marker to the commit you want it on. It doesn't matter if it's the checked-out branch or not. I've tried a few Git GUIs, but SmartGit continues to be my favorite. Pretty much every one of the recipes on https://ohshitgit.com/ https://ohshitgit.com/ is just a simple drag and drop or menu command in SmartGit. One of my favorite things is the way it handles the reflog. Just click the Recyclable Commits checkbox and every reflog commit becomes visible in the normal log view. You can see the commit's file contents without having to check it out, you can diff two reflog or normal commits, etc. https://www.syntevo.com/smartgit/ https://www.syntevo.com/smartgit/
fulafel 6y ago
Rebasing breaks a lot of what's good in git.

crispyambulance 6y ago

> On the surface the syntax is ugly, but the data model is brilliant. It's beyond ugly, it's needlessly incoherent. I use it because I have to and hate it. I've heard people say "the data model is a work of beauty". And I suppose that's true, but why have such a fucked up and confusing set of commands? Doesn't a "brilliant data model" deserve an equally brilliant command line? The thing that saves git is that it works, and by some miracle, it is popular. People just memorize what they need to do for their workflows and that's mostly fine. Sometimes there's a screw-up and you blow time googling around or looking up fixes. People won't publicly admit it but a lot of work gets trashed because finagling git intricacies is more painful than throwing away some work and starting over.

arp242 6y ago
> by some miracle, it is popular Probably because Linus Torvalds wrote it, and also because GitHub was actually quite a significant improvement over SourceForge. I know some people "love to hate" GitHub, but they made some really good "developer-first" UX improvements that many copied for good reasons. And lastly, Linus Torvalds wrote it. I still maintain that Mercurial is far better for most uses. Every time I mention this I get a flurry of technical replies about stuff most people don't even know about (HN is strongly biased like that, which is not a bad thing, just something to be aware of), but most people just want to commit, push, pull, and some related stuff like that. Git makes a lot of simple common stuff arcane to make the complex stuff easier, whereas mercurial makes the simple common stuff easy and keeps the complex stuff arcane. This strikes me as a much better design philosophy. Git and Mercurial are a tool designed to facilitate writing code (which is also a tool designed to solve problems). If you need to spend significant time to "get your head around it" then IMHO something, somewhere, has gone wrong. I still use git because it's just the pragmatical thing to do at this point in time, and to be fair there have been active efforts by the git team to make the common/simple stuff easier in recent times, but yeah, I'm not a fan.
- namdnay 6y ago
  Yes! I love Mercurial, it feels like someone designed a proper interface, instead of just exposing the internal api calls

dreamcompiler 6y ago

Agree with everything in this post except I find stash extremely useful when a pull would disrupt my current working directory. "If I only had a VCS to temporarily hang on to my local changes while I merge the team's." Stash, pull, stash pop. Done. (I don't use rebase because I like my history to tell the truth rather than be fictional. Maybe stash is less necessary with rebase; IDK.)

boring_twenties 6y ago
You don't need stash for that though, you can just create a branch. git branch my_stash git commit -am WIP # instead of stash save git pull git cherry-pick -n WIP git branch -D my_stash
- nemetroid 6y ago
  You don’t need to create a branch for that though, you can just use stash.
  - boring_twenties 6y ago
    And how is that better? You have to remember a second command with its own peculiar syntax and semantics, but don't gain any functionality. Stash is a superfluous misfeature.
    - cben 6y ago
      Behind the scenes, stashes _are_ branches! It's just UI on top of them, optimized for specific use case. You don't have to use it if you don't like it. Now staging (aka index) is special behind the scenes, making the model more complex for Al users.
    - nemetroid 6y ago
      99% of the time when I use stash, it’s ”stash” or ”stash pop”, usually with ten seconds or so between the two. It’s very easy to remember. Your alternative, on the other hand, uses an obscure flag to cherry-pick. What scenario would you use that flag for, except this particular one? How is remembering that flag any simpler? Also, I don’t think your sequence of commands is correct. First, ”git branch” doesn’t switch to the newly created branch, so ”WIP” would be committed on your original branch. Second, the argument to cherry-pick should be a reference to the commit rather than the commit message. I believe a correct version would be: git switch -c my_stash git commit -am WIP git switch - git pull git cherry-pick -n my_stash git branch -D my_stash