8 ms·

This might sound a little out of touch, but am I the only one who doesn't think git is that hard? It is a collection of named pointers and a directed acyclic gr

by jimmy1 9y ago

This might sound a little out of touch, but am I the only one who doesn't think git is that hard? It is a collection of named pointers and a directed acyclic graph. The internals aren't really important once you have that concept down.

banku_brougham 9y ago
But what about the deal breaker in the article: a way to follow the decendants of a commit.
- pdfernhout 9y ago
  Took a few seconds with a search engine on "git descendants of a commit": https://stackoverflow.com/questions/27960605/find-all-the-direct-descendants-of-a-given-commit#27962018 https://stackoverflow.com/questions/27960605/find-all-the-di... That said, I do feel some "porcelain" git commands are poorly named and operate inconsistently -- compared to the plumbing of the acyclic graph concepts which is good but limited.
  - e12e 9y ago
    You mean you didn't just read git's easy-to-follow, well-structured man pages or built-in help? /s Half the time, when I know what I want, I both keep forgetting git flags and sub-commands - and struggle to find them in the man pages. Like the fine: git diff --name-only # i list only the files that are changed. But I'm not --list-files.
    - OJFord 9y ago
      Diff lists files without --name-only though, so the flag specifies you want _only_ the filenames of those with a diff.
      - e12e 9y ago
        True, but it's inconsistent with eg grep.
    - yawaramin 9y ago
      Getting only the changed filenames is a fairly specialised operation. Often in normal use you can get away with a more generic operation that comes close to what you need, but is way more common, e.g. git diff --stat
  - chipotle_coyote 9y ago
    So, in git, to show descendants of a commit, you use git rev-list --all --parents | grep "^.\{40\}.*<PARENT_SHA1>.*" | awk '{print $1}' whereas in fossil, you use fossil timeline after <COMMIT> I mean, one of these looks just a little more straightforward than the other, doesn't it? Also, a cursory test in a local git repo just now showed that command seems to print out only immediate descendants--i.e., unless that commit is the start of a branch, it's only going to tell you the single commit that comes immediately after it, not the timeline of activity that fossil will--and all it gives you is the hash of those commit(s), with no other information. I use git myself, not fossil, but if this is something you really want in your workflow, fossil is a pretty clear win.
    - dbt00 9y ago
      I mean, sure. He really wanted this feature in fossil, gave it a first class command line ui, and its super easy. How many other ways of looking at commits or trees are there, that are hard in git but impossible in fossil because the author didn’t feel like it?
    - alain_gilbert 9y ago
      I don't know why they have the need to retrieve the hash of the descendant commit, but usually what I'm doing is: I use a decent visual tool and just follow the branch (sourcetree). You could alternatively use: git log --graph
    - glandium 9y ago
      git log <COMMIT>..
      - usr1106 9y ago
        `git log` stays in the current branch unless you give it the `--all` option. But when you give it the `--all` option the limitation by `<COMMIT>..` does no longer work. So not a solution.
        glandium 9y ago
kadenshep 9y ago
No you're definitely not the only one. Git is one of the simplest and dumbest tools developers have at our disposal. People's inability to conceptualize a pretty straight forward graph is something no amount of shiny UI can ever fix. I don't understand HN's hardon for hating Git.
- carussell 9y ago
  Sure, and a piece table is a simple way to represent a file's contents. But if anyone wrote a shell or a text editor that required you to directly interact with the piece table to edit a file—instead of something sane—then they'd rightfully be called out on it. It wouldn't matter how much you argued about how simple the piece table is to understand, and it wouldn't matter how right you were about how simple the piece table is to understand. It's the wrong level of abstraction to expose in the UI.
  - kadenshep 9y ago
    The only thing Git can really fix is changing it's command flags to be consistent across aliases/internal commands. That's about it. The whole point of an SCM is that graph that you want to move away from. People have asserted your claim many times but can't ever give specific things to fix about the "abstraction." There are about 5/6 fundamental operations you do in git/hg. If that's too much then again, there's not an abstraction that is going to help you out.
    - carussell 9y ago
      See, you're trying to foist a position on me that isn't mine—that I'm scared of the essential necessities of source control. And you act as if source control were invented with Git. Neither of these are true. > git/hg Mercurial was a great solution to the same problem that Git set out to tackle, virtually free of Git's foibles. The tradeoff was a few minor foibles of its own, but a much better tool. It's a fucking shame that Git managed to suck all the air out of the room, and we're left with a far, far worse industry standard.
mabbo 9y ago
If you're new to tech or you've got a different mental model of how version control works, getting across the gap to git is a challenge. My current team are mostly controls engineers, working on PLCs. But the software we're now working with has its configurations tracked in git. These aren't dumb people, they're quite talented, but their education wasn't in CS, and "directed acyclic graph" is not a thing they have a mental model for.
- deleted 9y ago
  [deleted]

by jimmy1 9y ago

banku_brougham 9y ago

But what about the deal breaker in the article: a way to follow the decendants of a commit.

pdfernhout 9y ago
Took a few seconds with a search engine on "git descendants of a commit": https://stackoverflow.com/questions/27960605/find-all-the-direct-descendants-of-a-given-commit#27962018 https://stackoverflow.com/questions/27960605/find-all-the-di... That said, I do feel some "porcelain" git commands are poorly named and operate inconsistently -- compared to the plumbing of the acyclic graph concepts which is good but limited.
- e12e 9y ago
  You mean you didn't just read git's easy-to-follow, well-structured man pages or built-in help? /s Half the time, when I know what I want, I both keep forgetting git flags and sub-commands - and struggle to find them in the man pages. Like the fine: git diff --name-only # i list only the files that are changed. But I'm not --list-files.
  - OJFord 9y ago
    Diff lists files without --name-only though, so the flag specifies you want _only_ the filenames of those with a diff.
    - e12e 9y ago
      True, but it's inconsistent with eg grep.
  - yawaramin 9y ago
    Getting only the changed filenames is a fairly specialised operation. Often in normal use you can get away with a more generic operation that comes close to what you need, but is way more common, e.g. git diff --stat
- chipotle_coyote 9y ago
  So, in git, to show descendants of a commit, you use git rev-list --all --parents | grep "^.\{40\}.*<PARENT_SHA1>.*" | awk '{print $1}' whereas in fossil, you use fossil timeline after <COMMIT> I mean, one of these looks just a little more straightforward than the other, doesn't it? Also, a cursory test in a local git repo just now showed that command seems to print out only immediate descendants--i.e., unless that commit is the start of a branch, it's only going to tell you the single commit that comes immediately after it, not the timeline of activity that fossil will--and all it gives you is the hash of those commit(s), with no other information. I use git myself, not fossil, but if this is something you really want in your workflow, fossil is a pretty clear win.
  - dbt00 9y ago
    I mean, sure. He really wanted this feature in fossil, gave it a first class command line ui, and its super easy. How many other ways of looking at commits or trees are there, that are hard in git but impossible in fossil because the author didn’t feel like it?
  - alain_gilbert 9y ago
    I don't know why they have the need to retrieve the hash of the descendant commit, but usually what I'm doing is: I use a decent visual tool and just follow the branch (sourcetree). You could alternatively use: git log --graph
  - glandium 9y ago
    git log <COMMIT>..
    - usr1106 9y ago
      `git log` stays in the current branch unless you give it the `--all` option. But when you give it the `--all` option the limitation by `<COMMIT>..` does no longer work. So not a solution.
      - glandium 9y ago

kadenshep 9y ago

No you're definitely not the only one. Git is one of the simplest and dumbest tools developers have at our disposal. People's inability to conceptualize a pretty straight forward graph is something no amount of shiny UI can ever fix. I don't understand HN's hardon for hating Git.

carussell 9y ago
Sure, and a piece table is a simple way to represent a file's contents. But if anyone wrote a shell or a text editor that required you to directly interact with the piece table to edit a file—instead of something sane—then they'd rightfully be called out on it. It wouldn't matter how much you argued about how simple the piece table is to understand, and it wouldn't matter how right you were about how simple the piece table is to understand. It's the wrong level of abstraction to expose in the UI.
- kadenshep 9y ago
  The only thing Git can really fix is changing it's command flags to be consistent across aliases/internal commands. That's about it. The whole point of an SCM is that graph that you want to move away from. People have asserted your claim many times but can't ever give specific things to fix about the "abstraction." There are about 5/6 fundamental operations you do in git/hg. If that's too much then again, there's not an abstraction that is going to help you out.
  - carussell 9y ago
    See, you're trying to foist a position on me that isn't mine—that I'm scared of the essential necessities of source control. And you act as if source control were invented with Git. Neither of these are true. > git/hg Mercurial was a great solution to the same problem that Git set out to tackle, virtually free of Git's foibles. The tradeoff was a few minor foibles of its own, but a much better tool. It's a fucking shame that Git managed to suck all the air out of the room, and we're left with a far, far worse industry standard.

mabbo 9y ago

If you're new to tech or you've got a different mental model of how version control works, getting across the gap to git is a challenge. My current team are mostly controls engineers, working on PLCs. But the software we're now working with has its configurations tracked in git. These aren't dumb people, they're quite talented, but their education wasn't in CS, and "directed acyclic graph" is not a thing they have a mental model for.

deleted 9y ago
[deleted]