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
--
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