On Tue, Feb 17, 2009 at 08:28:04PM -0800, Christopher Lee wrote: -> On Feb 17, 2009, at 8:12 PM, C. Titus Brown wrote: -> -> > Yes, that's a good process - but Istvan is combining multiple patches -> > into a single patch, which (unless I misunderstand) is not what your -> > process does, right? -> -> Hmm. I'm assuming Istvan is tracking his own development in a git -> branch of his own, so presumably I could pull from his branch rather -> than applying the whole thing as a single patch ( = 1 commit, -> right?). I tend to think it's better to keep the history of commits -> from someone's work, as long as they have some logic to them. Later -> on we can search through the commits to find the one that's relevant -> to a specific question, and then see just those changes to the code. -> That's not possible if a large number of changes are all combined into -> one massive patch. If someone is doing a major rewrite / refactor of -> a module, I guess it makes sense to treat that as one patch, since -> there are no "intermediate steps" that make sense (i.e. as code that -> works). -> -> Obviously if the commit history is a mess there's no benefit to -> keeping it.
Right, and that's why I'm asking... in any case, I think the magic term is "rebase" but I would appreciate some pointers to how Istvan is using it ;) --titus -- C. Titus Brown, [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
