[darcs-devel] darcs patch: use author field of git commit rather than committer a...

[Juliusz Chroboczek]

> That's not too bad a scheme.  It does sort of eliminate the meaning of the
> "commiter" field, since this allows one to easily generate git trees that
> have two or more *different* commits with identical commit information.

Yes.

> And, in fact, we'd also be generating false information as far as
> the committer goes, in that we'd be attributing commits to people
> who didn't make them.

Yes and no.  This is a new commit from Git's point of view, but from
Darcs' point of view, it's just an old commit up to reordering.

> This mostly reflects our different priorities regarding the darcs-git-darcs
> round trip vs the git-darcs-git round trip.

Yes.  My feeling is that you're looking at things from Git's point of
view, while I'm looking at them from Darcs'.  Which is funny.

> I suppose the reason you want both is so that the git-darcs-git roundtrip
> without patch reordering is lossless?

Yes, but there's a more fundamental issue.  The author info must be
preserved, as this is the data that's useful to the human user (who's
the jerk who wrote this code?).  The committer info must be preserved,
as otherwise we'll end up with distinct homonymous patches -- and we
already know how kindly Darcs reacts to that sort of situation.  So if
my mapping scheme is to be usable, we really need to preserve both in
a single Darcs patch.

To witness the latter scenario, consider the following Git history
(time flows downwards):

      A
     / \
    B   C
        |
        D

Now suppose that someone uses Git (not Darcs!) to cherry-pick the
change C into the left-hand branch; you'll get

      A
     / \
    B   C
    |   |
    C'  D

where C' is a Git commit with the same author field as C but a
different committer.  Now suppose that the branches are merged; you get

      A
     / \
    B   C
    |   |
    C'  D
     \ /
      E

When this history is interpreted by Darcs, we end up with two distinct
patches generated from C and C'.

> Of course, most of my reason for disliking this is because of my
> crazy-tagging perspective... the author is the person who made the patch
> and the committer is the person who made the tag.

Yes.  But even in your mapping, I don't see any good reason why you
couldn't encode the Committer in the patch.  And it would avoid the
issue outlined above, which applies equally well to both schemes.

> I think I'd prefer to include "git" or "Git" in the name, so users could
> see what this is referring to.

Okay, then I'll use Git-Committer.

                                        Juliusz