Re: [PATCH 04/19] reset: don't allow "git reset -- $pathspec" in bare repo

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

 



On Wed, Jan 9, 2013 at 11:32 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Martin von Zweigbergk <martinvonz@xxxxxxxxx> writes:
>
>> ---
>>  builtin/reset.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> With the patch that does not have any explicit check for bareness
> nor new error message to scold user with, it is rather hard to tell
> what is going on, without any description on what (if anything) is
> broken at the end user level and what remedy is done about that
> breakage...

Will include the following in a re-roll.

    reset: don't allow "git reset -- $pathspec" in bare repo

    Running e.g. "git reset ." in a bare repo results in an index file
    being created from the HEAD commit. The differences compared to the
    index are then printed as usual, but since there is no worktree, it
    will appear as if all files are deleted. For example, in a bare clone
    of git.git:

      Unstaged changes after reset:
      D       .gitattributes
      D       .gitignore
      D       .mailmap
      ...

    This happens because the check for is_bare_repository() happens after
    we branch off into read_from_tree() to reset with paths. Fix by moving
    the branching point after the check.
--
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]