On Thu, Feb 10, 2011 at 10:14:15PM -0500, John Wiegley wrote: > > And there are lots of other cases. What about "git cherry-pick -n"? What > > about rebasing? If there are no conflicts, is it OK to copy the origin > > field? How about if there are conflicts? How about in a "git rebase -i", > > where we may stop and the user can arbitrarily split, amend, or add new > > commits. How do the old commits map to the new ones with respect to > > origin fields? > > During rebasing, any commits which can be rebased without conflict have their > origin transferred (and each time it would cause the origin id list to grow by > one), but any commits which are squashed or edited would not transfer. OK. That's certainly the conservative answer, and where we should start. But I wonder in practice how many times we'll hit all the criteria just right for this feature to kick in (i.e., a cherry pick or rebase with no conflicts, followed by one that would cause a conflict). But I think there's nothing to do but implement and see how it works. After thinking about this a bit more, the whole idea of "is this cherry-picked/rebased/whatever commit the same as the one before" is really the same as the notes-rewriting case (i.e., copying notes on commit A when it is rebased into A'). Which makes me excited about using notes for this, because the rules that you do figure out to work in practice will be good rules for notes rewriting in general. > The problem with an external annotation is that if developers are sharing > feature branches, as a branch maintainer I want to know whether commits coming > from those feature branches are already in the branch I'm maintaining. In that case, I would suggest putting it in git-notes and sharing the notes with each other. The notes code should happily merge them all together, and then everyone gets to see everybody else's cherry-pick/rebase annotations. -Peff -- 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