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.
That summarizes well how I do original development, too. Whether its a
branch of an existing repo, or a newly cloned repo, when working on new
code I will do a first pass, committing as I go to provide useful
checkpoints.
Once I reach a satisfactory state, I'll refactor the patches so that
they make sense for upstream submission.
Jeff
-
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
