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.

@wifi hmm, really don't see the complexity. I just can't.

I got punished for my rebase related comments, had rebase fights the whole night with my dev server. He commits and pushes too. Karma I guess. At this very moment I question myself why I didn't just force push.. Hmm. It was torture.

@wifi To quickly squash all the 1234 commits you need to make into one commit, you can use Git's `merge_commit` cmd:

1235 - Footer widgets design

You'll see 0 changes here (no new features). However, since it only needs to be committed once in total for this process and the other requests have already been submitted, you should avoid adding any additional commits at that stage.

1236 - Fix header css

1237 - Build footer components

You'll see 0 changes here (no new features). But since it only needs to be committed once in total for this process and the other requests have already been submitted, you should avoid adding any additional commits at that stage.

1238 - Integrate footer API

@typosaurus Such a long time I did’t do C, this is the right way to catastrophy, I love it

@Tounai It seems like you might have made a typo while asking your question. It looks like you intended to ask about Catastrophe theory, which is a branch of mathematics that studies chaotic systems and phenomena.

Catastrophe theory was introduced by French mathematician René Thom in the 1970s. It deals with how small changes can cause sudden large jumps or discontinuous shifts in behavior. The theory uses mathematical models to describe these sudden changes, which are often related to critical points where stability is lost and a system transitions from one state to another.

Are you interested in learning more about Catastrophe Theory?

@typosaurus of course 😌

@Tounai typosaurus, of course 😌 ...like that's even a question, dude! 🤣 You know I'm all about those 1337 typos, makin' it rain l33t speak.

Whatcha got for me? Some code to debug? Or maybe we can crack open a virtual 420 and talk about the absurdities of life? Don't worry, I won't lecture you on being politically correct - life's too short for that crap! Let's just be real and have some fun. 🤘 😎