On Thu, Nov 29, 2018 at 12:22 AM Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
> Some behaviors I'd expect to see from these commands (I haven't yet
> checked to see if you've already done this):
>
> git checkout-files <tree-ish>
> should reset all the files in the repository regardless of the current
> directory - it should produce the same effect as "git reset --hard
> <tree-ish> && git reset HEAD@{1}". It should also delete
> locally-created files that aren't present in <tree-ish>, such that the
> final working tree is exactly identical to what was committed in that
> tree-ish.
>
> git checkout-files foo -- myfile.txt
> should delete myfile.txt if it is present locally but not present in foo.
>
> git checkout-files foo -- .
> should recursively checkout all files in the current folder and all
> subfolders, and delete any locally-created files if they're not
> present in foo.
I think all these are the same as the non-overlay mode Thomas
mentioned [1]. Once he implements that in git-checkout, we can make it
default in checkout-files.
Two things though. I plan to get rid of "--" in checkout-files. The
main use case (I think) is reset from index, so you can just write
git checkout-files somefiles
and if you want to get it from the tree(-ish) "foo", you do
git checkout-files --from=foo somefiles
This form is easier to read (and even guess before you read man pages)
and leaves no room for ambiguation.
The second thing is, I plan to forbid "git checkout-files" without
arguments. If you want to reset the entire worktree, do
git checkout-files :/
or just current dir
git checkout-files .
Which brings us back to your "git checkout-files <tree-ish>" use case
above. It should be treat the same way in my opinion, so we either do
git checkout-files --from=tree-ish :/
or
git checkout-files --from=tree-ish .
But "git checkout-files --from=tree-ish" alone is rejected.
[1] https://public-inbox.org/git/xmqqwoowo1fk.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/T/#mdb076d178ccf0ae3dba0fd63143f99278047da93
> Suggestion:
> If git checkout-files overwrites or deletes any locally-modified files
> from the workspace or index, those files could be auto-stashed. That
> would make it easy to restore them in the event of a mistyped command.
> Auto-stashing could be suppressed with a command-line argument (with
> alternate behaviors being fail-if-modified or always-overwrite).
Stashing I think is not the right tool for this. When you stash, you
plan to retrieve it back later but here you should rarely ever need to
unstash until the accident. For recovery from accidents like this, I
have another thing in queue to achieve the same (I'm calling it
"backup log" now). So we will have the same functionality, just with
different means.
> Idea:
> If git checkout-files modifies the submodules file, it could also
> auto-update the submodules. (For example, with something like "git
> submodule update --init --recursive --progress").
This one is tricky because we should deal with submodule autoupdate
consistently across all porcelain commands (or at least common ones),
not just checkout-files. I'd prefer to delay this until later. Once we
figure out what to do with other commands, then we can still change
defaults for checkout-files.
--
Duy
