Managing patches [was Re: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only]

[Mark McLoughlin]

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.