summaryrefslogtreecommitdiff
path: root/builtin/add.c
diff options
context:
space:
mode:
authorLibravatar Nguyễn Thái Ngọc Duy <pclouds@gmail.com>2019-04-25 16:45:50 +0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-05-07 13:04:47 +0900
commit183fb44fd234499ed76d72d745ccb480b25f6d15 (patch)
treeba2200871fff3db799ae4a2f136fb201be81a314 /builtin/add.c
parentcheckout: factor out worktree checkout code (diff)
downloadtgif-183fb44fd234499ed76d72d745ccb480b25f6d15.tar.xz
restore: add --worktree and --staged
'git checkout <tree-ish> <pathspec>' updates both index and worktree. But updating the index when you want to restore worktree files is non-intuitive. The index contains the data ready for the next commit, and there's no indication that the user will want to commit the restored versions. 'git restore' therefore by default only touches worktree. The user has the option to update either the index with git restore --staged --source=<tree> <path> (1) or update both with git restore --staged --worktree --source=<tree> <path> (2) PS. Orignally I wanted to make worktree update default and form (1) would add index update while also updating the worktree, and the user would need to do "--staged --no-worktree" to update index only. But it looks really confusing that "--staged" option alone updates both. So now form (2) is used for both, which reads much more obvious. PPS. Yes form (1) overlaps with "git reset <rev> <path>". I don't know if we can ever turn "git reset" back to "_always_ reset HEAD and optionally do something else". Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/add.c')
0 files changed, 0 insertions, 0 deletions