Re: [RFC/PATCH 2/2] stash: drop dirty worktree check on apply

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

>> So perhaps there is no broken case at all, and it was just a matter of
>> being overly conservative from the beginning.
>
> Perhaps.
>
> If we are going to treat this as another mergy operation, we should at
> least still make sure that the index is clean (i.e. "diff --cached" is
> empty), I think.

Please disregard this.  

If the user is doing "stash apply" without --index, it is Ok for the index
to be different from HEAD.  On the other hand, if the "stash apply" is
used with --index, even if the result conflicted in the working tree and
then resolution gets marked with "git add" for conflicted paths, it is Ok
to have a path that is unrelated to the "stash apply" already added to the
index.

So I don't think there is no point to insist that the index is clean. I
was just confused and was thinking about the "git merge" (where we must
have a clean index, as we are going to commit the index as the result of
the merge with conflict resolution).
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]