Dmitry Potapov wrote:
quoted text
>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:

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

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

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

quoted text
>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?

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

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

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

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

quoted text
> 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?"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html