J Lam 👩🏻💻👩🏻🎨I’m 99% convinced that anyone who wants squashed “linear history” on a main branch with multiple collaborators does not actually know how git works…. Like at all…
Unfair bias or informed inference? 😬🤷🏻♀️ you tell me…
Miguel Arroz@kangaroo5383 Very informed inference. History should always be preserved.
@arroz appreciate the validation … * imposter syndrome intensifies 😅 *
Hannah@kangaroo5383 Most of the time I find that a pull request containing 50 commits, a third of them a merge from main, is just noise that should not be preserved. Often, people are really bad with their commit messages and when what to commit. I like how git allows you to "commit early, commit often" and once you reached a good solution, allows you to throw away the mess (interactive rebase, squash merge).
@uncanny_static it’s expected that before a merge into main people could edit their history. Additionally when you are reading main, you can just parse the merge commits - i mean, the example you just cited is yet another reason to use no-ff
@uncanny_static Tho i don’t know what you mean that “1/3 of them from main” is it a visualization issue, or people submitting things incorrectly? If they are doing a bidirectional merge correctly with merge commits in place - it would be a visualization issue (ie ppl not understanding git and just look at a picture from some website that visualize it badly)
@kangaroo5383 My point is that a lot of people are really bad at keeping a commit history with only relevant commits. The "I just made a commit to see if the CI pipeline succeeds"-commits are usually not valuable, and I see these things all of the time.
@uncanny_static you can’t use bad practices to correct bad practices, that just makes everything worse.
Also you haven’t addressed the point of 1/3 commits from main. If they are just doing a bidirectional merge, that could be actually valid history but whatever website is displaying it badly if you didn’t actually look at the git tree itself
@kangaroo5383 "valid history" is not the same as "useful history". I prefer to keep only the information that is useful for me. "Who branched off from what branch" and "who pulled in main at which point in time" is usually not the information I like to keep.
@uncanny_static tbh your comment kinda proved my point… a specific visual representation of git history on some website is not the same as actual git history, you can get “useful” history by your definition via just w different tool or the right git cmd, but then you’re just gonna tell me that’s not your problem and imo that misses the whole point of why “valid history” is kinda the point of the whole thing
@kangaroo5383 What do you mean by "'valid history' is kinda the point of the whole thing"? That implies that using git for any other reason than having a "valid history" has no merits.
@uncanny_static your case of wanting to only read “readable history” can be easily achieved by just looking at merge commits in main. So you’re describing a data interpretation/reading challenge you’re having by not having the right tools. By recording valid history and change relationships, subsequent reading challenges are easily solved.
@kangaroo5383 Yeah, but if I just keep what I want, there is no problem to be solved at all.
Look. Like many people in tech, you seem to have the strong opinion that there is just one right way of doing a specific thing, in this case using git. Fine. You do you.
I think git is a flexible tool that can be used in a multitude of ways and different needs/preferences lend themselves to different ways of working.
Dominic Hopton@kangaroo5383 I agree, but… people do not play ball. They do not — as one would hope they would — clean up their commits, so you get 34 ‘wip’ commits, 3 reversal of direction by making edits, not rolling their branch back, and 1 ‘bug fixed’ message linking to the external bug system that will be burned to the ground because lic. fees.
(i am someone who does edit, but also barely understands git)
@grork that’s what PR review is for and it doesn’t really matter what their PR commit list is. For readability on main you can just look at the merge commits themselves
duhanebel@kangaroo5383 in my experience this requires discipline and a non-trivial amount of effort tha translates to work-work when the team is big and diverse enough. I find squad-merge at the pr level a requirement for main readability. You just need to keep PRs small enough that each one doesn’t introduce tons of changes
@duhanebel w the strict no ff approach you can just read the merge commits and ignore what ppl did in their PR. People keep thinking that how a website happens to show the commits is what git is, and it’s so wrong and frustrating it’s not even funny
@kangaroo5383 i don’t think it matters where you read your history: I only use cli. My point is: when you got a large team and you leave all the history in there, things tends to get messy. And while you can filter things out, why bother? If your PRs are your smallest unit of work, what happens inside a branch is just noise. And rightfully so: I can be as messy as I want and create all the commits I need to code my solution then commit the incremental change as a unit with a squash.
@kangaroo5383 and this works incredibly well with main-based CD in large teams. Ofc this approach makes less sense if you make use of long-lived branches or if your “squashed commit” ends up being thousands of lines long. On my side projects I keep all the history because that’s how I personally like to work. Git is great because it’s able to support a high variety of different workflows.
august@kangaroo5383 I’m fine if you want to show where you branched/merged from but I definitely do not want to see 20 commits like ‘does it work now?’, ‘fixes’, ‘lol?’, etc.
@august PR review fix history lol or just simply filter by merge commits since that seems to be what you want to read
Adam Bell 
@kangaroo5383 @august git commit -m “wip.final(2).docx”