On Wed, Sep 10, 2008 at 11:35:18AM +0200, Paolo Bonzini wrote:
quoted text
> 
> Junio explained that the way achieves the same effect in git is by
> forking the topic branch off the "oldest" branch where the patch will
> possibly be of interest.  Then he can merge it in that branch and all
> the newest ones.  That's great, but not all people are as
> forward-looking (he did say that sometimes he needs to cherrypick).

Those who base their work on the newest ones must be very forward-
looking :) but, seriously, cherry-picking is *not* a normal workflow
with Git. Git is optimized for easy merging while cherry-picking is
a rare operation reserved for correcting some past mistakes.

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

quoted text
> 
> 2) Besides this, topic branches are not cloned, so if I am the
> integrator on the older "maint" branch, I need to dig manually in the
> commits to find bugfixes.  True, I could use Bugzilla, but what if I
> want to use git instead?  There is "git cherry -v ... | grep -w ^+.*PR",
> except that it has too many false negatives (fixes that have already
> been backported, but do show up in the list).

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
useful information, and the 'origin' link is just one of many. It may
be okay to do some general mechanism for custom commit attributes (if
it's really necessary), but making a hack for one specific item of
information feels very wrong. In fact, I have not convinced at all
that the free-form text is not suitable to store this information.


Dmitry
--
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