>> If you fetch just branches A, B and C, but not D, the origin link from A
quoted text
>> 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.

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

quoted text
> "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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html