On Thu, Dec 11, 2014 at 02:35:05PM -0500, Rafael Schloming wrote: > Can you provide a bit more detail? I'm not the most expert git user, so I'm > not sure exactly what you're asking for, much less how to do it.
In my case, my usual workflow is to do small changes and commit them locally. If a change goes with a commit a few back I'll do: $ git commit -a --fixup=[early commit's hash] Then, when I'm ready to commit I'll do: $ git rebase -i HEAD~[# of commits to process] --autosquash and git will put the commits in the right order so I can squash them down. Normally I just do "HEAD~25" rather than counting the commits since we usually had a nice, linear stream of commits in our old repo that was cloned from Subversion. But when I did it this time that the commits overlapped with this merge commit: ===[snip]=== commit e8029597b825e49ee5ab2b7c8bd5d042e57321bb Merge: db437cf a5cb27e Author: Rafael Schloming <r...@alum.mit.edu> Date: Fri Nov 28 08:43:03 2014 -0500 Merge branch 'javascript' ===[snip]=== This made git them try to rebase all of those changes, which numbered up to about 60 or so commits that are out of sequence. So I had to abort that rebase and count the commits instead and do it again. When merging branches, etc. we can avoid this if, before merging branch A into master we go to branch A and rebase it on master. That way we avoid merge commits like this. To fix it, you would need to: 1. git rebase -i HEAD~[# of commits to the merge above] 2. when it pops up the list of commits, just save (you're not going to re-order them at that point) 3. check for any merge commits, dual adds or deletes with "git status" 4. fix any issues that you see: fix merges, etc. 5. git add (or del) files as needed 6. git rebase --continue 7. go to 3 as needed until all is fixed -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
pgpGCgaCe_wBM.pgp
Description: PGP signature