Re: Stage, test, and commit only some changes, then repeat

[Sergey Organov <sorganov@gmail.com>]

Géry Ogam <gery.ogam@gmail.com> writes:

>> Le 31 janv. 2022 à 22:56, Sergey Organov <sorganov@gmail.com> a écrit :
>> 
>> Géry Ogam <gery.ogam@gmail.com> writes:
>> 
>>>> Le 31 janv. 2022 à 17:27, Sergey Organov <sorganov@gmail.com> a écrit :
>>>> 
>>>> Géry Ogam <gery.ogam@gmail.com> writes:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> I would like to stage, test, and commit only *some* changes of the
>>>>> working tree, and then repeat this process with the remaining changes.
>>>>> 
>>>>> My current solution (published at
>>>>> https://stackoverflow.com/a/70914962/2326961):
>>>>> 
>>>>> 1. Stage some changes:
>>>>>  ```
>>>>>  git add -p file
>>>>>  ```
>>>>> 2. Save away the remaining changes:
>>>>>  ```
>>>>>  git diff >patch
>>>>>  git stash push -k
>>>>>  ```
>>>>> 3. Test the staged changes.
>>>>> 4. Commit the staged changes:
>>>>>  ```
>>>>>  git commit
>>>>>  ```
>>>>> 5. Restore the remaining changes:
>>>>>  ```
>>>>>  git apply patch
>>>>>  ```
>>>>> 6. Go to step 1.
>>>>> 
>>>>> It is not ideal because a) it uses a patch file for saving the
>>>>> remaining changes; b) it uses the stash only for setting the working
>>>>> tree to the index state.
>>>>> 
>>>>> It would be ideal if I could save *only* the remaining changes in the
>>>>> stash instead of resorting to a patch file. How to do it?
>>>> 
>>>> It looks like you don't need patch file for this workflow. What's
>>>> wrong with:
>>>> 
>>>> git add...
>>>> git stash push --keep-index
>>>> ... check, git add fixes
>>>> git commit
>>>> git stash apply
>>>> 
>>>> ???
>>>> 
>>>> -- Sergey Organov
>>> 
>>> Hello Sergey,
>>> 
>>> `git stash` saves the transition from the HEAD state to the working
>>> tree state. It also sets the working tree to the *HEAD* state.
>>> 
>>> `git stash --keep-index` saves the transition from the HEAD state to
>>> the working tree state. It also sets the working tree to the *index*
>>> state.
>>> 
>>> `git stash pop` applies the last saved transition. So if the working
>>> tree was not in HEAD state (like after `git stash --keep-index`),
>>> there will be a conflict.
>> 
>> Did you actually try it and got conflict? I doubt there will be any if
>> you don't modify anything after "git stash --keep-index" during testing,
>> and if you do, than any method might bring conflicts.
>> 
>> In fact I just re-tested this to make sure, and got no conflicts.
>> 
>> -- Sergey Organov
>
> git init
> touch file
> git add file
> git commit
> echo one >>file
> git add file
> echo two >>file
> git stash push --keep-index
> git stash pop

Yep, if you have overlapping changes in work-tree and in the index, it
will happen indeed. I've rather tested handling of non-overlapping
changes in the same file that occurs much more often in practice, at
least for me.

BTW, for reference, Emacs's magit, that is essentially alternate Git
porcelain, has support for all 4 possible modes of stashing:

z Save                  Z Snapshot          
i Save index            I Snapshot index    
w Save worktree         W Snapshot worktree 
x Save keeping index    r Snapshot to wipref

For Git itself I've recently added --staged/-S, so the only mode that is
still missing is --worktree indeed.

-- Sergey Organov