<div dir="ltr">Hi Dscho,<div><br><div>> as promised, a little Perl script to help with fixup commits.<br></div><div><br></div><div>Thank you very much!</div><div><br></div><div style>FYI, I have committed the script, together with your comments, here:</div>

<div style><br></div><div style>    <a href="https://github.com/ctrueden/ctr-scripts/commit/35f37efe">https://github.com/ctrueden/ctr-scripts/commit/35f37efe</a><br></div><div style><br></div><div style>I also added the alias "fix = !fixup-rebase" to my .gitconfig. Works like a charm.</div>

<div style><br></div><div style>Cheers,</div><div style>Curtis</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 5:55 PM, Johannes Schindelin <span dir="ltr"><<a href="mailto:schindelin@wisc.edu" target="_blank">schindelin@wisc.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Curtis,<br>
<br>
as promised, a little Perl script to help with fixup commits.<br>
<br>
For everybody who wonders what I am talking about: my preferred workflow<br>
involves topic branches for projects involving more than one commit<br>
(single commits are not worth the hassle). For this, I start with<br>
<br>
        git checkout -b <name><br>
<br>
(Actually, very often I do have changes already, but that's okay, I can<br>
still make a new branch from the current state.)<br>
<br>
Then I make changes and commit and rewrite the topic branch frequently.<br>
<br>
For example, when I find that I made a mistake in the first commit, but I<br>
am already on the fourth commit in the topic branch, I commit a "fixup":<br>
<br>
        git commit --fixup HEAD^^^<br>
<br>
This tells Git to look at the third-last commit, take the first line,<br>
prepend it with "fixup! " and commit with that message. Such a<br>
specially-crafted commit message is interpreted by "git rebase -i<br>
--autosquash" to mean that it should reorder the commits so that the fixup<br>
commit can amend the original one.<br>
<br>
After a couple of commits, my topic branch would look a bit like this:<br>
<br>
        <hash>   <first-line><br>
        01234567 Fix typos in the README<br>
        cafebabe Format LICENSE<br>
        fedcba98 fixup! Fix typos in the README<br>
        223387ab Add another author<br>
<br>
When calling "git rebase -i --autosquash origin/master" -- assuming that I<br>
started my topic branch directly on origin/master -- Git would present me<br>
with an "edit script" like this:<br>
<br>
        pick 01234567 Fix typos in the README<br>
        fixup fedcba98 fixup! Fix typos in the README<br>
        pick cafebabe Format LICENSE<br>
        pick 223387ab Add another author<br>
<br>
The "fixup" means that the second commit will be applied, but these<br>
changes will be merged into the first commit.<br>
<br>
I could ask rebase for further changes, such as "reword"ing the rather<br>
unhelpful commit message of the now-last commit, but usually I keep things<br>
as they are with the autosquash'ed reordering.<br>
<br>
If you grow tired -- as did I -- of having to type "--autosquash" all the<br>
time: do what I did:<br>
<br>
        git config --global rebase.autosquash true<br>
<br>
That will make that rather helpful behavior the default.<br>
<br>
I try to document such things on the Fiji Wiki, of course:<br>
<a href="http://fiji.sc/Topic_branches" target="_blank">http://fiji.sc/Topic_branches</a><br>
<br>
Back to you Curtis: I did write that Perl script which finds out what<br>
commit you should rebase onto, but the truth is that<br>
<br>
        git rebase -i --autosquash $(git merge-base HEAD origin/master)<br>
<br>
would work just as well: interactive rebase is clever enough not to<br>
rewrite the first commits when there is no need to. In other words, it<br>
does not re-commit any commit when it would have the same parent.<br>
<br>
Ciao,<br>
Dscho<br>
</blockquote></div><br></div></div></div>