Linus Torvalds wrote: > On Tue, 9 Sep 2008, Stephen R. van den Berg wrote: >> Jakub Narebski wrote: >>>"Stephen R. van den Berg" <srb@xxxxxxx> writes: >>>> The definition of the origin field reads as follows: >> >>>> - There can be an arbitrary number of origin fields per commit. >>>> Typically there is going to be at most one origin field per commit. >> >>> I understand that multiple origin fields occur if you do a squash >>> merge, or if you cherry-pick multiple commits into single commit. >>> For example: >>> $ git cherry-pick -n <a1> >>> $ git cherry-pick <a2> >>> $ git commit --amend #; to correct commit message >> >> Correct. > > Quite frankly, recording the origins for _any_ of the above sounds like a > horribly mistake. Actually the above is _not_ a good example for using 'origin', and why using 'origin'; just a bit convoluted example of multiple 'origin' headers. > All those operations are commonly used (along with "git rebase -i") to > clean up history in order to show a nicer version. > > The whole point of "origin" seems to be to _destroy_ that. If I understand correctly the point is to record those 'origin' headers for git-revert (when 'origin'-ed commit is somewhere in the history), and for git-cherry-pick from other long lived branch and thus require additional option to git-cherry-pick to record 'origin' (denoting that you this is "true" cherry-pick, and not reordering of commits and cleaning up a history, better done with interactive rebase). /me is playing advocatus diaboli here, 'cause I'm not that convinced to necessity of this feature. -- Jakub Narebski Poland -- 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
