Cleaner builds

[luis-pereira]

No description provided.

[yan12125]

Thanks!

[luis-pereira]

Squashing into master makes it much harder to find to what commit a change belongs, IMO.
A merge commit is much more helpful.

[yan12125]

A merge commit is not good as it introduces non-linear history and makes the history more complicated.

[luis-pereira]

A merge commit is not good as it introduces non-linear history and makes the history more complicated.

A squash commit eliminates history. One ends up with a single commit that contains multiple commits. One is not able anymore to say to what commit a change belongs. Squash has it's uses. For features branches merge --no-ff are the best, IMO.
Non linear history is one of the numerous advantages of git over say svn.

[yan12125]

Apparently we have some disagreements around project workflow. I guess that will not be a short discussion. Could you open a new ticket?

[luis-pereira]

Apparently we have some disagreements around project workflow. I guess that will not be a short discussion. Could you open a new ticket?

I wouldn't call it disagreements. My view is explained in the post above. There's no need to a new ticket, IMO.
That's your call on how to stuff is merged.

[Chiitoo]

I don't think I ever did a commit via GitHub, so I'm not sure if there is a way to commit without a merge commit, but also preserve all the commits?

I tend to take the patch of a PR, then 'git am' it and push it via CLI, retaining all the commits and author (possibly picked that up from Gentoo Linux way of doing it, where we don't use GitHub at all to do the actual commits).

I'm not a fan of merge commits myself, but preserving all the commits is of course good (unless there is a good reason to squash them)!

[yan12125]

A squash commit eliminates history. One ends up with a single commit that contains multiple commits. One is not able anymore to say to what commit a change belongs. Squash has it's uses.

In this case, I use squash as those two commits are trivial and closely related. In general, I use rebase to keep individual commits. I can use rebase for future pull requests even when I don't think there is a need to use multiple commits.

For features branches merge --no-ff are the best, IMO.
Non linear history is one of the numerous advantages of git over say svn.

Non linear history is useful in some cases, while I don't see a benefit that outweighs its disadvantage for qtermwidget/qterminal.

I don't think I ever did a commit via GitHub, so I'm not sure if there is a way to commit without a merge commit, but also preserve all the commits?

Rebase preserves author email/name/date and file changes, and merge further preserves committer email/name/date and signature. The latter two are not important for qterminal/qtermwidget IMO.

[luis-pereira]

In this case, I use squash as those two commits are trivial and closely related. In general, I use rebase to keep individual commits. I can use rebase for future pull requests even when I don't think there is a need to use multiple commits.

Maybe they are trivial now... wait two months ;)