On Fri, Feb 22, 2008 at 11:10:48PM -0500, Daniel Barkalow wrote:
> I find that the sequence of changes I make is pretty much unrelated to the
> sequence of changes that end up in the project's history, because my
> changes as I make them involve writing a lot of stubs (so I can build) and
> then filling them out. It's beneficial to have version control on this so
> that, if I screw up filling out a stub, I can get back to where I was.
>
> Having made a complete series, I then generate a new series of commits,
> each of which does one thing, without any bugs that I've resolved, such
> that the net result is the end of the messy history, except with any
> debugging or useless stuff skipped. It's this series that gets merged into
> the project history, and I discard the other history.
>
> The real trick is that the early patches in a lot of series often refactor
> existing code in ways that are generally good and necessary for your
> eventual outcome, but which you'd never think of until you've written more
> of the series. Generating a new commit sequence is necessary to end up
> with a history where it looks from the start like you know where you're
> going and have everything done that needs to be done when you get to the
> point of needing it. Furthermore, you want to be able to test these
> commits in isolation, without the distraction of the changes that actually
> prompted them, which means that you want to have your working tree is a
> state that you never actually had it in as you were developing the end
> result.
>
> This means that you'll usually want to rewrite commits for any series that
> isn't a single obvious patch, so it's not a big deal to commit any time
> you want to work on some different branch.
I do that so much that I have this alias:
reorder = !sh -c 'git rebase -i --onto $0 $0 $1'
... and actually pass it only one argument most of the time.
Mike
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
