This is the equivalent in Perforce of shelving your change, then redoing your work and diffing against your shelf.
The second-order-diff Git trick
21–30 of 44 posts
Re: The second-order-diff Git trick
#22A bit offtopic, but I think that you could have let the default `pandocCompiler` in Hakyll handle your old posts written in Textile format.
Re: The second-order-diff Git trick
#23git 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.
I'd call that "happening opaquely"
Re: The second-order-diff Git trick
#24Am 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.
Re: The second-order-diff Git trick
#25Why 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.
If you do that, you're just one accidental step away from uploading your bad changes to the origin. The stash way seems a bit safer and more natural to me.
Re: The second-order-diff Git trick
#26Earlier quoted context omitted.
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.
Because then git would be doing magic stuff you don't (necessarily) understand, and people who like that aren't git's target audience. Those are all separate pieces of functionality that shouldn't be stuck together by default.
The same argument could be applied against git pull, which is really the concatenation of fetch and merge (or rebase). I agree with the previous poster that there should be better defaults available to non-tweakers.
Re: The second-order-diff Git trick
#27Why 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.
If you do that, you're just one accidental step away from uploading your bad changes to the origin. The stash way seems a bit safer and more natural to me.
or, do it on a branch, then merge it into the production branch.
Re: The second-order-diff Git trick
#28Why 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.
> Why not just commit after the first step?
Good question. In answer, there are two reasons:
First, a stash is a commit, just one that doesn't get in your way and that you don't have to keep track of yourself because it's automatically pointed to by a known reference called "stash".
Second, by using "git stash" to create this commit instead of "git commit", you save yourself the (small) burden of moving the commit out of your way and resetting the working tree back to the clean slate you started from – and upon which you want to try a new, slightly adjusted sledgehammer from scratch. That's exactly what "git stash" does in one step:
"Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory." [1]
[1] http://www.kernel.org/pub/software/scm/git/docs/git-stash.ht...
Re: The second-order-diff Git trick
#29A bit offtopic, but I think that you could have let the default `pandocCompiler` in Hakyll handle your old posts written in Textile format.
I actually tried that at first, but the Typo-flavored Textile in my old posts wasn't reliably interpreted by Pandoc. (That's also why I had to clean up the posts after I used Pandoc to convert them into Markdown.) Since I had manual edits to do in any case, I figured I might as well do them after I converted my posts to Markdown since it seems to be the Pandoc's best-supported markup language.
Re: The second-order-diff Git trick
#30Am 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.
> Am i missing something, or is this nothing to do with Git?
Of course it's something to do with git, it describes a workflow in git. Yes, you can do this with other VC tools or even without, but this is how you do it with git and, I'd argue, it's better than other ways, certainly more convenient than without a version control tool at all, IMHO.