![]() | ||||||||||
Messages in this thread |
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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2008-02-23 06:07 [from the cache] ©2003-2008 | ||||||||||