Re: [PATCH] contrib/hooks: add post-update hook for updating working copy

Sam Vilain [off-list ref] writes:

Basically I'm trying to figure out "does the current index have any
uncommitted changes".  If it matches the tree from the previous (handful
of) ref(s), then the answer is "no".  If we can't find it anywhere then
it's probably got staged changes, and short of trying to move the
changes forward, we should stop.

The fact that the index does not match the HEAD means that the
user (possibly not the one who is pushing) is in the middle of
doing something.  A tree that happens to match that state exists
in the recent reflog history would only mean that the same state
exists _somewhere_; it does not mean it is easy for the end user
to go back to it at all.

quoted

But more importantly, why is it justified to throw away such
files to begin with?

Because we've already previously decided that they are safely stowed in
a previous (via time/reflog) revision of the current branch.

The user may have spent hours to come up to that state while
doing something we do not have any way of knowing what, and this
"heuristic" is allowing to lose that.  As you say, we do not
lose the tree from the repository, but we lose track of which
state the user was interested in.  I find that unjustified.

Perhaps it would make sense to do this check in the "update" hook as
well, thereby chmod +x refuses to allow a push that touches the
currently checked out branch.

Having the check in update to prevent it makes sense,
independently.

quoted

The longer I look at this patch, the more inclined I become to
say that the only part that is worth saving is the next hunk.

Actually, I think "the first sentence of the output in the next
hunk" was what I meant.  That is, "we are not updating it
because it is dirty and you cannot get back to the original
state if this was a mistake".  And not updating the index nor
the working tree.

How about doing something simpler, more predicatable and safer,
like this...

 * If HEAD/index/working tree match, then obviously we can do an
   equivalent of "reset --hard".  There is little chance that
   this is a wrong thing to do, and even when the user did not
   want that happen, the user can easily recover with for
   example "git checkout @{1} .".  So I am not opposed to
   updating the index/working tree in this case at all.

 * Otherwise, especially when HEAD and index do not match,
   touching index nor working tree is absolutely a no-no,
   without giving the user to sort the mess out.  So either in
   "update" hook you prevent it from happening.

Later, when we have git-stash, we can do a bit better in a dirty
working tree.  We could make a stash of the state _before_
updating the tip of the current branch, and let the push update
the tip, and do an equivalent of "reset --hard".  Unstashing the
state on top of the updated tip could fail, but at that point,
the user has the choice of making a new branch (or use detached
HEAD) at @{1} (that is, the HEAD before the push updated it) and
then unstash the state on top of it to recreate the state before
the push made a mess.