Problema chmod git: checkout viti exec bit


10

Sotto Ubuntu e Debian gli ultimi file impegnati stanno ottenendo il bit di esecuzione impostato, quando provo un checkout in seguito. È abbastanza strano e mi fa impazzire:

$ ls -l file
-rw-r--r-- ... file

# on branch master:
$ git commit -m 'mode is 644' file
[master 0123456] mode is 644
 1 files changed, 1 insertions(+), 1 deletions(-)
# All ok

$ git checkout dev-branch
Switched to branch 'dev-branch'
# Seemingly all ok, but file now has the exec bit set

$ git merge master
Updating 6543210..0123456
error: Your local changes to 'file' would be overwritten by merge.  Aborting.
Please, commit your changes or stash them before you can merge.
# Oops...

$ ls -l file
-rwxr-xr-x ... file

Qualcuno ha un'idea, quando e perché il bit di esecuzione scivola dentro? core.filemodeè impostato su true.

Ho il file aperto in vim durante il cambio di ramo, se questo è importante in qualche modo.

Addendum 1: è il checkout, in cui le autorizzazioni sono rovinate. Posso giocare all'infinito:

$ git br
* master
  dev-branch

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

$ chmod 644 file

$ git diff

$ git checkout dev-branch

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

$ chmod 644 file

$ git diff

$ git checkout master

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

# ...and so on ad inf.

Addendum 2: Questo succede, tra l'altro, per ogni file in questo repository, che commetto. Dopo aver eseguito correttamente il commit, non posso cambiare ramo senza l'autorizzazione sbagliata.


Hai controllato i permessi nel passaggio # apparentemente tutto ok ...
— RobotHumans il

Sono d'accordo qui. Su dev-branch, 'git-log master ... HEAD - file' e vedi se qualcosa è cambiato tra il ramo e ora su quel file.
— yuriismaster,

@ aking1012: Sì, a quel punto le modalità del file sono già cambiate. Aggiornerò la domanda.
— Boldewyn,

@yuriismaster: git-lognon mostra alcun output, per nessuna combinazione di master, dev-brancho HEAD(il che è strano, non è vero? Il comando non dovrebbe stampare l'ultimo messaggio di commit da master?)
— Boldewyn,

2
Su quale filesystem sei?
— Maschera di bit

Risposte:


12

Non è un utente Git, ma credo che Git memorizzi l'intera maschera di autorizzazione dei file.

Ciò significa che una volta hai impostato il file su eseguibile, che Git ha raccolto e replicato nel repository. Pertanto è necessario modificare la maschera di autorizzazione del file stesso prima di eseguire il commit.

Per fare in modo che Git ignori tali modifiche, usare

git config core.filemode false

Da git-config (1) :

   core.fileMode
       If false, the executable bit differences between the index and the
       working copy are ignored; useful on broken filesystems like FAT.
       See git-update-index(1). True by default.

1
In realtà, faccio del mio meglio per eseguire il commit dei file con le autorizzazioni corrette. Ho anche ri-eseguito il commit di tutti i file dopo averli modificati. Dal momento che lavoro su Windows di tanto in tanto (non con questo repository, però), lo so core.fileMode, ma speravo di poterlo lasciare true.
— Boldewyn,

Potrebbe persino essere un bug in git quando si lavora su quelli che chiamano "filesystem rotti". Non ci sono filesystem rotti, solo software rotti.
— harrymc,

4
Devo concordare con gli sviluppatori git che il grasso è rotto
— RobotHumans,

3
OK, era il file system. Non sono riuscito a riprodurlo su un'altra macchina, in cui la directory è montata tramite NFS. Sulla macchina principale è, come ho detto, CIFS. Quando ho chiesto sulla mailing list di git, ho avuto la risposta, che CIFS è rotto per quanto riguarda i bit di esecuzione. Darn!
— Boldewyn,


3

Hai verificato se esiste un hook personalizzato che viene eseguito durante il commit o il checkout? Potrebbero esserci alcuni hook personalizzati che alterano i tuoi file. Checkout la pagina di manuale githooks .

Gli hook sono fondamentalmente piccoli programmi chiamati da Git in determinati eventi (commit, checkout ecc.).


Buona prova, ma la mia .git/hooksdirectory non è stata toccata.
— Boldewyn,

1

hai provato git commit -m 'mode is 644' file sul ramo dev-branch

a me sembra che ciò che sta accadendo è che stai cambiando i permessi su main, quindi tirando giù il ramo dev che ha il permesso sbagliato, bloccando il tuo permesso locale. poi prova a impegnarmi di nuovo. clonare, modificare, eseguire il commit, unire; oppure prova a modificare il file singolarmente con un singolo file commit in dev quindi unisci


1
In realtà, non tocco mai le autorizzazioni nello scenario originale. Tutte le modifiche alle autorizzazioni vengono eseguite da git nel passaggio 'checkout'.
— Boldewyn,

... cioè, ho fatto un po 'di chmodingegno sui file, ma purtroppo non ricordo, se il problema ha iniziato a verificarsi subito dopo. Penso di no.
— Boldewyn,

ho provato a replicare il tuo problema e non posso
— RobotHumans,

Questo perché non lavori su un CIFS montato ;-). Ho dimenticato il +1 per la prova, grazie!
— Boldewyn,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.