Re: [RFC] origin link for cherry-pick and revert

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sep 9, 2008, 23:35 UTC
Message-ID: <alpine.LFD.1.10.0809091631250.3117@nehalem.linux-foundation.org>
In-Reply-To: <20080909194354.GA13634@cuci.nl>

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

Show 15 quoted lines

> 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