Sam Vilain <sam@xxxxxxxxxx> 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.
>> 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.
-
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
