|
What advantages are there in all this commit squashing nonsense? I would have assumed that more commits are generally better because you have more fine-grained information and control over your repo.
|
#
?
Apr 17, 2017 16:51
|
|
|
|
| # ? May 12, 2024 00:49 |
|
|
Less clutter in the graph visualization of already merged branches? 
|
|
#
?
Apr 17, 2017 16:59
|
|
|
My main motivation was that, when doing a git blame, it was becoming impossible to figure out what was going on when a single function had five different commits with useless messages and one commit that actually contained the issue number. In Eclipse, there'd be a rainbow of highlight colors on the line numbers, making it less clear that a function was added in a single task. It was often a problem when I was doing lots of bug triage, because I couldn't quickly figure out where code had come from and why.
|
|
#
?
Apr 17, 2017 17:06
|
|
|
ChickenWing posted:What advantages are there in all this commit squashing nonsense? I would have assumed that more commits are generally better because you have more fine-grained information and control over your repo.
|
|
#
?
Apr 17, 2017 17:07
|
|
|
I think it's a question of what you want to track. If you want to track granular changes to code, don't rebase. If you want to track features added, rebase. This is why I say Git isn't a solution to a problem, it's toolbox that let's you build a solution. But you have to decide what you want your process to be, and build appropriately. Git requires a level of customization I never saw in (my admittedly limited experience with) SVN. Hell I'm pretty sure Git was originally built with that in mind. The tools and documentation that it originally shipped with were so minimal you practically had to learn what a blob was before you could do anything.
|
|
#
?
Apr 17, 2017 17:11
|
|
|
ChickenWing posted:What advantages are there in all this commit squashing nonsense? I would have assumed that more commits are generally better because you have more fine-grained information and control over your repo. If you're shipping releases that run on-premises, you need to be able to move some bug-fixes between the support branch from a year ago and the in-development master branch. Having a clean commit log means that the person who has to move patches around doesn't want to kill themselves. You say "here's the commit you want: 'issue #2596 fix DB pool exhaustion'". It's also nice if you've kept a Grand Moff-like grip on the commit history because you can look at the history for a file and make sense of it and even have confidence that you can roll back to prior commits without loving everything. I do it so that my Github-based code reviews are more readable. Since I've already been in the habit of tidying my commits, I feel this is worth the small time investment it costs me. It can be a lot of effort, though, and if nobody on your team ever even runs `git log` then there's no point in keeping it tidy. Probably the opposite, because you can inflate your Github score by keeping thousands of little commits: "oops" "write more code" "try adding comma" "remove comma" "add comma back on different line" "working!"...
|
|
#
?
Apr 17, 2017 17:18
|
|
|
Someone needs to dig up that HackerNews thread where they were debating whether or not the ideal git commit history would include every single keypress you made while working...
|
|
#
?
Apr 17, 2017 17:20
|
|
|
You joke, but this could be interesting and useful filtered down to an undo-redo history in between commits.
|
|
#
?
Apr 17, 2017 17:52
|
|
|
Rebasing is retarded. Force pushing is retarded. Git-flow is retarded. You already have compressed history for added features, it's called a branch. I've been using Git for the better part of a decade both in teams large and small, and all I've EVER seen the need (or benefit) for, is basic branching, committing, and merging. As a plus, you can onboard people by saying "here's our repo, make feature branches, merge them, go home at 5. Use PR's if you want. If I added up all the time wasted by autistic engineers arguing about the proper Git process across all the companies I've worked at, it would far outweigh any sort of benefit that complex Git workflows might confer.
|
|
#
?
Apr 17, 2017 18:36
|
|
|
darthbob88 posted:On the other hand, more commits means that when I browse the codebase, I have to scroll through a foot and a half of "WIP MAYBE THIS WORKS LOL" intermediate commits in your branches, instead of just one or two squashed "Now we have a new feature, woo!" commit. Git stash can really help lessen that. It became one of my favorite things because good lord did some of my "wip this is a save commit" things look painful after a while. I had to fix some stuff that didn't work properly and it was just too drat hard to figure out which things were right or in the right order.
|
|
#
?
Apr 17, 2017 18:39
|
|
|
revmoo posted:Rebasing is retarded. Force pushing is retarded. Git-flow is retarded. It's like watching the "making of" of a nightmare coworker/manager story 
|
|
#
?
Apr 17, 2017 18:49
|
|
|
revmoo posted:Rebasing is retarded. Force pushing is retarded. Git-flow is retarded. Sounds like hell to me.
|
|
#
?
Apr 17, 2017 18:49
|
|
|
raminasi posted:It's like watching the "making of" of a nightmare coworker/manager story I would say you are projecting but no, this is the Dunning-Kruger effect at work. Take comfort in the fact that you're in good company.
|
|
#
?
Apr 17, 2017 20:08
|
|
|
revmoo posted:Use PR's if you want. You must work with some really talented people.
|
|
#
?
Apr 17, 2017 20:56
|
|
|
I suspect that choosing to do laundry over continuing the workday is quite a condemnation of a situation. 
|
|
#
?
Apr 17, 2017 21:37
|
|
|
revmoo posted:Rebasing is retarded. Force pushing is retarded. Git-flow is retarded. Clanpot Shake posted:You must work with some really talented people.
|
|
#
?
Apr 17, 2017 21:42
|
|
|
Yes the hot take where I said it makes more sense to use Git the way it was intended. How outrageous. Go spend time with your families you spergs. (USER WAS PUT ON PROBATION FOR THIS POST)
|
|
#
?
Apr 17, 2017 22:01
|
|
|
Yeah, how dare we discuss working in development in this thread, of all threads!
|
|
#
?
Apr 17, 2017 22:29
|
|
|
I mean, it's perfectly fine not to rebase things or use the history edit tools if you don't want to or think it helps; the mere existence of git commit --fixup isn't a gun to your head. Do what works for you and the people you work with. Personally, for the stuff we do at work I think the time spent cleaning up history is worth it for making the log readable and debugging easier down the line. I don't expect that holds everywhere, but it's why we occasionally type git rebase --interactive --autosquash. Is it the One True Workflow as intended by Linus Himself? No clue, don't particularly care. Is it what you should do? Maybe, maybe not.
|
|
#
?
Apr 17, 2017 22:37
|
|
|
Linus endorses rebase. The difference is 99% of devs and projects are better suited to a simple workflow.
|
|
#
?
Apr 17, 2017 22:40
|
|
|
revmoo posted:Rebasing is retarded. Force pushing is retarded. Git-flow is retarded. One of my teams is replacing some middleware in the project from another division. So they've been working in that code base that follows what revmoo is suggesting. At some point during integration things broke in a very very odd fashion. So someone went to git-bisect the merge branch to see where things went wrong... About 90% of the commits had messages of 'WIP' or '.' Only about 80% of the commits don't compile. Of the 20% that do, 50-60% don't link. He was still bisecting it 3 days later when the problem was figured out. At the retrospective at the end of the sprint we added to our DoD that we'd have a Clean Checkin Policy. Any commit that goes to master has to build. Even if it means force pushed previously shared branches and squashed commits.
|
|
#
?
Apr 17, 2017 22:54
|
|
|
the problem is devs that commit bull poo poo like 'WIP' and think that's acceptable.
|
|
#
?
Apr 17, 2017 23:00
|
|
|
Hughlander posted:Any commit that goes to master has to build. Also, That is a very low bar. When it's up to me, nothing touches master until it's basically ready to deploy. Who the gently caress merges broken code to master?
|
|
#
?
Apr 17, 2017 23:02
|
|
|
It's git, the workflow is to commit early and often, because that's better than losing track of where you were or losing your code if your laptop catches fire. Ultimately, you can just go back later and fix it up to be a sensible commit to show to other human beings, unless your name is Rev. Moo, in which case all of your code is perfect the first time and your commits are always sparkling.
|
|
#
?
Apr 17, 2017 23:03
|
|
|
Look, I'm right, and several of you are dead wrong. And who spends three loving days in git bisect? It is literally divide-and-conquer. after 24 work hours you should be able to literally bisect tens of thousands of commits.
|
|
#
?
Apr 17, 2017 23:11
|
|
|
revmoo posted:the problem is devs that commit bull poo poo like 'WIP' and think that's acceptable. Not doing that is one solution. Another is the squash/force push thing you're arguing against. Sometimes I think this argument is really about what the word "commit" should mean. There are "sensible units of history" and there are "snapshots of right now so I can get back here if I gently caress it up" and I'm pretty sure both of these things are obviously (1) not the same and (2) useful. Your workflow will make a particular choice of how to use features of your tools to turn one into the other and, shockingly, there is more than one way to do it.
|
|
#
?
Apr 17, 2017 23:18
|
|
|
Related relevant articlequote:Look, I don’t give two shits about my Git commits.
|
|
#
?
Apr 17, 2017 23:26
|
|
|
revmoo posted:Yes the hot take where I said it makes more sense to use Git the way it was intended. How outrageous. Go spend time with your families you spergs. Intended is a weird concept. Git was built for people to email patches, which are manually applied by testers and integrators. There's still some nice tools for creating, sending, and applying patches in every installation of Git.
|
|
#
?
Apr 17, 2017 23:26
|
|
|
If you don't push at the end of the day, every day, you are doing it wrong I don't give a gently caress if it's a work in progress, it's a easy way to see what you did for the day, and to save it. Everything in master better be in deployable shape and tagged.
|
|
#
?
Apr 18, 2017 04:30
|
|
|
Stop gettin' mad about
|
|
#
?
Apr 18, 2017 13:51
|
|
|
I used to think squashing and history management was real obsessive, but I think I'm coming around to it. Haven't done it yet but I got another dev on the team who makes a lot of "fix thing" "refix thing" "undo fix thing" - a bunch of experimentation commits basically.
|
|
#
?
Apr 18, 2017 14:12
|
|
|
I do a bunch of that, I should totally squash my history, good idea. I do that especially if I'm jumping around a lot and need to save my work and don't want to stash it--I'm gonna forget that I have it stashed, for example.
|
|
#
?
Apr 18, 2017 15:27
|
|
|
Presented without context, from a paper from 1996. quote:Why would the internet community prefer to rediscover and reimplement all the technologies that the operating system community long ago solved?
|
|
#
?
Apr 18, 2017 15:58
|
|
|
revmoo posted:Also, I'm pretty sure you're just not thinking. Person makes 15 commits, the 15th works and is pushed to master (rebased or merged, I'm not sure what this remote teams workflow was.) 14 of those are poo poo. So broken code isn't merged to master. However you're bisecting 10,000 commits after merging master into your long lived branch. Commit 5000 is one of those 14 that didn't build. You can't mark it as good or bad. And have to try +/- 1. Which also doesn't work. Take ~15 minutes for the compile failure or ~22 for the link failure and you're eating up a lot of time. I get it, in the web world you're just not used to the size of the projects and the horribleness of out of country teams that are your customer. That doesn't mean everyone has those limited experiences.
|
|
#
?
Apr 18, 2017 16:38
|
|
|
Wait, what project are you working on with 37 minute builds?
|
|
#
?
Apr 18, 2017 16:56
|
|
|
revmoo posted:Wait, what project are you working on with 37 minute builds? Desktop Dick Sucking Enterprise Edition
|
|
#
?
Apr 18, 2017 16:59
|
|
|
revmoo posted:Wait, what project are you working on with 37 minute builds? Build + Link is 22 minutes. And a large large enterprise project. Of which we only develop part of the middleware and that full build time was a source build with the middleware integrated by the internal end customer. Also: quote:When it's up to me, nothing touches master until it's basically ready to deploy. That sure sounds a lot like a process, maybe even git-flow like particularly if multiple people/teams are collaborating on a feature prior to it being 'basically ready to deploy'
|
|
#
?
Apr 18, 2017 17:23
|
|
|
Meanwhile, the designer for the Ceylon language sure does like pushing straight to master: https://gitter.im/ceylon/dev?at=58f39e8908c00c092a876976
|
|
#
?
Apr 18, 2017 17:29
|
|
|
I am personally more in agreement with revmoo's take on this business, but I'm working with a fairly small group right now. I especially hate people committing stuff with the equivalent of "WIP: Did stuff." Mostly I hate WIP becuase, well, of course it's a work-in-progress. Do you think you will be making the last commit to this project forever? A problem I had recently is that a few of us agreed to start working on somebody else's branch to do integration of different components before sending it back to master. What became implicit here was that branch was a master among us. In practice, that meant I had to wade through a pile of "WIP" and broken tests before I could even stir in my contribution. My complaints about this really frustrated the owner of that branch because, well, it was their branch and it was a work-in-progress. However, that person signed the social contract too. Well, I suppose they didn't really understand what they signed. I tried to explain that when other people started working on a branch together, then the code that reaches that branch should be runnable at least for the bits we all are caring about. It's not just me getting butthurt about fetching new code and discovering none of it works. I am obligated to pass along code that works to everybody else. I feel like there's a kind of evolution for source control. I kind of want to use that brain-expanding meme for this, but I might shoot myself for having done it: 1. Source control is a necessary evil so that multiple team members can work on code at the same time. 2. Source control is useful for me because it lets me back up my poo poo off of my computer. 3. Source control is good for me because it lets me take a shot at something without fear that I'll pain myself into an irrevocable corner. 4. Source control is great for me because it helps me manage all the little changes and nibbles I make while I'm thinking through stuff. Unfortunately, I deal with a lot of people that are still in number 1 and will probably stay there forever. My local team is at least in number 2, but I don't know how far they've gotten beyond that. So I have to read up on policy stuff online to figure out what the grown-ups are doing. I found the whole rebase flow to be confusing. Personally, I'd rather use merges instead of rebasing because I really do want to see how all the sausage is being made. If somebody's making incremental, broken, WIP changes, rebasing that into the branch isn't going to magically fix it. Well, if they squash in the process, it will, but I rarely see that. I'd rather all that poo poo sit in a side branch so I can inspect and bisect the master first before I try to find a smoking gun in a topic branch--if I ever even feel compelled to do that. However, all our tools here are set up to block merges by default, so we're kind of stuck in a rebasing hell hole. It's funny to me because the other team members have the damdest time wrapping their head around rebasing and would rather merge too. So does Linus like rebasing for combining branches now? When I first heard about the religious war, I tried to look up what the Word of God had to say, and came across this. Disregarding possibly cargo culting on something Linus said, I generally hate having a fully-linear, rebased history where different branches of commits end up getting woven together because sometimes the different changes aren't even sequentially cogent. The way I see people getting around that with Gerrit is just squashing their entire branch into a single commit for review. I am also unsettled by that because those single commits can get huge. IMO I think a lot of methodologies end up being molded by external tools like GitHub or Gerrit, and people end up just take the limitations from them back into git. The strangest thing I've seen BTW is somebody merging by basically cherry-picking their stuff on to the target branch. However, the best I could muster in reaction to it was to point at it and kind of mutter, "Yeah uhhh I don't ever see that, but, uhhhh you do you, I guess?"
|
|
#
?
Apr 18, 2017 17:35
|
|
|
|
| # ? May 12, 2024 00:49 |
|
|
People at my work place are making plans to jump ship. It's sinking pretty drat fast. Looks like it's time to crank up the  , maybe I'll find a place with front-end engineers that actually understand that not everything works on all browsers. It's terrifying to think that I'm the most competent engineer in the room.
|
|
#
?
Apr 18, 2017 18:24
|
|