In order to squash everything into two commits I'd probably just do a 'git reset xxxxx' where xxxxx is the hash of the commit that your work is based on.  This will undo all your commits, but leave your changes in the working tree.  Now just git add the vtk files, commit, git add the test files, commit.<br>
<br>Linking to github's diff view probably works as well or better than attaching patches.  In your email I only found a link to your repo url and branch name though.   I fetched it to look at the diff.  I guess I'd find it most convenient to have diffs attached to the email (for small changes) and a link to the repo for those motivated to take a closer look.<br>
<br>Pat<br><br><br><div class="gmail_quote">On Thu, Sep 23, 2010 at 2:42 PM, David Doria <span dir="ltr"><<a href="mailto:daviddoria@gmail.com">daviddoria@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Wed, Sep 22, 2010 at 10:45 AM, pat marion <<a href="mailto:pat.marion@kitware.com">pat.marion@kitware.com</a>> wrote:<br>
> Are you talking about pushing your commits 26d55f7a59 thru bb4b221faf2?  My<br>
> opinion is that these commits are not ready to be pushed, but I have not had<br>
> a lot of time to do a proper review.  For ease of reviewing, I'd recommend<br>
> squashing all your commits into two- the first commit performs adds your new<br>
> feature, the second commit that adds the tests.  Then use git format-patch<br>
> and attach the commits to the mailing list.<br>
><br>
> Pat<br>
<br>
</div>Yes, those are the commits. I did some reading about squashing etc. I<br>
see how to combine commits, but I don't know how to separate commits.<br>
That is, in most of the commits I worked on the implementation as well<br>
as the test. How would I break these apart?<br>
<br>
Also, why would you want to use git format-patch? Isn't github's<br>
interface exactly for this type of review? And the idea of publishing<br>
a branch instead of just the files is that a review can clone the<br>
branch and try everything out right away, right? And githubs red/green<br>
highlighted lines as well as displaying individual files also solves<br>
the problem of having the test and the implementation in the same<br>
commit, right?<br>
<br>
It just look to me like this process of preparing the code for a<br>
review will take just as much time as writing these tiny patches. Is<br>
this the "agreed upon" procedure? I know ITK has been using Gerrit and<br>
I know we're not there yet, but would most people know what to do with<br>
a git format-patch email?<br>
<font color="#888888"><br>
David<br>
</font></blockquote></div><br>