Re: [RFC PATCH v3 0/5] {checkout,reset,stash} --patch

[Thomas Rast <trast@student.ethz.ch>]

I wrote:
> 
> Similarly, "stash" has some problems: we want to encode the changes
> HEAD..index into one commit, and index..worktree into another.
> However, these patches may not apply on top of each other depending on
> what hunks were selected.  I see three options:
> 
> * Make more a priori restrictions, such as, --patch is strictly about
>   the worktree and simply refuses to stash anything if you have staged
>   changes; or, we only deal with the worktree and always stash the
>   index whole.  I think at least the first option would make it
>   significantly less useful though.

I'm still not happy with this interface.  How about the following to
make it less confusing:

1b) 'stash save -p' defaults to --keep-index (which can be disabled
    with a new option --no-keep-index).  In --keep-index mode, it only
    offers hunks from the worktree.

That way, it's almost analogous to 'git add -p', but for "adding to
the stash".

> * Hope that it works out, and catch failure later.  This is what it
>   currently does.
> 
> * Expand the stash format to four commits so that, e.g.,
>   stash^1..stash^2 is HEAD..index and stash^3..stash is
>   index..worktree.  (Currently stash^1 is HEAD, stash^2 is index and
>   stash is worktree.)  This would require more changes, and make these
>   stashes backward incompatible w.r.t. application, so I'm not sure it
>   is worth the trouble.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch