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

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

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

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