Re: [PATCH] doc: fix location of index in worktree scenatio

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

 



Andreas Heiduk <asheiduk@xxxxxxxxx> writes:

> When setting `.gitattributes` in a second worktree, a plain `rm .git/index`
> does not actually delete the index.
>
> Signed-off-by: Andreas Heiduk <asheiduk@xxxxxxxxx>
> ---
>  Documentation/gitattributes.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Right.  

I however have to wonder if we can do the same without futzing
directly with the "index" file as a filesystem entity.  With or
without your update, what is taught in the document feels like
munging a disk block with binary editor to correct a corrupted
filesystem X-<.

For example, can we do this "empty the index" step with things like

    $ git rm --cached .

or

    $ git read-tree --empty

instead?

Thanks.

> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 473648386..4c6b74fa6 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -229,7 +229,7 @@ From a clean working directory:
>  
>  -------------------------------------------------
>  $ echo "* text=auto" >.gitattributes
> -$ rm .git/index     # Remove the index to re-scan the working directory
> +$ rm "$(git rev-parse --git-path index)"  # Remove the index to re-scan the working directory
>  $ git add .
>  $ git status        # Show files that will be normalized
>  $ git commit -m "Introduce end-of-line normalization"



[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]