CONTRIBUTING.md: Adding unversioned Cask info

[treyharris]

The docs seemed to suggest that if versioned downloads were available,
to prefer them over unversioned ones. Since that's incorrect presently,
I attempted to correct that (see #6126 for more details).

[vitorgalvao]

I’ll ask you to not reference Vagrant directly, since I’ll change the example later today (as per suggestion in #4992). I’ll do it with Unity, which is a big download (that I’m currently updating). Not referring to any specific name but solely as the “example above” should also cover us in the future.

[vitorgalvao]

Would you mind squashing the commits in the end?

[treyharris]

@vitorgalvao I'm not familiar with how to squash already-pushed commits safely; I've always known that as a git no-no. Are you asking me to create a new branch and pull request? If not, a pointer to how to do it would be helpful.

[vitorgalvao]

I've always known that as a git no-no.

Generally, yes, but not in this case. If the commits were already merged in, it could lead to very bad results. However, the commits are, currently, only on your side, and presumably no one else is depending on your repo, meaning there won’t be any consequences of you doing it. It should be very safe; we have been requesting that of contributors for a long time, and never had a single issue.

[treyharris]

@vitorgalvao Ah, okay. Done (though it turns out my toolchain really didn't want me doing this "risky" thing, so I ended up using the raw git commands, which I almost never do!).

[vitorgalvao]

Looks good. Thank you.

[rolandwalker]

@treyharris thanks! I agree that we should document the current situation, even as we move to change it, because that will take some time.

So long as it is not a public branch, manipulating git history is fun, and makes the world a better place. I usually do so with git rebase -i, but there is also a one-liner for when you only want to squash the last two commits:

$ git checkout <your-feature-branch>
$ git reset --soft 'HEAD^' && git commit --amend -C HEAD

I have that second line as an alias in my .gitconfig. It's quick, though you have to be certain of what you are doing, because it won't stop you from squashing a private commit into a public one.

[treyharris]

@rolandwalker Thanks. I do that all the time, actually. My usual git client, Magit, offers several flavors of the latter command as one-keystroke choices:

• a for standard --amend
• e for extend: squash staged changes without editing the commit message (good for when you commit and then see the bug, which for me seems to happen in about 11 out of every 10 commits)
• r for reword: amend the commit message of the prior commit but don't amend its commit tree, even if something is staged (handy when you realize that the commit you're about to make makes the prior commit message unclear but you don't actually want to squash them)
• f for --fixup with the appropriate commit selected
• s for --squash with an arbitrary commit selected

Magit's folding mechanism (trees fold into files, which fold into diffs, which fold into hunks) also makes it just as easy to work on hunks as on files. I know how to do all these things with the raw, unporcelained git commands, but I probably wouldn't if it weren't for how easy Magit makes it. :-)

Showing off Magit has actually resulted in more than one vi-using coworker switching to Emacs' Evil vim-emulation just to be able to use Magit!

[treyharris]

Oh, but Magit does do sanity checks before operations, which is why I had trouble earlier; it did not want me squashing across a public-push boundary! I could probably have done it with the correct sequence of resets, pushes, pulls, rebases and rewrites, but it was easier to just break out git push --force. :-)