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