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

[Paul Gortmaker]

On Wed, Jul 9, 2008 at 8:21 PM, Harald Welte <laforge at gnumonks.org> wrote:
> 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?

If you really like quilt, then perhaps look into guilt?  (A cross between
the functionality of quilt, layered onto the underpinnings of git).

Or you can cherry-pick your unchanged commits onto a new branch,
plus the one requiring a change; make the change, do a git-add and
a git-commit --amend and then cherry pick the remaining unchanged
commits.  (I believe this is essentially what guilt would do for you.)

The idea here is that since you aren't expecting someone else to
directly pull from your git repo (i.e. if you aren't a main maintainer)
then you are free to "rebase" and re-write history to fix your mistakes
without having to continually add on new commits and thus get
commit log pollution.

I don't claim to be a git expert, but I hope that helps some.  You
might find this an interesting read too.

http://kerneltrap.org/Linux/Git_Management

Paul.

>
>> 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)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFIdVYcXaXGVTD0i/8RAsV/AJ0csYVQbIRTa7iqAf3BGtS0xQORlACeL25v
> AeUH4n0YtPWYvyig6S/16pA=
> =JIP7
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>