Two Years of Squash Merge (2019) • Hacker News Board

Re: Two Years of Squash Merge (2019)

#191

Post by u801e » Sun, May 02, 2021, 7:56 PM UTC

tharkun__ wrote: post #190

u801e wrote: post #189

Earlier quoted context omitted.

> I make individual commits for addressing review comments. Those changes are visible when you make a force push in github since it generates a link that shows those changes. > Association should be there through tickets. I've seen companies change ticketing systems several times in career. Once it changes, all the old links and associations are as good as gone. But if that association is maintained via git, then tha…

I like how you first say that doing something in git itself is not needed because a random tool you use but I don't does things so that you can still see it easily and then you turn around and tell me that something is better to be visible in git history itself only because companies change tools. Weird. Tell me, in your career, how many times have you seen companies switch source control tools? I have seen it many m…

> Tell me, in your career, how many times have you seen companies switch source control tools?

Twice. Once from CVS to SVN (where people started using SVN for new projects and left existing projects in CVS). And once from SVN to git where we used tools to get the SVN history into git.

> who really needs commit history from 15 years ago?

It really depends on how old the code is. I've worked on code that was last deployed close to a decade ago and some of the git blame output was showing commit dates from 2008 (not quite 15 years ago). Unfortunately, the commit messages left something to be desired and didn't really help in terms of figuring out what the issue was).

> I loved digging through commit history on code that originally was tracked via RCS on a (at the time) ~15 year old code base. And that was about 15 years ago. I'm getting old lol!

Same here. I never got to use RCS at work, though I learned about it in school :)

Re: Two Years of Squash Merge (2019)

#192

Post by pizza234 » Tue, May 04, 2021, 9:05 PM UTC

thom wrote: post #105

tharkun__ wrote: post #93

Earlier quoted context omitted.

I can give you an example though I have to be sort of vague for obvious reasons too. In fact, I have been bisecting to find the cause of a bug 3 times in the past 3 to 4 weeks. Customer Service reported a problem with something that my team is responsible for. I knew almost for certain that we didn't break it. I had a vague idea that another team might have broken it by a recent-ish change to a different service that…

But that just sounds like an _incredible_ amount of effort and even at the end you still don't actually know the cause of the bug. Surely you just raise it to someone who owns the code in question? It sounds like you know who they are already?

To keep in mind that in cases where a bug can be programmatically reproducible (typically, existing or "upcoming" automated test coverage), bisect can be automated trivially.

Re: Two Years of Squash Merge (2019)

#193

Post by hbogert » Wed, May 05, 2021, 1:54 PM UTC

tablespoon wrote: post #25

calpaterson wrote: post #5

Earlier quoted context omitted.

> Developers should be required to submit _clean_ PRs, that is, PR's whose git history has been organized and refactored in such a way that it removed "clean up commits", "typo fix", etc. A complete and utter waste of time. You spend more time messing about with rebase than solving problems. When you're digging through VCS history due to a bug you often ignore the commit message anyway - if the code did what it seeme…

> A complete and utter waste of time. You spend more time messing about with rebase than solving problems. Eh. Not really. A clean history is a good resource for figuring out what was changed and why . Cleaning up history isn't even that much work anyway. > When you're digging through VCS history due to a bug you often ignore the commit message anyway - if the code did what it seemed to do you wouldn't be there. Only…

amen!

really, do people even use git bisect? If you do, you go through some rite of passage and I've seen people including myself make better (not perfect) commits. It remains a black art to gauge what the perfect amount of work in a commit should be.

Re: Two Years of Squash Merge (2019)

#194

Post by nickbauman » Thu, May 13, 2021, 2:02 AM UTC

gouggoug wrote: post #65

nickbauman wrote: post #14

Generally, time spent twiddling with the repo is time not spent delivering code. It's a distraction. Yes git has all these features that lets you do that and those feature matter when you're committing to the Linux repo which has thousands of eyes and your commit history has to help you communicate to a very wide audience. But the vast majority of us are not using git like this. I've used git bisect so rarely all thi…

- Generally time spent writing documentation is time not spent delivering code. - Generally time spent commenting code is time not spent delivering code. - Generally time spent diagramming on a white board is time not spent delivering code. - Generally time spent writing specs is time not spent delivering code. Yet, doing all of these are actually extremely important. How much importance you give each one of them is…

I've never seen documentation efforts pay off in organizations that do not have documentation as a deliverable artifact to outside stakeholders.

I've never used commit comments to store important information about the systems I'm working on. OTOH I can see people working on Linux needing that a lot more than I do.

Feel free to twiddle if that floats your boat though. I will refrain from twiddling, thank you.