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

2 messages, 2 authors, 2017-06-10 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2017-06-10 11:17:52

Andreas Heiduk [off-list ref] writes:
When setting `.gitattributes` in a second worktree, a plain `rm .git/index`
does not actually delete the index.

Signed-off-by: Andreas Heiduk <redacted>
---
 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.
quoted hunk
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"

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

From: Andreas Heiduk <hidden>
Date: 2017-06-10 17:25:00

Am 10.06.2017 um 13:17 schrieb Junio C Hamano:
Andreas Heiduk [off-list ref] writes:
quoted
When setting `.gitattributes` in a second worktree, a plain `rm .git/index`
does not actually delete the index.
[...]
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-<.
IMO `rm .git/index` is like munging a disk block WITHOUT a binary
editor but with plain `dd seek=... skip=... count=...`, `hexdump`,
`ed` and back - every step is clear in principle but painful and
dangerous. :-)
For example, can we do this "empty the index" step with things like

    $ git rm --cached .
That would be `git rm --cached -rq .`?

Executing this in the git repo gives me an index file with 2.1kb. I
don't know whether or not this index still contains something relevant
for this case.
or

    $ git read-tree --empty

instead?
Nice! The `index` file contains 46 bytes.

For me THAT one is like a nice binary editor apt for the job :-)
I'll queue that.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help