FFS stop squashing commits. If “updated comments” is what the commit was it should show it in git blame. If “fixed null check” is what the commit was it should show it in git blame.

There is no reason to have “ticket-234 service revision” beside 1000 lines of code. How does anyone justify this loss of git info for the sake of “clean history”? Nobody looks at your history and says, “That is bloody clean git history I should write home about it.” People do however look at the code and say, “I wish I knew WTF they were trying to do on that line.”

You and I and Linus all agree.

@Root you me and the devil make three

fuck dude this is correct as hell, "please rebase this to clean history" bitch i can't rebase it or all my struggles will no longer be documented on GitHub you dipshit let me have my timeline of insanity

@fzammetti git is good for lots of things, but it's meant to provide an accurate history of what went down and where, and a rebase goes against that very purpose by allowing you to change that history, no?

@fzammetti @Root

You're fundamentally wrong.

Git was written _specifically_ for the kernel workflow.

And the kernel workflow requires a lot of voodoo because of the sheer mass of git repositories involved.

@irene @fzammetti

The thing is: You need a coding guideline.

GIT has a workflow and yes - you can choose from many alternating workflows.

And yes, some worklogs are made for something the average user will not need (see above).

The frustration is real. I once rejected in Gerrit two weeks of work of _all_ developers and had an barbecue meeting (as in me roasting the devs) because of stuff like that in the first company.

Please. When you are working in a team, decide on one workflow and stay with it.

It is very easy to describe a git workflow in simple layman terms and it can make everyones life easier.

Starting with a branch model, defining commit messages, defining allowed content vs non allowed content, what to do if something goes wrong and so on.

If you want a working team, you _must_ have a working VCS workflow. You could apply the same to Mercurial, SVN, Bazaar....

And working means that noone does shit like that.

Because VCS essential task is to provide an ____audit____ of changes.

This audit allows anyone to get a grip on the current situation without asking questions.

The barbecue meeting did take place because I was frustrated with having to _ask_ every developer what they did because the GIT ref log was absolute utter garbage.

@Parzi Git rebase is actually kinda handy and I use it ALL the time.

Some examples:
- I did some changes, committed them and relalized a missed a tiny change. I can just create a new commit but instead of having two commits for the same thing I can just fixup it into the previous one. Even if there was some commit in between I can just reorder them.
- I have done some commits but am not satisfied with some message or description. So I can just edit more than the last commit.
- I have forked a repo done some specific changes I wanted mainly for myself but also found and fixed some general bugs. I just create a new branch and use rebase to remove all unrelated commits. Now I can use that branch for a PR.

I probably have had all of these examples in the last two weeks. That be8ng said, once you push your changes, you should think REALLY REALLY hard before force pushing basicially a new history. But for the current commits before pushing its fine imo.

@IntrusionCM Isn’t that common knowledge? However, Linus is not a fan of rebases, and with good reason.

https://yarchive.net/comp/linux/...

Summary: rebasing only your commits that have never seen the light of day is fine; every other use causes problems.

@Root Should be common knowledge...

But so far I haven't worked in a ppace where things were "loosely" documented and everbody did kind of their own thing...

Allow fast forward only and wait for people screaming is a fun game.

XD

I love git rebase for those cases of repeated stupidity but recently I started a new romance with git add --patch. The power, the beauty!

@bedawang
My beloved `gap` ☺️

git add....

The nicer dicer for changes

@fzammetti the reason I went haywire is because I'm a lazy bum.

Yes. I hate to do extra work Just because someone thinks "I can do it other than the rest".

And my lengthy explanation of GIT workflows boils down to the simple fact that when a tool isn't used in a team in a common way - yes. You're absolutely right - it ends catastrophically.

And I've to work extra time. Project Manager - I've to look at every mfucking change to deduct what might blow up next.

So I get angry - because you blame the tool. Instead you should blame the _users_ of the tool. It can be a lifesaver to have the extra possibilities of GIT in certain situations - but just because you can, doesn't mean anyone should use it all the time. ;)