GitLab mysterie

[RoyTrenneman]

Ik ben een beginner als het gaat om het gebruik van Git, maar moet mij dit nu eigen maken.

Ik was vandaag aan het spelen met Git en Gitlab, maar heb erg zitten stoeien om uiteindelijk mijn bestanden te kunnen pushen.

Wat ik deed:

* Project aangemaakt in GitLab
* Map aangemaakt lokaal met wat bestanden

code:

git init

code:

git add .

code:

git commit -m "<commit message>"

code:

git remote add origin https://gitlab.com/<user>/<project>.git

code:

git push -u origin main

Dit resulteerde in het volgende resultaat:

code:

$ git push -uf origin main
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 230 bytes | 230.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: GitLab: You are not allowed to force push code to a protected branch on
this project.
To https://gitlab.com/<user>/<project>.git
 ! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to 'https://gitlab.com/<user>/<project>.git'

Uiteindelijk heb ik een workaround gevonden door een andere branch (master) aan te maken en deze als default branch in te stellen en de main branch te verwijderen (deze kon ik ook behouden).

Maar dat maakt nog niet dat ik begrijp waarom ik niet kon pushed naar de main branch toen de default was, maar wel maar master branch nadat deze default was.

Iemand een verklaring?

[Opifex]

Doorgaan is rechtstreeks pushen naar master/main bad practice. De filosofie is dat je naar een featurebranch pusht en dan een Pull Request opent. Vandaar dat Gitlab main/master automatisch als "protected" zet.

Als je dit wil uitschakelen kan dat onder Settings --> Repository --> Protected branches.

[ Voor 8% gewijzigd door Opifex op 26-06-2023 21:51 ]

[Barryvdh]

Waarschijnlijk heb je de branch protected gemaakt, of was dat de default?

Ik gebruik zelf geen Gitlab, maar bij Bitbucket kan je op basis van branch naam instellen welke branches protected zijn, niet of hij wel/niet default is.

Normaal gesproken wordt dat gedaan zodat je een Pull Request kan maken, pipelines kan draaien met test/review foreceren, en daarna pas mergen.

[Oon]

Om je ook daadwerkelijk te laten zien waaraan je de al gesuggereerde conclusie zou kunnen trekken:

code:

 ! [remote rejected] main -> main (pre-receive hook declined)

Het is de remote die je commit geweigerd heeft, in de pre-receive hook. In de meeste gevallen betekent dit dat jouw gebruiker geen rechten heeft om data überhaupt te sturen, dus of een protected branch waar je niet heen mag pushen of een repo waar je geen rechten op hebt.

Daarmee kun je dus al concluderen dat het probleem aan de kant van Gitlab zit. Omdat je wel netjes een error krijgt van een git hook (pre-receive in dit geval) en geen auth error oid kun je ook concluderen dat je wél rechten hebt om met gitlab.com te verbinden.

Dus de enige opties die dan over blijven zijn dat je of de verkeerde repo hebt gepakt (dus <user> of <project> is fout), of dat je in het geval dat die correct zijn en dat je eigen repo hebt, de main branch als protected hebt aangemerkt (of dat dat de standaardoptie is van Gitlab).

[jeroen3]

Je hebt waarschijnlijk een git repository met een template readme aangemaakt online.
Dat betekent dat er al een initial commit is die je lokaal niet hebt.
Die probeer je te overschrijven, en dat mag standaard niet.

Doe even een

code:

git pull

, dan download hij de commit met de readme.md file en werkt je push wel.

Of, slecht advies, zet in de settings->repository tijdelijk force push naar main even aan. En gebruik

code:

git push --force -u origin

Hoe voorkom je dit de volgende keer?
Maak de repository leeg aan. Die keuze krijg je.

[ Voor 16% gewijzigd door jeroen3 op 26-06-2023 22:02 . Reden: hoe te voorkomen ]

[Opifex]

jeroen3 schreef op maandag 26 juni 2023 @ 21:58:
Je hebt waarschijnlijk een git repository met een template readme aangemaakt online.
Dat betekent dat er al een initial commit is die je lokaal niet hebt.
Die probeer je te overschrijven, en dat mag standaard niet.

Zou je dan geen andere error moeten zien?
Iets in de trend van...

Updates were rejected because the tip of your current branch is behind its remote counterpart.

?

[RoyTrenneman]

Opifex schreef op maandag 26 juni 2023 @ 21:49:
Doorgaan is rechtstreeks pushen naar master/main bad practice. De filosofie is dat je naar een featurebranch pusht en dan een Pull Request opent. Vandaar dat Gitlab main/master automatisch als "protected" zet.

Als je dit wil uitschakelen kan dat onder Settings --> Repository --> Protected branches.

Roerend eens, maar het ging nu om te leren werken met Git en Gitlab.
In werkelijkheid zou ik inderdaad een feature branche aanmaken en een merge request doen naar de main / master branch

Barryvdh schreef op maandag 26 juni 2023 @ 21:49:
Waarschijnlijk heb je de branch protected gemaakt, of was dat de default?

De branch was default protected.

Oon schreef op maandag 26 juni 2023 @ 21:57:
Om je ook daadwerkelijk te laten zien waaraan je de al gesuggereerde conclusie zou kunnen trekken:

code:

 ! [remote rejected] main -> main (pre-receive hook declined)

Het is de remote die je commit geweigerd heeft, in de pre-receive hook. In de meeste gevallen betekent dit dat jouw gebruiker geen rechten heeft om data überhaupt te sturen, dus of een protected branch waar je niet heen mag pushen of een repo waar je geen rechten op hebt.

Daarmee kun je dus al concluderen dat het probleem aan de kant van Gitlab zit. Omdat je wel netjes een error krijgt van een git hook (pre-receive in dit geval) en geen auth error oid kun je ook concluderen dat je wél rechten hebt om met gitlab.com te verbinden.

Dus de enige opties die dan over blijven zijn dat je of de verkeerde repo hebt gepakt (dus <user> of <project> is fout), of dat je in het geval dat die correct zijn en dat je eigen repo hebt, de main branch als protected hebt aangemerkt (of dat dat de standaardoptie is van Gitlab).

Ik ben te groen om dit goed te analyseren, ook met een beetje zoeken kwam ik er niet uit.

De main branch is inderdaad protected, maar het gekke blijft, dan als ik een master branch aanmaak en deze instel als default, dan lijkt deze ook protected.

jeroen3 schreef op maandag 26 juni 2023 @ 21:58:
Je hebt waarschijnlijk een git repository met een template readme aangemaakt online.
Dat betekent dat er al een initial commit is die je lokaal niet hebt.
Die probeer je te overschrijven, en dat mag standaard niet.

Doe even een

code:

git pull

, dan download hij de commit met de readme.md file en werkt je push wel.

Of, slecht advies, zet in de settings->repository tijdelijk force push naar main even aan. En gebruik

code:

git push --force -u origin

Hoe voorkom je dit de volgende keer?
Maak de repository leeg aan. Die keuze krijg je.

Bedankt. Bij de eerste oefening had ik inderdaad een readme aangemaakt, maar bij de tweede oefening niet, maar het resultaat was gelijk.

Ik ga morgen eens verder stoeien met jouw scenario's.

To be continued...

[jeroen3]

@Opifex Nee. Daarvoor moet je eerst een fetch hebben gedaan, en dan nog geeft hij dat als hints, en die zie ik niet staan. Staan uit denk ik? Welke versie van git heb je? (git --version)

Standaard force-push uit op master/main is goed.

Helemaal overheen gekeken...

code:

git push -uf origin main

Die F in -uf moet weg....

offtopic:
Als je net begint met git, gebruik een tool zoals sourcetree of gitkraken. Maakt je leven zo veel simpeler.

[ Voor 18% gewijzigd door jeroen3 op 26-06-2023 22:32 ]

[BCC]

Dit is een known issue op gitlab, het is echt heel onvriendelijk voor nieuwe mensen imho en als je niet genoeg rechten hebt is het soms zelfs onoplosbaar.

[Opifex]

Onoplosbaar? Volgens mij maken jullie het veel moeilijker dan het is hoor...

[RobIII]

Opifex schreef op dinsdag 27 juni 2023 @ 00:38:
Onoplosbaar? Volgens mij maken jullie het veel moeilijker dan het is hoor...

[Afbeelding]

Dat kun je alleen doen bij een bestaande repository Als je een nieuwe repo pushed heb je die settings nog niet he? Beetje kip-ei verhaal. En dan is 't dus voor meeste mensen die een tutorial volgen die alles in de terminal doet niet altijd duidelijk wat er precies aan de hand is exact wat hier aan de orde is*.

* Ik zie net dat TS wél eerst een repo ("project") heeft aangemaakt.

[ Voor 18% gewijzigd door RobIII op 27-06-2023 03:10 ]

[Opifex]

RobIII schreef op dinsdag 27 juni 2023 @ 00:51:
[...]

Dat kun je alleen doen bij een bestaande repository Als je een nieuwe repo pushed heb je die settings nog niet he? Beetje kip-ei verhaal. En dan is 't dus voor meeste mensen die een tutorial volgen die alles in de terminal doet niet altijd duidelijk wat er precies aan de hand is; exact wat hier aan de orde is.

Kan zijn dat ik fout ben, want ik gebruik Gitlab eigenlijk nooit, maar... volgens mij kan je helemaal niet zomaar naar gitlab pushen, zonder dat je eerst een repo aanmaakt via de GUI? Of kan dat wel? (Heb dat nog nooit gedaan alleszins)

De meesten die hier reageerden volgden overigens geen tutorial volgens mij, maar zijn eerder al bedreven in Git-toestanden.

[CyBeR]

Je moet inderdaad eerst een repo aanmaken. Daarbij heb je de optie, die default aan staat, om de repo te initialiseren met een README file. Dat is waarschijnlijk het probleem, want als je dan een los geinitialiseerde repo probeert te pushen naar de repo op gitlab (je hebt nu dus feitelijk twee repo's, met verschillende inhoud) dan kan dat alleen met een force push en dat wordt default ook niet toegestaan.

TS kan het beste de gitlab repo weggooien en opnieuw aanmaken zonder de "Initialize repository with a README" optie aan. Waar overigens ook netjes onder staat: "Skip this if you plan to push up an existing repository."

[RobIII]

Opifex schreef op dinsdag 27 juni 2023 @ 02:01:
volgens mij kan je helemaal niet zomaar naar gitlab pushen, zonder dat je eerst een repo aanmaakt via de GUI? Of kan dat wel?

Dat kan wel.

CyBeR schreef op dinsdag 27 juni 2023 @ 02:30:
Je moet inderdaad eerst een repo aanmaken.

Nope.



Et voila.

[ Voor 13% gewijzigd door RobIII op 27-06-2023 03:03 ]

[CyBeR]

RobIII schreef op dinsdag 27 juni 2023 @ 02:55:
[...]

Dat kan wel.


[...]

Nope.

[Afbeelding]

Et voila.

Nieuw voor mij, maar TS zei dat hij het project eerst in gitlab had aangemaakt.

[RobIII]

CyBeR schreef op dinsdag 27 juni 2023 @ 03:11:
[...]


Nieuw voor mij, maar TS zei dat hij het project eerst in gitlab had aangemaakt.

Ja, dat edit ik er net bij; ik had "Project aangemaakt in GitLab" gemist.

Either way: de melding lijkt me vrij duidelijk: "GitLab: You are not allowed to force push code to a protected branch on this project."
Ofwel: je probeert te pushen op een protected branch. Dat heeft volgens mij niks met bestaande README's o.i.d. te maken.

[ Voor 40% gewijzigd door RobIII op 27-06-2023 03:14 ]

[CyBeR]

default is de master branch niet zodanig protected dat je helemaal niet mag pushen, maar alleen dat je niet mag force pushen. En een force push is nodig als je een een repo aan het pushen bent die niet overeen komt met wat er al staat. Normaal doe je dat met --force overigens, ik neem aan dat hier óf git dat automatisch doet want de remote komt niet overeen, óf dat de error message net niet helemaal klopt.

[ Voor 27% gewijzigd door CyBeR op 27-06-2023 03:54 ]

[Merethil]

jeroen3 schreef op maandag 26 juni 2023 @ 22:31:

offtopic:
Als je net begint met git, gebruik een tool zoals sourcetree of gitkraken. Maakt je leven zo veel simpeler.

Het leven wordt simpeler maar je doet er erg weinig kennis van git mee op als het gros van de acties worden weggewerkt achter een paar knopjes. Een aantal van mijn collega's gebruiken sourcetree sinds het begin en snappen niets van git op de CLI waardoor ze nu:

1. Niet snappen hoe bepaalde problemen te fiksen
2. Ze doodleuk hun riedeltje van "pull, doe mijn ding, push" volgen en bij problemen maar opnieuw starten met hun wijziging
3. Ze altijd problemen hebben met het opzetten van bijvoorbeeld een CICD pipeline als er eens iets meer nodig is dan een simpele pull van de laatste commit

Ik vind de GUI's die je kan vinden voor git er mooi uitzien maar ik zou (zeker als je vooral wil leren hoe git werkt) altijd de CLI aanraden voor de meeste acties en de GUI's hoogstens gebruiken voor visualisatie.

[jeroen3]

@Merethil Ja


Als je wilt weten hoe git werkt is zijn op youtube een uitstekende videos die uitleggen hoe git onder water in elkaar zit en als je dat weet dan is het ineens logisch. Maar die video duurt lang en daar heeft niemand geduld voor tegenwoordig.
Er zijn ook veel tutorials die je een kunstje aanleren, maar daar heb je volgens mij weinig aan.

[RoyTrenneman]

Merethil schreef op dinsdag 27 juni 2023 @ 04:18:
[...]


Het leven wordt simpeler maar je doet er erg weinig kennis van git mee op als het gros van de acties worden weggewerkt achter een paar knopjes. Een aantal van mijn collega's gebruiken sourcetree sinds het begin en snappen niets van git op de CLI waardoor ze nu:

1. Niet snappen hoe bepaalde problemen te fiksen
2. Ze doodleuk hun riedeltje van "pull, doe mijn ding, push" volgen en bij problemen maar opnieuw starten met hun wijziging
3. Ze altijd problemen hebben met het opzetten van bijvoorbeeld een CICD pipeline als er eens iets meer nodig is dan een simpele pull van de laatste commit

Ik vind de GUI's die je kan vinden voor git er mooi uitzien maar ik zou (zeker als je vooral wil leren hoe git werkt) altijd de CLI aanraden voor de meeste acties en de GUI's hoogstens gebruiken voor visualisatie.

Vandaag nog even verder knoeien, om het beter te snappen allemaal. Het is helder wat ik moet doen om te snappen hoe ik het mis laat gaan en dus ook

Vwb. de GUI client; initieel werd ik door een collega naar Fork gedirigeerd, maar ik zoals hier genoemd, ik vind de client niet intuïtief, en heb geen idee wat ik aan het doen was.

Dus YouTube to the rescue en een GIT voor Dummies gekeken en dat maakte heel veel duidelijk. Ook werd het voorbeeld gegeven met de CLI (en GitHub) en ben ik hier verder meegegaan en vind ik dit intuïtiever dan de GUI, al zijn niet alle foutmeldingen even duidelijk (voor mij) of goed op te zoeken en dan is het Tweakersforum wel weer fijn om verder te komen.

[Oon]

Merethil schreef op dinsdag 27 juni 2023 @ 04:18:
[...]


Het leven wordt simpeler maar je doet er erg weinig kennis van git mee op als het gros van de acties worden weggewerkt achter een paar knopjes. Een aantal van mijn collega's gebruiken sourcetree sinds het begin en snappen niets van git op de CLI waardoor ze nu:

1. Niet snappen hoe bepaalde problemen te fiksen
2. Ze doodleuk hun riedeltje van "pull, doe mijn ding, push" volgen en bij problemen maar opnieuw starten met hun wijziging
3. Ze altijd problemen hebben met het opzetten van bijvoorbeeld een CICD pipeline als er eens iets meer nodig is dan een simpele pull van de laatste commit

Ik vind de GUI's die je kan vinden voor git er mooi uitzien maar ik zou (zeker als je vooral wil leren hoe git werkt) altijd de CLI aanraden voor de meeste acties en de GUI's hoogstens gebruiken voor visualisatie.

Het ene zou het andere niet uit moeten sluiten, ik gebruik zelf voornamelijk een UI voor het bouwen en controleren van mijn commits en voor het overzicht van alle branches en commits die zijn gedaan, bij dat laatste vind ik een web UI ook echt een toegevoegde waarde (waar je makkelijk van alle repo's en branches een overzicht kunt zien, ook als je die niet hebt gecloned), maar als ik een keer iets op moet lossen dan doe ik dat gewoon CLI. Als ik mijn UI niet open heb staan en een vlugge wijziging moet committen ga ik uiteraard niet eerst m'n UI openen maar doe ik dat ook CLI.

TS is goed op weg om Git te leren, maar een visuele weergave is altijd een mooie toevoeging daarbovenop.

[RoyTrenneman]

jeroen3 schreef op dinsdag 27 juni 2023 @ 08:29:
@Merethil Ja
[Afbeelding]

Als je wilt weten hoe git werkt is zijn op youtube een uitstekende videos die uitleggen hoe git onder water in elkaar zit en als je dat weet dan is het ineens logisch. Maar die video duurt lang en daar heeft niemand geduld voor tegenwoordig.
Er zijn ook veel tutorials die je een kunstje aanleren, maar daar heb je volgens mij weinig aan.

Initieel was ik op zoek naar het kunstje om te kunnen starten, maar ik ga zeker de gelinkte video eens kijken om het ook te snappen. Ik snap graag wat ik doe, zodat ik problemen ook op kan lossen.

[Merethil]

Oon schreef op dinsdag 27 juni 2023 @ 08:32:
[...]

Het ene zou het andere niet uit moeten sluiten, ik gebruik zelf voornamelijk een UI voor het bouwen en controleren van mijn commits en voor het overzicht van alle branches en commits die zijn gedaan, bij dat laatste vind ik een web UI ook echt een toegevoegde waarde (waar je makkelijk van alle repo's en branches een overzicht kunt zien, ook als je die niet hebt gecloned), maar als ik een keer iets op moet lossen dan doe ik dat gewoon CLI. Als ik mijn UI niet open heb staan en een vlugge wijziging moet committen ga ik uiteraard niet eerst m'n UI openen maar doe ik dat ook CLI.

TS is goed op weg om Git te leren, maar een visuele weergave is altijd een mooie toevoeging daarbovenop.

Dat was toch ook mijn punt? Gebruik de CLI om de controle te hebben en alles zelf te kunnen doen, en de GUI's gebruiken als visualisatie.

Ik moet sowieso nog de eerste git GUI-applicatie tegenkomen die alle functionaliteit van git fatsoenlijk heeft ingebouwd en niet alles half wegabstraheert "voor het gemak"

RoyTrenneman schreef op dinsdag 27 juni 2023 @ 08:34:
[...]


Ik snap graag wat ik doe, zodat ik problemen ook op kan lossen.

Dat is de beste insteek, succes!

[ Voor 9% gewijzigd door Merethil op 27-06-2023 08:36 ]

[RoyTrenneman]

CyBeR schreef op dinsdag 27 juni 2023 @ 02:30:
Je moet inderdaad eerst een repo aanmaken. Daarbij heb je de optie, die default aan staat, om de repo te initialiseren met een README file. Dat is waarschijnlijk het probleem, want als je dan een los geinitialiseerde repo probeert te pushen naar de repo op gitlab (je hebt nu dus feitelijk twee repo's, met verschillende inhoud) dan kan dat alleen met een force push en dat wordt default ook niet toegestaan.

TS kan het beste de gitlab repo weggooien en opnieuw aanmaken zonder de "Initialize repository with a README" optie aan. Waar overigens ook netjes onder staat: "Skip this if you plan to push up an existing repository."

Net geverifieerd. zonder readme.md blijft het resultaat eender.

[RoyTrenneman]

RobIII schreef op dinsdag 27 juni 2023 @ 03:12:
[...]

Ja, dat edit ik er net bij; ik had "Project aangemaakt in GitLab" gemist.

Either way: de melding lijkt me vrij duidelijk: "GitLab: You are not allowed to force push code to a protected branch on this project."
Ofwel: je probeert te pushen op een protected branch. Dat heeft volgens mij niks met bestaande README's o.i.d. te maken.

Het bijzondere is dat het resultaat nog steeds eender is, ook als ik de branch unprotected maak.

Ik kan voor nu door met het werk, ik ga in mijn vrije tijd eerst eens door de video en de verder de documentatie in, zodat ik een betere begripsvorming krijg, alvorens jullie verder lastig te vallen.

Allen bedankt in ieder geval voor het meedenken en het geven van richting. Alle antwoorden waar nuttig om e.e.a. beter te begrijpen.

[com2,1ghz]

Merethil schreef op dinsdag 27 juni 2023 @ 04:18:
[...]


Het leven wordt simpeler maar je doet er erg weinig kennis van git mee op als het gros van de acties worden weggewerkt achter een paar knopjes. Een aantal van mijn collega's gebruiken sourcetree sinds het begin en snappen niets van git op de CLI waardoor ze nu:

1. Niet snappen hoe bepaalde problemen te fiksen
2. Ze doodleuk hun riedeltje van "pull, doe mijn ding, push" volgen en bij problemen maar opnieuw starten met hun wijziging
3. Ze altijd problemen hebben met het opzetten van bijvoorbeeld een CICD pipeline als er eens iets meer nodig is dan een simpele pull van de laatste commit

Ik vind de GUI's die je kan vinden voor git er mooi uitzien maar ik zou (zeker als je vooral wil leren hoe git werkt) altijd de CLI aanraden voor de meeste acties en de GUI's hoogstens gebruiken voor visualisatie.

Ik ken ook zoveel git CLI gebruikers en die weten ook niet meer dan een pullen een push te gaan doen. Dingen als merge conflicten met CLI oplossen is vrijwel niet te doen. Die collega's zijn dus goed bezig.
Goed gereedschap is het halve werk. Je programmeert ook niet in een plain text editor maar ook in een IDE.

Heb je meer nodig dan zoek je het wel op. Maar om nou de hele git cli geneuzel iedere keer te gaan typen is zonde van je tijd.

[Opifex]

@TS: Heb de suggestie die ik tweemaal postte nu al geprobeerd? Dat lees ik namelijk nergens. Ik blijf erbij dat men het hier véél complexer aan het maken is dan nodig en ze je op het verkeerde been aan het zetten zijn. Bovendien is het me een raadsel hoe het antwoord waar je een vinkje aan hebt gegeven je probleem heeft kunnen oplossen?

RobIII schreef op dinsdag 27 juni 2023 @ 02:55:
[...]

Dat kan wel.

(...knip...)

Et voila.

Oh! Dat wist ik niet. Goed om te weten, want bespaart heel veel tijd! Alleen vraag ik me af of je dan nog steeds master als protected hebt by default? Want als dat zo is zit je met hetzelfde probleem als TS.

[Keyb]

Dingen als merge conflicten met CLI oplossen is vrijwel niet te doen.

Incorrect. Het is prima te doen, als je weet hoe/wat.

Je programmeert ook niet in een plain text editor maar ook in een IDE.

Ik programmeer veelal in neovim. Dat is een beetje tussen een texteditor en IDE in.

Heb je meer nodig dan zoek je het wel op. Maar om nou de hele git cli geneuzel iedere keer te gaan typen is zonde van je tijd.

Niks mis met persoonlijke voorkeuren, maar dit soort ongenuanceerde stellingen zijn niet constructief. Ik werk met neovim en ook Intellij en doe al mijn git werk op de commandline.

[Merethil]

com2,1ghz schreef op dinsdag 27 juni 2023 @ 09:43:
[...]

Ik ken ook zoveel git CLI gebruikers en die weten ook niet meer dan een pullen een push te gaan doen. Dingen als merge conflicten met CLI oplossen is vrijwel niet te doen. Die collega's zijn dus goed bezig.
Goed gereedschap is het halve werk. Je programmeert ook niet in een plain text editor maar ook in een IDE.

Heb je meer nodig dan zoek je het wel op. Maar om nou de hele git cli geneuzel iedere keer te gaan typen is zonde van je tijd.

Dat je het nog steeds niet snapt als je de CLI gebruikt is gewoon gebrek aan leervermogen of totale desinteresse. Een GUI abstraheert stappen en dat maakt het lastiger debuggen als er echt eens wat misgaat - wat zeker bij mensen met wat minder kennis weer vaker gebeurt. Al met al dus een beetje een vicieuze cirkel.

Wat betreft "het cli geneuzel iedere keer te gaan typen" - ik vind het juist zonde van m'n tijd om mijn handen van mijn toetsenbord af te halen om op allemaal knopjes te klikken. Kwestie van voorkeur gok ik.

[RoyTrenneman]

Opifex schreef op dinsdag 27 juni 2023 @ 10:08:
@TS: Heb de suggestie die ik tweemaal postte nu al geprobeerd? Dat lees ik namelijk nergens. Ik blijf erbij dat men het hier véél complexer aan het maken is dan nodig en ze je op het verkeerde been aan het zetten zijn. Bovendien is het me een raadsel hoe het antwoord waar je een vinkje aan hebt gegeven je probleem heeft kunnen oplossen?


[...]


Oh! Dat wist ik niet. Goed om te weten, want bespaart heel veel tijd! Alleen vraag ik me af of je dan nog steeds master als protected hebt by default? Want als dat zo is zit je met hetzelfde probleem als TS.

Opifex schreef op dinsdag 27 juni 2023 @ 10:08:
@TS: Heb de suggestie die ik tweemaal postte nu al geprobeerd? Dat lees ik namelijk nergens. Ik blijf erbij dat men het hier véél complexer aan het maken is dan nodig en ze je op het verkeerde been aan het zetten zijn. Bovendien is het me een raadsel hoe het antwoord waar je een vinkje aan hebt gegeven je probleem heeft kunnen oplossen?

Zie:

RoyTrenneman schreef op dinsdag 27 juni 2023 @ 09:39:
[...]


Het bijzondere is dat het resultaat nog steeds eender is, ook als ik de branch unprotected maak.

Ik kan voor nu door met het werk, ik ga in mijn vrije tijd eerst eens door de video en de verder de documentatie in, zodat ik een betere begripsvorming krijg, alvorens jullie verder lastig te vallen.

Allen bedankt in ieder geval voor het meedenken en het geven van richting. Alle antwoorden waar nuttig om e.e.a. beter te begrijpen.

De methode je aangaf, werkte niet, maar ik sluit een user error nog niet uit.
Ik ga er op een rustiger moment even voor zitten, zodat ik de stappen ook even noteer, zodat ik mijn fouten er wellicht zelf uit kan halen. Bedankt in ieder geval.

Het vinkje was onjuist inderdaad. Ik heb dit aangepast.

[com2,1ghz]

Merethil schreef op dinsdag 27 juni 2023 @ 10:24:
[...]


Dat je het nog steeds niet snapt als je de CLI gebruikt is gewoon gebrek aan leervermogen of totale desinteresse. Een GUI abstraheert stappen en dat maakt het lastiger debuggen als er echt eens wat misgaat - wat zeker bij mensen met wat minder kennis weer vaker gebeurt. Al met al dus een beetje een vicieuze cirkel.

Wat betreft "het cli geneuzel iedere keer te gaan typen" - ik vind het juist zonde van m'n tijd om mijn handen van mijn toetsenbord af te halen om op allemaal knopjes te klikken. Kwestie van voorkeur gok ik.

Ik zie het dus vaker andersom. Mensen die lopen te klagen als er merge conflicten optreden, dan kom ik er even bij zitten en zie ik ze omslachtig met git cli bezig zijn. Vervolgens een aparte clone doen en daar alle wijzigingen met de hand overzetten. Vervolgens hoor je dat ze de hele ochtend daar mee bezig zijn. Terwijl het met een GUI tool zo de diff per file kan zien en kan scrollen.

Idem met cURL en Postman. Moeten googlen hoe je nou die ene header erop zet. Met postman klik je op de jusite tabblad en voer je hem zo in. En je kan het exporteren naar een cURL command.

Ik ben handig met VI editor, maar geef mij liever een IntelliJ Of nog mooier. Geef mij liever Lens dan kubectl.

Ik hou van CLI, maar ik ben het er niet mee eens dat dit de productiviteit verbeterd. Je hoeft niet alle tooltjes volledig te begrijpen om je werkzaamheden te uitvoeren.

[Sito]

jeroen3 schreef op maandag 26 juni 2023 @ 21:58:
Je hebt waarschijnlijk een git repository met een template readme aangemaakt online.
Dat betekent dat er al een initial commit is die je lokaal niet hebt.
Die probeer je te overschrijven, en dat mag standaard niet.

Doe even een

code:

git pull

, dan download hij de commit met de readme.md file en werkt je push wel.

Of, slecht advies, zet in de settings->repository tijdelijk force push naar main even aan. En gebruik

code:

git push --force -u origin

Hoe voorkom je dit de volgende keer?
Maak de repository leeg aan. Die keuze krijg je.

Of doe een

code:

git clone

[Keyb]

RoyTrenneman schreef op dinsdag 27 juni 2023 @ 10:27:
[...]


[...]


Zie:


[...]


De methode je aangaf, werkte niet, maar ik sluit een user error nog niet uit.
Ik ga er op een rustiger moment even voor zitten, zodat ik de stappen ook even noteer, zodat ik mijn fouten er wellicht zelf uit kan halen. Bedankt in ieder geval.

Het vinkje was onjuist inderdaad. Ik heb dit aangepast.

https://endev.nl/help/topics/git/git_rebase#force-push

Als je dat vinkje allow force push aan zet of de branch unprotected maakt zou het moeten mogen.
Krijg je wel dezelfde error als voorheen als je dat hebt aangepast?

[Merethil]

com2,1ghz schreef op dinsdag 27 juni 2023 @ 10:53:
[...]

Ik hou van CLI, maar ik ben het er niet mee eens dat dit de productiviteit verbeterd. Je hoeft niet alle tooltjes volledig te begrijpen om je werkzaamheden te uitvoeren.

Maar git is nou net zo'n tool waar het wél handig is om alles te begrijpen om je werkzaamheden uit te voeren.
Juist omdat je samenwerkt met anderen en dingen hopeloos stuk kan maken als je doodleuk gaat lopen forcen of je merge volledig verkeerd doet.

Om je merge-voorbeeld nog even te benoemen: ik heb in VS Code gewoon m'n IDE die highlight waar er nu een syntaxfout zit (namelijk een <<<<<< die hij niet verwacht) en daar moet ik dus mijn aanpassingen maken om de merge conflicts op te lossen. Prima begrijpelijk, heb ik geen git GUI voor nodig. Daarna kwestie van wijzigingen weer commiten en conflict is opgelost.
Als je collega's daar uren over kunnen doen zitten ze echt in het verkeerde vak hoor.

[Opifex]

RoyTrenneman schreef op dinsdag 27 juni 2023 @ 10:27:

Zie:


[...]


De methode je aangaf, werkte niet, maar ik sluit een user error nog niet uit.

Mijn excuses. Hier had ik over gekeken. Bizar dat het niet werkt. Want exact jouw scenario is iets waar veel gitlab gebruikers tegenaanlopen: ze verwachten niet dat gitlab deze by default protected maakt. Unprotecten lost het doorgaans meteen op.
Misschien een open deur intrappen, maar... je bent niet op "OK" vergeten klikken o.i.d. ?

Merk op dat in jouw error hij ook zegt dat je probeert te force-pushen. Dat hoor je sowieso niet te doen in dit geval. Voor force pushen is er een aparte beveiliging op dezelfde plaats als waar je de branch kon unprotecten. Heb je daar al eens naar gekeken?

com2,1ghz schreef op dinsdag 27 juni 2023 @ 09:43:
[...]

Dingen als merge conflicten met CLI oplossen is vrijwel niet te doen.

Dit is loco. Als je niet met een CLI kan werken, gebruik dan Mercurial. De kracht van git kan je pas benutten wanneer je het in een CLI gebruikt. Merge conflicten oplossen met een GUI geeft meestal meer last dan dat het problemen oplost.

Goed gereedschap is het halve werk. Je programmeert ook niet in een plain text editor maar ook in een IDE.

Ik gebruik al jaren uitsluitend Vim. Collega's van mij gebruiken uitsluitend eMacs. IDEs lossen een onbestaand probleem op. Tenkoste van heel wat performantie van zowel mens al machine natuurlijk.

Heb je meer nodig dan zoek je het wel op. Maar om nou de hele git cli geneuzel iedere keer te gaan typen is zonde van je tijd.

`grbm` typen kost letterlijk één vierde van een seconde. Zelfs met de entertoets erbij. Hoogstens een halve, als je een trage typer bent.
Maar hoe lang duurt het om in een GUI naar je juiste branch te klikken, de rebase knop te zoeken en er op te klikken, dan de juiste target branch te zoeken en te selecteren, dan op "OK" klikken, en dan wachten tot alles geladen is?
Ik kan me onmogelijk voorstellen dat dat niet minstens 5 seconden duurt (20 keer trager), of 20 seconden als je er niet bedreven in bent (80 keer trager).

[CyBeR]

RoyTrenneman schreef op dinsdag 27 juni 2023 @ 09:30:
[...]


Net geverifieerd. zonder readme.md blijft het resultaat eender.

Ik zag het eerder niet maar je doet:

 git push -uf origin main

Die -f staat voor force. Force pushen is default niet toegestaan omdat je daar problemen mee veroorzaakt als anderen ook die repo gebruiken (hun historie klopt dan niet meer met de repo). Die -f staat ook niet in je instructies, dus ik weet niet waarom je die erbij bedacht had?

Haal die -f weg en het werkt zoals je verwacht.

[ Voor 8% gewijzigd door CyBeR op 27-06-2023 13:28 ]

[jeroen3]

@Opifex het typen is het niet het werk. Het moeten onthouden van alle details, volgordes en commando's is veel werk en foutgevoelig. Een gui zet gewoon de opties netjes onder mekaar, soms zelfs met vriendelijke tekst erbij hoe het ook alweer moest.

Altijd met cli werken is slechts weggelegd tot een klein groepje hardcore powerusers. En dat is mooi, die moet je hebben. Ik kan aardig wat doen met de cli en wat nano. Maar het is toch comfortabeler met sourcetree en beyond compare. En bovenal ben ik graag lui.

[Verwijderd]

Ik denk dat github met github desktop wat beter voor je is en makkelijker. Bij github moet je alleen Keys instellen als je via de cli wilt.

[RobIII]

Verwijderd schreef op dinsdag 27 juni 2023 @ 17:28:
Ik denk dat github met github desktop wat beter voor je is en makkelijker. Bij github moet je alleen Keys instellen als je via de cli wilt.

Github / Gitlab is lood om oud ijzer. TS wil/moet Git (version control) leren; GitHub en GitLab zijn diensten daaromheen en zijn helemaal niet relevant als je Git wil leren.

[dragonhaertt]

Als je het principe achter git wil leren, kan een tool als TortoiseGIT, sourcetree of visual studio ook helpen.
Dan hoef je niet te pielen met command lines en heb je gewoon een grafische omgeving om in te werken.

[RobIII]

dragonhaertt schreef op dinsdag 27 juni 2023 @ 21:31:
Als je het principe achter git wil leren, kan een tool als TortoiseGIT, sourcetree of visual studio ook helpen.

Wat fijn leert is voor iedereen anders; ik snap dan ook niet (van beide kanten) dat er zó op 't één of 't ander wordt aangedrongen. Als TS het graag leert in de CLI dan is dat toch helemaal prima?
TS kwam met een vraag die onderhand al lang opgelost is - de oorzaak daarvan staat / stond los van het wel/niet gebruik van een GUI. Laten we 't bij de vraag van TS houden.

[dragonhaertt]

RobIII schreef op dinsdag 27 juni 2023 @ 21:36:
[...]

Wat fijn leert is voor iedereen anders; ik snap dan ook niet (van beide kanten) dat er zó op 't één of 't ander wordt aangedrongen. Als TS het graag leert in de CLI dan is dat toch helemaal prima?
TS kwam met een vraag die onderhand al lang opgelost is - de oorzaak daarvan staat / stond los van het wel/niet gebruik van een GUI. Laten we 't bij de vraag van TS houden.

Als hij dat graag op die manier leert prima, als hij niet weet dat er ook grafische interfaces bestaan dan kan hij dat overwegen na het lezen van mijn advies.

Sorry dat mensen proberen behulpzaam te zijn, als de TS zijn initiële vraag het enige is wat behandeld mag worden kan je het topic beter sluiten...

[RobIII]

dragonhaertt schreef op dinsdag 27 juni 2023 @ 21:51:
[...]

Als hij dat graag op die manier leert prima, als hij niet weet dat er ook grafische interfaces bestaan dan kan hij dat overwegen na het lezen van mijn advies.

Het is inmiddels diverse keren voorbijgekomen dat er grafische interfaces zijn; ik denk dat TS onderhand op de hoogte is daarvan

dragonhaertt schreef op dinsdag 27 juni 2023 @ 21:51:
Sorry dat mensen proberen behulpzaam te zijn, als de TS zijn initiële vraag het enige is wat behandeld mag worden kan je het topic beter sluiten...

Ik zeg niet dat behulpzaamheid niet op prijs wordt gesteld - ik zeg alleen dat 2 kampen (CLI vs GUI) hier langzaam aan een "mijne is beter" "nee mijne" aan 't starten zijn en dat voegt niets toe. Zeker niet met magere of zelfs compleet ontbrekende onderbouwing. Verder is het vrij gebruikelijk dat we proberen een beetje ontopic te blijven. Natuurlijk is een zijstraatje op z'n tijd niet verboden, maar dit werd een herhaling van zetten.

[ Voor 4% gewijzigd door RobIII op 27-06-2023 22:02 ]

[RoyTrenneman]

Opifex schreef op dinsdag 27 juni 2023 @ 11:36:
[...]

Mijn excuses. Hier had ik over gekeken. Bizar dat het niet werkt. Want exact jouw scenario is iets waar veel gitlab gebruikers tegenaanlopen: ze verwachten niet dat gitlab deze by default protected maakt. Unprotecten lost het doorgaans meteen op.
Misschien een open deur intrappen, maar... je bent niet op "OK" vergeten klikken o.i.d. ?

No worries. Ik heb het vandaag nog een keer op mijn gemak gedaan en het werkte zoals verwacht. Bedankt.

[RoyTrenneman]

My 2 cents als het gaat om CLI vs GUI.

Ik prefereer vaak de CLI, omdat deze op elk OS eender werkt en ik dus maar 1 ding hoef te onthouden, behalve dat ik op een Windows PC nog Cygwin installeer.

Ik gebruik dan wel weer graag een IDE i.p.v. een CLI teksteditor.

Als ik een GUI-based applicatie gebruik, dan probeer ik wel altijd een cross-platform applicatie te gebruiken, zodat ik niet aan nieuwe tools hoef te wennen als ik een ander OS gebruik.

Ik geef wel een voorkeur voor het toetsenbord in plaats van een muis, omdat dit voor mij sneller werkt.

Ik ben gestart met GIT via de Fork GUI, maar had geen idee wat ik deed en vond het allesbehalve intuïtief. Die paar commands voor de terminal zitten al in mijn hoofd. Bij errors, zal ik er meer tijd in moeten steken, maar dat is niet anders dan bij een GUI.

[CyBeR]

RoyTrenneman schreef op woensdag 28 juni 2023 @ 14:33:
[...]


No worries. Ik heb het vandaag nog een keer op mijn gemak gedaan en het werkte zoals verwacht. Bedankt.

Je had het ook kunnen fixen door, zoals ik zei, niet de -f flag te gebruiken bij het pushen.

[Oon]

RoyTrenneman schreef op woensdag 28 juni 2023 @ 14:41:
My 2 cents als het gaat om CLI vs GUI.

Ik prefereer vaak de CLI, omdat deze op elk OS eender werkt en ik dus maar 1 ding hoef te onthouden, behalve dat ik op een Windows PC nog Cygwin installeer.

Misschien wel goed/leuk om te weten is dat Git Bash (standaard) op cygwin draait tegenwoordig, en dat de git installer ook de optie heeft om linux binaries beschikbaar te stellen voor Windows. Daarmee krijg je écht een omgeving waarbij je zelfs in CMD van Windows gewoon de standaard Linux commando's kunt gebruiken, en Git Bash is dan met de Cygwin installer uitbreidbaar als je bijv. extra packages nodig hebt.

Ik installeerde eerder ook altijd Cygwin, maar tegenwoordig installeer ik dus gewoon Git voor Windows en dan komt de rest vanzelf

[Opifex]

CyBeR schreef op woensdag 28 juni 2023 @ 14:46:
[...]


Je had het ook kunnen fixen door, zoals ik zei, niet de -f flag te gebruiken bij het pushen.

De -f flag is, zoals ik zei, een aparte protection in Gitlab. Die staat op dezelfde instellingpagina, maar is een afzonderlijke beveiliging.

[CyBeR]

Opifex schreef op woensdag 28 juni 2023 @ 15:17:
[...]


De -f flag is, zoals ik zei, een aparte protection in Gitlab. Die staat op dezelfde instellingpagina, maar is een afzonderlijke beveiliging.

Dat weet ik, ik gebruik gitlab namelijk elke dag, en die staat standaard aan. De melding in de TS was ook expliciet dat een force push niet is toegestaan. Ik had alleen in m'n eerste post niet gezien dat TS de -f flag gebruikte want hij zegt eerder `git push -u origin main` te doen, maar in werkelijkheid doet 'ie dat met -uf.

Een push naar een lege repo zonder default branch is wél standaard toegestaan en dan had dit probleem niet voorgekomen.

[RoyTrenneman]

CyBeR schreef op woensdag 28 juni 2023 @ 15:37:
[...]


Dat weet ik, ik gebruik gitlab namelijk elke dag, en die staat standaard aan. De melding in de TS was ook expliciet dat een force push niet is toegestaan. Ik had alleen in m'n eerste post niet gezien dat TS de -f flag gebruikte want hij zegt eerder `git push -u origin main` te doen, maar in werkelijkheid doet 'ie dat met -uf.

Een push naar een lege repo zonder default branch is wél standaard toegestaan en dan had dit probleem niet voorgekomen.

Slordig van mij, maar ik had de eerste foutmelding gedeeld met -uf, maar had al door dat ik de f niet moest gebruiken. Alleen -u werkte niet.

[RoyTrenneman]

Oon schreef op woensdag 28 juni 2023 @ 14:51:
[...]


Misschien wel goed/leuk om te weten is dat Git Bash (standaard) op cygwin draait tegenwoordig, en dat de git installer ook de optie heeft om linux binaries beschikbaar te stellen voor Windows. Daarmee krijg je écht een omgeving waarbij je zelfs in CMD van Windows gewoon de standaard Linux commando's kunt gebruiken, en Git Bash is dan met de Cygwin installer uitbreidbaar als je bijv. extra packages nodig hebt.

Ik installeerde eerder ook altijd Cygwin, maar tegenwoordig installeer ik dus gewoon Git voor Windows en dan komt de rest vanzelf

Nice. Cygwin had ik al geïnstalleerd, maar goed om te weten. Scheelt volgende keer weer een applicatie.

Binnenkort kan ik Windows weer verwijderen en gewoon Linux weer installeren. Dat maakt het werken een stuk makkelijker en prettiger.