Re: [RFC] origin link for cherry-pick and revert

[Paolo Bonzini <bonzini@gnu.org>]

> Btw, so far nobody has even _explained_ what the advantage of the origin 
> link is. It apparently has no effect for most things, and for other things 
> it has some (unspecified) effect when it can be resolved.
> 
> Apart from the "dotted line" in graphical history viewers, I haven't 
> actually heard any single concrete example of exactly what it would *do*.

I mentioned git-cherry as an additional use case.  Automatic rename
detection works because it might have the occasional false negative, but
it has practically no false positive, and those are what screws up
merges.  But automatic changeset detection a la git-patch-id has too
many false negatives to make the current implementation of git-cherry
practical, and here's when the origin link comes in.  Also, automatic
changeset detection does not work with reverts, only with cherry-picks.

Blame could also use the origin link to go backwards in the history and
find the origin of the code, without being fooled by reverts.

I'll quote another message I sent in the thread:

>> And why are the notes created by git cherry-pick -x insufficient for that?
> 
> For example, these notes (or the ones created by "git revert") are
> *wrong* because they talk about commits instead of changesets (deltas
> between two commits).
> 
> Why is only one commit present?  Because these messages are meant for
> users, not for programs.  That's easy to see: users think of commits as
> deltas anyway, even though git stores them as snapshots---"git show
> HEAD" shows a delta, not a snapshot.
> 
> And what does this mean for programs?  That they must resort to
> commit-message scraping to distinguish the two cases. (*)
> 
>    (*) A GUI blame program, for example, would need to distinguish
>    whether code added by a commit is taken from commit 4329bd8, or is
>    reverting commit 4329bd8.  (In the first case, the author of that
>    code is whoever was responsible for that code in 4329bd8; in the
>    second case, it is whoever was responsible for that code in
>    4329bd8^).  If recording changesets, you see 4329bd8^..4329bd8 in
>    the first case, and 4329bd8..4329bd8^ in the second, so it is trivial
>    to follow the chain.
> 
> And scraping is bad.  Imagine people that are writing commit messages in
> their native language.  What if they patch git to translate the magic
> notes created by "git cherry-pick -x" or "git revert" (maybe a future
> version of git will do that automatically)?  Should they translate also
> every program that scrapes the messages?
> 
> 
> Whenever there is a piece of data that could be useful to programs (no
> matter if plumbing or porcelain), I consider free form notes to be bad.
> Because data is data, and metadata is metadata.
> 
> If there was a generic way to put porcelain-level metadata in commit
> messages (e.g. Signed-Off-By and Acknowledged-By can be already
> considered metadata), I would not be so much in favor of "origin" links
> being part of the commit object's format.  Now if you think about it,
> commit references within this kind of metadata would have mostly the
> properties that Stephen explained in his first message:
> 
> 1) they would be rewritten by git-filter-branch
> 
> 2) these references, albeit weak by default

(Note to Linus: reinforcement of your disagreement will be implicitly
assumed :-)

> could optionally be
> followed when fetching (either with command-line or configuration options)
> 
> 3) they would not be pruned by git-gc, unlike notes
> 
> 4) possibly, git rev-list --topo-order would sort commits by taking into
> account metadata references too.
> 
> So the implementation effort would be roughly the same.
> 
> But, can you think of any other such metadata?  Personally I can't, so
> while I understand the opposition to a new commit header field that
> would be there from here to eternity (or until the LHC starts), I do
> think it is the simplest thing that can possibly work.

Paolo