>> If you fetch just branches A, B and C, but not D, the origin link from A >> to D is dangling. Once you have fetched D as well [..] > > So I just said we deleted beanch 'D', so there's no way to ever fetch it > again. > > Get it? Yes, but you should not have used Stephen's proposed new option to git cherry-pick, just like you shouldn't have used the existing -x option. "-x" would not have created a dangling reference, but it would have created a puzzling commit message. > The fact is, a big part of git is temporary branches. It's one of the > *best* features of git. Throw-away stuff. Those throw-away branches are > often done for initial development, and then the final result is often a > cleaned-up version. Often using rebase or cherry-picking or any number of > things. These days I doubt people would use cherry-pick, they would probably use interactive rebase. But anyway, exactly for the same reason... > "git cherry-pick" DOES NOT PUT THE ORIGINAL SHA1 IN THE > COMMENT FIELD BY DEFAULT. ... neither should cherry-picking create the origin link by default. Only if requested by the user, using a new option that is basically "-x" done in a different way. Just like "-x", it should not be used when cherry-picking from private branches. But say someone does it, then what happens? If people clone the branch, the reference will be basically unusable. But since "git gc" does not delete the referenced commit, at least the origin commit is still available in the repository where the cherry-pick was made. It is debatable whether it is better or worse than "-x". Can we discuss instead a generic way to have porcelain-level metadata, immutable or at least versioned, for the commit objects? (This is the same kind of metadata as the author or committer, which clearly have nothing to do with the git plumbing.) Do you have any proposal of saner semantics, not for the origin link but for commit references within this kind of metadata in general? Paolo -- 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
