Managing patches [was Re: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only]
Mark McLoughlin
markmc at redhat.com
Tue Sep 4 11:53:50 UTC 2007
On Tue, 2007-09-04 at 06:19 -0500, Matt Domsch wrote:
> On Tue, Sep 04, 2007 at 09:17:59AM +0100, Mark McLoughlin wrote:
> > Hey,
> >
> > On Tue, 2007-08-21 at 16:18 -0400, Jeremy Katz wrote:
> > > * It's good to get into the habit of doing git commits for each
> > > separate
> > > change. Then you can get a patch per change. And that would avoid
> > > having the addidir/addsdir stuff being in the same changes
> >
> > FWIW, I don't think this approach useful, unless you're the type of
> > person that gets every change perfect first time :-)
> >
> > Basically, git records a history of how you developed a set of changes,
> > rather than allowing you to work individual changes separately.
>
> Branches are "free" in git. So, you can make a branch for what you
> want to work on, do it there with lots of commits, then when you're
> really happy with the change and want to apply it as one or more
> commits to your master branch, you can create a new branch from
> master; git diff master..yourdevbranch; apply the patches and commit as
> you like in your new branch; git push master. So you get the best of both worlds.
Granted, but if you're working on a few interrelated patches, this gets
seriously cumbersome. Yes, you could use branches of branches but ...
Point is that git doesn't do a good job of this right now - although
stgit is promising - so I think git would ultimately just discourage
people from the concept of splitting their patches into nice
easy-to-review chunks.
It may not be terribly sophisticated, but at least quilt has the right
model and is simple to use and understand. A stack of patches, each
independently hackable.
Cheers,
Mark.
More information about the Fedora-livecd-list
mailing list