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

["Stephen R. van den Berg" <srb@cuci.nl>]

Linus Torvalds wrote:
>On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:
>> Jakub Narebski wrote:
>> >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.

>All those operations are commonly used (along with "git rebase -i") to 
>clean up history in order to show a nicer version.

Actually, I'd suggest that cherry-pick takes an -o flag which turns on
the origin link.  This needs to be a concious decision because one deems
the history relevant.  This typically is a Good Thing when the
development has several long-term-stable branches which never get merged
with each other, yet they receive frequent backports (using cherry-pick)
between them.

>The whole point of "origin" seems to be to _destroy_ that.

Only in the case where the committer thinks the history is of interest,
and even then, since the origin link is in the header, displaying it or
not suddenly is under the control of git.
Had it been in the free-form textarea, there'd be no way suppress the
display of it.

>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.

As you might have noticed, the actual process of pulling/fetching
explicitly does *not* pull in the objects being pointed to.
That, in turn, will cause the origin link output to be automatically
suppressed.  I.e. you'll never know the difference.

OTOH, if someone adds a free-form link to the commit message, you
essentially cannot hide that and are just suffering the clutter without
having any use for it.

>IOW, I'm seeing a _lot_ of downsides, and not any actual upsides. What are 
>the upsides again? 

The upsides are:
- If your repository contains the proper branches, it will show a richer
  content.
- If your repository lacks the proper branches, it will show a *reduced*
  clutter content (because actual free-text references in the commit
  messages will decrease).

I see a lot of upsides, what were the downsides again?
-- 
Sincerely,
           Stephen R. van den Berg.

"Be spontaneous!"