Hoe kan ik voorkomen dat git denkt dat ik de naam heb gewijzigd

Ik heb twee bestanden index.htmlen template.html. Ik heb het grootste deel van index.htmlverplaatst naar template.htmlen nu denkt git dat ik de naam heb gewijzigd toen ik beide bestanden toevoeg. Is het mogelijk om dit in specifieke gevallen te voorkomen?


Antwoord 1, autoriteit 100%

Waarom denkt Git dat uw bestanden kopieën zijn

Git volgt inhoud, geen bestandsnamen. Als resultaat, als twee bestanden substantieel gelijkaardige inhoud hebben, zal git denken dat je het bestand hebt gekopieerd of hernoemd. Als je git-log(1) leest, zul je leren:

De overeenkomstindex is het percentage ongewijzigde regels en de ongelijkheidsindex is het percentage gewijzigde regels. Het is een naar beneden afgerond geheel getal, gevolgd door een procentteken. De gelijkheidsindexwaarde van 100% is dus gereserveerd voor twee gelijke bestanden, terwijl 100% ongelijkheid betekent dat geen enkele regel uit het oude bestand in het nieuwe is terechtgekomen.

Dus, ervan uitgaande dat je overeenkomstindex 100% is, zal git denken dat het een kopie is. Je kunt het beste een verstandig logbericht of notitie toevoegen (zie git-notes(1) voor meer daarover) om uit te leggen wat er aan de hand is als je denkt dat git niet het juiste doet.

De gelijkheidsindex aanpassen

Je zou ook kunnen proberen de waarden aan te passen die git gebruikt om iets te kopiëren of te hernoemen. De handleiding voor git-log(1) zegt:

-M[<n>], --find-renames[=<n>]
If generating diffs, detect and report renames for each commit. For
following files across renames while traversing history, see --follow. If
n is specified, it is a threshold on the similarity index (i.e. amount
of addition/deletions compared to the file’s size). For example, -M90%
means git should consider a delete/add pair to be a rename if more than
90% of the file hasn’t changed.
-C[<n>], --find-copies[=<n>]    
Detect copies as well as renames. See also --find-copies-harder.
If n is specified, it has the same meaning as for -M<n>.

Nogmaals, dit zal je niet helpen als de bestanden grotendeels op elkaar lijken, maar je kunt deze waarden zeker gebruiken om af te stemmen hoevergelijkbaar ze moeten zijn om als kopieën of hernoemingen te worden beschouwd. Uw kilometerstand kan variëren.


Antwoord 2, autoriteit 41%

Er is een “geaccepteerd” antwoord, maar het geeft geen hint over hoe de vraag te beantwoorden.

Het juiste antwoord, van git-log(1) en git-diff(1) is:

  --no-renames
       Turn off rename detection, even when the configuration
       file gives the default to do so.

Antwoord 3, autoriteit 34%

Als je net voor een commit bent en “je voelt je rot dat git gek is geworden”, maak dan de toevoeging van het ambigue bestand waarvan git dacht dat je het hernoemd had ongedaan, voer een commit uit, voeg dan het ambigue bestand opnieuw toe en commit :

git reset ambiguous_file_git_thought_you_renamed
git commit
git add ambiguous_file_git_thought_you_renamed
git commit

Dit werkte voor mij.

Controleer of er geen hernoeming heeft plaatsgevonden:

git diff --name-status -C HEAD^^ HEAD
M       ambiguous_file_git_thought_you_renamed
M       original_file

“M” aan het begin betekent gewijzigd, “R” betekent Hernoemd. Merk op dat hier geen Renamed bestaat.


Antwoord 4

Als je bestand A, B en C hebt gewijzigd; en verwijderd bestand D, E en F; er is een kans dat git denkt dat D is hernoemd naar A, of iets dergelijks.

De eenvoudigste oplossing is om bestandswijzigingen en verwijderingen in twee vastleggingen te splitsen.

Other episodes