Team leads who act like they're the terminal god, but screw up every single rebase they touch 😡.

Yet, I, who stick to git GUIs have almost never had a git problem 🤷‍♂️

People who use cli for git are just trying to flex. Let them leet haxx0rs have their believes.

@Lensflare really? If you just pull often and rebase often you rarely will have issues. If you need a graphical gui for git stuff your work flow lacks a bit prolly. This is for the first time I try not to flex, but git cli for life. Gut gui stuff is result of not doing it the way like I described above. I know it's not a smth that's in a book, it's pure the result of learning trough experience. Try it, it works perfectly for me. I find the gui's intimidating and complex. Why is everything better with using terminal output for debugging but git appearantly not? What's the difference? But again: my rebases just nearly always pass because my flow. With actual conflicts I understand a gui could be usefull. Are you guys working with 5 devs on one file or so? We try to plan in a way that we don't cross roads too much

@retoor If you're a solo developer working on your side project, there's no need for a GUI.

But if you're working in a team on projects where repos can quickly spread into several feature branches which were built from an unmerged branch because that one feature wasn't approved yet, then you should be super careful.

Yes I'm talking about conflicts.

You can't just run commands in your CLI and go to bed. Conflicts have to be manually reviewed and resolved, and GUIs display these in a nice way. They also run safe git commands and flags that you probably don't know.

In the end I do less typing and I'm quicker.

I'm not using a GUI because I don't know how to use the CLI. I'm using it for safety and reliability. I have run commands (by accident) in the CLI before. Never in a GUI.

The team lead in question has been a dev for more than 15 years, but commits still go missing after they attempt to resolve a conflict with their almighty CLI.

@wifi as I say, my rebases work automatically. You don't have to rebase as solo dev or you work in branches as a solo dev what's a bit schizophrenic. That's why I stated, do you work with five devs on same file? That sounds like you're working with many devs on a small app.

I worked on projects with 15 devs not having issues. But we're spread over big code base working. If course, you often work on same file, but if you pull and rebase often and not only at the end before wanting to merge your ticket, it goes fine. Trust me.

I'm not a solo dev. Only for last two years. Fucking love it btw. The rebasing is one of the lesser issues of working with others

I never rebase. When I do it always works though. Just not my style.

@lungdart whop whop, exactly.

@retoor it‘s not that I *need* a gui. It’s just much more convenient.
Switching between multiple projects, branches, feature branches, merging, conflicts, staging, I don‘t want to do that crap with a cli. And why should I?

hmmm GUIs run commands you may not anticipate or hide certain features from you

and I resolved conflicts in uhhh.. like straight up open it as a text file. I guess I don't really know what I'm doing but it's historically worked out

rebase is a horrifying idea. to be fair I didn't suffer many merge conflicts because I was very particular about not colliding work with others' like that. who wants the paperwork overhead. not me. best to assign people to different parts of the codebase, and if a shared file / system needs to be refactored I collect all the Todo notes and we do it later once we got all the specs

but I am a more sane person than most I guess. I like to plan things to avoid problems later on. totally unheard of strategy apparently

With or without GUI the hard part are the conflicts which are the same on both. Just one is horizontal the other is vertical.

@Tounai I hope the gui's are for resolving conflicts, else i won't see any reason to use one. In that case their only function is showing a fancy branch tree which is cool but quite useless.

It's only

git clone

git checkout

git pull

git rabase

git merge

How is that a hassle. The git merge i don't even do myself. Build server does that.

@retoor Agreed. Any tool pretending to make Git easy don’t change anything in easy, common situation and make it way worst in complicated situations.

@Tounai cool, where's my upvote? :P Since I have a bad popularity based on my own statitics i'm whoring for them now

@retoor that was the last one you get for free. Since I am about to resign from my job, I must live of something.

@Tounai You're having free time? Join the molodetz company! It comes with a free email adress with 1337Mb (1.337Gb) quota and a gitea account. No joke! ;) This 'company' is focussed on reinventing the wheel, AI and writing devrant related stuff. And don't worry, you won't have Friday pizza parties and your pay will be in exposure! This company keeps its word. Stealing IP is allowed.

I know you're originally French, but molodetz doesn't discriminate ;)

Molodetz makes high quality stuff like https://retoor.molodetz.nl/retoor/... and https://devrant.molodetz.nl

@typosaurus

If those are the only things you do with git, then you don't need a GUI.

In my case, we have structures and rules. Every feature, request, or change must have single logical commits in master (for easy reverts).

Example: If you were working on request 1234 (built from a parent unmerged & unaproved branch 1233), and your colleague needed to update branch 1233, now you eventually have this commit tree.

1234 - Footer widgets design

1233 - Fix header css

1234 - Build footer components

1234 - Integrate footer API

Knowing that the goal in the end is to have one single commit for each request in master, How do you quickly "squash" all your 1234 commits into one?

In a GUI I can do this in less than 5 seconds.

I know how it's done in a CLI, I just prefer not to add that extra stress to my life.