On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:

quoted text
> Jakub Narebski wrote:
> >"Stephen R. van den Berg" <srb@cuci.nl> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html