Re: git stash: add --index-only, or --keep-index should not stash index?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 14, 2011 at 11:21 PM, Neal Kreitzinger
<nkreitzinger@xxxxxxxxx> wrote:
> On 3/11/2011 12:47 PM, Piotr Krukowiecki wrote:
>>
>> Hi,
>>
>> I wanted to do something like "Testing partial commits" described in
>> git-stash documentation (see end of mail for reference). I think this
>> is a common scenario: you start working on some feature, then discover
>> a bug, start fixing it, but realize it needs more work. So now you have
>> two features that needs more work (both are not ready for committing).
>>
>> The documentation says to use --keep-index in this case.
>>
>> The problem is that --keep-index leaves changes in index intact, but at
>> the same time it saves them in stash. So if I edit those changes I'm
>> likely
>> to get conflicts when applying the stash.
>>
>> For example:
>>
>> $ git init&&  echo a>  a&&  git add .&&  git commit -m a
>> $ echo x>  a&&  git add a&&  git stash save --keep-index
>> $ echo y>  a&&  git add a&&  git commit -m y
>> $ git stash pop
>> Auto-merging a
>> CONFLICT (content): Merge conflict in a
>>
>> Maybe --keep-index should not stash staged changes? This would fix this
>> problem. And I can't  think of a situation when would want to stash
>> changes
>> and at the same time keep them.
>>
>> If --keep-index works correctly maybe a new option, for example
>> --index-only
>> (or --cached-only?) could be introduced?
>>
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Testing partial commits::
>>
>> You can use `git stash save --keep-index` when you want to make two or
>> more commits out of the changes in the work tree, and you want to test
>> each change before committing:
>> +
>> ----------------------------------------------------------------
>> # ... hack hack hack ...
>> $ git add --patch foo            # add just first part to the index
>> $ git stash save --keep-index    # save all other changes to the stash
>> $ edit/build/test first part
>> $ git commit -m 'First part'     # commit fully tested change
>> $ git stash pop                  # prepare to work on all other changes
>> # ... repeat above five steps until one commit remains ...
>> $ edit/build/test remaining parts
>> $ git commit foo -m 'Remaining parts'
>> ----------------------------------------------------------------
>>
>>
> behind-the-scenes, git stash saves your working tree as a commit and your
> index as another commit.  "git-stash apply" and "git-stash pop" only apply
> your stashed-index if you do "git-stash-apply --index".  The default is to
> only apply your stashed-work-tree.  You can create new branches from your
> stashes with "git-stash branch".  You may find that much better to deal with
> for managing your work.  Stashes aren't really intended to be the primary
> way to manage your work, but instead are a supplement.  Branches are a
> better main tool for managing work.  You can create a branch from your stash
> and when the branch is ready you can merge it into your other branch.

Thanks for explanation, I understand there is not much pressure on improving it.

But it still does not explain how leaving code in index (with
--keep-index) while
still stashing it might be helpful?

I would understand the use of --index-only (I gave an example of use case),
or even --workdir-only, but not --keep-index. If I'm missing something please
correct me.


-- 
Piotr Krukowiecki
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]