from Hacker News

The second-order-diff Git trick

by malloc47 on 2/19/13, 4:54 AM with 41 comments

• by stasm on 2/19/13, 2:48 PM

  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'.

  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.

  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.

• by DoubleCluster on 2/19/13, 8:56 AM

  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.

• by pseut on 2/19/13, 8:53 AM

  I think 'git add -p .' would have worked better for the specific example he gave, though. (Step through and stage change by change)

• by niggler on 2/19/13, 5:21 AM

  git stash has other cool features and use cases (for example, when you want to pull from upstream and you have conflicting changes.) http://git-scm.com/book/ch6-3.html is a nice summary and the manpage also gives some sample workflows.

• by tmeasday on 2/19/13, 7:13 AM

  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!

• by gbog on 2/19/13, 3:05 PM

  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.

• by ibotty on 2/19/13, 9:06 AM

  when i have an idempotent sledgehammer (i.e. i can apply it twice and get the same result) i usually just

     git add -p 
  

  everything that is ok. git diff will only show you the differences against the index, so this works as well.

• by habosa on 2/19/13, 6:17 AM

  This is a great tip, thanks! I never thought of using git diff to test things out, and I definitely didn't know you could diff against a stash.

• by zacharypinter on 2/19/13, 3:56 PM

  I find this alias really useful for accomplishing similar goals:

  alias gqc="git commit -m 'quick commit'"

  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.

  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.

  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).

• by twic on 2/19/13, 10:47 AM

  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.

• by emillon on 2/19/13, 9:52 AM

  A bit offtopic, but I think that you could have let the default `pandocCompiler` in Hakyll handle your old posts written in Textile format.

• by minhajuddin on 2/19/13, 7:43 AM

  Nice tip, My sledgehammer is a git-sub script (http://minhajuddin.com/2011/12/13/script-to-do-a-global-sear...) :)

• by shurcooL on 2/19/13, 6:53 AM

  This is very useful, as the article describes in detail.

  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.

• by wubbfindel on 2/19/13, 2:21 PM

  I tend to 'git commit' and then 'git commit --amend' until I'm happy, then push to others.

  I find it easier anyway. But the stash approach is interesting, thanks for sharing!

• by kapuzineralex on 2/19/13, 6:08 AM

  Nice one, indeed!

• by cecilpl on 2/19/13, 9:22 AM

  This is the equivalent in Perforce of shelving your change, then redoing your work and diffing against your shelf.