Earlier quoted context omitted.
My #1 use of stash is as the quickest way to express "get rid of all this crap". I rarely intend to ever retrieve it.
'git reset'.
Doesn't do the same thing, without some more options. Stash is shorter.
Lesser known Git commands
41–50 of 142 posts
Re: Lesser known Git commands
#42I've seen more stash accidents than any other kind with git. Stashing is more dangerous than committing or branching, and to me it doesn't seem to provide any advantages... do people actually find stashing easier than branching? Is it just because when you branch you have to name it, and that causes friction? I stay away from stash. Right from the man page: "If you mistakenly drop or clear stashes, they cannot be rec…
While it's true that they can't be recovered through the "normal" safety mechanisms, they can certainly be recovered - that too up to 30 days in most cases. `git fsck` can help here [0]. Also when a stash is dropped, it's SHA is printed to the console. If the console buffer hasn't been cleared and you realise it soon enough, recovery can be quite straightforward. [0]: http://stackoverflow.com/questions/89332/how-to-r…
Yep true, and to be fair to the man page, that's the next sentence after the one I quoted.
But, fsck is a big hammer, and most people I've had to help recover their stashes completely glaze over when they see commands named fsck and reflog. Some people when faced with fsck opt to give up and recreate the lost changes, it's that intimidating.
And why not just avoid accidents? git's role in life is to be a safety net. Stash is hanging halfway over the edge of the net. Yes it's still possible to recover from accidents, but it's harder. That alone makes it more dangerous. It should be hard to screw up, not hard to recover.
Re: Lesser known Git commands
#43Earlier quoted context omitted.
If you're stashing your changes, that means they're just in the working copy and haven't been committed to the incorrect branch. In this case, simply create the branch and switch to it (git checkout -b branchname) and you're good. It's like it never happened ;) (remember that branches are just labels - until you commit it doesn't really matter).
Typically once I've noticed I haven't branched is after I've already added and committed.
Then just create the branch where you are, and afterwards go back and reset the original branch
Re: Lesser known Git commands
#44I'm no Git wizard, but switching from "merge" to "rebase" and from "add " to "add -p" cleaned up my repos quite a bit.
One reason I like git so much is that right there. The author is interested in reasoning about what branch certain changes came from, but I have to wonder why. Once changes are squashed and ff-merged, it's pretty clear where they came from.
Re: Lesser known Git commands
#45Earlier quoted context omitted.
I use stash when I forget to branch. So I might be working and then realize I never branched. So I stash my changes, create a new branch, and then pop my changes on the new branch.
My #1 use of stash is as the quickest way to express "get rid of all this crap". I rarely intend to ever retrieve it.
Now here's one I actually like. As an alternative to git reset, a git stash is safer, and gives you an easier way than reflog to recover if you dropped a commit you want back.
Re: Lesser known Git commands
#46The first commit of a repository can not be rebased like regular commits
That's not necessarily true. This can be done with:
git rebase -i --rootRe: Lesser known Git commands
#47This doesn't even look like I wrote it, but I thought I did and use it all the time: "What was that (private) branch I worked on a few weeks ago?"
Just put this shell script in /usr/local/bin or wherever as "git-branch-dates"
git branch-dates
#!/bin/bash
for k in `git branch|perl -pe s/^..//`;do echo -e `git show --pretty=format:"%Cgreen%ci %Cblue%cr%Creset" $k|head -n 1`\\t$k;done|sort -rRe: Lesser known Git commands
#48Earlier quoted context omitted.
I use stash when I forget to branch. So I might be working and then realize I never branched. So I stash my changes, create a new branch, and then pop my changes on the new branch.
Why stash? Why not just branch then commit?
Because you might be currently not at the place where you intended to branch off. For example trying to make a bugfix on an experimental feature branch, but then you realize you should branch it off master.
Re: Lesser known Git commands
#49> git it and empty root commit Why doesn't git init does this by default? It would be nice if every repo had an empty root commit (with no author, date,... so it has the same commit hash), then every two repos would have a common commit. Semantically it would mean that repos would be just specific branches of a hypotetical large repo.
That would prevent merging a second repository into the first in its entirity.
Re: Lesser known Git commands
#50Earlier quoted context omitted.
Why stash? Why not just branch then commit?
Because you might be currently not at the place where you intended to branch off. For example trying to make a bugfix on an experimental feature branch, but then you realize you should branch it off master.
So branch to a temporary branch, commit, checkout the branch you wanted to be on, cherry-pick the temporary branch to grab its head commit, then delete the temporary branch once you're sure you don't need it.
This isn't completely safe because deleting a branch also deletes its reflogs, but it does avoid use of the stash command at all, which I find good for my own safety (because it reduces cognitive load). And it scales obviously to making multiple commits onto the temporary branch, etc.