On Wed, Sep 10, 2008 at 11:35:18AM +0200, Paolo Bonzini wrote: > > 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. > > 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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
