On Wed, Aug 19, 2009 at 11:40:20AM +0200, Thomas Rast wrote:
> > I took a look at this today.
> Heh, now *my* procrastination is paying off :-)
Curses, I fell into your trap!
> I think that is the correct way to go about it from the user's POV.
> He would be confused if the patch applied to WT/index were different
> (because of a later merge) from the hunks he chose in the -p loop.
>
> However, there's the issue of merge conflicts. Some options I can
> think of are
>
> 1) refuse to work in the face of merge problems
I had assumed we would do (1), just to keep things simple. Otherwise
stash becomes a multi-invocation command (with a --continue feature),
which really has a lot of complexity and corner cases.
> 2) stash requires a clean WT, so we can move the user's index out of
> the way and use temporary index + WT to let the user resolve the
> conflicts
>
> 3) require both clean WT and index so we can simply use the repo to
> resolve
Actually, we currently require that the index and WT match, so
these two are equivalent. But I think they add a lot of complexity
because of the continuation.
> (The first one isn't quite as restrictive as it sounds; the user can
> always apply on top of a clean HEAD, fix conflicts and re-stash, thus
> doing a "stash rebase".)
Which is really a nice way of dodging the continuation bullet, since the
results after each step are well-defined in terms of currently existing
steps. That is, the user could "git stash apply" and never invoke "git
stash apply -p" if munging the conflicts led to the result they wanted.
OTOH, it may have been simpler for them to edit the stash beforehand to
avoid the conflicts.
Hmm. Maybe we are really talking about two different commands:
1. edit the hunks that will be applied to the working tree from the
stash (apply -p)
2. edit the _stash itself_, taking or leaving hunks to create a new
stash
What was in my patch was basically (2), but then always followed by
applying. By splitting them, you can use whichever makes sense for your
situation.
> > 1. For --index mode, it actually invokes add--interactive twice. It
> > would be nice to do both passes at the same time, but I don't think
> > it is possible with the current add--interactive infrastructure.
>
> Note that the 'git stash -p' in next always stashes the index whole,
> so the "easy" way might simply be to also unstash the index whole (if
> requested).
That might be worthwhile. It is less flexible, but I really wonder if
people actually keep stash randomly different changes in their index and
worktree and want to pick through them individually. I guess we could
also add a --patch-index for people who really wanted it.
-Peff
--
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