chore: lessen unneeded den här/det här/detta

B-embedding-git-in-your-applications.asc

@@ -3,7 +3,7 @@
 == Bädda in Git i dina applikationer
 
 Om din applikation är för utvecklare är chansen stor att den skulle kunna dra nytta av integration med versionshantering.
-Även applikationer som inte är för utvecklare, såsom dokumentredigerare, kan potentiellt dra nytta av versionshanteringsfunktioner, och Gits modell fungerar mycket bra för många olika scenarier.
+Även applikationer som inte är för utvecklare, såsom dokumentredigerare, kan eventuellt dra nytta av versionshanteringsfunktioner, och Gits modell fungerar mycket bra för många olika scenarier.
 
 Om du behöver integrera Git med din applikation har du i praktiken två alternativ: starta ett skal och anropa kommandoradsprogrammet `git`, eller bädda in ett Git‑bibliotek i din applikation.
 Här går vi igenom kommandoradsintegration och flera av de mest populära inbäddningsbara Git‑biblioteken.

C-git-commands.asc

@@ -39,7 +39,7 @@ I <<ch07-git-tools#_credential_caching>> använde vi det för att sätta upp en
 
 I <<ch08-customizing-git#_keyword_expansion>> visade vi hur man sätter upp smudge‑ och clean‑filter för innehåll som går in och ut ur Git.
 
-Slutligen är i princip hela <<ch08-customizing-git#_git_config>> dedikerat åt kommandot.
+Slutligen är i princip hela <<ch08-customizing-git#_git_config>> ägnat åt kommandot.
 
 [[ch_core_editor]]
 ==== git config core.editor‑kommandon
@@ -101,7 +101,7 @@ Vi nämner kort hur du kan ändra standardgrennamnet från "`master`" i <<ch03-g
 
 Vi använder kommandot för att skapa ett tomt bart kodförråd för en server i <<ch04-git-on-the-server#_bare_repo>>.
 
-Slutligen går vi igenom några detaljer om vad det faktiskt gör bakom kulisserna i <<ch10-git-internals#_plumbing_porcelain>>.
+Slutligen går vi igenom några detaljer om vad det egentligen gör bakom kulisserna i <<ch10-git-internals#_plumbing_porcelain>>.
 
 ==== git clone
 
@@ -183,7 +183,7 @@ I <<ch03-git-branching#_git_branches_overview>> går vi igenom i mycket större
 
 Vi tittade på hur man signerar incheckningar kryptografiskt med flaggan `-S` i <<ch07-git-tools#_signing_commits>>.
 
-Slutligen tittar vi på vad kommandot `git commit` gör i bakgrunden och hur det faktiskt är implementerat i <<ch10-git-internals#_git_commit_objects>>.
+Slutligen tittar vi på vad kommandot `git commit` gör i bakgrunden och hur det egentligen är implementerat i <<ch10-git-internals#_git_commit_objects>>.
 
 ==== git reset
 
@@ -229,7 +229,7 @@ Det finns bara en handfull kommandon som implementerar det mesta av grening och
 Kommandot `git branch` är i praktiken ett verktyg för grenhantering.
 Det kan lista de grenar du har, skapa en ny gren, ta bort grenar och byta namn på grenar.
 
-Merparten av <<ch03-git-branching#ch03-git-branching>> är dedikerat till kommandot `branch` och det används genom hela kapitlet.
+Merparten av <<ch03-git-branching#ch03-git-branching>> är ägnat åt kommandot `branch` och det används genom hela kapitlet.
 Vi introducerar det först i <<ch03-git-branching#_create_new_branch>> och går igenom de flesta andra funktionerna (lista och ta bort) i <<ch03-git-branching#_branch_management>>.
 
 I <<ch03-git-branching#_tracking_branches>> använder vi alternativet `git branch -u` för att sätta upp en spårningsgren.
@@ -291,7 +291,7 @@ I <<ch07-git-tools#_commit_ranges>> går vi igenom detta ganska ingående.
 I <<ch07-git-tools#_merge_log>> och <<ch07-git-tools#_triple_dot>> går vi igenom formatet `branchA...branchB` och syntaxen `--left-right` för att se vad som finns i den ena grenen eller den andra men inte i båda.
 I <<ch07-git-tools#_merge_log>> tittar vi också på hur man använder alternativet `--merge` för att hjälpa till med felsökning av sammanslagningskonflikter samt hur man använder `--cc` för att titta på sammanslagningsincheckningskonflikter i historiken.
 
-I <<ch07-git-tools#_git_reflog>> använder vi alternativet `-g` för att visa Git‑refloggen genom det här verktyget i stället för att traversera grenar.
+I <<ch07-git-tools#_git_reflog>> använder vi alternativet `-g` för att visa Git‑refloggen genom verktyget i stället för att traversera grenar.
 
 I <<ch07-git-tools#_searching>> tittar vi på att använda alternativen `-S` och `-L` för att göra ganska avancerade sökningar efter något som hände historiskt i koden, såsom att se historiken för en funktion.
 

book/01-introduction/sections/about-version-control.asc

@@ -40,7 +40,7 @@ Den här modellen ger många fördelar, särskilt jämfört med lokala VCS:er.
 Till exempel vet alla till viss del vad alla andra i projektet gör.
 Administratörer har detaljerad kontroll över vem som kan göra vad, och det är betydligt enklare att administrera ett centraliserat system än att hantera lokala databaser på varje klient.
 
-Men den här modellen har också några allvarliga nackdelar.
+Men modellen har också några allvarliga nackdelar.
 Den mest uppenbara är den enda felpunkt som den centraliserade servern utgör.
 Om den servern går ner i en timme kan ingen under den tiden samarbeta eller spara versionshanterade ändringar i det de jobbar med.
 Om hårddisken där den centrala databasen ligger blir korrupt och man inte har riktiga säkerhetskopior förlorar man allt – hela projektets historik, förutom de enstaka versioner som råkar finnas på folks lokala maskiner.

book/01-introduction/sections/command-line.asc

@@ -2,7 +2,7 @@
 
 Det finns många olika sätt att använda Git.
 Det finns de ursprungliga kommandoradsverktygen och det finns många grafiska användargränssnitt med varierande möjligheter.
-För den här boken kommer vi att använda Git i kommandoraden.
+I boken använder vi Git i kommandoraden.
 För det första är kommandoraden det enda stället där du kan köra _alla_ Git-kommandon – de flesta grafiska gränssnitt implementerar bara en delmängd av Gits funktionalitet för enkelhetens skull.
 Om du kan köra kommandoradsversionen kan du troligen också räkna ut hur du använder den grafiska versionen, medan det omvända inte nödvändigtvis är lika lätt.
 Dessutom är valet av grafisk klient en smakfråga, men _alla_ användare har kommandoradsverktygen installerade och tillgängliga.

book/01-introduction/sections/help.asc

@@ -18,7 +18,7 @@ $ git help config
 ----
 
 Dessa kommandon är smidiga eftersom du kan använda dem överallt, även utan uppkoppling.
-Om manualsidorna och den här boken inte räcker och du behöver personlig hjälp kan du prova kanalerna `#git`, `#github` eller `#gitlab` på Libera Chat IRC-servern, som finns på https://libera.chat/[^].
+Om manualsidorna och boken inte räcker och du behöver personlig hjälp kan du prova kanalerna `#git`, `#github` eller `#gitlab` på Libera Chat IRC-servern, som finns på https://libera.chat/[^].
 På dessa kanaler samlas regelbundet hundratals personer som är kunniga i Git och ofta villiga att hjälpa till.(((IRC)))
 
 Dessutom, om du inte behöver hela manualsidan utan bara en snabb påminnelse om vilka flaggor som finns för ett Git-kommando, kan du be om den kortare hjälpen med `-h`-flaggan, till exempel:

book/02-git-basics/sections/getting-a-repository.asc

@@ -37,7 +37,7 @@ $ git init
 ----
 
 Det här skapar en ny underkatalog som heter `.git` och innehåller alla nödvändiga filer – ett skelett för ditt Git‑kodförråd.
-I det här läget är inget i projektet spårat.
+I nuläget är inget i projektet spårat.
 Se <<ch10-git-internals#ch10-git-internals>> för mer information om exakt vilka filer som finns i `.git`-katalogen du nyss skapade.(((git commands, init)))
 
 Om du vill börja versionshantera befintliga filer (till skillnad från en tom katalog) bör du börja spåra dem och göra en första incheckning.

book/02-git-basics/sections/recording-changes.asc

@@ -341,7 +341,7 @@ index 0000000..03902a1
 +My Project
 ----
 
-Viktigt att notera är att `git diff` i sig inte visar alla ändringar sedan senaste incheckningen – bara ändringar som ännu inte kommer ingå i nästa incheckning.
+Viktigt att tänka på är att `git diff` i sig inte visar alla ändringar sedan senaste incheckningen – bara ändringar som ännu inte kommer ingå i nästa incheckning.
 Om du har köat alla ändringar att ingå i nästa incheckning ger `git diff` ingen utskrift.
 
 Ytterligare ett exempel: om du köar `CONTRIBUTING.md` och sedan ändrar den igen kan du använda `git diff` för att se både de köade och oköade ändringarna.
@@ -559,7 +559,7 @@ Det betyder att du kan göra saker som:
 $ git rm log/\*.log
 ----
 
-Notera omvänt snedstreck (`\`) framför `*`.
+Observera omvänt snedstreck (`\`) framför `*`.
 Det behövs eftersom Git gör sin egen filnamnsexpansion utöver skalets expansion.
 Kommandot tar bort alla filer med filändelsen `.log` i katalogen `log/`.
 Eller så kan du göra något i stil med:

book/02-git-basics/sections/remotes.asc

@@ -6,7 +6,7 @@ Fjärrkodförråd är versioner av ditt projekt som finns någonstans på nätet
 Du kan ha flera, och var och en är i regel antingen skrivskyddad eller läs/skriv för dig.
 Att samarbeta innebär att hantera dessa fjärrkodförråd och att skicka och uppdatera data till och från dem när du behöver dela arbete.
 Att hantera fjärrkodförråd innefattar att lägga till nya, ta bort sådana som inte längre är giltiga, hantera fjärrgrenar och markera dem som spårade eller inte, och mycket mer.
-I det här avsnittet går vi igenom några av dessa färdigheter.
+I avsnittet går vi igenom några av dessa färdigheter.
 
 [NOTE]
 .Fjärrkodförråd kan ligga på din lokala maskin
@@ -67,7 +67,7 @@ origin    git@github.com:mojombo/grit.git (push)
 Det betyder att vi kan uppdatera bidrag från alla dessa ganska enkelt.
 Vi kan också ha rättigheter att skicka till en eller flera av dem, men det ser vi inte här.
 
-Notera att fjärrkodförråden använder olika protokoll; vi går igenom detta mer i <<ch04-git-on-the-server#_getting_git_on_a_server>>.
+Observera att fjärrkodförråden använder olika protokoll; vi går igenom detta mer i <<ch04-git-on-the-server#_getting_git_on_a_server>>.
 
 ==== Lägga till fjärrkodförråd
 

book/02-git-basics/sections/tagging.asc

@@ -4,7 +4,7 @@
 (((tags)))
 Precis som de flesta VCS:er kan Git tagga särskilda punkter i ett kodförråds historik.
 Vanligtvis används detta för att markera utgåvor (`v1.0`, `v2.0` och så vidare).
-I det här avsnittet lär du dig hur du listar befintliga taggar, hur du skapar och tar bort dem, samt vilka typer av taggar som finns.
+I avsnittet lär du dig hur du listar befintliga taggar, hur du skapar och tar bort dem, samt vilka typer av taggar som finns.
 
 ==== Lista taggar
 
@@ -233,7 +233,7 @@ $ git tag -d v1.4-lw
 Deleted tag 'v1.4-lw' (was e7d5add)
 ----
 
-Notera att detta inte tar bort taggen från några fjärrkodförråd.
+Observera att detta inte tar bort taggen från några fjärrkodförråd.
 Det finns två vanliga sätt att ta bort taggar från fjärrkodförråd.
 
 Det första är `git push <fjärrnamn> :refs/tags/<taggnamn>`:

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -7,7 +7,7 @@ Du kommer att följa dessa steg:
 . Skapa en gren för en ny användarberättelse du jobbar på.
 . Gör arbete i den grenen.
 
-I det här läget får du ett samtal om att ett annat problem är mer kritiskt och att det behövs en snabbkorrigering.
+I det läget får du ett samtal om att ett annat problem är mer kritiskt och att det behövs en snabbkorrigering.
 Då gör du följande:
 
 . Byt till produktionsgrenen.
@@ -60,7 +60,7 @@ Nu får du samtalet om att det finns ett problem med webbplatsen som måste fixa
 Med Git behöver du inte distribuera din fix tillsammans med `iss53`-ändringarna, och du behöver inte lägga tid på att ångra dem innan du kan jobba mot produktion.
 Allt du behöver göra är att byta tillbaka till `master`.
 
-Notera dock att om arbetskatalogen eller köytan innehåller icke checkade in ändringar som krockar med grenen du vill växla till, kommer Git att hindra bytet.
+Observera dock att om arbetskatalogen eller köytan innehåller icke checkade in ändringar som krockar med grenen du vill växla till, kommer Git att hindra bytet.
 Det är bäst att ha en ren arbetskatalog när du byter gren.
 Det finns sätt att komma runt detta (gömma ändringar eller göra en tilläggsincheckning), vilket vi går igenom senare i <<ch07-git-tools#_git_stashing>>.
 För tillfället antar vi att du har checkat in allt och kan byta tillbaka till `master`:
@@ -138,7 +138,7 @@ $ git commit -a -m 'Finish the new footer [issue 53]'
 .Arbetet fortsätter på `iss53`
 image::images/basic-branching-6.png[Arbetet fortsätter på `iss53`]
 
-Det är värt att notera att arbetet du gjorde i `hotfix`-grenen inte finns i `iss53`.
+Värt att veta är att arbetet du gjorde i `hotfix`-grenen inte finns i `iss53`.
 Om du behöver få in ändringarna kan du sammanfoga `master` in i `iss53` med `git merge master`, eller vänta tills du senare sammanfogar `iss53` till `master`.
 
 [[_basic_merging]]

book/03-git-branching/sections/rebasing.asc

@@ -3,7 +3,7 @@
 
 (((rebasing)))
 I Git finns två huvudsätt att integrera ändringar från en gren in i en annan: `merge` och `rebase`.
-I det här avsnittet lär du dig vad ombasering är, hur man gör det, varför det är ett imponerande verktyg och när du inte ska använda det.
+I avsnittet lär du dig vad ombasering är, hur man gör det, varför det är ett imponerande verktyg och när du inte ska använda det.
 
 ==== Grundläggande ombasering
 
@@ -23,7 +23,7 @@ Men det finns ett annat sätt: du kan ta ändringspatchen som introducerades i `
 I Git kallas detta _rebase(ombasera)_.
 Med `rebase` kan du ta alla ändringar som checkats in på en gren och spela upp dem på en annan.(((git commands, rebase)))
 
-I det här exemplet växlar du till `experiment` och flyttar den till `master` så här:
+I exemplet växlar du till `experiment` och flyttar den till `master` så här:
 
 [source,console]
 ----
@@ -57,7 +57,7 @@ Ofta gör du detta för att säkerställa att dina incheckningar går att applic
 Då gör du arbetet i en gren och flyttar det till `origin/master` när du är redo att skicka in dina ändringspatchar.
 På så vis behöver förvaltaren bara snabbspola eller applicera ändringarna rent.
 
-Notera att ögonblicksbilden som den sista incheckningen pekar på – oavsett om det är den sista flyttade incheckningen eller den sista sammanslagningsincheckningen – är densamma.
+Observera att ögonblicksbilden som den sista incheckningen pekar på – oavsett om det är den sista flyttade incheckningen eller den sista sammanslagningsincheckningen – är densamma.
 Det är bara historiken som skiljer sig.
 Ombasering spelar upp ändringar i samma ordning som de introducerades, medan sammanslagning tar ändpunkterna och fogar samman dem.
 
@@ -174,7 +174,7 @@ Om du kör `git pull` skapar du en sammanslagningsincheckning som innehåller b
 .Du sammanfogar samma arbete igen i en ny sammanslagningsincheckning
 image::images/perils-of-rebasing-4.png[Du sammanfogar samma arbete igen i en ny sammanslagningsincheckning]
 
-Om du kör `git log` i det här läget ser du två incheckningar med samma författare, datum och meddelande, vilket är förvirrande.
+Om du kör `git log` i det läget ser du två incheckningar med samma författare, datum och meddelande, vilket är förvirrande.
 Om du skickar upp den här historiken till servern återinför du dessutom de omskrivna incheckningarna, vilket kan förvirra andra.
 Det är rimligt att anta att den andra utvecklaren inte vill ha `C4` och `C6` i historiken; det var därför de flyttade om den från början.
 
@@ -222,7 +222,7 @@ Om du eller en kollega behöver göra det, se till att alla vet att de ska köra
 Nu när du har sett ombasering och sammanslagning i praktiken undrar du kanske vilket som är bäst.
 Innan vi kan svara behöver vi ta ett steg tillbaka och prata om vad historik betyder.
 
-Ett perspektiv är att ditt kodförråds incheckningshistorik är *en redogörelse för vad som faktiskt hände*.
+Ett perspektiv är att ditt kodförråds incheckningshistorik är *en redogörelse för vad som verkligen hände*.
 Det är ett historiskt dokument, värdefullt i sig, och ska inte manipuleras.
 Ur det perspektivet är ändring av historiken nästan hädelse; du _ljuger_ om vad som skedde.
 Vad gör det om det finns en stökig serie sammanslagningsincheckningar?

book/03-git-branching/sections/remote-branches.asc

@@ -111,7 +111,7 @@ From https://github.com/schacon/simplegit
  * [new branch]      serverfix    -> origin/serverfix
 ----
 
-Det är viktigt att notera att när du uppdaterar nya fjärrspårade grenar får du inte automatiskt en lokal, redigerbar kopia av dem.
+Tänk på att när du uppdaterar nya fjärrspårade grenar får du inte automatiskt en lokal, redigerbar kopia av dem.
 I det här fallet har du alltså ingen ny lokal `serverfix`-gren – bara en `origin/serverfix`-pekare som du inte kan ändra.
 
 För att sammanfoga arbetet med din nuvarande gren kan du köra `git merge origin/serverfix`.
@@ -199,7 +199,7 @@ Vi ser också att `master` spårar `origin/master` och är uppdaterad.
 `serverfix` spårar `server-fix-good` på `teamone` och ligger före med tre och efter med en, vilket betyder att det finns en incheckning på servern som vi inte har sammanfogat ännu och tre lokala incheckningar som inte är skickade.
 Slutligen ser vi att `testing` inte spårar någon fjärrgren.
 
-Det är viktigt att notera att dessa siffror bara gäller sedan senaste gången du uppdaterade från varje server.
+Tänk på att dessa siffror bara gäller sedan senaste gången du uppdaterade från varje server.
 Kommandot kontaktar inte servrarna utan visar vad som finns i din lokala mellanlagring.
 Vill du ha helt uppdaterade siffror behöver du uppdatera från alla fjärrkodförråd precis innan du kör det, till exempel så här:
 

book/03-git-branching/sections/workflows.asc

@@ -1,7 +1,7 @@
 === Arbetsflöden med grenar
 
 Nu när du har grunderna i grenarbete och sammanslagning, vad kan eller bör du göra med dem?
-I det här avsnittet går vi igenom några vanliga arbetsflöden som de lättviktiga grenarna möjliggör, så att du kan avgöra om du vill använda dem i din egen utvecklingscykel.
+I avsnittet går vi igenom några vanliga arbetsflöden som de lättviktiga grenarna möjliggör, så att du kan avgöra om du vill använda dem i din egen utvecklingscykel.
 
 ==== Långlivade grenar
 

book/04-git-server/sections/protocols.asc

@@ -182,7 +182,7 @@ Om du vill ha anonym läsåtkomst och samtidigt använda SSH för uppsändning m
 
 (((protocols, git)))
 Till sist har vi Git-protokollet.
-Det är en särskild demon som följer med Git; den lyssnar på en dedikerad port (9418) och tillhandahåller en tjänst liknande SSH, men helt utan autentisering eller kryptering.
+Det är en särskild demon som följer med Git; den lyssnar på en egen port (9418) och tillhandahåller en tjänst liknande SSH, men helt utan autentisering eller kryptering.
 För att ett kodförråd ska kunna erbjudas via Git-protokollet måste du skapa en `git-daemon-export-ok`-fil – annars serveras det inte – men förutom det finns det ingen säkerhet.
 Antingen är kodförrådet tillgängligt för alla att klona eller inte alls.
 Det innebär att man normalt inte skickar upp via detta protokoll.