Wachtwoord-toegang afgeschaft
Het gebruik van een gewoon wachtwoord voor git pull, git push enz is eind april afgeschaft door GitLab.
Met als gevolg dat je
– niet meer met je wachtwoord kan inloggen
– een foutmelding krijgt bij je commando’s, bv:

git push
remote: HTTP Basic: Access denied. If a password was provided for Git authentication, the password was incorrect or you're required to use a token instead of a password. If a token was provided, it was either incorrect, expired, or improperly scoped. See https://gitlab.com/help/topics/git/troubleshooting_git.md#error-on-git-fetch-http-basic-access-denied
fatal: Authentication failed for 'https://gitlab.com/mijnproject/mijnproject.git

Je hebt nu een token nodig in plaats van het wachtwoord.

Een token maken
Het token maak je online op de GitLab website, en daar is intussen 2FA verplicht, dus houd je e-mail al in de buurt (tenzij je een andere 2FA methode had ingesteld).
In het webplatform van GitLab inloggen met naam en (nog wel) het wachtwoord, dan verification code uit de mail ingeven.
In je instellingen (rechtsboven onder icoon/avatar) een token bijmaken.
Preferences / access / personal access tokens
Je ziet daar een overzicht van de toestand van je tokens: Active, Expiring, Revoked en Expired tokens.

Kies “generate token” en volg de aanwijzingen op het scherm; je moet alvast invullen:
– token name
– description
– vervaldatum (maximal tot 2027-05-27)
– select scopes (bv write_repository, api)
Bevestig, dan krijg je:

Your new token has been created
Token details

en daaronder een lijn met 62 tekens (hoofd/kleine letters, cijfers en leestekens)

Die moet je kopieren van de site en ergens veilig opslaan; dat is de nieuwe vervanging voor het wachtwoord bij git bewerkingen.

In het overzicht staat nu:

Active tokens
1

Ik kan geen nieuw wachtwoord ingeven
Als ik git commando’s ingeef moet ik het wachtwoord niet ingeven, en ook geen login.
– in de config file zie ik de standaardgegevens voor git gebruik
– git config –list toont ook de standaard gebruiker.

Als je in een “Konsole” terminal in een KDE-omgeving werkt, kan het zijn dat je wachtwoorbeheerder van KDE je wachtwoord bijhield. Daar kan je het wachtwoord veranderen; plak de gegenereerde tekstlijn (token) in de plaats van het wachtwoord.

Het kan zelfs dat daar een andere login staat dan in de .gitconfig file.

Meer tokens
Je kan op toestellen waar je alleen code moet afhalen een ander token gebruiken, waarbij je alleen lees-rechten instelt bij scope van het token, bij het aanmaken.
Daardoor is het wachtwoord van je account niet nodig op die plaats, wat veiliger is.

Ik zoek wanneer een bepaald stuk code ingevoerd is.

Met git log krijg ik de nummers van de commits.

Met git show (commit nummer) kan ik kijken wat daarin gebeurd is (+ -)

Wanneer is een bepaald bestand in mijn project veranderd?

Ik wil weten wanneer ik de laatste keer het bestand Libraries.txt heb aangepast, omdat ik het niet terugvind in Changes.txt (log van versienummers en veranderingen). Ik ben nu aan versie 0.6.9.

git log -p Libraries.txt

Bovenste deel van het antwoord:

commit 3acf9773661770233e444600....
Author: cybrarian
Date: Fri Feb 21 00:49:20 2025 +0100
'
0.6.2 gridinfo 3j columns
'
diff --git a/Libraries.txt b/Libraries.txt
index e353c0e..e8a4df3 100644
--- a/Libraries.txt
+++ b/Libraries.txt
@@ -1 +1 @@
-myprojectlib 0.6.4
+myprojectlib 0.6.6
.
commit a45dd20dd2bd279017....
Author: cybrarian
Date: Thu Feb 13 19:47:52 2025 +0100
...
...


Het antwoord: bij versie 0.6.2 is de inhoud gewijzigd van 0.6.4 naar 0.6.6.

git checkout HEAD -- naamvanbestand

Als ik op mijn huidige systeem git diff doe, wordt het antwoord getoond in een soort tekstverwerker waarin ik handig kan scrollen, zoeken enz, en die ik verlaat met “q”.
Maar helaas, als ik daarna een andere aktie wil doen, bv een commit waarin ik als commentaar iets schrijf wat ik uit die diff haal, zie ik die niet meer.

Ik wil dus de uitvoer van diff op het scherm houden, bv voor het bestand Changes.txt:

git --no-pager diff Changes.txt

Even gemakkelijk kan je dan de text ook omleiden naar een bestand:

git --no-pager diff Changes.txt > ~/diffMybranchOtherbranch-Changes.txt

Er is ergens een stomme bug veroorzaakt, waarschijnlijk lang geleden, en de oorzaak is onduidelijk; is het met een aanpassing aan de code gebeurd, of per vergissing door even in de editor in een verkeerd bestand iets te doen bij te snelle toetsaanslagen tijdens het werk?

Hoe kan git mij helpen dat moment terug te vinden?

Log path:

git log --path

bv:
git log -- Trypo/.src/TrypoForms/FDayReq.class

Daarmee kan je al zien wanneer daar de laatste aanpassingen gedaan zijn. Maar welke?

Bv de bug bevondt zich op regel 889 en betrof missende () bij een bewerking.

Log line:

git log -L(from),(to):(path)

bv:

git log -L887,891:Trypo/.src/TrypoForms/FDayReq.class

Dit geeft me de – en + regels, en hiermee kan ik snel vinden wat er juist gebeurd is.

De online versie van de master en mijn eigen lokale versie zijn uiteengelopen.

git checkout master
Switched to branch 'master'
Your branch and 'origin/master' have diverged,
and have 11 and 1 different commits each, respectively.


Ik kan het niet eenvoudig oplossen met push of pull:


git status
On branch master
Your branch is ahead of 'origin/master' by 11 commits.
(use "git push" to publish your local commits)
'
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: .project
'
no changes added to commit (use "git add" and/or "git commit -a")
linuxuser@copyleft:~/Git/MyProject> git push
To gitlab.com:dev/myproject.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'gitlab.com:dev/myproject.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
linuxuser@copyleft:~/Git/MyProject> git pull
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.


Ik haalde de main af in een test directory en met Kompare bekeek ik de verschillen om te checken wat er aan de hand was. Conclusie: mijn locale versie moet de nieuwe main/master worden.

Ik beveilig eerst mijn locale wijzigingen in een nieuwe branch:
(Als het over een kleine wijziging ging zou ik misschien git stash en git stash pop gebruiken)

git branch backup-mainlocal

Daarna even checken:

git status
On branch master
Your branch and 'origin/master' have diverged,
and have 12 and 1 different commits each, respectively. (...)

Ik zit nog in mijn master; gelijkzetten met de online versie:

git reset --hard origin/master
HEAD is now at efde303 Update ReadMe.txt with sourceforge tar.gz link

Ik zie de laatste wijziging daar in mijn ReadMe bestand.
Nu zijn beide versies terug gelijk:

git status
On branch master
Your branch is up to date with 'origin/master'.

en kan ik de wijzigingen toepassen uit mijn backup:

git merge backup-mainlocal
Merge made by the 'ort' strategy.
.component | 4 ++++
.gitignore | 19 +++++++++++++++++
.project | 3 ++-
.src/FMain.class | 54 +++++++++++++++++++++++++++++++++++++++++-------
.src/FMain.form | 4 ++--
...
Changes.txt | 15 ++++++++++++++
Help.txt | 2 +-
10 files changed, 441 insertions(+), 29 deletions(-)
create mode 100644 .component
create mode 100644 .gitignore

En online brengen:

linuxuser@copyleft:~/Git/MyProject/> git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 627 bytes | 627.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0), pack-reused 0
To gitlab.com:dev/myproject.git
efde303..c950ea5 master -> master

Ok nu zijn ze terug synchroon.

Ik moet een oud project oppikken dat ooit een aparte branch had waarin ik wil gaan werken, en ik moet de code up to date maken met de huidige stand.

git reset --hard origin/master

Als antwoord krijg ik:

HEAD is now at 01d4e38 fix conflicts

Ik vraag me af welke conflicts er dan zijn, want er worden er geen opgesomd. Normaal, als er conflicten zijn, wordt de aktie niet uitgevoerd, maar hier heb ik wel de bevestiging van “Head is now at ..”.

Bij nader inzien bleek “fix conflicts” de commit message te zijn van de laatse commit waar head nu op zit ….

Eén enkele branch afhalen van een git repository

Ik heb in een “dev” map een project “myproject” met ontwikkeling in Gambas3 op een pc met Kde-desktop.

Er is één tak van het project, branch “compat-lxde”, die ik ontwikkel op een ander toestel (Raspberry Pi) met een LXDE desktop; om de applicatie daar compatibel met die desktop te houden. Hierin neem ik bijna alles over van de “main”, behalve de dingen die niet werken in een LXDE desktop, die laat ik weg of pas ik aan.

De branches main en compat-lxde lopen dus grotendeels parrallel.

Soms wijzig ik iets op di Pi aan de lxde versie dat ook nuttig is voor main, en om dat binnen te halen wil ik ook de lxde code op mijn KDE-pc, maar op zo’n manier dat ik mij niet vergis met mijn gewone development, ik moet vermijden dat ik mijn gewone development aan het doen ben in de lxde versie bv.

Ik wil dus op mijn pc op een andere plek één bepaalde tak van mijn ontwikkeling apart bijhouden om die daar enkel te raadplegen.
Ik wil hier niet alle andere branches in hebben want die heb ik in mijn dev map, en daar werk ik ook aan.

Algemeen:
git clone -b --single-branch

Bv: als branch compat-lxde bestaat in het project:
git clone -b compat-lxde --single-branch https://gitlab.com/project/myproject.git

Ook op de Raspberry Pi kan het nuttig zijn om niet alle code binnen te halen, maar enkel de branch “compat-lxde” en bv “main” of “test”.

Nu kan ik op de pc in mijn dev directory de branches gebruiken om in te werken, bv in “feat-abc”, dan naar test, tot binnenhalen in main.

Ik ga naar de pi, integreer daar alles van main in de lxde branch. Ik doe terloops ook nog een kleine correctie (die terug naar test/main moet).

Ik ga op de pc naar de map met de lxde, haal de wijzigingen af (pull), kan die openen en knippen/plakken naar het project dat in de ontwikkelomgeving open staat in dev directory.

Normaal zit in de dev directory ook de lxde branch, en kan je daar diff’s met test/main doen en zo.

Om een enkele tak lokaal toe te voegen, doe:

git remote set-branches –add origin [remote-branch]
git fetch origin [remote-branch]:[local-branch]

Doel: een “Developer” mogelijkheid geven om de main te updaten.

De leden van een project kunnen hun rol hebben gekregen doordat ze lid zijn va een “group”, en die kan dan niet apart ingesteld worden voor een subproject van die group, bv devcopyleft/clTools
Rollen zijn in stijgende volgorde : Guest - Reporter - Developer - Maintainer - Owner

Ga naar de hoofdpagina van de group, bv devcopyleft.
Daar bij “Manage”, zie je de “Group Members”.
Als je de nodige rechten hebt (oprichter van de group: “owner”) kan je in de kolom “Role” klikken op de rol en die veranderen, bv naar “Maintainer”.
Nu kan hij “push” naar “main” doen.

Access denied

git clone https://gitlab.com/devgroep/myprojectterminal.git
Cloning into ‘myprojectterminal’…
Username for ‘https://gitlab.com’: mijngebruiker
Password for ‘https://mijngebruiker@gitlab.com’:
remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password. See https://gitlab.com/help/topics/git/troubleshooting_git#error-on-git-fetch-http-basic-access-denied
fatal: Authentication failed for ‘https://gitlab.com/devgroep/myprojectterminal.git/’

Gebruik SSH keys
De site van gitlab legt dat goed uit;

https://docs.gitlab.com/ee/user/ssh.html

Kijk eerst of je al ssh sleutels hebt:

cd ~
cd .ssh/
Als je nog geen .ssh directory hebt, moet je checken of ssh geînstalleerd is, en/of genereer de ssh keys:

ssh-keygen -t ed25519 -C "mijngitlabaccountnaam"

Bij de vraag waar de key bewaren kan je normaal bevestigen:

Enter file in which to save the key (/home/user/.ssh/id_ed25519):

Als de .ssh map nog niet bestond, zal die nu gemaakt worden (geeft melding).

Nog wat bevestigen, en daarna vind je twee (nieuwe) bestanden, waarvan 1 de publieke sleutel is (die eindigt op .pub); en je kreeg ook wat randomart te zien…

The key’s randomart image is:

De inhoud van het pub bestand, inclusief opmerking, kopieren in de gitlab site bij je avatar, “edit profile, linkse kolom ssh keys”.. Add new key ..

De geldigheid kan je instellen als je wil.

Je ziet daarna dat de key is toegevoegd in je lijstje op https://gitlab.com/-/user_settings/ssh_keys

Nu vraagt git nog altijd mijn username en wachtwoord, maar nadien werkt bv het clonen wel.

Clean?
Een “cleane worktree” is je worktree na een commit/push of na een clone of pull.
Je ziet dat aan git status.

Dirty?
Vanaf je iets gewijzigd hebt, is het een “dirty worktree”, de toestand is “bezoedeld” door wijzigingen die nog nergens geregistreerd zijn.

Multiple?
Werken aan twee branches TEGELIJK.
(normaal schakel je om met git checkout branch1, hackhackhack, get stash, git checkout branch2, hackhackhack, git commit+push, git checkout branch1 ….)

Als je aan twee branches tegelijk wil werken kan je in een andere directory terug een clone doen van het project. Dan zit je met veel dubbele code, en moet je telkens beiden syncen. Je kan het Git zelf laten doen met git worktree, dan heb je minder ruimte nodig op de harde schijf, en verloopt het synchroon houden ook automatisch:
Bv: op een Raspberry Pi een “legacy” versie van software vergelijken met de huidige universele (die evolueert).

git worktree list
git worktree add MijnNieuweWerkboom *
en als je er mee klaar bent:
git worktree remove MijnNieuweWerkboom

Goede uitleg van het principe op https://tecadmin.net/git-worktrees-parallel-development-guide/
https://devdynamics.ai/blog/understanding-git-worktree-to-fast-track-software-development-process/

Eens die worktree gemaakt, zie je in je projectmap een map met de naam van de nieuwe worktree. En daarin staan terug dezelfde files als je al had in de directory erboven. Oei, dat was niet de bedoeling, die map hier in mijn projectcode te hebben.
(*) Belangrijk is om de directory op te geven waar die nieuwe worktree moet gezet worden bij git worktree add:

git worktree add ./../MijnNieuweWerkboom
of
git worktree add /home/username/directoryEtc

Terug verwijderen:
git worktree remove MijnNieuweWerkboom
git prune

git worktree add ./../MijnNieuweWerkboom
dan met
cd ..
cd MijnNieuweWerkboom
git status
git worktree list

Ik heb twee situaties gehad, de eerste was:
-1 In die directory zie ik een branch met de naam MijnNieuweWerkboom, terwijl ik die niet expliciet heb aangemaakt.

Normaal geef je als parameter een bestaande branch op (denk ik).

git worktree add ./../MijnNieuweWerkboom bestaandeBranch
(branch die ik daar wil om parrallel in te werken)
of
git worktree add /home/username/directoryEtc bestaandeBranch

-2 ik kreeg een foutmelding “invalid reference: bestaandeBranch”; misschien bestond die niet of had ik hem verkeerd geschreven.

-3: fatal: “.. is already checkout out at ..”
Dat is eigenlijk wel zo… Ik kon dit oplossen door eerst een andere branch aktief te maken:
git checkout otherbranch
git worktree add ../MijnNieuweWerkboom bestaandeBranch

.. preparing …
HEAD is now at .. (shows comment of commit)

Bij geval 1: In Gambas is de naam van de map ook de naam van het project, dus dat is nu plots ook veranderd.

Hmm, nog niet goed? Je kan bij het maken van een worktree (blijkbaar/soms) ook de naam van de nieuwe branch meegeven, verschillend van eender welke bestaande.

In mijn geval is het nu niet zo erg, je moet eventueel een nieuw configuratiebestand aanmaken, of het bestaande kopieren. Hierdoor kan je ze ook uit elkaar houden (bv voor de executable; handig dat de naam anders is).

---

Stash
git stash kan heel interessant zijn: je bewaart alleen je huidige veranderingen.

VRAAG: Dus als je twee gelijkaardige projecten hebt die enkel een beetje verschillen, maar die verschillen moeten blijven bestaan, dan kan je met stash je nieuwe werk bewaren (dat dan niet over die specifieke verschillen mag gaan), en die “toepassen” op eender welke andere branch, of je eigen branch als je dat nog niet gedaan had en toch was uitgecheckt.

hackhackhack
git stash wijzigingen op de LIFO
git stash show
git stash apply (laatste toepassen) —-> this you can do on another commit; how?
git stash drop (laatste verwijderen)
git stash pop = apply + drop
git stash list
git stash clear (leegmaken)

git stash pop, ofwel git pop 0 (voor de laatste) git pop 1=voorlaatste enz. past de laatste stash to op de huidige worktree, en gooit hem daarna weg.

om “een stash” te verwijderen uit de “git stash list” doe je git stash drop i

Nu nog uitzoeken hoe ik een stash toepas op .. bv een ander worktree?

---

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – git worktree – GitLab vb – SourceForge vb – git en gambas)

In principe ga je in de ontvangende tak staan (git checkout achtergeblevenbranch)
En merge je een andere naar je toe (git merge voorlopendebranch)

Eenvoudige merges, samenvoegen van iets dat verder voorop is en eenvoudig toegevoegd wordt aan een achtergebleven tak, is gemakkelijk te begrijpen, maar soms is het ingewikkelder.

git merge [-n] [–stat] [–no-commit] [–squash] [–[no-]edit]
[–no-verify] [-s ] [-X ] [-S[]]
[–[no-]allow-unrelated-histories]
[–[no-]rerere-autoupdate] [-m ] [-F ]
[–into-name ] […​]
git merge (–continue | –abort | –quit)

merge strategiën
De verschillende merge “strategies” zijn recursive, resolve, octopus, ours, subtree

Je kan zelf de merge strategy opgeven met een parameter:
(ook bij git pull trouwens)

git merge -s recursive tak1 tak2

git merge -s resolve tak1 tak2

git merge -s octopus tak1 tak2 tak3 .. takn

git merge -s ours tak1 tak2 .. takn

git merge -s subtree takA takB

Type van strategie

– Expliciet
Dit is de standaard merge methode. Het betekent dat er een nieuwe “merge commit” gemaakt wordt. Dit toont waar de merge werd gedaan in de merge geschiedenis, en dat is niet altijd gewenst (omdat het de aandacht afleidt, ruis dus). Als je deze details niet in je merge history wil, zal je misschien explicit merge vermijden.

– Impliciet
Impliciete merge via rebase of fast-forward merge

– Squash
Squash on merge, meestal zonder expliciete merge

Recursive merge strategy options

ours, theirs, patience, diff-algorithim, ignore, renormalize (no-normalize, no-renames), find-renames=n, subtree

Er zijn veel mogelijkheden, en hoe moet je kiezen wat te gebruiken alvorens je ze doorgrondt?

Een merge van twee branches (dev-hq en roadie) gedaan die verkeerd afloopt, bv omdat de versies meer verschilden dan je dacht (op beide was een stukje ontwikkeling gedaan ipv op één van beiden)? Je kan correcties gaan doen in de broncode, die door git voorzien is van merktekens als

< <<<< HEAD
======
>>>>>>> roadie

.. met daartussen brokken tekst van de verschillende versies.
Soms is het duidelijk, een klein verschil kan een eenvoudige correctie zijn, of een uitbreiding van een string of een commentaar. Dan kan je die onmiddellijk verbeteren met een .txt editor (zelfs buiten de normale programmeeromgeving).

Maar als de verschillen te groot zijn en/of je er niet aanuit kan, wil je misschien de “merge” operatie herstellen naar de toestand voordien.

Zolang je het conflict niet opgelost hebt, en niets kon pushen, niet gecomit hebt, kan je nog altijd terug met :

git merge --abort

Je kan info krijgen van git:

git reflog

Als je terug wil gaan naar de laatste gemeenschappelijke toestand, kan je die vinden met:

$ git merge-base dev-hq roadie
806f8ac3c61b1e55cdd5b53a0205b51d1d31387a

Dan kan je terug naar die toestand met

git reset 806f8ac3c61b1e55cdd5b53a0205b51d1d31387a

Unstaged changes after reset:
M .src/FConfigure.class
M .src/FConfigure.form

Om hem online te krijgen volstaat een gewone git push niet:

git push
To gitlab.com:stockpi/stockpiapp.git
! [rejected] dev-hq -> dev-hq (non-fast-forward)
error: failed to push some refs to ‘gitlab.com:stockpi/stockpiapp.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.

git push --force

git push –force
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for dev-hq, visit:
remote: https://gitlab.com/stockpi/stockpiapp/-/merge_requests/new?merge_request%5Bsource_branch%5D=dev-hq
remote:
To gitlab.com:stockpi/stockpiapp.git
+ 8a060eb…806f8ac dev-hq -> dev-hq (forced update)

(zie bv https://www.atlassian.com/git/tutorials/undoing-changes/git-reset)
Julia Evans: “git rebase: what can go wrong?”

Binnen een branch kan je kijken met git log, maar als je een overzicht wil over alle branches…

Lijst van alle branches met laatste commit bericht:
git branch -v

Gesorteerd op datum (maar zonder die weer te geven)

git branch -v --sort=committerdate

Alle, inclusief remote:
git branch -v --sort=committerdate

git for-each-ref --sort='-committerdate:iso8601' --format='%(committerdate:relative)|%(refname:short)|%(committername)' refs/remotes/ | column -s '|' -t


2 months ago           origin/HEAD               matty
2 months ago           origin/master             matty
2 months ago           origin/test               matty
3 months ago           origin/feat-Day           matty
6 months ago           origin/integrate-lib      matty
3 years, 7 months ago  origin/feat-Fact       cybrarian

git for-each-ref --sort=-committerdate refs/heads/ --format='%(committerdate:short) %(authorname) %(refname:short)'

2022-02-11 cyb master
2022-02-11 cyb test
2022-02-09 cyb feat-DayAdd
2021-12-08 cyb fixMissingDayTypeDispl

git for-each-ref --sort=committerdate refs/heads/ --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(authorname) (%(color:green)%(committerdate:relative)%(color:reset))'

 fixMissingDayTypeDispl - a493cbe - FDayReq: fix missing daytype display - mat.ara (2 months ago)
* feat-DayAdd - dea7f5e - gitignore err - cyb (9 days ago)
  test - a94611e - merge test ie FMain.class - cyb (7 days ago)
  master - 33ac1e2 - fix Changes.txt  - cyb (7 days ago)

Met de datum ervoor:

git for-each-ref --sort=-committerdate refs/heads/ --format='%(authordate:short) %(color:red)%(objectname:short) %(color:yellow)%(refname:short)%(color:reset) (%(color:green)%(committerdate:relative)%(color:reset))'

Deze is ook mooi:

git branch -vv --color=always | while read; do echo -e $(git log -1 --format=%ci $(echo "_$REPLY" | awk '{print $2}' | perl -pe 's/\e\[?.*?[\@-~]//g') 2> /dev/null || git log -1 --format=%ci)" $REPLY"; done | sort -r | cut -d ' ' -f -1,4-

2022-02-11   master                 33ac1e2 [origin/master] fix Changes.txt for merge
2022-02-11   test                   a94611e [origin/test] fix merge test FMain.class
2022-02-09 * feat-DayAdd            dea7f5e [origin/feat-DayAdd] gitignore 
2021-12-08   fixMissingDayTypeDispl a493cbe FDayReq: fix missing daytype display

Of maak een alias…

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – GitLab vb – SourceForge vb – git en gambas)

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – stash – GitLab vb – SourceForge vb – git en gambas)

Undo
Wijzigingen niet bewaren (die niet toegevoegd waren – ‘not staged’) en terugkeren naar de laatste goede toestand van de bestanden in je directory:

– git reset --hard
Alle wijzigingen weggooien en terug beginnen met de vorige toestand van je ontwikkeltak.

– git checkout -- vuilbestand
Eén bestand terugdraaien naar de laatste normale toestand van voor je (klad)werk.
Een typisch voorbeeld is een .settings bestand dat kan reageren op het starten van een programma; bv omdat het een teller bevat, of de laatste toestand van schermen of geopende documenten bijhoudt of zo.

– git stash
Dit laat je toe de wijzigingen niet op te nemen in je programmeervoortgang, maar toch ook niet helemaal definitief weg te gooien; je zet ze opzij om voort te kunnen met je normale ontwikkeling.
Daarbij hoort nog:
git stash list : lijst van stash-items in tijdelijke editor (q=quit).
git stash show : diff
git stash apply : toepassen van deze stash op huidig werk.
git stash pop: toepassen van deze stash op huidig werk en uit stash halen.

Zie ook stash

Ik zit ijverig te werken en nadien zie ik dat ik in de master branch bezig ben ipv de dev branch.
Ik heb nog geen git add of commit gedaan.
(in git status zie ik modified: BestandWaaraanIkBezigWas.class )
Ik kan natuurlijk alles weggooien en de master terugzetten op een vorig punt.

Maar ik wil de wijzigingen wel bijhouden, en ik wil die in de dev krijgen.

De aanbevelingen die ik lees gaan ongeveer zo:
– maak een nieuwe branch vanuit die master die je gewijzigd hebt (maar nog niet ge-commit), geef hem een tijdelijk naam bv tempdev.
git checkout -b tempdev
Switched to a new branch ‘tempdev’

– voeg eventueel nieuwe bestanden toe (niet nodig als je alleen “modified” hebt), en commit al je werk:
git add .
git commit -m "some new work"

Als ik nu terug ga (git checkout master) en daar git status vraag, geeft die geen modified bestanden meer.

– check of je de dev branch hebt:
git branch -l
master
* tempdev

Als je de dev branch niet hebt, kijken of hij er remote wel is:
git branch -lr (opgelet dit kan een vertekend beeld geven als die recent is bijgemaakt en je niet hebt bijgewerkt met fetch…)

origin/HEAD -> origin/master
origin/master

Of git branch -a om beiden te zien.

Dus eerst synchroniseren met online:
git fetch

remote: Enumerating objects: 32, done.
remote: Counting objects: 100% (28/28), done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 16 (delta 12), reused 0 (delta 0)
Unpacking objects: 100% (16/16), done.
From git://git.code.sf.net/p/myproject/code
* [new branch] dev -> origin/dev
0c4e870..b8c15dc master -> origin/master

git branch -rl
origin/HEAD -> origin/master
origin/dev
origin/master
Beter!
– schakel naar dev branch en merge die met devtemp (importeert de devtemp wijzigingen).
git checkout dev
git merge tempdev
– commit en push zodat de (online) “remote” dev branch is bijgewerkt.
– schakel naar die je master en reset hem naar de laatste versie (van remote halen dus? Nee gebeurt lokaal): git reset --hard HEAD.

Stash
Misschien korter/handiger: gebruik “stash”, dat de wijzigingen lokaal even opzij zet (om ze al dan niet nadien toe te passen):

git stash
git checkout dev
git stash apply

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – GitLab vb – SourceForge vb – git en gambas)

(in de reeks Git…)

Zien
Online (in de web interface) zie ik de branches:

• master
• test
• issue1

Maar lokaal zie ik alleen mijn eigen master (sic!):

git branch -l
* master

Ook na een git fetch blijft dat zo.

Git fetch heeft een standaardgedrag of volgt instellingen, maar je kan meer specifiek git fetch origin doen:

~/Git/TrypoPrj/TrypoPrj> git fetch origin
~/Git/TrypoPrj/TrypoPrj> git branch -l
* master

Bovendien moet je eigenlijk –list gebruiken (-l dient om een reflog aan te maken), en toont git branch –list enkel de lokale branches. Maar

git branch -r

origin/HEAD -> origin/master
origin/feat-01
origin/master
origin/test


toont de remote, of wil je alles:

git branch -a

* master
remotes/origin/HEAD -> origin/master
remotes/origin/feat-01
remotes/origin/master
remotes/origin/test

met extra info als laatste commit message:

git branch -v -a

* master 8ab6216 [ahead 1] remove .directory from tracked files
remotes/origin/HEAD -> origin/master
remotes/origin/feat01 2bbd368 Complete changes.txt with done work
remotes/origin/master de381ad Resolve merge conflict by combine and reorder lines in changes.txt

Afhalen
Als je een branch van remote wil halen kan je die opgeven

git fetch origin
of
git fetch origin branch-naam
Daarna bv merge in je eigen (bv master) en commit:

git merge origin/branch-naam
git commit ...

Of:
– check met git branch -la
– indien ok, git checkout WantedBranch
(gewoon met de naam, paar letters en gebruik TAB om aan te vullen)
Reaktie:

Branch WantedBranch set up to track remote branch WantedBranch from origin.
Switched to a new branch 'WantedBranch'

upd 2020-11-18

Een lokale branch ook remote maken

Situatie: ik heb een lokale “develop” branch en wil iemand mee laten ontwikkelen (of zelf vanop een andere plaats/toestel).

Er is een master branch, en de andere gebruiker ziet die:
De andere gebruiker heeft alleen de master:

git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
.
git pull
Already up to date.


Ik heb die ook, plus een develop, waarin ik aktief ben.

cybrarian@copylefthost:~/Gb3Prj/MyProject/ControlPanel> git status
On branch develop
nothing to commit, working tree clean
cybrarian@copylefthost:~/Gb3Prj/MyProject/ControlPanel> git push
fatal: The current branch develop has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin develop
cybrarian@copylefthost:~/Gb3Prj/MyProject/ControlPanel> git branch -r --list
origin/master
cybrarian@copylefthost:~/Gb3Prj/MyProject/ControlPanel> git push --set-upstream origin develop
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: To create a merge request for develop, visit:
remote: https://gitlab.com/cybrarian.copyleft/ControlPanel/-/merge_requests/new?merge_request%5Bsource_branch%5D=develop
remote:
To gitlab.com:cybrarian.copyleft/ControlPanel.git
* [new branch] develop -> develop
Branch develop set up to track remote branch develop from origin.

Nu kan de andere gebruiker:
.
git pull
From gitlab.com:cybrarian.copyleft/ControlPanel
* [new branch] develop -> origin/develop
Already up to date.

De andere gebruiker kan nu ook mee aan de slag…
(mits hij de juiste rechten heeft – bv gitlab “maintainer”)

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – GitLab vb – SourceForge vb – git en gambas)

(in de reeks Git…)

Hoewel ik .settings heb toegevoegd tot gitignore, blijft het af en toe opduiken als gewijzigd bestand, klaar om mee te committen. Ik begrijp niet of het komt door merge met andere medewerkers die misschien een andere instelling hebben (hoewel ik dacht dat die lokaal was).

Oorzaak is bv dat het bestand oorspronkelijk niet in gitignore zat, en er pas later is aan toegevoeg, toen het al getracked werd. En .gitignore werkt alleen voor “untracked” files (voor nieuwe bestanden dus).

Er is een extraatje nodig (how to make git forget..):

git update-index --assume-unchanged

git update-index --assume-unchanged .settings

Je krijgt geen feedback na dit commando.

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – GitLab vb – SourceForge vb – git en gambas)

SourceForge (https://sourceforge.net/) was in de open source en free softwarewereld zowat de eerste, grootste en bekendste website voor het online houden van een open source of free software project. Je kon de broncode gewoon uploaden als .tar.gz bestanden, of het Code Versioning System gebruiken (cvs), naast de vele project-tools voor opvolging van bugs, communicatie enz. (zie 2009)

SourceForge heeft achtergrond in VA Software (denk ook aan VA Linux, Geeknet, enz), ondertussen horen ze bij Slashdot media.
Het traject van de zoektocht naar rendabiliteit en de overnames deed Sourceforge geen goed en zaaide twijfel bij developers.
Heel wat nieuwe projecten gingen naar GitHub, (en meer recent GitLab), die specifiek gericht waren op het ondertussen in de FOSS wereld populaire geworden git-broncodebeheersysteem.

Maar ondertussen biedt SourceForge ook Git aan. Sinds januari 2018 promoten ze het aktief met een importeer-tool om GitHub projecten over te zetten naar SourceForge.
https://sourceforge.net/blog/introducing-the-new-sourceforge/

Wie al op Sourceforge zit kan zijn project beginnen beheren met git: https://sourceforge.net/p/forge/documentation/Git/

Om gemakkelijk te communiceren met de sourceforge repository is het best om een public key/private key communicatie op te zetten. Daarvoor moet je een “key” hebben, die je maakt met ssh-keygen.
Daarna moet je de projectdirectory initialiseren voor gebruik met git. En dan moet je je startcode “uploaden”, in git-terminologie comit-en en push-en.

1. Keys

1.1 keys maken:

De handleiding van sourceforge zegt:

ssh-keygen -t ed25519 -C “gebruikersnaam@shell.sf.net”

De plaats waar je dit doet is eender (bv kan je al in de projectdirectory staan).
De gebruikersnaam is die van je login, niet de weergegeven naam!
Na het commando krijg je de vraag in welk bestand de key bewaard mag worden, je kan het voorstel gewoon bevestigen.
Daarna kan je een wachtwoord ingeven (veiliger), wat je moet heringeven om te bevestigen.
Het eindigt met de plaatsen waar je identificatie en je public key bewaard werden*, en met je fingerprint.
Daaronder komt een beetje “ascii-art” met je randomart image.
* Je kan je instellingen checken in de bestanden:
private key: /home/usernaam/.ssh/id_ed25519 (deze moet je geheim houden!)
public key: /home/usernaam/.ssh/id_ed25519.pub (deze moet je meedelen)

1.2 keys registreren

Log in op SF en ga naar:
https://sourceforge.net/auth/shell_services
Daar plak je de inhoud van je .pub bestand.

2. Projectdirectory

De directory die je wil opnemen in het git beheer moet je initialiseren voor git gebruik.
Ga in de directory staan (cd projectdir), en check git:

git status
Als je … krijgt is er al een git repository van gemaakt!
Als er nog geen git initialisatie gebeurd is op deze directory krijg je een melding als:

fatal: Not a git repository

…(enz)

Tik het initialisatiecommando dat de nodige subdirectories en bestanden maakt:
init git

Initialised empty Git repository in …

Opgelet! Nu zijn er een aantal (onzichtbare) directories/bestanden bijgekomen voor git, gebruik deze projectdirectory niet meer om op een andere manier te kopiëren als project sourcecode, want hij is “vervuild” met git.

3. Stel de bron in

Als de broncode nog niet in de directory staat, kopieer je die ernaartoe. Ze vormen de verzameling van alle onderdelen die je nodig hebt om een programma te kunnen compileren.
Met git status toont git wat het daar ziet.

Je stelt ook de bestanden in die NIET naar de git-server moeten, omdat ze enkel lokaal nut of belang hebben (bv lokale instellingen van de programmeeromgeving), of omdat ze prive-informatie bevatten.
Maak daarvoor een bestand .gitignore in de projectdirectory.

git rm --chached (file) om iets wat er per vergissing toch is terechtgekomen; check met git status.

git commit -am ‘initial commit at version 0.1.5’

Je krijgt de melding dat een ‘standaard’ e-mail adres gebruikt is; je kan het instellen met:

git config --global --edit

pas aan, bewaar (standaard met ESC :w en :q), en daarna fix de identiteit die gebruikt werd met:

git commit --amend --reset-author

Je krijgt dan een tekst te zien (waarin je bv het e-mail adres kan verbeteren, dacht ik, maar dat blijkt achteraf niet met git log**); ook weer ESC :wq om te bewaren en verlaten.

4. Stel de server in

Nu moet je een verbinding instellen met de server, waar de broncode naartoe moet.

git remote add origin ssh://login@git.code.sf.net/p/gitin/code

(met je eigen login natuurlijk; de username).

En dan de eigenlijke “upload”:

git push -u origin master
Er wordt een bevestiging gevraagd van de git.code.sf.net server (met ip)
Die wordt dan toegevoegd aan de “known hosts”.
Daarna moet je je wachtwoord ingeven (dat van de ssh key).

Met wat geluk eindigt alles met:

Branch master set up to track remote branch master from origin.

Nu kan je via de website het resultaat zien onder het tabblad “code”:
https://sourceforge.net/p/projectname/code/

De projectdirectory is volledig te “browsen”!
Onderaan verschijnt de inhoud van het readme.txt bestand.

Zeer handig is de kolom “Commit”, want daar verschijnt de commit message, en je kan daarmee snel zien wat de laatste verandering is in een directory of bestand.

---

**)
Je moet eerst expliciet de gegevens instellen, bv het e-mail adres wordt afgeleid uit je username en je hostname, dus je krijgt username@host, en dat kan bv de lokale hostname van je pc zijn.

Je moet dan eerst expliciet de username of het e-mail adres instellen:

git config --global user.name "gebruikersnaam"
git config --global user.email "user@domein.abc"

5. Gebruik.

– Code

git commit -am 'initial commit at v.0.1.3'

Nadat van een project de originele code naar de server geladen is, wordt ze zichtbaar in de “code” tab van de Sourceforge website, bv als:

Tree[987456] master/

Op die pagina krijg je ook de commando’s aangeboden die je nodig hebt om ssh/https/RO (read-only) toegang te krijgen.

– Clone

RO is genoeg om het project af te halen:

git clone git://git.code.sf.net/p/projectnaam/code projectnaam-code

Dit maakt een lokale directory projectnaam-code, verwijzend naar de structuur op de server (beetje verschillend van GitLab).

Om ook schrijftoegang te hebben moeten eventueel de rechten aangepast worden door de admin van het project, en moet je één van de voorgestelde read/write commando’s geven.

git branch --list toont: “* master”

fatal: remote error: access denied or repository not exported…

Als je oorspronkelijk enkel read-access hebt gevraagd (bij project clone), kan je nadien de instellingen aanpassen in het .git/config bestand. Volgens de documentatie:

git://PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME (read-only)
ssh://USERNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME (read/write)

Bij mij zag het er iets anders uit:

url = git://git.code.sf.net/p/projectnaam/code

url = ssh://USERNAME@git.code.sf.net/p/projectnaam/code

Zoek de regel die begint met git:// en verander hem naar ssh:// waarbij je “USERNAME@” toevoegt (maar dan je echte loginnaam natuurlijk).