git - git-checkout 是否会在发生 fatal error 时保留 'half-done' 工作树更改？

Question

 jordan zu$  git status
On branch origin/features
Your branch is up to date with 'remotes/origin/features'.
nothing to commit, working tree clean

 jordan zu$  git checkout master
error: unable to unlink old 'api_rest/vendor/....php': Permission denied
fatal: cannot create directory at 'api_rest/vendor/...php': Permission denied

 jordan zu$  git status
On branch origin/features
Your branch is up to date with 'remotes/origin/features'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
   ---- 100's of deleted/modified files ---

 jordan zu$  git branch
  master
* origin/features
  ^^^ still on origin/features; but index is now changed!

所以，我在“功能”分支上做了一个“git checkout master”，但失败了。失败后，我运行了“git status”，现在我的索引中充满了更改和未跟踪的文件。所以，这就是我认为发生的事情:git checkout 尽可能地修改工作树，但是一旦遇到错误，它就会退出，并且不会更新 HEAD。它没有将工作树恢复到运行之前的状态，而是直接退出。

我的想法是否正确？是这样吗？

子问题；部分问题是当我启动我的 docker 服务时，它们修改了一些工作树并留下了“root”拥有的目录和文件，这就是 git checkout 遇到问题的地方。有没有标准的方法来处理这种情况？我能以某种方式将 docker 用户映射到工作树的所有者吗？

感谢您的帮助。

Answer 1

git checkout got as far as it could with modifying the worktree, but once it hit an error, it quit, and didn't update HEAD. Instead of reverting the worktree to before it was ran, it just quits.

我想确实是这样。
git status 显示:

• 索引文件与当前 HEAD 提交之间存在差异的路径，
• 工作树和索引文件之间存在差异的路径，
• 以及 Git 未跟踪的工作树中的路径

如果 HEAD 仍然作为功能，而索引和工作树开始反射(reflect) master，您会看到所有这些差异。

顺便说一句，使用 git switch master 将是 modern equivalent of git checkout (当切换分支时，因此 switch 命令

part of the problem is that when I start my docker services, they modify some of the worktree and leave directories and files that are owned by 'root', and this is where git checkout runs into problems.

Can I map the docker user to the owner of the worktree somehow?

是的，你可以Isolate containers with a user namespace

The best way to prevent privilege-escalation attacks from within a container is to configure your container’s applications to run as unprivileged users.

For containers whose processes must run as the root user within the container, you can re-map this user to a less-privileged user on the Docker host.
The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.

一般原则:

About remapping and subordinate user and group IDs

The remapping itself is handled by two files: /etc/subuid and /etc/subgid.
Each file works the same, but one is concerned with the user ID range, and the other with the group ID range.

Consider the following entry in /etc/subuid:

testuser:231072:65536

This means that testuser is assigned a subordinate user ID range of 231072 and the next 65536 integers in sequence.

• UID 231072 is mapped within the namespace (within the container, in this case) as UID 0 (root).
• UID 231073 is mapped as UID 1, and so forth.

If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, which does not even map to a real user.
This means the process has no privileges on the host system at all.

在您的情况下，这意味着容器内的用户 root 可以将文件写入容器外作为您当前的用户帐户 uid/gid。

我通常问的是:

cat  /etc/docker/daemon.json
{
  "data-root": "/project/docker-root",
  "storage-driver": "overlay2",
  "userns-remap": "myUserApp1:myGroup"  =====
}

sysctl -w user.max_user_namespaces=15000
systemctl restart docker
systemctl status docker
cat /proc/sys/user/max_user_namespaces

(关于 user.max_user_namespaces，请参阅“Docker error process_linux.go:319: getting the final child's pid from pipe caused "EOF": unknown”和 moby/moby issue 40835)

与:

cat /etc/subuid
myUserApp1:44581:65536
cat /etc/subgid
myGroup:14220:65536

(假设当前用户帐户 myUserApp1:MyGroup 的 uuid/guid 为 44581:14220)

有时(例如 Docker JBoss/wildfly 图像，默认以 1000:1000 运行)，我必须请求 /etc/subuid 为 43581(而不是 44581)，因为这样，容器内的用户1000映射到容器外的44581(43581+1000)。

大缺点:这意味着您只能将一个 内部容器用户映射到一个 外部主机用户。
如果您有另一个使用 1000:1000 运行的容器，它将映射到相同的 myUserApp1，即使您可能有另一个服务帐户 myUserApp2 对于第二个容器持久数据。