Re: who's on first? - following first parent and merge-management

Jeff King [off-list ref] writes:

This gave me an idea that I think is probably crazy, but that I hadn't
seen mentioned before.
...
You could extend it to topic branches, too ("refs/heads/master >
refs/heads/jk/*"). Of course, depending on your workflow, you might
_want_ to have them flipped. I.e., when it is not just laziness or lack
of understanding, and you really are making a merge commit to say "topic
XYZ depends on something that is now in master, so let's merge that in
before continuing topic development".

It certainly is *fun* to think about, and in a way it is sort-of in
line at least in spirit with the -m option to the "revert" command
to give the user run-time control over the order of the parents when
creating a new merge commit object.

But I agree that people are overly and needlessly interested in
first parenthood.

So I think the primary audience would be people doing clueless
centralized-repo development. Of course you'd perhaps want to flip the
merge message, too. And I do think people are overly-interested in
--first-parent in the first place, so the effort of specifying the
parent ordering like this is probably not worth it.

As I already said in my first message in this thread, using shared
central repository workflow does not make one a bad person, let
alone clueless.  It just means that the first parenthood is not a
suitable tool for summarlizing their histories, and there are more
suitable ones such as shortlog that would apply equally well to all
workflows regardless of the parent order.