Jeff King <peff@xxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html