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

[Petr Baudis <pasky@suse.cz>]

On Tue, Sep 09, 2008 at 03:22:12PM +0200, Stephen R. van den Berg wrote:
> - During fetch/push/pull the full commit including the origin fields is
>   transmitted, however, the objects the origin links are referring to
>   are not (unless they are being transmitted because of other reasons).
> 
> - When fetching/pulling it is optionally possible to tell git to
>   actually transmit objects referred to by origin links even if it would
>   otherwise not have done so.

I think this is misguided. In general case, cherrypicks can be from
completely unrelated histories, and if you are doing the cherry pick,
you are saying that actually, the history *does not matter*. In that
case, this kind of link tries to impose a meaning where there is none,
and in an ill-defined way when whether the commit is actually around
anywhere is essentially random.

Why do you actually *follow* the origin link at all anyway? Without its
parents, the associated tree etc., the object is essentially useless for
you; the authorship information and commit message should've been
preserved by a proper cherry-pick anyway. You're cluttering the object
store with invalid objects, which also breaks quite some fundamental
logic within Git (which assumes that if an object exists, all its
references are valid - give or take few special cases like shallow
repositories, but this would have very different characteristics).

Having history browsers draw fancy lines is fine but I see nothing wrong
with them extracting this from the free-form part of the commit message.
For informative purposes, we don't shy away from heuristics anyway, c.f.
our renames detection (heck, we are even brave enough to use that for
merges).

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates