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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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.