-2

I have a client with a bunch of messy things done to it that I want to stash off so that I have a pristine state but can get back to the mess at a later date. Things I want to stash and then recover may include:

  • things in the scope of .gitignore
  • new un-tracked files
  • new, tracked, but un-staged files (i.e. git add -N)
  • staged but not committed files.
  • etc.
  • etc.
  • etc.

In short, I want the same effect I'd get by using git clone to create a new client and doing the work there, but all in the same client.

EDIT: a specific case where things like git stash -a fail to accomplish what I want:

touch new_file
git add -N new_file
git stash -a

That results in an error and makes stash do nothing at all.

BCS
  • 75,627
  • 68
  • 187
  • 294
  • Is it feasible to copy the whole thing somewhere else? You can diff directories, if that helps. – wjandrea Apr 30 '20 at 20:55
  • `git stash` is not, in my opinion, a good tool for this. `git worktree add` is better as long as your Git is at least version 2.15. Making a new clone is the only 100%-perfect solution. Note that you can clone your clone, to make this go faster, and then use `git remote add` or `git remote set-url` to add a second remote or change the URL associated with the `origin` remote, and then `git fetch`. – torek Apr 30 '20 at 22:28
  • @Inigo I did read the docs, I just didn't talk about it. The list of things I mentioned is the list of thing that my investigation didn't find a clean solution for or (e.g. `git add -N`) any solution at all for. -- And, no it's not open ended, if git doesn't have a feature for specifically this, than a precise statement of that lack is what I'm looking for, I'll just clone another client rather than do any other kind of complex hacky workaround, – BCS May 01 '20 at 14:15
  • @torek, I've been using extra clients with alternate remotes already. The reasons that I didn't find them an ideal solution is: 1) they inherently add another things to manage (have I `git pull`'ed all my branches /everywhere/?), 2) they are more complex to manage (do you know *off hand* how to git-stash/pop across a remote?) 3) it forces the files to be at a different OS path, (which has some advantages, but can also can grow the context switch cost). -- `git worktree` I suspect will address some of those, but still adds complexity to what fundamentally needs to be a trivial action . – BCS May 01 '20 at 14:28
  • @Inigo `touch new_file ; git add -N new_file ; git stash push -a` -> *ERROR* – BCS May 01 '20 at 14:39

1 Answers1

1

It is possible to stash all tracked, untracked, and ignored files with git stash -a. That is the most complete option that git stash has available.

If you need something more complex or if you need additional features, like preserving permissions other than the executable bit, then you'll have to resort to just copying the file into another directory or using tar.

You can also use git branch to create another branch with the same history and use git worktree to check it out elsewhere, then copy the files over.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • One of the case I mentioned causes `git stash -a` to refuse to stash *anything*: `touch new_file ; git add -N new_file ; git stash -a` --> results in `error: Entry 'new_file' not uptodate. Cannot merge. Cannot save the current worktree state` – BCS May 01 '20 at 14:32
  • 1
    This is the only feature `git stash` has available that does anything close to what you want. If you used `--intent-to-add`, you told Git you were going to add it, so if you want to create a commit using that object (i.e., a stash commit), you actually have to follow through and add it. – bk2204 May 01 '20 at 20:04
  • So the fact that `git stash` is implemented in terms of a commit (which is 100% irrelevant as far as what I'm wanting to accomplish) is getting in my way? I can accept that, thought I was hoping for a better answer. – BCS May 02 '20 at 02:00
  • Yup, that's your problem. You're welcome to report the issue to the Git list if you like. – bk2204 May 02 '20 at 02:02
  • I don't think I'll get them to re-implemented `git stash` to not be in terms of commits. And if I had any chance of getting them to fundamentally change the operational model git, that's not what I'd start with. :0) – BCS May 02 '20 at 02:15