5 ms·

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.
      - fortran77 4y ago
        Well put! And it demonstrates why people (like the HN'ers who think they're 10xers) have trouble with git. They fundamentally don't understand the problem and how git solves it.
      - howinteresting 4y ago
        This is correct, and yet Git is an embarrassment to our profession. That's how bad it is.
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.

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.
    - fortran77 4y ago
      Well put! And it demonstrates why people (like the HN'ers who think they're 10xers) have trouble with git. They fundamentally don't understand the problem and how git solves it.
    - howinteresting 4y ago
      This is correct, and yet Git is an embarrassment to our profession. That's how bad it is.

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.