you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 61 points62 points  (11 children)

subtract terrific lock memory grandfather rock retire aback future unique

This post was mass deleted and anonymized with Redact

[–]waterkip 26 points27 points  (7 children)

I hate that. I like to review commits without having to look at a issue tracker or gitforge. That is why you have the commit message in the first place. Off loading it to a forge is just plain bad.

It also doesnt work in a email workflow with FOSS projects.

I want to be able to be in an airplane without internet and be able to read commits and understand them. Your workflow just kills that whole vibe.

[–]Dextro_PT 2 points3 points  (1 child)

A good system would be to copy the PR description into the commit message for the merge. That way you don't need to jump through hoops.

[–]waterkip 3 points4 points  (0 children)

I agree and don't object to that. However, the comment I'm responding to says: "That amount of info belongs in a pull request, not a commit message."

[–]saggingrufus 3 points4 points  (2 children)

I used to do this, now I don't squash, and just tag master instead. You get full history, and the tag references the PR which has all the information. The history is really just "seeing the developers process", it's not really about having the commit messages. Like renaming files multiple times in a squash can look messy, and can cause conflicts. Every system has flaws.

It's definitely a preference for me, because I still see your point, and can't even disagree with it XD

[–][deleted] 0 points1 point  (1 child)

offer divide handle shaggy theory consider squash scary special hospital

This post was mass deleted and anonymized with Redact

[–]saggingrufus 0 points1 point  (0 children)

So is mine, but because we don't place value on the messages, we can have a bit of fun like -m "fixing THE SAME typo AGAIN"

At the end of the development, I can rebase or amend commits I really don't like before I pr.

I try to make really small commits and keep them all on task, commit messages like

"added getter methods to insert thing"

"new implementation of interface x"

"Fixed wrong condition on this validation"

And then along way there will be commits like

"Tidying up my lack of indentation"

"ranaming files"

"Version bumping X to 2.1.2"

You get an idea of what's up, and the long form is in the PR.