# wishlist: "--cached|--staged" to "git commit file(s)" 3 messages from 2018-08-13 to 2018-08-14. Participants: Yaroslav Halchenko, Junio C Hamano. Thread: https://gitlist.dev/t/49117 ## Yaroslav Halchenko, 2018-08-13 16:22 Subject: wishlist: "--cached|--staged" to "git commit file(s)" Message-ID: <20180813162236.GO732@hopa.kiewit.dartmouth.edu> URL: https://gitlist.dev/e/20180813162236.GO732%40hopa.kiewit.dartmouth.edu ``` Dear Git developers, Following up on my quick question/discussion on IRC a few days back: Please consider adding --cached or --staged option for git commit file(s) command. ATM there is no non-interactive (via --patch/--interactive I think it is possible) way to commit selected subset of staged files not from the worktree (as it is done with "git commit file(s)") but from the index. Original usecase (I would be happy to elaborate): committing specified by user files in "direct" mode of git-annex, where it (via git annex add) first converts files to the symlinks within index (they remain original files within worktree), so we cannot use "git commit file(s)" since then they would get committed disregarding their state in index. But thinking about it I realized that it was quite a common use case to me, that I typically stage all modified files whenever I reach "it is no longer broken" stage, and then decide to commit that staged state in a number of separate commits, and only then commit worktree state. Current workaround as suggested on IRC is to - cp .git/index .git/index2 - GIT_INDEX_FILE=.git/index2 git reset files_not_to_be_committed - GIT_INDEX_FILE=.git/index2 git commit - rm .git/index2 or may be there is another (better) way? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ``` ## Junio C Hamano, 2018-08-13 21:33 Subject: Re: wishlist: "--cached|--staged" to "git commit file(s)" Message-ID: URL: https://gitlist.dev/e/xmqqva8e2bpf.fsf%40gitster-ct.c.googlers.com In-Reply-To: <20180813162236.GO732@hopa.kiewit.dartmouth.edu> ``` Yaroslav Halchenko writes: > command. ATM there is no non-interactive (via --patch/--interactive I > think it is possible) way to commit selected subset of staged files not > from the worktree (as it is done with "git commit file(s)") but from the > index. Hmph, so edit A B C git add A B edit A B C git commit --cached B would create a commit that is different from the original HEAD by the edit to file B you did in the first step, but not the edit to A or C, or edit to B after you did "git add"? That sounds like a useful feature. If you do not need that "exclude the later edit since the last 'git add'", you can do "git commit B", but if you added crufts to B in the working tree since you added a good copy of B to the index, that would not do what you want to do. Sounds like a good starter project for somebody who wants to try to get their hands dirty. I think it is just the matter of updating builtin/commit.c::prepare_index() where COMMIT_PARTIAL is handled, skipping "(2) update the index with the given paths" when "--cached" option is given, but doing everything else in that codepath. ``` ## Yaroslav Halchenko, 2018-08-14 00:37 Subject: Re: wishlist: "--cached|--staged" to "git commit file(s)" Message-ID: <20180814003712.GK580@hopa.kiewit.dartmouth.edu> URL: https://gitlist.dev/e/20180814003712.GK580%40hopa.kiewit.dartmouth.edu In-Reply-To: ``` On Mon, 13 Aug 2018, Junio C Hamano wrote: > > command. ATM there is no non-interactive (via --patch/--interactive I > > think it is possible) way to commit selected subset of staged files not > > from the worktree (as it is done with "git commit file(s)") but from the > > index. > Hmph, so > edit A B C > git add A B > edit A B C > git commit --cached B > would create a commit that is different from the original HEAD by > the edit to file B you did in the first step, but not the edit to A > or C, or edit to B after you did "git add"? yes > That sounds like a useful feature. If you do not need that "exclude > the later edit since the last 'git add'", you can do "git commit B", > but if you added crufts to B in the working tree since you added a > good copy of B to the index, that would not do what you want to do. exactly > Sounds like a good starter project for somebody who wants to try to > get their hands dirty... asking "around" ;-) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ```