On Mon, Jun 16, 2008 at 12:24 AM, Michael FIG <[EMAIL PROTECTED]> wrote: >> Don't you have this problem in both cases? If the changes are >> independent, it shouldn't matter whether they are in the form of a >> patch file or in git (in which case they can be extracted as >> patches). > > The problem that I have is of interleaved changes. I work for a > little on patch A, then patch B, then patch A again, but A and B > should be kept separate so that they can be easily reviewed. A and B > may or may have dependencies on one another.
Have a separate branches for A and B? (and then delete them when they are merged and no longer necessary). I believe git also has an option of "squashing" patches i.e. you can make a change A1, A2, A3 and when they're fully ready, they can be "squashed" into just one change A. Or they can be merged upstream as A1, A2, An - depending on whether one wants to preserve the history of smaller changes or just get the final, neat package. If there are dependencies between A and B, you can e.g. have branch A and then branch AB based on that that has A + B. You couldn't have A and B truly independent - but if they're dependent on each other, then it's the case no matter how you manage the changes. -- kjk _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
