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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> >delete of the origin branch will basically make them unreachable.

>> False.

>Stephen, here's a f*cking clue:
> - I know how git works.

I'd presume you do, but that doesn't mean you always accurately express
yourself.

>> If you fetch just branches A, B and C, but not D, the origin link from A
>> to D is dangling.  Once you have fetched D as well [..]

>So I just said we deleted beanch 'D', so there's no way to ever fetch it 
>again.

You did not state you deleted branch 'D' on the repository being fetched
*FROM*.  I assumed you meant you deleted branch 'D' on the repository
doing the fetching (after having fetched 'D' in the past).

>Get it?

"You stupid git".

>The fact is, a big part of git is temporary branches. It's one of the 
>*best* features of git. Throw-away stuff. Those throw-away branches are 
>often done for initial development, and then the final result is often a 
>cleaned-up version. Often using rebase or cherry-picking or any number of 
>things.

Indeed, features I value in git very much, and use every day, thanks.

[...portions of man git-cherry-pick stripped...]

>Can you not understand that? The "origin" field is _garbage_. It's garbage 
>for all normal cases. The original commit will not ever even EXIST in the 
>result, because it has long since been thrown away and will never exist 
>anywhere else.

The origin field will *not* be created on regular cherry-picks, this
*would* create garbage.  The origin field is not meant to be generated
when doing things with temporary branches.  The origin field is meant to
be filled *ONLY* when cherry-picking from one permanent branch to
another permanent branch.  This is a *rare* operation.

>Garbage should be _avoided_, not added.

Quite.

I do understand that "normal cases" in your case mean cherry-picks among
temporary branches.
Well, you are completely right that *your* normal cases should not (and
will not) generate an origin field.
The origin field is intended for the *abnormal* cases, which means
cherry-picking between permanent branches (which, apparently, you rarely
do, if ever), this is something that (depending on your workflow) can be
a more frequent event.  For *those* cases, the origin field will not
contain garbage.
-- 
Sincerely,
           Stephen R. van den Berg.
"There are three types of people in the world;
 those who can count, and those who can't."
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux