Nix wrote: > After all that setup, my question's simple. Does a `parent' in git > terminology simply mean `this commit was derived in some way from the > commit listed here'? If so, I suppose I can list heads/some-change-foo > as one parent on these merge commits, even though the `merging' > mechanism is so odd that I expect to be pelted with rotten vegetables as > soon as I post this. Yes, being parent means that this commit was derived in some way from the commit listed here. It needs not to be this commit is the result of merge of commits listed here... there was a discussion some time ago to use one of parents (first for example) instead of special header for "prev" link to previous value of the ref (which discussion was obsoleted by reflog). It provies two things you have to think about if to use 'parenthood' for something a bit unexpected. First, parents are connectivity, so even if you delete trunks/some-name and then prune, averything that was merged in some branch or tag which lives still wouldn't get pruned. Second, the information about merges is used in merge strategies: consider if having this information would help your strange merge strategy. And of course there is a question if the graph as visualized by for example gitk would have more sense or not with the "strange merges" marked as merges. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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