Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lesser known Git commands

hackernoon.com

Post reply on HN
Print view View original

71–80 of 142 posts

Re: Lesser known Git commands

#71

Post by eridius »

dahart wrote: post #16

I'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…

Why did you write your rearrange with the ! form? The whole point of the leading ! is to say "don't prefix my alias with `git`", but then you go ahead and prefix your alias with `git`. You should be able to write that as

  rearrange = "rebase -i $(git merge-base HEAD @{u})"

Re: Lesser known Git commands

#72

Post by eridius »

geofft wrote: post #50
Grue3 wrote: post #48

Earlier quoted context omitted.

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 s…

Or even just branch, commit, rebase onto the desired branch.

Re: Lesser known Git commands

#74

Post by dahart »

chocolatebunny wrote: post #67
dahart wrote: post #16

I'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…

I mostly only stash when I want to rebase -i because rebase -i seems to complain when I have uncommitted changes.

That's a good example of what I'd consider to be a mildly unsafe use of stash, since if anything goes wrong you can lose unsaved changes. It's easier to forget what you're doing if you have merge conflicts during your rebase, or end up stashing something else while you rebase.

The safer alternative workflow is:

  git commit -am "WIP"           # Just throw your uncommitted changes into a commit
  git rebase -i origin/master    # you might want to checkout my git rearrange command above
  git reset --soft HEAD^         # now un-stage your uncommitted changes and keep working
The advantage of this is getting your uncommitted changes into a commit that can be easily recovered if anything goes wrong. Even though you get rid of the commit, this process is all stored in the reflog, and you can undo any of it easily and without resorting to fsck.

Re: Lesser known Git commands

#75

Post by randallsquared »

pkamb wrote: post #61
dahart wrote: post #16

I'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…

> do people actually find stashing easier than branching? Branching wouldn't be enough, you'd need to commit your entire working copy to approximate a stash. I'd say it's generally a bug-prone mistake any time you commit your entire working copy (rather than staging lines/hunks on a one-commit-per-feature/bug basis). So branching and committing and pushing into a `backupForTomorrow` branch is fine, but you have to be…

Committing your entire working copy to a separate branch can work just like a safe stash:

    $ git branch
      master
    * cool-feature-1
    $ git checkout -b stash-2016.09.30T01.10
    $ git add -A; git commit -m "stashing WIP for later; maybe add some commentary to remind myself what I'm doing"
    $ git branch
      master
      cool-feature-1
    * stash-2016.09.30T01.10
    $ git checkout master
    $ git branch
    * master
      cool-feature-1
      stash-2016.09.30T01.10
    # do other things
    # later...
    $ git checkout cool-feature-1
    $ git merge --no-commit --no-ff stash-2016.09.30T01.10
    Automatic merge went well; stopped before committing as requested
    $ git reset
    $ git status
    On branch cool-feature-1
    Untracked files:
     ...
And now your old WIP is back, ready to keep working, and in the meantime you could have pushed up your "stash" to a remote and grabbed it back.

There might be something terribly wrong with this, but if there's not, then I don't understand why git stash doesn't do something similar to this by default.

Re: Lesser known Git commands

#76

Post by dahart »

eridius wrote: post #71
dahart wrote: post #16

I'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…

Why did you write your rearrange with the ! form? The whole point of the leading ! is to say "don't prefix my alias with `git`", but then you go ahead and prefix your alias with `git`. You should be able to write that as rearrange = "rebase -i $(git merge-base HEAD @{u})"

Ha! You're right, that's silly, thanks! I didn't even notice. I don't remember why, it's been a long time, but I think I had a tricky pipe command to figure out the upstream branch-point a long time ago before I learned about merge-base and @{u}.

Re: Lesser known Git commands

#78

Post by raverbashing »

dahart wrote: post #16

I'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…

Stashing is great

Because some things are only possible while there are no changes. (I changed this one-off file for testing or debugging something, need to pull latest changes, so I stash)

Stashing comes from a tool called quilt https://savannah.nongnu.org/projects/quilt

Re: Lesser known Git commands

#79

Post by dahart »

pkamb wrote: post #61
dahart wrote: post #16

I'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…

> do people actually find stashing easier than branching? Branching wouldn't be enough, you'd need to commit your entire working copy to approximate a stash. I'd say it's generally a bug-prone mistake any time you commit your entire working copy (rather than staging lines/hunks on a one-commit-per-feature/bug basis). So branching and committing and pushing into a `backupForTomorrow` branch is fine, but you have to be…

> Branching wouldn't be enough, you'd need to commit ...

Yes, you're right. I mentioned both committing I branching. I imagine commits only as the alternative to a single stash/pop, and commits & branching as the alternative to using multiple stashes.

> I'd say it's generally a bug-prone mistake any time you commit your entire working copy

The workflow I'd use instead of stash is to commit, do things, then reset --soft. Exact same effect as stash, except that it's less bug-prone, there's an easier & safer recovery mechanism in case of problems.

> If that temporary backup commit somehow stays around in the final feature branch, a stash would be much preferred.

You're comparing making a small mess to losing work. Your opinion is your own, I'm not here to argue, but in my book the downside of losing work while using a revision control system is much larger than the downside of accidentally preserving imperfect commit refactoring. You're preferring something superficially nice over the actual safety mechanisms that is git's sole purpose.

Re: Lesser known Git commands

#80

Post by JadeNB »

komali2 wrote: post #20
SEJeff wrote: post #6

My personal favorite two: jschroeder@omniscience:~$ git config alias.up pull --rebase jschroeder@omniscience:~$ git config alias.down push They can be used thusly: git up && git down

"Here let me UPload the local repo to our git server" git down "Great now let me DOWNload the changes to another branch" git up What?

I think the 'up' is as in 'update' rather than 'upload', but I agree that the use of 'down' makes that confusing.
Post reply on HN