[U-Boot-Users] usage of git to send patches to u-boot mailinglist

Harald Welte laforge at gnumonks.org
Thu Jul 10 02:21:49 CEST 2008


On Thu, Jul 10, 2008 at 12:30:03AM +0200, Wolfgang Denk wrote:
> In message <20080707074039.GC4412 at prithivi.gnumonks.org> you wrote:
> > 
> > New patch at the end of this mail!
> 
> Could you please start using git to prepare and  send  patches?  That
> would save me (and others) a lot of time.

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?

> Applied, thanks.

thanks!

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080710/852ce08e/attachment.pgp 


More information about the U-Boot mailing list