Hello! This is my first idea for a suggested code change, and I'm seeking some input on whether it makes sense to address, and if so, a bit of help with how to implement. I was futzing with "git log --children" and noticed that the output doesn't display children for the HEAD commit in a detached HEAD state (or even when HEAD points to a branch tip that in fact does have a child commit that is ahead of the branch). I assume the children of the HEAD commit don't display because of the way Git starts parsing backward in a parent-wise direction, so the children of the HEAD commit would never be found. But it seems like displaying the children of the HEAD commit _when they exist_ would be useful for users who have checked out a commit somewhere in the middle of a long commit history. In this case, a user might want to be able to easily find and check out a commit in the "child" direction without having to go all the way back up to the branch tip (or nearest tag) to see commits between the detached HEAD and the branch tip. I'm not sure if this really qualifies as a "bug" per se, or if there is some way to do this that I'm just missing, or if it goes against the way Git's rev lists work. But I'm wondering if it could be addressed by simply adding a discrete check to see if any commits point to HEAD as a parent, (only when the --children option is used of course), and if so, populate those ids into the log message. It does seem to make sense that ALL commits with children would show those children in the log when the --children option is used... The current behavior seems to be that all commits _except_ HEAD will display their children. Thx for your thoughts! Best, Jack
