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. 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. I would refuse to ever touch anything that had an "origin" pointer, so if git were to add that feature, it would be a huge disappointment to me. I'd have to have a version that makes sure that anything it pulls hasn't been crapped on by somebody who added a stupid link to some dirty history that I'm not at all interested in seeing. IOW, I'm seeing a _lot_ of downsides, and not any actual upsides. What are the upsides again? Linus -- 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
