5 ms·

as great as git is, I wish there was something more intuitive. Git is definitely one of the more confusing tools out there.

VLM 11y ago
I'm curious if you don't like the concepts of how it works or the UI or maybe the workflow. A workflow example would be doing a rebase after a push is almost universally seen as naughty so why permit it without some kind of UI like --I-really-know-what-i-am-doing=yes or something? WRT the UI itself, I've read a couple people claiming the emacs magit package is easier to use than the CLI itself, which would isolate the problem to the GUI. I have not personally invested the time into magit and would find comments on that theory by people who have experimented to be interesting. http://magit.vc/ http://magit.vc/
- zyxley 11y ago
  Git's CLI is just awful in a bunch of ways. There's a bunch of commands that do two or more different things depending on how you use them, and whole piles of cryptic and incomprehensible error messages. Heck, the just the contrast between `git add <file>` and `git reset HEAD <file>` is terrible.
  - mnarayan01 11y ago
    I wouldn't describe the CLI as "awful", though I hear your complaint. Not sure where you're going with `add` versus `reset` though. `git rm --cached ${file}` would presumably do what you want with parallel syntax.
    - zyxley 11y ago
      The sane way to do it would be to have something like `git stage` and `git unstage`, as distinct single-purpose commands.
      - mnarayan01 11y ago
        The first example at https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases is literally exactly what you want.
        zyxley 11y ago
        "It's easy to make the CLI less bad, but the developers have never bothered to do so themselves" is reinforcement of my complaint, not dismissal of it.
        mnarayan01 11y ago
        Not trying to dismiss, just assist ;)
- angdis 11y ago
  There is NO particular workflow built into git. Teams have to reach an informal agreement on how they're going to use it, otherwise chaos ensues.
albinofrenchy 11y ago
Honestly? There kind of is -- https://mercurial.selenic.com/ https://mercurial.selenic.com/. I learnt mercurial first but have now spent about 3x as much time with git and I still find mercurial to be more intuitive.
- crimsonalucard 11y ago
  Cool. The problem is git is already pretty much ubiquitous. Would it be possible to put a mercurial like UI on top of git? Does one exist yet?
  - mikekchar 11y ago
    Git and Mercurial have different workflows. I don't think it would be reasonable to translate one to the other in the general case. The every day operations for both are pretty straight forward. It's where you want to do something strange where it gets hairy. At that point you want to really understand what's going on under the hood anyway. If you are interested in using Mercurial on your own project and are simply worried about hosting, here's a list of providers: https://mercurial.selenic.com/wiki/MercurialHosting https://mercurial.selenic.com/wiki/MercurialHosting If you are thinking of using Mercurial when the rest of your team uses Git, then I would just suck it up and learn Git (or convince your team to switch). It is not, by any means, the most complicated thing you have to learn for your job ;-). Back in the bad old days when I was forced to use Visual Source Safe for version control, we used to maintain our code in multiple repositories -- using CVS for development and simply pushing to VSS when features were complete. That kind of tactic is still open to you, but the overhead is rather large for the minimal difference between Git and Mercurial.
    - bbcbasic 11y ago
      > Back in the bad old days when I was forced to use Visual Source Safe for version control Sounds interesting. So was this basically a team of 'bandits' secretly using a non-endorsed VCS to collaborate and get shit done, and then pushing to VSS to keep the pointy-haired boss happy?
barrkel 11y ago
Git is the easiest to work with SCM I've used, however I've only used SourceSafe, cvs and svn before. Once you grok that it's more or less an immutable DAG with diffs for edges and hashes for node names, that tags are read-only labels for hashes and branches are read-write labels for hashes, all possible operations are obvious; you just need to find the right incantation. The concept of git being so simple is what makes working with it much easier than something like svn or cvs, where doing the equivalent of a rebase, cherry-pick or merge of a diff into multiple different branches is sufficiently difficult that I developed my own tools and workflow to get around them. When I had to work with svn writing bug fixes or doing development, instead of committing my work, I saved my work to patch files which I saved / reapplied when I switched branches. I developed scripts to do 3-way merges. I haven't had to do any of that crap with git. Git is far more logical. It's just missing a consistent command-line UI.
- Someone 11y ago
  "Once you grok that it's more or less an immutable DAG" That's problem #1. More or less immutable = mutable. Other SCMs limit mutations to additions and use a separate command (svnadmin) to do things that may permanently lose information. The svn repository may be ugly, but it can be relied on to store history. "you just need to find the right incantation." Incantation is the right term. As you admit, it's "just" missing a consistent command-line UI. The combination of these two makes me very weary whenever I do anything remotely difficult in git. A third thing that scares me is the ease with which people talk about things still being there "as long as git hasn't garbage collected them". To me, that sounds like having a memory allocator with an 'unfree' call that you can use to try and recover accidentally freed memory.
  - barrkel 11y ago
    The dag is immutable; it's a bit more than just a dag though. That's what I meant. Your GC fears sound like superstition, sorry. Nothing to do with manual memory allocation, and the problems of manual memory management are irrelevant. GC just collects nodes no longer reachable from branches or tags. Very unscary once you understand the dag nature.
erikb 11y ago
Only as long as you don't learn it. If you really need to use git often, please take the time and go through the git book. Then most things make sense and using git becomes way more stable. It's a powertool for power users. It sks that it became the major tool of our time, but that doesn't change it's design decisions. (And I'm a huge git fan. But I'm also a power user who is happy to spend weekends to learn all the details about such a tool)

VLM 11y ago

I'm curious if you don't like the concepts of how it works or the UI or maybe the workflow. A workflow example would be doing a rebase after a push is almost universally seen as naughty so why permit it without some kind of UI like --I-really-know-what-i-am-doing=yes or something? WRT the UI itself, I've read a couple people claiming the emacs magit package is easier to use than the CLI itself, which would isolate the problem to the GUI. I have not personally invested the time into magit and would find comments on that theory by people who have experimented to be interesting. http://magit.vc/ http://magit.vc/

zyxley 11y ago
Git's CLI is just awful in a bunch of ways. There's a bunch of commands that do two or more different things depending on how you use them, and whole piles of cryptic and incomprehensible error messages. Heck, the just the contrast between `git add <file>` and `git reset HEAD <file>` is terrible.
- mnarayan01 11y ago
  I wouldn't describe the CLI as "awful", though I hear your complaint. Not sure where you're going with `add` versus `reset` though. `git rm --cached ${file}` would presumably do what you want with parallel syntax.
  - zyxley 11y ago
    The sane way to do it would be to have something like `git stage` and `git unstage`, as distinct single-purpose commands.
    - mnarayan01 11y ago
      The first example at https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases is literally exactly what you want.
      - zyxley 11y ago
        "It's easy to make the CLI less bad, but the developers have never bothered to do so themselves" is reinforcement of my complaint, not dismissal of it.
        mnarayan01 11y ago
        Not trying to dismiss, just assist ;)
angdis 11y ago
There is NO particular workflow built into git. Teams have to reach an informal agreement on how they're going to use it, otherwise chaos ensues.

albinofrenchy 11y ago

Honestly? There kind of is -- https://mercurial.selenic.com/ https://mercurial.selenic.com/. I learnt mercurial first but have now spent about 3x as much time with git and I still find mercurial to be more intuitive.

crimsonalucard 11y ago
Cool. The problem is git is already pretty much ubiquitous. Would it be possible to put a mercurial like UI on top of git? Does one exist yet?
- mikekchar 11y ago
  Git and Mercurial have different workflows. I don't think it would be reasonable to translate one to the other in the general case. The every day operations for both are pretty straight forward. It's where you want to do something strange where it gets hairy. At that point you want to really understand what's going on under the hood anyway. If you are interested in using Mercurial on your own project and are simply worried about hosting, here's a list of providers: https://mercurial.selenic.com/wiki/MercurialHosting https://mercurial.selenic.com/wiki/MercurialHosting If you are thinking of using Mercurial when the rest of your team uses Git, then I would just suck it up and learn Git (or convince your team to switch). It is not, by any means, the most complicated thing you have to learn for your job ;-). Back in the bad old days when I was forced to use Visual Source Safe for version control, we used to maintain our code in multiple repositories -- using CVS for development and simply pushing to VSS when features were complete. That kind of tactic is still open to you, but the overhead is rather large for the minimal difference between Git and Mercurial.
  - bbcbasic 11y ago
    > Back in the bad old days when I was forced to use Visual Source Safe for version control Sounds interesting. So was this basically a team of 'bandits' secretly using a non-endorsed VCS to collaborate and get shit done, and then pushing to VSS to keep the pointy-haired boss happy?

barrkel 11y ago

Git is the easiest to work with SCM I've used, however I've only used SourceSafe, cvs and svn before. Once you grok that it's more or less an immutable DAG with diffs for edges and hashes for node names, that tags are read-only labels for hashes and branches are read-write labels for hashes, all possible operations are obvious; you just need to find the right incantation. The concept of git being so simple is what makes working with it much easier than something like svn or cvs, where doing the equivalent of a rebase, cherry-pick or merge of a diff into multiple different branches is sufficiently difficult that I developed my own tools and workflow to get around them. When I had to work with svn writing bug fixes or doing development, instead of committing my work, I saved my work to patch files which I saved / reapplied when I switched branches. I developed scripts to do 3-way merges. I haven't had to do any of that crap with git. Git is far more logical. It's just missing a consistent command-line UI.

Someone 11y ago
"Once you grok that it's more or less an immutable DAG" That's problem #1. More or less immutable = mutable. Other SCMs limit mutations to additions and use a separate command (svnadmin) to do things that may permanently lose information. The svn repository may be ugly, but it can be relied on to store history. "you just need to find the right incantation." Incantation is the right term. As you admit, it's "just" missing a consistent command-line UI. The combination of these two makes me very weary whenever I do anything remotely difficult in git. A third thing that scares me is the ease with which people talk about things still being there "as long as git hasn't garbage collected them". To me, that sounds like having a memory allocator with an 'unfree' call that you can use to try and recover accidentally freed memory.
- barrkel 11y ago
  The dag is immutable; it's a bit more than just a dag though. That's what I meant. Your GC fears sound like superstition, sorry. Nothing to do with manual memory allocation, and the problems of manual memory management are irrelevant. GC just collects nodes no longer reachable from branches or tags. Very unscary once you understand the dag nature.

erikb 11y ago

Only as long as you don't learn it. If you really need to use git often, please take the time and go through the git book. Then most things make sense and using git becomes way more stable. It's a powertool for power users. It sks that it became the major tool of our time, but that doesn't change it's design decisions. (And I'm a huge git fan. But I'm also a power user who is happy to spend weekends to learn all the details about such a tool)