6 ms·

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-give

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
      git log --all --ancestry-path ^<COMMIT>

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
    git log --all --ancestry-path ^<COMMIT>