Re: [RFC PATCH v3 0/5] {checkout,reset,stash} --patch
- From
Thomas Rast <trast@student.ethz.ch>
- Date
- Jul 27, 2009, 10:10 UTC
- Message-ID
- <200907271210.40001.trast@student.ethz.ch>
- In-Reply-To
- <cover.1248557241.git.trast@student.ethz.ch>
I wrote:
Show 11 quoted lines
> > 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".
Show 9 quoted lines
> * 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