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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 8, 2012, 07:38 UTC
Message-ID: <7v8vjbfspu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120308071403.GE7643@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

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

Show 5 quoted lines

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