tags:

views:

42

answers:

1

So I've been bashing away at my favorite open source project for quite some time, and It's time for submitting issues with patches back. I have to regroup my commits more or less fully, and hopefully extract some pieces of code that can function as distinct patches to avoid code bombing. Currently I usually do something like this:

  1. rebase/squash everything to one commit since the old ones often don't make sense as patches
  2. undo that commit
  3. start adding stuff that I think fits to one commit, using add/add -i
  4. commit
  5. stash the rest
  6. test that commit
  7. re-apply the stash and start from 3 until all is accounted for

It works, but is there a better way ?

+2  A: 

If current (unsquashed) commits has no relation to the patches you want to get, just keep doing according to your scheme.

Personally I would create "for-upstream" branch and cherry-pick some commits there (and split or edit them if needed), but this needs similar resources like using your way.

Vi
Well some commits have good relationship to the future patches, but I invariably tend to accumulate related changes in later commits. And I also often pollute these commits with other changes.
krosenvold