You don’t need to create a branch for that though, you can just use stash.

boring_twenties · on July 12, 2020

And how is that better?

You have to remember a second command with its own peculiar syntax and semantics, but don't gain any functionality.

Stash is a superfluous misfeature.

nemetroid · on July 13, 2020

99% of the time when I use stash, it’s ”stash” or ”stash pop”, usually with ten seconds or so between the two. It’s very easy to remember.

Your alternative, on the other hand, uses an obscure flag to cherry-pick. What scenario would you use that flag for, except this particular one? How is remembering that flag any simpler?

Also, I don’t think your sequence of commands is correct. First, ”git branch” doesn’t switch to the newly created branch, so ”WIP” would be committed on your original branch. Second, the argument to cherry-pick should be a reference to the commit rather than the commit message. I believe a correct version would be:

  git switch -c my_stash
  git commit -am WIP
  git switch -
  git pull
  git cherry-pick -n my_stash
  git branch -D my_stash

boring_twenties · on July 13, 2020

You are right of course, that my commands weren't correct. Yours are, I'm pretty sure, but I think the following way is better anyway: What I actually do when I want to pull and reapply my local changes is simply `git commit -am WIP && git pull --rebase`. That's it.

I'm don't know now, why I suggested the convoluted temporary branch strategy. Probably because I assumed the GP didn't want the WIP commit, but I guess you could just get rid of it with `git reset HEAD^`. Personally I think WIP commits are way better than having uncommitted changes lying around, and what better time to create one than when you're at the terminal pulling and rebasing anyway? Anyhow.

Now when the rebase fails I can just abort it and be in a very easy to understand state: I have a tracking branch that has diverged from the remote, as `git status` would put it. I find this much better than "my tracking branch says 'up-to-date' but only because my actual changes are in a temporary branch somewhere, or heaven forbid, a stash."

> obscure flag to cherry-pick

Sorry, I'm having a little trouble with this one. What flags aren't obscure then? It's one of the elite 0.01% or so of git command-line options deemed worthy of a short option, so I think it stands to reason that it's rather frequently used.

Personally I used it a lot when I first started using git, before I got the hang of amending and squashing. Almost exactly the same way as I used to use stash, before I realized it was adding negative value. :)

Have you never been in the situation where you pop your stash, have a conflict, fix and commit it and then forget to drop the stash? (pop only drops it automatically if there were no conflicts.)

What if you want to save resolving the conflict for later? Do you just leave it in your stash to have to dig for later (amongst all the redundant leftovers from the preceding paragraph)? Or do you remember to run `git stash branch` at this point, and hopefully don't get interrupted before you can do so? Better, IMO, to just use branches in the first place, instead of this weird out-of-band thing where things are kind of like commits, but not really, and live in a separate place I have to remember to check.

Sorry about the length.

cben · on July 17, 2020

Behind the scenes, stashes _are_ branches! It's just UI on top of them, optimized for specific use case. You don't have to use it if you don't like it.

Now staging (aka index) is special behind the scenes, making the model more complex for Al users.