7 ms·

> I believe the core issue is devs like above never take the time to “grok” Git. The problem I have with git us that it's just too complicated. When I'm juggli

> I believe the core issue is devs like above never take the time to “grok” Git. The problem I have with git us that it's just too complicated. When I'm juggling project complexities and design complexities and implementation complexities, I frequently don't want to have to deal with git too. I understand how to stage and check in and squash, and branch and merge, and how to manage remotes. But last week I still managed to get a new repo into a state where I couldn't push local changes to github without doing a pull first, and I couldn't do a pull without (apparently) first updating the remote. I had a hard deadline and ended up deleting the repo and starting fresh. Nothing much was lost. I never had this trouble with tfs... Maybe I'm just not clever enough, but I've never come across a dev tool with as much surface complexity as git. (Not a git hater. Use it every day. Have had a personal github profile for a decade. Etc etc.)

howinteresting 4y ago
You're not alone. Git is an embarrassment to our profession.
- SavageBeast 4y ago
  Finally someone comes out and says it - I totally agree. I don't recall ever having to have a "tutorial" on Subversion. Git solves a problem the average dev really doesn't have in the first place.
  - fortran77 4y ago
    It was painfully difficult to branch in subversion. And remember the agony of asking someone to check in a file so another developer can check it out?
    - capitainenemo 4y ago
      Branching was just a copy? What was so hard about that? As for check-out locks. you only had to ask them to do that if they'd requested a lock on the file which was not the default. I hope people weren't doing that too often at your workplace.
      - howinteresting 4y ago
        To be fair, Subversion had plenty of serious limitations. Local commits are a really good thing. It's just that Git itself is a terrible UI around a bunch of decent ideas.
        capitainenemo 4y ago
        Sure. Absolutely but there were some benefits to its simple model that are still attractive for a corporate env. https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs... One of my fav rants on this subject.
      - juped 4y ago
        Merging is an operation which takes three inputs: left, right, and common ancestor. This is a very old algorithm, the diff3 utility on Unix is at least from the 70s I think? The reason history is a graph is to walk the graph and find common ancestors. Subversion's model cannot do this (screw off, pedants, I know they added an attempt at detecting common ancestors after Git had long since supplanted Subversion in relevance). And if you can't merge, you can't branch. And if you can't branch, you need locks.
        capitainenemo 4y ago
        I'm just saying, as someone who has used subversion quite a lot over the years, the situation he is describing where you have an exclusive lock where they have to check in before you can, does not happen. Exclusive locks are very rarely used in subversion. If you and your coworker are working on a file, and he checks in before you, you will simply have to update and merge. Similar to if you were both working on a local git or mercurial tree.
        capitainenemo 4y ago
        Oh, and in that situation the 3 way merge is between the version he checked into the repo, your local version you are trying to commit, and your parent revision.
- rubyist5eva 4y ago
  Mercurial should have won, it's superior in every way. For pesonal projects I use Fossil, which is fantastic.
  - devman0 4y ago
    I organized the migration from CVS -> Mercurial at my last job, and finally after several years when it became clear Git was where industry was headed we switched from Mercurial -> Git. After resisting it for a long time and then being forced to use it for a collaborative project with another firm, I have to say git is way better at being a DVCS than Mercurial. I think, as other have mentioned, that once you truly "grok" git you begin to understand the elegance and simplicity of the system and how its layered. Ultimately git's use of branch pointers was a way better solution than encoding branch data in the commit itself. To it's credit Mercurial did attempt to rectify this later with bookmarks, but ultimately DVCSs are about branch management, and git has always excelled at it.
    - rubyist5eva 4y ago
      Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck. Many things in git, are frankly anti-patterns in any other sane versioning system - comitting partial changesets because of the index? gross. Rewriting history and force pushing? absolutely insane. The fact that I don't have to "grok" mercurial like you need to git is actually a plus. Mercurial can do everything that git does (and more: check out changeset evolution in mercurial, it blows anything you can do with git rebase out of the water) and it doesn't require Ph.D. level knowledge in directed acyclic graphs to do it either.
      - WorldMaker 4y ago
        > Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck. `git merge --no-ff former-branch` by default includes "former-branch" in the auto-generated merge commit name. When it matters what branch a commit "originated" on, it's very easy to use `--no-ff` (which doesn't rewrite history and won't need any sort of force push!) and most PR tools used to default to that before "rebase" and "squash merge" became some people's favorites because of some weird (in some cases OCD) wish to see SVN-like straight lines only in their commit history.
- omnipath 4y ago
  No, it isn't. It's just a tool designed to work with complex software development workflows, which 90% of software projects do not need. 8 commands (pull, fetch, merge, push, add, commit, checkout and branch) are all you need to get going for git, which is like 2-3 more than what you need for svn/cvs. It's like getting upset that cars that are manual have an extra pedal (clutch) compared to automatic cars with their 2 (brake, accelerator).
  - howinteresting 4y ago
    Why does any serious workflow require you to be in the middle of an interactive rebase all the time?
    - WorldMaker 4y ago
      None of my serious workflows require rebases, much less interactive ones. Not that I don't do interactive rebases sometimes in local branches, but that I absolutely do not make them a part of any more general workflows. I rather try to avoid rewriting shared history where I can, and I'm happy with DAG navigation tools like --first-parent.
      - howinteresting 4y ago
        How do you manage stacks of commits for code review? (I'm guessing you just don't -- a lot of git users have really messy, unprofessional repository histories. The fact that git doesn't have great tooling for history management is also an embarrassment to our profession)
        WorldMaker 4y ago
        As I stated in the comment you are replying to: > Not that I don't do interactive rebases sometimes in local branches I don't have a problem with rebasing in local branches before code review. I just don't allow rebasing once a branch has started code review, and I especially don't allow rebasing in a public integration branch ever. (I also rarely feel the need to rebase, personally, even in my own local branches. Working in better tools than git in a past life has given me a lot of the discipline I feel that I need to build good commits as I work. I make much more use of the git staging area than I see most devs generally do and use `git add --patch` and `git add --interactive` far more than `git rebase`. `git add --patch` especially is an under-sung hero that I think a lot of junior developers should learn well in advance of rebase.) Also, I'm just not that bothered by messy histories in code reviews when I review other developers work. If the idea comes across even if the commit messages don't have the greatest narrative flow or are perfect, I'm perfectly fine with that. I make sure all merges are --no-ff and after that I can browse a "clean" history post code reviews with DAG traversal tools such as --first-parent. But that also gives me an opportunity to dig back into the mess months or years later after the code review if I need to research a bug or a regression. That sort of "sewage archeology" isn't "fun" by any means, but the number of problems I've been able to solve with it is high enough I appreciate keeping that mess around in source control. It's source control's job to keep the mess for me and present me pretty views for more regular work. That's why I prefer to trust tools like --no-ff and --first-parent over --squash, because that's what source control is built to do, control old histories messy or not.
fortran77 4y ago
I teach git professionally. I have a 3-day 12-hour course I give. I'm amazed how many people who have used SVN or CVS just assume git works like that but with different commands. And, of course, they get very screwed up. (GitHub contributes to this problem, too, with their own set of commands like "forks" and "pull requests" that aren't really a part of git.) One you understand the Merkle DAG that's at the heart of git, understanding the rest is simple. Yes the commands are named badly, but get past that and it's a great system.
- greazy 4y ago
  12 hour days? That seems way too long. How did the participants handle the amount of information over the time period?
  - fortran77 4y ago
    No! It's 12 hours over 3 days.
    - greazy 4y ago
      Apologies for misreading. That makes much more sense
  - deleted 4y ago
    [deleted]
- juped 4y ago
  These days, with more young people developing, it's less CVS assumptions as such and more a Frankenstein of cargo-culted CVS assumptions they got at a remove from the Internet and Github's truly awful and confusing web interfaces. You can't even get a simple gitk-style graph visualization on Github. Which is a website. After so many years, I really think all the blame for developer confusion can be laid at Github's feet.
  - WorldMaker 4y ago
    There's been a graph visualization in GitHub for a long time, they've just intentionally buried it. Currently: Insights tab > Network Arguably they buried it because it isn't actually what people want when they are looking for commit information. I know I've confused many developers by showing them gitk. I've been slowly working on a hypothesis that "subway diagrams" of commits look fantastic (Git Kraken looks great in screenshots) but get in the way of actually getting work done, much less thinking about the git DAG as an important tool beyond just "visualizing branches". (At this point I keep threatening to build a --first-parent based drill-down UI, that would look ugly as all get out in screenshots but might be a joy to actually use, but so far no one has sent me the check to make good on that threat.)
crispyambulance 4y ago
I've resigned myself to accepting git because I have to use it. But JFC, I've hated it from the first time I tried it. We now have a large selection of tools that allow you to visualize what's going on (I use git-kraken), as well as google for help on doing something that isn't in muscle memory. But, really, SO MUCH pain and suffering could have been resolved by refactoring the damn commands to something more coherent and consistent. Git people sometimes call this "porcelain"-- which I guess is an apt name because it makes one think of a toilet (but an improvement to a hole in the ground).
- jacquesm 4y ago
  Seconded. Git, like Linux is used everywhere, you can't avoid them. And even though I use it externally locally I use subversion, whose commands make a lot more sense to me. But Linus has something going for him: he knows how to establish critical mass for his projects, and how to create viable ecosystems.
  - airtonix 4y ago
    [dead]
- fisherjeff 4y ago
  This is maybe the most cogent version of my exact feelings on git I’ve ever read. In theory, I have no issues with git! In practice, the UX is often very very bad.
- kinkrtyavimoodh 4y ago
  i am no apologetic for the messy git UI. But i also know that any competent software engineer can be given a sufficient understanding / mental model of the basic git way of doing things in 1-2 hours, after which they can Google for the exact syntax of the commands they need (if they are doing complicated things). i feel that if they are unwilling to invest even that much time, then they are going to waste an eternity on endless tools and GUIs. it's like tar or rsync or ffmpeg. Yes, it's hard to keep track of all the command line flags etc. but thanks to the internet we don't need to. it's far more useful to understand the underlying concepts.
karmakaze 4y ago
One thing to remember is that a pull is fetch + merge. I always fetch first which doesn't change any local branches. If that doesn't work fix your remotes. You can always recreate your local branches to track remotes, then reset to specific git hashes (if you take note of them or give them temp branch names).
RichardCA 4y ago
It is not outside the realm of possibility that Github itself had a problem. I've seen instances where "git fetch" pulls refs but not the objects pointed to by the refs, then it gets cleared up an hour later and my builds suddenly start working again. It's almost pure happenstance that Linus's idea of Git being distributed lent itself to the Cloud hosting business model. And the hardest thing to teach is the mental mapping of local and remote refs. So this isn't just Git being too complicated. It's a confluence of several factors that would never have been possible if Git had never happned.

howinteresting 4y ago

You're not alone. Git is an embarrassment to our profession.

SavageBeast 4y ago
Finally someone comes out and says it - I totally agree. I don't recall ever having to have a "tutorial" on Subversion. Git solves a problem the average dev really doesn't have in the first place.
- fortran77 4y ago
  It was painfully difficult to branch in subversion. And remember the agony of asking someone to check in a file so another developer can check it out?
  - capitainenemo 4y ago
    Branching was just a copy? What was so hard about that? As for check-out locks. you only had to ask them to do that if they'd requested a lock on the file which was not the default. I hope people weren't doing that too often at your workplace.
    - howinteresting 4y ago
      To be fair, Subversion had plenty of serious limitations. Local commits are a really good thing. It's just that Git itself is a terrible UI around a bunch of decent ideas.
      - capitainenemo 4y ago
        Sure. Absolutely but there were some benefits to its simple model that are still attractive for a corporate env. https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs... One of my fav rants on this subject.
    - juped 4y ago
      Merging is an operation which takes three inputs: left, right, and common ancestor. This is a very old algorithm, the diff3 utility on Unix is at least from the 70s I think? The reason history is a graph is to walk the graph and find common ancestors. Subversion's model cannot do this (screw off, pedants, I know they added an attempt at detecting common ancestors after Git had long since supplanted Subversion in relevance). And if you can't merge, you can't branch. And if you can't branch, you need locks.
      - capitainenemo 4y ago
        I'm just saying, as someone who has used subversion quite a lot over the years, the situation he is describing where you have an exclusive lock where they have to check in before you can, does not happen. Exclusive locks are very rarely used in subversion. If you and your coworker are working on a file, and he checks in before you, you will simply have to update and merge. Similar to if you were both working on a local git or mercurial tree.
        capitainenemo 4y ago
        Oh, and in that situation the 3 way merge is between the version he checked into the repo, your local version you are trying to commit, and your parent revision.
rubyist5eva 4y ago
Mercurial should have won, it's superior in every way. For pesonal projects I use Fossil, which is fantastic.
- devman0 4y ago
  I organized the migration from CVS -> Mercurial at my last job, and finally after several years when it became clear Git was where industry was headed we switched from Mercurial -> Git. After resisting it for a long time and then being forced to use it for a collaborative project with another firm, I have to say git is way better at being a DVCS than Mercurial. I think, as other have mentioned, that once you truly "grok" git you begin to understand the elegance and simplicity of the system and how its layered. Ultimately git's use of branch pointers was a way better solution than encoding branch data in the commit itself. To it's credit Mercurial did attempt to rectify this later with bookmarks, but ultimately DVCSs are about branch management, and git has always excelled at it.
  - rubyist5eva 4y ago
    Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck. Many things in git, are frankly anti-patterns in any other sane versioning system - comitting partial changesets because of the index? gross. Rewriting history and force pushing? absolutely insane. The fact that I don't have to "grok" mercurial like you need to git is actually a plus. Mercurial can do everything that git does (and more: check out changeset evolution in mercurial, it blows anything you can do with git rebase out of the water) and it doesn't require Ph.D. level knowledge in directed acyclic graphs to do it either.
    - WorldMaker 4y ago
      > Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck. `git merge --no-ff former-branch` by default includes "former-branch" in the auto-generated merge commit name. When it matters what branch a commit "originated" on, it's very easy to use `--no-ff` (which doesn't rewrite history and won't need any sort of force push!) and most PR tools used to default to that before "rebase" and "squash merge" became some people's favorites because of some weird (in some cases OCD) wish to see SVN-like straight lines only in their commit history.
omnipath 4y ago
No, it isn't. It's just a tool designed to work with complex software development workflows, which 90% of software projects do not need. 8 commands (pull, fetch, merge, push, add, commit, checkout and branch) are all you need to get going for git, which is like 2-3 more than what you need for svn/cvs. It's like getting upset that cars that are manual have an extra pedal (clutch) compared to automatic cars with their 2 (brake, accelerator).
- howinteresting 4y ago
  Why does any serious workflow require you to be in the middle of an interactive rebase all the time?
  - WorldMaker 4y ago
    None of my serious workflows require rebases, much less interactive ones. Not that I don't do interactive rebases sometimes in local branches, but that I absolutely do not make them a part of any more general workflows. I rather try to avoid rewriting shared history where I can, and I'm happy with DAG navigation tools like --first-parent.
    - howinteresting 4y ago
      How do you manage stacks of commits for code review? (I'm guessing you just don't -- a lot of git users have really messy, unprofessional repository histories. The fact that git doesn't have great tooling for history management is also an embarrassment to our profession)
      - WorldMaker 4y ago
        As I stated in the comment you are replying to: > Not that I don't do interactive rebases sometimes in local branches I don't have a problem with rebasing in local branches before code review. I just don't allow rebasing once a branch has started code review, and I especially don't allow rebasing in a public integration branch ever. (I also rarely feel the need to rebase, personally, even in my own local branches. Working in better tools than git in a past life has given me a lot of the discipline I feel that I need to build good commits as I work. I make much more use of the git staging area than I see most devs generally do and use `git add --patch` and `git add --interactive` far more than `git rebase`. `git add --patch` especially is an under-sung hero that I think a lot of junior developers should learn well in advance of rebase.) Also, I'm just not that bothered by messy histories in code reviews when I review other developers work. If the idea comes across even if the commit messages don't have the greatest narrative flow or are perfect, I'm perfectly fine with that. I make sure all merges are --no-ff and after that I can browse a "clean" history post code reviews with DAG traversal tools such as --first-parent. But that also gives me an opportunity to dig back into the mess months or years later after the code review if I need to research a bug or a regression. That sort of "sewage archeology" isn't "fun" by any means, but the number of problems I've been able to solve with it is high enough I appreciate keeping that mess around in source control. It's source control's job to keep the mess for me and present me pretty views for more regular work. That's why I prefer to trust tools like --no-ff and --first-parent over --squash, because that's what source control is built to do, control old histories messy or not.

fortran77 4y ago

I teach git professionally. I have a 3-day 12-hour course I give. I'm amazed how many people who have used SVN or CVS just assume git works like that but with different commands. And, of course, they get very screwed up. (GitHub contributes to this problem, too, with their own set of commands like "forks" and "pull requests" that aren't really a part of git.) One you understand the Merkle DAG that's at the heart of git, understanding the rest is simple. Yes the commands are named badly, but get past that and it's a great system.

greazy 4y ago
12 hour days? That seems way too long. How did the participants handle the amount of information over the time period?
- fortran77 4y ago
  No! It's 12 hours over 3 days.
  - greazy 4y ago
    Apologies for misreading. That makes much more sense
- deleted 4y ago
  [deleted]
juped 4y ago
These days, with more young people developing, it's less CVS assumptions as such and more a Frankenstein of cargo-culted CVS assumptions they got at a remove from the Internet and Github's truly awful and confusing web interfaces. You can't even get a simple gitk-style graph visualization on Github. Which is a website. After so many years, I really think all the blame for developer confusion can be laid at Github's feet.
- WorldMaker 4y ago
  There's been a graph visualization in GitHub for a long time, they've just intentionally buried it. Currently: Insights tab > Network Arguably they buried it because it isn't actually what people want when they are looking for commit information. I know I've confused many developers by showing them gitk. I've been slowly working on a hypothesis that "subway diagrams" of commits look fantastic (Git Kraken looks great in screenshots) but get in the way of actually getting work done, much less thinking about the git DAG as an important tool beyond just "visualizing branches". (At this point I keep threatening to build a --first-parent based drill-down UI, that would look ugly as all get out in screenshots but might be a joy to actually use, but so far no one has sent me the check to make good on that threat.)

crispyambulance 4y ago

I've resigned myself to accepting git because I have to use it. But JFC, I've hated it from the first time I tried it. We now have a large selection of tools that allow you to visualize what's going on (I use git-kraken), as well as google for help on doing something that isn't in muscle memory. But, really, SO MUCH pain and suffering could have been resolved by refactoring the damn commands to something more coherent and consistent. Git people sometimes call this "porcelain"-- which I guess is an apt name because it makes one think of a toilet (but an improvement to a hole in the ground).

jacquesm 4y ago
Seconded. Git, like Linux is used everywhere, you can't avoid them. And even though I use it externally locally I use subversion, whose commands make a lot more sense to me. But Linus has something going for him: he knows how to establish critical mass for his projects, and how to create viable ecosystems.
- airtonix 4y ago
  [dead]
fisherjeff 4y ago
This is maybe the most cogent version of my exact feelings on git I’ve ever read. In theory, I have no issues with git! In practice, the UX is often very very bad.
kinkrtyavimoodh 4y ago
i am no apologetic for the messy git UI. But i also know that any competent software engineer can be given a sufficient understanding / mental model of the basic git way of doing things in 1-2 hours, after which they can Google for the exact syntax of the commands they need (if they are doing complicated things). i feel that if they are unwilling to invest even that much time, then they are going to waste an eternity on endless tools and GUIs. it's like tar or rsync or ffmpeg. Yes, it's hard to keep track of all the command line flags etc. but thanks to the internet we don't need to. it's far more useful to understand the underlying concepts.

karmakaze 4y ago

One thing to remember is that a pull is fetch + merge. I always fetch first which doesn't change any local branches. If that doesn't work fix your remotes. You can always recreate your local branches to track remotes, then reset to specific git hashes (if you take note of them or give them temp branch names).

RichardCA 4y ago

It is not outside the realm of possibility that Github itself had a problem. I've seen instances where "git fetch" pulls refs but not the objects pointed to by the refs, then it gets cleared up an hour later and my builds suddenly start working again. It's almost pure happenstance that Linus's idea of Git being distributed lent itself to the Cloud hosting business model. And the hardest thing to teach is the mental mapping of local and remote refs. So this isn't just Git being too complicated. It's a confluence of several factors that would never have been possible if Git had never happned.