As others have pointed out, you need 'git rebase' here. With an interactive rebase, you can cherry-pick what you want to do with each commit (keep, edit, squash etc). It can also help you apply your changes to a different branch (using the '-- onto' option). HTH, -mandeep On Fri, Dec 12, 2014 at 6:58 AM, Kumar Amit Mehta <gmate.amit@xxxxxxxxx> wrote: > Hi, > > I know that it's not a typical Linux kernel related query but I reckon > that people involved in Linux kernel testing/development might have > gotten into similar situation. So, please bear with me for this rather > generic framework related query. > > The scenario: > 1: Cloned linux-next at time T1 > $ git clone blahblah > > 2: Created a branch called development at T2 > $ git checkout -b development > > 3: Made change1 in development branch and did a commit at T3 > $ git commit -a > > 4: Made another commit in development branch and did another commit > at time T4, but during this development phase, *some* of the changes > that I made during my previous commit at time T3 were wrong, so had to > remove *some* of the changes > $ git commit -a > > 5: Now I create a branch called test, based off the master > $ git checkout -b test origin/master > > 5: So my test branch(and also the master branch) is two commits behind the > development branch. Now I wish to create a patch, based on my changes in > development branch and apply that patch to my test branch for further > testing. > > $ git format-patch origin/master -o patches > The above command creates two patches, which I need to apply in an > increasing order(0001 ---> 0002), otherwise, the patch won't work. > > So far so good, but what If, I am not particularly proud of the first > patch, but have to send that anyway, If my patches are to be applied. > Another approach would be to create another branch, say development-again, > based of origin/master and make the necessary changes and then just > create one patch file. But I was wondering that while doing development, > don't we make commits in our working branches, which we think is > correct, only to find it ridiculous later (say after few more commits > in future) ? And what to do in such scenario ? Or how to use git to > solve such scenario. > > Thanks, > Kumar > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
