Nice tip, My sledgehammer is a git-sub script (http://minhajuddin.com/2011/12/13/script-to-do-a-global-sear...) :)
The second-order-diff Git trick
11–20 of 44 posts
Re: The second-order-diff Git trick
#12git 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.
I actually saw this as a strike against git usability -- this should happen transparently imo, why should I have to git stash save; git pull --rebase; git stash pop for things to apply cleanly? Just do it automatically and fail if the stash application fails.
You could just create an alias for that.
Re: The second-order-diff Git trick
#13Of 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!
GP here. You're right that the final diff, in this case the second-order diff, cannot by itself prove that my final adjustment fixed all of the broken sentence-end links. But I wasn't merely going on that evidence.
The whole point of using a second-order diff was to allow me to reliably carry forth the knowledge gained by my exhaustive review of the prior diff. That exhaustive review told me that there were a dozen broken sentence-end links. And that's how many showed up as fixed in the final, second-order diff: one dozen.
So the prior and final evidence, together, allowed me to be confident that the adjustment worked as intended.
Re: The second-order-diff Git trick
#14Of 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!
GP here. You're right that the final diff, in this case the second-order diff, cannot by itself prove that my final adjustment fixed all of the broken sentence-end links. But I wasn't merely going on that evidence. The whole point of using a second-order diff was to allow me to reliably carry forth the knowledge gained by my exhaustive review of the prior diff. That exhaustive review told me that there were a dozen b…
Very true, and a good point. I thought it was a interesting little gotcha about the whole technique though: sometimes you will actually need to go ahead and look at whole diff to be 100% sure.
Re: The second-order-diff Git trick
#15Earlier quoted context omitted.
GP here. You're right that the final diff, in this case the second-order diff, cannot by itself prove that my final adjustment fixed all of the broken sentence-end links. But I wasn't merely going on that evidence. The whole point of using a second-order diff was to allow me to reliably carry forth the knowledge gained by my exhaustive review of the prior diff. That exhaustive review told me that there were a dozen b…
Very true, and a good point. I thought it was a interesting little gotcha about the whole technique though: sometimes you will actually need to go ahead and look at whole diff to be 100% sure.
Indeed. Whenever you drop the sledgehammer, you have the obligation to exhaustively review its effects at least once to be sure there wasn't collateral damage. The beauty of the second-order diff is that, once you do an exhaustive review, you need not do another one just to adjust the sledgehammer.
Re: The second-order-diff Git trick
#16This 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.
That was news to me as well. I've always done the following: $ diff -u
never again.. by the way, `git diff --no-index` also works like a generic diff utility on any two files.
(Wow, that --no-index behavior seems to be default outside repositories now. I learned something, just git diff works now.)
Re: The second-order-diff Git trick
#17I think 'git add -p .' would have worked better for the specific example he gave, though. (Step through and stage change by change)
Re: The second-order-diff Git trick
#18Why 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.
Re: The second-order-diff Git trick
#19when i have an idempotent sledgehammer (i.e. i can apply it twice and get the same result) i usually just
git add -p
Re: The second-order-diff Git trick
#20I think 'git add -p .' would have worked better for the specific example he gave, though. (Step through and stage change by change)
as i said in my other comment. that will only work for idempotent things: if you like to change, say, ' to ", the workflow in the article works, but git add -p won't.