Hi Harald,
Harald Welte laforge@gnumonks.org writes:
can do, even though I believe it is by far not the best tool to do so. The problem is that I would have to use one local branch per feature (i.e. lots of local branches that need to be kept in sync), and even then any incremental changes/fixes to one particular feature are visible in the commitlog (and thus result in changelog pollution).
My best experience so far really is quilt for maintaining patchsets. You can keep a large number of patches, easily switch between them and keep your modifications organized per-feature, rather than in the chronological commit order of a revision control system.
So what I can probably do is to continue to use quilt up to the point where I'd want to send something to a mailinglist, and then put into a local git branch, export the patch from there and send it to the list.
However, any further change to that patch based on feedback from the list would again go into the quilt tree, I'd have to start with a clean 'origin' u-boot git tree and commit the modified change into the git tree. Otherwise we start having all the commit messages (like 'changed coding style according to mailinglist feedback') in the code, even _before_ that code was ever merged into the respective mainline git tree.
So is this really the preferred workflow? How are others dealing with this? How to avoid commitlog pollution?
I never used quilt, but I believe stacked git (stgit) implements more or less the same behavior on top of git.
Best regards
Markus Klotzbuecher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de