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.