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

Signed-off-by: Josef Andersson <janderssonse@proton.me>

Author: janderssonse

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]]