Re: [RFC] origin link for cherry-pick and revert, and more about porcelain-level metadata

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Sep 10, 2008, 15:15 UTC
Message-ID: <20080910151542.GA10523@cuci.nl>
In-Reply-To: <20080910143329.GE28210@dpotapov.dyndns.org>

Dmitry Potapov wrote:

Show 6 quoted lines

>On Wed, Sep 10, 2008 at 11:35:18AM +0200, Paolo Bonzini wrote:
>> Another problem is that in some projects actually there are two "maint"
>> branches (e.g. currently GCC 4.2 and GCC 4.3), and most developers do
>> not care about what goes in the older "maint" branch; they develop for
>> trunk and for the newer "maint" branch, and then one person comes and
>> cherry-picks into the older "maint" branch.  This has two problems:

>> 1) Having to fork topic branches off the older branch would force extra
>> testing on the developers.

Show 12 quoted lines

>If a branch is meant to included in the oldest version, it must be
>tested with that version anyway, and it is better when it is written for
>the old version, because functions tend to be more backward compatible
>than forward compatible. In other words, functions may often acquire
>some extra functionality over time without changing their signature, so
>the code written for a new version will merge without any conflict to
>the old one, but it won't work correctly under some conditions. It is
>certainly possible to have a problem in the opposite direction, but it
>is much less likely, and usually bugs introduced in the development
>version are not as bad as destabilizing a stable branch. Thus starting
>branch that is clearly meant for inclusion to the old version from that
>version is the right thing do.

Show 5 quoted lines

>Of course, if you have more than one stable branch for a long time then
>you may want some branches forked from the new stable. You can do that
>by merging uninteresting changes from the new stable with the 'ours'
>strategy (so they will be ignored), and after that merging actually
>interesting features from the new stable.

>In contrast to cherry-picking, the real merge creates the history that
>can be easily visualized and understood.

Could you explain how the above mechanisms work based on the following cherry-pick action:

A -- B -- C -- D -- L
      \            /
       E -- F -- G -- H -- K

D is the stable branch. K is the development branch. G is cherry-picked and applied to D producing L. The origin link of L would have contained (G, F).

How would such a workflow be implemented using the temporary branches you describe?

>If you clearly mark all bugs in the commit message, there will be no
>problem to find them by grepping log. There is a lot of potentially

Sometimes they're not bugs, yet they still are backported and thus carry no special marks.

>useful information, and the 'origin' link is just one of many. It may

True, but it's one of the few machine-useable ones.

>be okay to do some general mechanism for custom commit attributes (if
>it's really necessary),

That's the problem, a general mechanism is undesirable, that we already have the free-form textfield for.

> but making a hack for one specific item of
>information feels very wrong.

It's a rather well-defined usefull property (which precludes it from being a hack, I suppose).

-- 
Sincerely,
           Stephen R. van den Berg.

"Am I paying for this abuse or is it extra?"