On 01/07/2014 10:52 AM, IOhannes m zmölnig wrote:
these things are easy enough to fix (do a *mixed* reset of your branch to the split-point and factor new commits from there). i could do that myself, but then the authorship of the patches would be lost and i'd rather leave that intact, so you get proper credits for your work.
i'll try to explain what i mean by this. personally i'm using gitk (a graphical version browser) to navigate the history and move my repository to a given revision, whenever it becomes non-trivial. in this case, i would fire up gitk, place my cursor on revision 28f58f488 (which is the one were you branched off), right click and select "reset branch to here". i'l lbe given the choice of whether i want to do a "hard reset" (resetting working tree and index), a "soft reset" (leaving working tree and index untouched) and a "mixed reset" (leave working tree untouched, reset index). i'd chose "mixed reset", which results in having all the modified files in the working tree, but none of them committed yet.
git reset --mixed 28f58f488
then i'd start a new branch
git checkout -b "osx_fixes"
and start creating new "clean" commits, where each commit does only a "single thing" (though probably changing multiple files at once; e.g. i'd remove all the default arguments in a single commit).
if a single file has multiple changes in it (that should belong to multiple commits), then i'd use a graphical commit tool like: git gui (which allows me to commit single lines). you could also do this from the cmdline using git add -p thisfile.x
once this is done, i'd create *new* pull request on github and close the old one.
fgmadsr IOhannes