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

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

Petr Baudis wrote:
>On Wed, Sep 10, 2008 at 12:56:03AM +0200, Stephen R. van den Berg wrote:

>In other way, I think this is purely a porcelain matter and recording
>this information in the free-form area is more than enough.

>> I'd prefer to formalise the (weak) relationship of an origin link, instead of
>> relying on vague assumptions when parsing the free-form commit message
>> and then guessing what the mentioned hash might mean.

>Why?

Using special references in the free-form area of a commit is akin to
using X-... headerfields in E-mail with all the assorted mess:
- No strict definition of what it means.
- Diverging porcelain implementations making use of the field in ever so
  slightly changing ways over the years.
- You cannot rely on the field being always available.
- Automated "renumbering" becomes difficult at best.

What we want are concise and unambiguous definitions which allow us to
build tools that operate predictably on them now, and will operate
predictably on them in the future.

>> >Having history browsers draw fancy lines is fine but I see nothing wrong

>> It's not just that.  If I make a change to an area that was cherrypicked
>> from another branch, then I find it rather important to check if any
>> changes to this area need to be backported/forwardported to the branches
>> the origin links are pointing to.
>> I.e. the origin link allows me to improve my efficiency as a programmer.

>And why are the notes created by git cherry-pick -x insufficient for that?

Things like rebase/filter-branch/stgit mess that up because they don't
know if the hash in the free-form should be altered.
Also, there is no automated way to actually fetch missing branches we
cherry-picked from this way.
-- 
Sincerely,
           Stephen R. van den Berg.

"Be spontaneous!"