You and I and Linus all agree.
Parzi888827dfuck 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
fzammetti60027d@Root Then Linus probably shouldn't have written the abomination that is Git that allows for all this bullshit. Commit the changes, require a message, and that's it. All this other garbage makes Git a huge PITA for anything non-trivial (and as this post indicates, even some of what should be trivial stuff isn't because Git lets you screw the pooch ten ways to Sunday if you want, which is NOT a good idea for the majority of "professional" developers out there).
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.
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.
LinusCDE296627d@Parzi Git rebase is actually kinda handy and I use it ALL the time.
- 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.
bedawang827dI love git rebase for those cases of repeated stupidity but recently I started a new romance with git add --patch. The power, the beauty!
The nicer dicer for changes
fzammetti60026d@IntrusionCM "All this other garbage makes Git a huge PITA for anything non-trivial" ... I said that specifically because Git was created for the kernel workflow, which is non-trivial. And ever there, I'm not convinced what Linus created was really great even for that workflow, but certainly I would agree that it's MORE appropriate for that workflow than most others where Git is used, which are, by and large, trivial by comparison.
IntrusionCM329626d@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. ;)
fzammetti60025d@IntrusionCM "So I get angry - because you blame the tool. Instead you should blame the _users_ of the tool."
As a general statement, I would usually agree with that. However, in this case, it IS the tool in my view.
As a lead developer/architect, I can say unequivocally that I've spent more time helping developers, who are otherwise solid, out of sticky situations with Git, FAR more than I EVER had to with SVN or even CVS before that. That to me screams that it's a problem with the tool, not the users.
You're right, there's power in flexibility, and certainly Git provides that. But, it ALSO provides the mechanisms by which you NEED that flexibility more than most other options I've seen. When we're not talking about amateur developers, the finger can't be pointed in their direction.
I mean, at the end of the day, Git has taken over the IT world no matter what I have to say about it. I personally think that's a huge mistake, but it's the reality, so I'll just have to cope.