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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 2, 2007, 01:10 UTC
Message-ID: <7vk5tj1uh4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46882AF2.6020705@vilain.net>

Sam Vilain <sam@vilain.net> writes:

Show 5 quoted lines

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

Show 5 quoted lines

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

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