Dmitry Potapov wrote:
>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.
>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.
>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?"
--
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
