3 ms·

In Chromium (well, actually depot_tools[1], the closest thing Chromium has to a developer SDK) we provide `git freeze`[2] and `git thaw`[3]. These behave simila

In Chromium (well, actually depot_tools[1], the closest thing Chromium has to a developer SDK) we provide `git freeze`[2] and `git thaw`[3]. These behave similarly to 'stash', but instead of taking your content and putting it who-knows-where, they commit it on top of your current branch in a special FREEZE commit (or multiple commits, if you have both staged and unstaged changes) which they then know how to thaw out again. Our other tools (such as `git rebase-update`[4]) also know how to deal with FREEZE commits, and can automatically thaw them for you when you go back to working on that branch. [1] https://chromium.googlesource.com/chromium/tools/depot_tools.git https://chromium.googlesource.com/chromium/tools/depot_tools... [2] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-freeze.html https://commondatastorage.googleapis.com/chrome-infra-docs/f... [3] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-thaw.html https://commondatastorage.googleapis.com/chrome-infra-docs/f... [4] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-rebase-update.html https://commondatastorage.googleapis.com/chrome-infra-docs/f...

dahart 10y ago
Brilliant! I wonder why git stash wasn't implemented similarly in the first place.
- derefr 10y ago
  My hypothesis: git was implemented assuming that—at least for large projects—you would have a local on-disk bare clone of the repo, and then multiple workdir checkouts of that bare clone sitting on different branches. The setup with a single clone containing a workdir with a .git dir inside it is a hack that's nice for "on-the-go" use-cases, but wasn't intended for serious developers contributing many changes to the same codebase. git-stash, then, is only for the use-cases that are not better solved by just leaving your WIP workdir as it is and checking out another, concurrent workdir for your new feature. Such as, for example, taking code you were accidentally writing on one branch, and "shifting it over" onto some other branch; or "moving your changes out of the way" to run some tool that is broken by them, then putting them back in place, because you really still are working on them.
  - Asooka 10y ago
    Er... but then you have (N+1) checkouts of the repository where N is the number of workdirs, no? How does this even work with submodules? Will I have a copy of the submodules tree in each workdir? Our submodules tree is like 4Gb at this point, I can't very well have 5 of them. Disks are large, but not yet infinite.
    - derefr 10y ago
      Directory hard-links?
  - Too 10y ago
    This is how you have to deal with branching in almost every scm. Changing branch might require you to rebuild something slow and then it's good to have multiple working directories. If you have monorepos you might also want to test component a on branch x vs component b on branch y etc. If you are only working serially then switching branch in one working dir is obviously easier and to be preferred but some times you really need multiple checkouts of the same repo.

dahart 10y ago

Brilliant! I wonder why git stash wasn't implemented similarly in the first place.

derefr 10y ago
My hypothesis: git was implemented assuming that—at least for large projects—you would have a local on-disk bare clone of the repo, and then multiple workdir checkouts of that bare clone sitting on different branches. The setup with a single clone containing a workdir with a .git dir inside it is a hack that's nice for "on-the-go" use-cases, but wasn't intended for serious developers contributing many changes to the same codebase. git-stash, then, is only for the use-cases that are not better solved by just leaving your WIP workdir as it is and checking out another, concurrent workdir for your new feature. Such as, for example, taking code you were accidentally writing on one branch, and "shifting it over" onto some other branch; or "moving your changes out of the way" to run some tool that is broken by them, then putting them back in place, because you really still are working on them.
- Asooka 10y ago
  Er... but then you have (N+1) checkouts of the repository where N is the number of workdirs, no? How does this even work with submodules? Will I have a copy of the submodules tree in each workdir? Our submodules tree is like 4Gb at this point, I can't very well have 5 of them. Disks are large, but not yet infinite.
  - derefr 10y ago
    Directory hard-links?
- Too 10y ago
  This is how you have to deal with branching in almost every scm. Changing branch might require you to rebuild something slow and then it's good to have multiple working directories. If you have monorepos you might also want to test component a on branch x vs component b on branch y etc. If you are only working serially then switching branch in one working dir is obviously easier and to be preferred but some times you really need multiple checkouts of the same repo.