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.