9 ms·

Git is one of those things that people (including myself) have frequently derided for being "unintuitive", "full of footguns", etc. But after looking at other

by mlsu 3y ago

Git is one of those things that people (including myself) have frequently derided for being "unintuitive", "full of footguns", etc. But after looking at other source control options, I find it to be an absolute joy to use -- even for very complex tasks. The VC problem itself is where the complexity lies. Any tool that deals with collaborative working on document will present the same issues that Git does. Maybe worse. Be thankful that you can use any tool you want to create plain-text diffs; that git performs operations quickly; that resets, undo's, etc are possible; that the precise history (both of the actual state and the steps taken to get there) is entirely legible; that each command performs a single, well-defined, and well documented atomic operation; that the tool is extensible, command-line script-able, usable locally, free; that it keeps the size of a repository small; that it is scalable across any number of contributors working simultaneously. Some, all, or none of these may be true with other tools. Anyone ever had to do a diff of a Microsoft Visio document by hand? Anyone had to manually type in the name of a document and its revision by hand into a web form? Anyone ever spent an afternoon working on a document, only to realize that someone else already made the changes you made but forgot to update the filaname which caused their changes not to be visible to you? Programmers are spoiled with the best tools in version control. People in other domains are doing this, without even knowing that they are doing this. They are making commits, merging, rebasing, etc.. without even having a word to describe it.

paulddraper 3y ago
Yes and no. Git beautifully matches the problem of collaboration at a fundamental level. The abstractions, the data structures... if not flawless then at least very, very good. (And that is enough to overcome any number of other issues.) The complaints are the inconsistency of the interface. E.g. `git branch`
- mlsu 3y ago
  Yes, But I would say that is a minor issue; I appreciate that there actually is lots of documentation for the precise and unchanging behavior of `git branch`! Instead of: "Oh, email this to doc management. Depends on who you get. If you get Nancy, she will double check that your rev C filename matches with your rev D filename in the changes section. Matteo does it differently though, sometimes you do need to include redlines for minor AND major changes, even if the major version gets rev'd. Oh, that doc doesn't have any minor changes at all. I don't really know why, but you better not include minor changes because that will be flagged for sure, only on this document though, for every other one you should have C->D in the footer. Oh that one, the template never got updated so you actually have to type it in manually. Yeah, no idea why it does that. It would be great if you got the change review back by Wednesday because regulatory has a preliminary product summative scheduled Monday. There's a confluence page for which doc manager should be CC'd for each document to get the review back in time."
  - throw0101a 3y ago
    > Yes, But I would say that is a minor issue; "Just memorize these shell commands and type them to sync up. If you get errors, save your work elsewhere, delete the project, and download a a fresh copy." * https://xkcd.com/1597/ https://xkcd.com/1597/
    - theycallhermax 3y ago
      There truly is a XKCD for everything...
    - erik_seaberg 3y ago
      If you deeply understand git, I recommend keeping that to yourself, unless you want to be named in git.txt. But being the guy who sort of understood svnmerge.py was much worse.
    - Blackthorn 3y ago
      I wish people would do a little bit of yak shaving when they run into errors (usually some form of merge conflict when pulling) to learn how to fix them, roll back, etc. They would learn how to appreciate the power and flexibility of git then. I've helped people in my own open source project when they hit git roadblocks. They've never needed to save out their work and wipe their repo. There was always a solution within git and once they learned it, they really understood how version control worked much better.
      - seba_dos1 3y ago
        I always assumed that xkcd strip was a parody (who didn't do that at least once after all!), but some people seem to consider it a literal advice...
  - SOLAR_FIELDS 3y ago
    Another example is stuff like this: git fetch origin main git reset —-hard origin/main Why does the first “origin main” not need a slash and the second does? I’m sure there’s a “perfectly reasonable” explanation for it but it screams UX inconsistency to me. In before people tell me that it makes perfect sense because that’s how Git works. Well duh, because Git was designed that way, not that the problem that it’s encapsulating demands it
- masklinn 3y ago
  > The abstractions, […] The complaints are the inconsistency of the interface. E.g. `git branch` Surely “git branch” is “the abstractions”?
  - paulddraper 3y ago
    Git branches are a model/concept/abstraction. `git branch` is a CLI command.
    - LudwigNagasena 3y ago
      Public functions/commands are supposed to abstract internal functions/commands.
      - da39a3ee 3y ago
        By "abstractions", parent means the abstract entities forming the application domain model. The user interface to that domain model is not the abstractions.
        LudwigNagasena 3y ago
        I don’t get the distinction. An application’s domain model always has an interface layer. It can either be API or UI, but in either case it’s something your model allows to expose.
        paulddraper 3y ago
        Substitute "domain modeling" for"abstraction" in my statement and it may make more sense.
        LudwigNagasena 3y ago
        Do you not consider stuff like <tree-ish> or <pathspec> that are referred to in git docs[1] to be an abstraction? [1] https://git-scm.com/docs/git-reset https://git-scm.com/docs/git-reset
sverhagen 3y ago
Up to 2011 I used Subversion. Then I worked for a year for a company that used CVS. So, by comparison, my time with Subversion looks trouble-free, as you can imagine. I've worked in Git ever since, but every time Git makes my feet hurt, I think back with fond memories to Subversion and TortoiseSVN, probably unwarranted so.
- TylerE 3y ago
  Don’t even have to go that far back. Mercurial is/was a way better ux over a very similar feature set.
  - paulddraper 3y ago
    I wonder why mercurial didn't win. I think it was the performance.
    - nordsieck 3y ago
      IMO, it really helped that Linux/Linus had a lot more fame. At the time there was drama around Bitkeeper, which Linux found acceptable, but was closed source.
    - HWR_14 3y ago
      Mercurial was optimized for performance on windows. On other OSes it was worse. But the reason it didn't win isn't that. It was GitHub. GitHub changed it from "use one of several analogous products"[0] to network effects. [0] Joel, founder of StackOverflow, had a GitHub like competitor that used either git or mercurial commands on the same repository. Just as one example of how similar they are.
      - paulddraper 3y ago
        But bitbucket supported both
        jholman 3y ago
howinteresting 3y ago
Simple question: why is there no git undo command shipped in box? There is absolutely no technical barrier to shipping such a command.
- paulddraper 3y ago
  Like, git revert? Or git reset?
  - hinoki 3y ago
    git reflog? All of those need you to know what you’re doing and what exactly you want to undo
  - nordsieck 3y ago
    It would be a wrapper: something like: * git branch hidden current * git do-the-command-here * if we call git undo, checkout the hidden branch, otherwise delete it In practice, I think a lot of people call `git lg` often enough that they can just git reset --hard to a recent commit hash, or they manually create a just-in-case branch if they're going to do something risky/dangerous.
  - howinteresting 3y ago
    Look at the last repository-altering operation you ran and reverse the effects of it. Add a --dry-run to see what it would do, and print out the command it runs as a way to teach people more advanced things about Git. Microsoft Word has undo. Git can as well.
- jsunderland323 3y ago
  Do you mean literally deleting your last commit? That would break a lot of the guarantees gained from the append only graph that git exploits for nearly everything it does. I think undo is too ambiguous in the context of vcs that it would be risky to introduce as a part of the cli api. What would you expect undo to do?
  - masklinn 3y ago
8ig8 3y ago
Have you spent much time using Fossil? https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki
nvy 3y ago
>But after looking at other source control options, I find it to be an absolute joy to use Git is objectively pretty janky, though, so it seems to me this statement is an indictment of Subversion and CVS rather than some statement about the virtues of git. I think it's much like the case with Wireguard. It's not that wireguard is some super amazing thing to deserve such adulation; it just sucks (a lot) less than what came before it.
- mlsu 3y ago
  Nope, I'm not even talking about subversion or CVS (although, I certainly prefer git to those, and it's a fun discussion). I am talking about patched-together workflows developed at regulatory agencies, law offices and the like; collaborative editing of... non-code "information". People who are doing "version control" but don't know that they are doing version control. They are editing documents in parallel. They are changing documents and recording the changes with a paper trail and diffs. They are working on separate parts of the same document in parallel, and managing the conflicts that appear in those documents when they are rev'd. They are sending their changes to someone else to have them reviewed before they are rev'd. Version control. Their workflows and their tools are positively prehistoric compared to what is being discussed here.
  - nvy 3y ago
    I'm an aerospace engineer so I know all about Windows shops that operate on the "RequirementsSpec-final (3) Nate's comments.docx" school of version control. Half the industry runs on excel spreadsheets. I feel your pain.
lelanthran 3y ago
> But after looking at other source control options, ... > Anyone ever had to do a diff of a Microsoft Visio document by hand? Anyone had to manually type in the name of a document and its revision by hand into a web form? Anyone ever spent an afternoon working on a document, only to realize that someone else already made the changes you made but forgot to update the filaname which caused their changes not to be visible to you? Programmers are spoiled with the best tools in version control. People in other domains are doing this, without even knowing that they are doing this. They are making commits, merging, rebasing, etc.. without even having a word to describe it. I don't see what that last paragraph has to do with git being any good. You're looking at the difficulty of collaboration without revision control, and saying "this shows how good this particular revision control system is". If you think git is good because of that last paragraph, then it's no better than CVS.
- robertlagrant 3y ago
  That isn't the point there. It's that we should be thankfuly for text-based tools in general, compared to most other professions' experience of digital collaboration.
  - masklinn 3y ago
    That has nothing to do with git then, and it very much fails to justify the assertion that > Any tool that deals with collaborative working on document will present the same issues that Git does. Maybe worse.
  - lucideer 3y ago
    That isn't the point I gleaned from reading it. The gp seemed to be making a specific point about Git, not about text based tools in general.
e12e 3y ago
> But after looking at other source control options, I find it to be an absolute joy to use -- even for very complex tasks. The VC problem itself is where the complexity lies. I think mercurial is a lot better and more intuitive. So does the recent "jj" appear to be: https://github.com/martinvonz/jj https://github.com/martinvonz/jj I think maybe both fossil and bitkeeper are more intuitive too. Did you try any of those?
lucideer 3y ago
> But after looking at other source control options Genuinely curious: what other VCS are you referencing here? Personally, I have not used many, but of the total of three that I have used, Git is the hardest. I've used SVN and I will start by saying that Git is objectively better. But that "better" is a balance between ease-of-use and features/power. SVN is much much nicer to use than Git in certain (admittedly narrow) contexts. To be more specific, the SVN (cli) user interface is a lot nicer to use than Git's. Merge conflict resolution is improved in Git, and decentralisation is pretty useful - the ability to setup a local repo and persist changes to disk immediately with no remote is essential in modern version control. These things make Git better but it is not easier to use. Then of course there's Mercurial: somehow delivers on all the things Git has over SVN while still being almost as easy to use as SVN. No competition here.
senda 3y ago
git is just a dag once you get that you're golden

by mlsu 3y ago

paulddraper 3y ago

Yes and no. Git beautifully matches the problem of collaboration at a fundamental level. The abstractions, the data structures... if not flawless then at least very, very good. (And that is enough to overcome any number of other issues.) The complaints are the inconsistency of the interface. E.g. `git branch`

mlsu 3y ago
Yes, But I would say that is a minor issue; I appreciate that there actually is lots of documentation for the precise and unchanging behavior of `git branch`! Instead of: "Oh, email this to doc management. Depends on who you get. If you get Nancy, she will double check that your rev C filename matches with your rev D filename in the changes section. Matteo does it differently though, sometimes you do need to include redlines for minor AND major changes, even if the major version gets rev'd. Oh, that doc doesn't have any minor changes at all. I don't really know why, but you better not include minor changes because that will be flagged for sure, only on this document though, for every other one you should have C->D in the footer. Oh that one, the template never got updated so you actually have to type it in manually. Yeah, no idea why it does that. It would be great if you got the change review back by Wednesday because regulatory has a preliminary product summative scheduled Monday. There's a confluence page for which doc manager should be CC'd for each document to get the review back in time."
- throw0101a 3y ago
  > Yes, But I would say that is a minor issue; "Just memorize these shell commands and type them to sync up. If you get errors, save your work elsewhere, delete the project, and download a a fresh copy." * https://xkcd.com/1597/ https://xkcd.com/1597/
  - theycallhermax 3y ago
    There truly is a XKCD for everything...
  - erik_seaberg 3y ago
    If you deeply understand git, I recommend keeping that to yourself, unless you want to be named in git.txt. But being the guy who sort of understood svnmerge.py was much worse.
  - Blackthorn 3y ago
    I wish people would do a little bit of yak shaving when they run into errors (usually some form of merge conflict when pulling) to learn how to fix them, roll back, etc. They would learn how to appreciate the power and flexibility of git then. I've helped people in my own open source project when they hit git roadblocks. They've never needed to save out their work and wipe their repo. There was always a solution within git and once they learned it, they really understood how version control worked much better.
    - seba_dos1 3y ago
      I always assumed that xkcd strip was a parody (who didn't do that at least once after all!), but some people seem to consider it a literal advice...
- SOLAR_FIELDS 3y ago
  Another example is stuff like this: git fetch origin main git reset —-hard origin/main Why does the first “origin main” not need a slash and the second does? I’m sure there’s a “perfectly reasonable” explanation for it but it screams UX inconsistency to me. In before people tell me that it makes perfect sense because that’s how Git works. Well duh, because Git was designed that way, not that the problem that it’s encapsulating demands it
masklinn 3y ago
> The abstractions, […] The complaints are the inconsistency of the interface. E.g. `git branch` Surely “git branch” is “the abstractions”?
- paulddraper 3y ago
  Git branches are a model/concept/abstraction. `git branch` is a CLI command.
  - LudwigNagasena 3y ago
    Public functions/commands are supposed to abstract internal functions/commands.
    - da39a3ee 3y ago
      By "abstractions", parent means the abstract entities forming the application domain model. The user interface to that domain model is not the abstractions.
      - LudwigNagasena 3y ago
        I don’t get the distinction. An application’s domain model always has an interface layer. It can either be API or UI, but in either case it’s something your model allows to expose.
        paulddraper 3y ago
        Substitute "domain modeling" for"abstraction" in my statement and it may make more sense.
        LudwigNagasena 3y ago
        Do you not consider stuff like <tree-ish> or <pathspec> that are referred to in git docs[1] to be an abstraction? [1] https://git-scm.com/docs/git-reset https://git-scm.com/docs/git-reset

sverhagen 3y ago

Up to 2011 I used Subversion. Then I worked for a year for a company that used CVS. So, by comparison, my time with Subversion looks trouble-free, as you can imagine. I've worked in Git ever since, but every time Git makes my feet hurt, I think back with fond memories to Subversion and TortoiseSVN, probably unwarranted so.

TylerE 3y ago
Don’t even have to go that far back. Mercurial is/was a way better ux over a very similar feature set.
- paulddraper 3y ago
  I wonder why mercurial didn't win. I think it was the performance.
  - nordsieck 3y ago
    IMO, it really helped that Linux/Linus had a lot more fame. At the time there was drama around Bitkeeper, which Linux found acceptable, but was closed source.
  - HWR_14 3y ago
    Mercurial was optimized for performance on windows. On other OSes it was worse. But the reason it didn't win isn't that. It was GitHub. GitHub changed it from "use one of several analogous products"[0] to network effects. [0] Joel, founder of StackOverflow, had a GitHub like competitor that used either git or mercurial commands on the same repository. Just as one example of how similar they are.
    - paulddraper 3y ago
      But bitbucket supported both
      - jholman 3y ago

howinteresting 3y ago

Simple question: why is there no git undo command shipped in box? There is absolutely no technical barrier to shipping such a command.

paulddraper 3y ago
Like, git revert? Or git reset?
- hinoki 3y ago
  git reflog? All of those need you to know what you’re doing and what exactly you want to undo
- nordsieck 3y ago
  It would be a wrapper: something like: * git branch hidden current * git do-the-command-here * if we call git undo, checkout the hidden branch, otherwise delete it In practice, I think a lot of people call `git lg` often enough that they can just git reset --hard to a recent commit hash, or they manually create a just-in-case branch if they're going to do something risky/dangerous.
- howinteresting 3y ago
  Look at the last repository-altering operation you ran and reverse the effects of it. Add a --dry-run to see what it would do, and print out the command it runs as a way to teach people more advanced things about Git. Microsoft Word has undo. Git can as well.
jsunderland323 3y ago
Do you mean literally deleting your last commit? That would break a lot of the guarantees gained from the append only graph that git exploits for nearly everything it does. I think undo is too ambiguous in the context of vcs that it would be risky to introduce as a part of the cli api. What would you expect undo to do?
- masklinn 3y ago

8ig8 3y ago

Have you spent much time using Fossil? https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki

nvy 3y ago

>But after looking at other source control options, I find it to be an absolute joy to use Git is objectively pretty janky, though, so it seems to me this statement is an indictment of Subversion and CVS rather than some statement about the virtues of git. I think it's much like the case with Wireguard. It's not that wireguard is some super amazing thing to deserve such adulation; it just sucks (a lot) less than what came before it.

mlsu 3y ago
Nope, I'm not even talking about subversion or CVS (although, I certainly prefer git to those, and it's a fun discussion). I am talking about patched-together workflows developed at regulatory agencies, law offices and the like; collaborative editing of... non-code "information". People who are doing "version control" but don't know that they are doing version control. They are editing documents in parallel. They are changing documents and recording the changes with a paper trail and diffs. They are working on separate parts of the same document in parallel, and managing the conflicts that appear in those documents when they are rev'd. They are sending their changes to someone else to have them reviewed before they are rev'd. Version control. Their workflows and their tools are positively prehistoric compared to what is being discussed here.
- nvy 3y ago
  I'm an aerospace engineer so I know all about Windows shops that operate on the "RequirementsSpec-final (3) Nate's comments.docx" school of version control. Half the industry runs on excel spreadsheets. I feel your pain.

lelanthran 3y ago

> But after looking at other source control options, ... > Anyone ever had to do a diff of a Microsoft Visio document by hand? Anyone had to manually type in the name of a document and its revision by hand into a web form? Anyone ever spent an afternoon working on a document, only to realize that someone else already made the changes you made but forgot to update the filaname which caused their changes not to be visible to you? Programmers are spoiled with the best tools in version control. People in other domains are doing this, without even knowing that they are doing this. They are making commits, merging, rebasing, etc.. without even having a word to describe it. I don't see what that last paragraph has to do with git being any good. You're looking at the difficulty of collaboration without revision control, and saying "this shows how good this particular revision control system is". If you think git is good because of that last paragraph, then it's no better than CVS.

robertlagrant 3y ago
That isn't the point there. It's that we should be thankfuly for text-based tools in general, compared to most other professions' experience of digital collaboration.
- masklinn 3y ago
  That has nothing to do with git then, and it very much fails to justify the assertion that > Any tool that deals with collaborative working on document will present the same issues that Git does. Maybe worse.
- lucideer 3y ago
  That isn't the point I gleaned from reading it. The gp seemed to be making a specific point about Git, not about text based tools in general.

e12e 3y ago

> But after looking at other source control options, I find it to be an absolute joy to use -- even for very complex tasks. The VC problem itself is where the complexity lies. I think mercurial is a lot better and more intuitive. So does the recent "jj" appear to be: https://github.com/martinvonz/jj https://github.com/martinvonz/jj I think maybe both fossil and bitkeeper are more intuitive too. Did you try any of those?

lucideer 3y ago

> But after looking at other source control options Genuinely curious: what other VCS are you referencing here? Personally, I have not used many, but of the total of three that I have used, Git is the hardest. I've used SVN and I will start by saying that Git is objectively better. But that "better" is a balance between ease-of-use and features/power. SVN is much much nicer to use than Git in certain (admittedly narrow) contexts. To be more specific, the SVN (cli) user interface is a lot nicer to use than Git's. Merge conflict resolution is improved in Git, and decentralisation is pretty useful - the ability to setup a local repo and persist changes to disk immediately with no remote is essential in modern version control. These things make Git better but it is not easier to use. Then of course there's Mercurial: somehow delivers on all the things Git has over SVN while still being almost as easy to use as SVN. No competition here.

senda 3y ago

git is just a dag once you get that you're golden