It looks like what you're really looking for is a local branch that you never push to the remote, and 'git diff master...' with 'git rebase'.<p>Create a local branch, apply the sledgehammer, and start reviewing changes. Use 'git diff master...' to review changes. (This is short for 'git diff master...HEAD' which in turn stands for 'compare current branch's HEAD with the commit on master off of which you've branched.) 'git add -p' and commit changes that you like.<p>Iterate until you're happy with the result. You will have ended up with a few commits on your local branch. Use 'git rebase -i master' to squash all commit in a single one. Finally, check out the master branch and merge your local branch in, preferably with --ff.
Why not just commit after the first step? You can then use the normal diff, and afterwards you just remove your temporary commit to make the final one.
git stash has other cool features and use cases (for example, when you want to pull from upstream and you have conflicting changes.) <a href="http://git-scm.com/book/ch6-3.html" rel="nofollow">http://git-scm.com/book/ch6-3.html</a> is a nice summary and the manpage also gives some sample workflows.
Of course the problem here is that the GP can't actually be sure that every link he wanted to fix in the final step was fixed; just that the ones that _were_ fixed were fixed right!
I used a similar technique for a less frivolous task. I had script dumping data in text format, and wanted to refactor it. I committed the result and could refactor brutally step by step, running the script at each step and reverting whenever the dumped data showed some diffs.
when i have an idempotent sledgehammer (i.e. i can apply it twice and get the same result) i usually just<p><pre><code> git add -p
</code></pre>
everything that is ok. git diff will only show you the differences against the index, so this works as well.
I find this alias really useful for accomplishing similar goals:<p>alias gqc="git commit -m 'quick commit'"<p>The command is usually preceded by "git add ." (or alias "ga."). Making a commit ends up being more reliable for me than stash. Also, the commit stays with the branch, making it easy to switch to master branch, make or check an important change, then go back to what I was working on in the develop branch. Additionally, it makes rebasing a work in progress easier. Just gqc && git pull --rebase.<p>When it comes time to push, I can just check the log for all the "quick commit" commits. If there's just one, then I make an amend commit. If there's more than one, I rebase interactively.<p>I suppose I could add a hook to make sure I never accidentally push a quick commit, but it hasn't been an issue yet (over the past year or so I've only made the mistake once).
Am i missing something, or is this nothing to do with Git? You could do this with any source control tool, or indeed with simple copies of the files. I've used exactly this approach without Git for years.
Nice tip, My sledgehammer is a git-sub script (<a href="http://minhajuddin.com/2011/12/13/script-to-do-a-global-search-and-replace-in-a-git-repository" rel="nofollow">http://minhajuddin.com/2011/12/13/script-to-do-a-global-sear...</a>) :)
This is very useful, as the article describes in detail.<p>I've found it useful to be able do diffs of diffs in my work, hence I'm planning to add the ability to do that to my toolset. Combined with live editing, I think it's going to be quite neat.
I tend to 'git commit' and then 'git commit --amend' until I'm happy, then push to others.<p>I find it easier anyway. But the stash approach is interesting, thanks for sharing!