Hacker News new | past | comments | ask | show | jobs | submit login

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.




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?


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


  git log <COMMIT>..


`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.


  git log --all --ancestry-path ^<COMMIT>




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: