git-update-index - Registrera filinnehåll i arbetsträdet till indexet

Ändrar indexet. Varje nämnd fil uppdateras i indexet och alla tillstånd som ej sammanslagen eller behöver uppdateras rensas bort.

Se även git-add[1] för ett mer användarvänligt sätt att utföra några av de vanligaste operationerna på indexet.

Hur git update-index hanterar filer som det får information om kan ändras med olika alternativ:

--refresh beräknar inte någon ny sha1-fil och uppdaterar inte indexet för läges-/innehållsändringar. Men det gör att stat-informationen för en fil "matchas om" mot indexet, så att du kan uppdatera indexet för en fil som inte ändrats men där stat-posten är inaktuell.

Till exempel kan du vilja göra detta efter en git read-tree, för att koppla stat-indexdetaljerna till rätt filer.

--cacheinfo används för att registrera en fil som inte finns i den aktuella arbetskatalogen. Detta är användbart för sammanslagning med minsta möjliga utcheckning.

För att låtsas att du har en fil på en sökväg med visst läge och sha1, skriv:

--info-only används för att registrera filer utan att lägga dem i objektdatabasen. Detta är användbart för kodförråd som bara används för status.

Både --cacheinfo och --info-only beter sig likartat: indexet uppdateras men inte objektdatabasen. --cacheinfo är användbart när objektet finns i databasen men filen inte är tillgänglig lokalt. --info-only är användbart när filen är tillgänglig men du inte vill uppdatera objektdatabasen.

--index-info är en kraftfullare mekanism som låter dig mata in flera postdefinitioner från standardindata, särskilt avsedd för skript. Den kan ta indata i tre format:

För att lägga in en post med högre steg i indexet bör sökvägen först tas bort genom att mata in en post med mode=0 för sökvägen, och därefter mata in nödvändiga rader i det tredje formatet.

Till exempel med detta index som utgångspunkt:

du kan mata in följande till --index-info:

Den första raden i indatan matar in 0 som läge för att ta bort sökvägen; SHA-1 spelar ingen roll så länge den är korrekt formaterad. Därefter matar den andra och tredje raden in steg 1- och steg 2-poster för sökvägen. Efter ovanstående får vi detta:

Många operationer i Git är beroende av att ditt filsystem har en effektiv implementation av lstat(2), så att st_mtime-information för filer i arbetsträdet kan kontrolleras billigt för att se om filinnehållet har ändrats jämfört med versionen registrerad i indexfilen. Tyvärr har vissa filsystem ineffektiv lstat(2). Om ditt filsystem är ett av dem kan du sätta biten "assume unchanged" på sökvägar du inte har ändrat, så att Git inte gör denna kontroll. Observera att att sätta denna bit på en sökväg inte betyder att Git kontrollerar filinnehållet för att se om det ändrats — det gör att Git utelämnar all kontroll och antar att det inte har ändrats. När du gör ändringar i filer i arbetsträdet måste du uttryckligen tala om det för Git genom att ta bort biten "assume unchanged", antingen före eller efter att du ändrat dem.

För att sätta biten "assume unchanged", använd alternativet --assume-unchanged. För att avmarkera den, använd --no-assume-unchanged. För att se vilka filer som har biten "assume unchanged" satt, använd git ls-files -v (se git-ls-files[1]).

Kommandot läser konfigurationsvariabeln core.ignorestat. När den är sann markeras sökvägar som uppdaterats med git update-index paths... och sökvägar som uppdaterats med andra Git-kommandon som uppdaterar både index och arbetsträd (t.ex. git apply --index, git checkout-index -u och git read-tree -u) automatiskt som "assume unchanged". Observera att biten "assume unchanged" inte sätts om git update-index --refresh finner att filen i arbetsträdet matchar indexet (använd git update-index --really-refresh om du vill markera dem som "assume unchanged").

Ibland förväxlar användare biten assume-unchanged med biten skip-worktree. Se sista stycket i avsnittet "Skip-worktree bit" nedan för en förklaring av skillnaderna.

För att uppdatera och uppfriska endast de filer som redan är utcheckade:

Skip-worktree-biten kan definieras i en (lång) mening: säg åt git att undvika att skriva filen till arbetskatalogen när det rimligen går, och behandla filen som oförändrad när den inte finns i arbetskatalogen.

Observera att inte alla git-kommandon tar hänsyn till denna bit, och vissa stöder den bara delvis.

Flaggorna i update-index och read-tree-funktionerna relaterade till skip-worktree-biten fanns före introduktionen av kommandot git-sparse-checkout[1], som ger ett mycket enklare sätt att konfigurera och hantera skip-worktree-bitarna. Om du vill begränsa arbetsträdet till att bara hantera en delmängd av filerna i kodförrådet rekommenderar vi starkt att använda git-sparse-checkout[1] i stället för lågnivåprimitiver som update-index och read-tree erbjuder.

Huvudsyftet med skip-worktree-biten är att möjliggöra glesa utcheckningar, d.v.s. arbetskataloger där bara en delmängd av sökvägarna finns. När skip-worktree-biten är satt kommer Git-kommandon (som switch, pull, merge) att undvika att skriva dessa filer. Dessa kommandon kommer dock ibland ändå att skriva filerna i viktiga fall, som konflikter under sammanslagning eller ombasering. Git-kommandon undviker också att tolka frånvaron av sådana filer som avsiktlig radering; till exempel kommer git add -u inte att köa en radering för dessa filer och git commit -a kommer inte heller att skapa en incheckning som raderar dem.

Även om denna bit liknar biten assume-unchanged är syftet annorlunda. Assume-unchanged-biten används för att lämna filen i arbetsträdet men låta Git utelämna kontroller av ändringar och anta att filen inte ändrats (även om Git, om det kan avgöra utan att stat:a filen att den har ändrats, kan registrera ändringarna). skip-worktree säger åt Git att ignorera filens frånvaro, undvika att uppdatera den när det är möjligt med kommandon som normalt uppdaterar stora delar av arbetskatalogen (t.ex. checkout, switch, pull, osv.), och att inte registrera frånvaron i incheckningar. Observera att i glesa utcheckningar (uppsatta med git sparse-checkout eller genom att sätta core.sparseCheckout till true) kommer Git att rensa skip-worktree-biten för en fil om filen är markerad som skip-worktree i indexet men hittas i arbetsträdet.

Läget är utformat för kodförråd med mycket stora index och syftar till att minska tiden det tar att upprepade gånger skriva dessa index.

I detta läge delas indexet upp i två filer, $GIT_DIR/index och $GIT_DIR/sharedindex.<SHA-1>. Ändringar samlas i $GIT_DIR/index, det delade indexet, medan den delade indexfilen innehåller alla indexposter och förblir oförändrad.

Alla ändringar i det delade indexet förs tillbaka till den delade indexfilen när antalet poster i det delade indexet når en nivå som anges av konfigurationsvariabeln splitIndex.maxPercentChange (se git-config[1]).

Varje gång en ny delad indexfil skapas tas gamla delade indexfiler bort om deras ändringstid är äldre än vad som anges av konfigurationsvariabeln splitIndex.sharedIndexExpire (se git-config[1]).

För att undvika att ta bort en delad indexfil som fortfarande används uppdateras dess ändringstid till aktuell tid varje gång ett nytt delat index baserat på den delade indexfilen skapas eller läses.

Denna cache är avsedd att snabba upp kommandon som behöver fastställa ospårade filer, som git status.

Funktionen fungerar genom att registrera mtime för katalogerna i arbetsträdet och sedan utelämna katalogläsning och stat-anrop mot filer i kataloger vars mtime inte har ändrats. För att detta ska fungera måste det underliggande operativsystemet och filsystemet ändra fältet st_mtime för kataloger när filer i katalogen läggs till, ändras eller tas bort.

Du kan testa om filsystemet stöder detta med alternativet --test-untracked-cache. Alternativet --untracked-cache brukade implicit utföra testet i äldre Git-versioner, men så är det inte längre.

Om du vill aktivera (eller inaktivera) funktionen är det enklare att använda konfigurationsvariabeln core.untrackedCache (se git-config[1]) än att använda alternativet --untracked-cache till git update-index i varje kodförråd, särskilt om du vill göra det för alla kodförråd du använder. Du kan sätta konfigurationsvariabeln till true (eller false) i $HOME/.gitconfig en enda gång och få den att påverka alla kodförråd du arbetar med.

När konfigurationsvariabeln core.untrackedCache ändras läggs ospårad cache till i eller tas bort från indexet nästa gång ett kommando läser indexet. När --[no-|force-]untracked-cache används läggs ospårad cache däremot till eller tas bort från indexet omedelbart.

Före 2.17 hade den ospårade cachen ett programfel där ersättning av en katalog med en symbolisk länk till en annan katalog kunde göra att filer som spåras av git felaktigt visades som ospårade. Se incheckningen "status: add a failing test showing a core.untrackedCache bug" i git.git. En tillfällig lösning för detta är (och den kan även fungera för andra ännu oupptäckta programfel i framtiden):

Denna programfel har också visat sig påverka fall utan symboliska länkar där en katalog ersätts med en fil, när det gäller de interna strukturerna i den ospårade cachen. Men inget fall har rapporterats där detta gav felaktig utdata från "git status".

Det finns också fall där befintliga index skrivna av git-versioner före 2.17 refererar till kataloger som inte längre finns, vilket kan orsaka många varningar av typen "could not open directory" vid "git status". Detta är nya varningar för befintliga problem som tidigare tyst ignorerades.

Precis som med programfelet ovan är lösningen att köra en engångs-"git status" med core.untrackedCache=false för att rensa ut kvarvarande felaktig data.

Den här funktionen är avsedd att snabba upp git-operationer för kodförråd med stora arbetskataloger.

Det gör att git kan samarbeta med en filsystemövervakare (se git-fsmonitor--daemon[1] och avsnittet "fsmonitor-watchman" i githooks[5]) som kan informera om vilka filer som har ändrats. Detta gör att git kan undvika att behöva köra lstat() på varje fil för att hitta ändrade filer.

När den används tillsammans med ospårad cache kan prestandan förbättras ytterligare genom att undvika kostnaden för att skanna hela arbetskatalogen efter nya filer.

Om du vill aktivera (eller inaktivera) funktionen är det enklare att använda konfigurationsvariabeln core.fsmonitor (se git-config[1]) än att använda alternativet --fsmonitor till git update-index i varje kodförråd, särskilt om du vill göra det för alla kodförråd du använder. Du kan sätta konfigurationsvariabeln i $HOME/.gitconfig en enda gång och få den att påverka alla kodförråd du arbetar med.

När konfigurationsvariabeln core.fsmonitor ändras läggs filsystemövervakningen till i eller tas bort från indexet nästa gång ett kommando läser indexet. När --[no-]fsmonitor används läggs filsystemövervakningen däremot till eller tas bort från indexet omedelbart.

Kommandot respekterar konfigurationsvariabeln core.filemode. Om kodförrådet ligger på ett filsystem vars exekveringsbitar är opålitliga bör detta sättas till false (se git-config[1]). Då ignorerar kommandot skillnader i fillägen mellan indexet och filsystemet om de bara skiljer i exekveringsbit. På ett sådant olyckligt filsystem kan du behöva använda git update-index --chmod=.

På liknande sätt, om konfigurationsvariabeln core.symlinks är satt till false (se git-config[1]), checkas symboliska länkar ut som vanliga filer, och detta kommando ändrar då inte ett registrerat filläge från symbolisk länk till vanlig fil.

Kommandot läser konfigurationsvariabeln core.ignorestat. Se avsnittet "Using "assume unchanged" bit" ovan.

Kommandot läser också konfigurationsvariabeln core.trustctime. Detta kan vara användbart när inodens ändringstid regelbundet ändras av något utanför Git (filsystemsindexerare och backup-system använder ctime för att markera bearbetade filer) (se git-config[1]).

Utökningen för ospårad cache kan aktiveras med konfigurationsvariabeln core.untrackedCache (se git-config[1]).

Användare försöker ofta använda bitarna assume-unchanged och skip-worktree för att säga åt Git att ignorera ändringar i spårade filer. Detta fungerar inte som förväntat, eftersom Git ändå kan jämföra filer i arbetsträdet mot indexet vid vissa operationer. I allmänhet erbjuder Git inget sätt att ignorera ändringar i spårade filer, så alternativa lösningar rekommenderas.

Till exempel om filen du vill ändra är någon form av konfigurationsfil, kan kodförrådet innehålla en exempelkonfigurationsfil som sedan kan kopieras till det ignorerade namnet och ändras. Kodförrådet kan till och med innehålla ett skript som behandlar exempelfilen som en mall och ändrar samt kopierar den automatiskt.

git-config[1], git-add[1], git-ls-files[1]

En del av git[1]-sviten