On Thu, May 19, 2011 at 12:25:38PM -0700, Junio C Hamano wrote:
> > Yeah. I personally find the concept of "5y" crazy; how do you know that
> > it is 5, and not 4 or 6, if you haven't yet seen them?
>
> That one is surprisingly easy to answer. Before I decide to use
> "incremental", I've seen the diff at least once but more often number of
> times. I know where things are when I start my incremental sessions, and
> "5" (just an example) is something I would use when I think I know there
> are 8 or 9, i.e. a number that will surely undershoot but will get me
> to the end sooner. An alternative would be something akin to "/<pattern>"
> but that adds, instead of skips.
OK, I figured it was something like that. I still think it's a little
crazy, but hey, if it works for you, who am I to tell you you're wrong.
> > I think a much better safety valve is to store the user's worktree state
> > that we are about to destroy. Then when they accidentally erase
> > something, whether they realize it immediately, or even 5 minutes later,
> > it is recoverable. And in the common case where everything goes well,
> > they needn't be bothered at all.
>
> Intereting.
>
> Where does the data go (perhaps to "stash create", not "stash save"), and
> where would we plug that in ("checkout -p" codepath only)?
Yeah, definitely not "stash save", as we consider the contents of the
stash list to be under user control. Even "stash create" is a bit of an
overkill, as for "checkout -p" we don't care about the index state (er,
wait, do we? I guess for "checkout -p $some_commit", we will be munging
both work-tree and index).
Using "stash create", we could easily print a "by the way, here is your
previous state" message. But I think I prefer a stash-like reflog of
states. Then for the common case (you _didn't_ screw up), there is no
extra cruft printed. Plus, you can go back and recover 5 minutes later,
when you have closed that terminal window and only then realize you
messed something up.
So maybe there should be another stash-like ref at refs/worktree (or
refs/WORKTREE?). Then it would expire naturally according to the usual
reflog expiration rules. We could also write to it during "git reset
--hard", which suffers the same safety issue.
You could also stash the index state during "git reset --mixed" and "git
reset -p". That is not as big an issue, though, as you are only ever
throwing away the work of adding things to the index (for that matter,
one could do the same thing on "git add"). You may lose a minute or two
of sorting changes, but you will never lose actual data, as you can with
"checkout" or "checkout -p".
Obviously this safety valve incurs a performance penalty. Probably it
should be optional via config for each callsite. In general, I wouldn't
expect it to be too expensive, though. The biggest part will be the "git
add" of new content; but in theory, this is stuff you might have
committed anyway, so it's probably not that big.
You could put a similar safety valve in "git clean", but it may be much
more expensive, since it is by definition files that you have _not_
marked to be tracked by git. So they may be large binary cruft.
-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