search

lxqt / qtermwidget

The terminal widget for QTerminal
https://lxqt.github.io
GNU General Public License v2.0
506 stars 255 forks source link

Cleaner builds #519

Closed luis-pereira closed 1 year ago

luis-pereira commented 1 year ago
yan12125 commented 1 year ago

Thanks!

luis-pereira commented 1 year ago

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

yan12125 commented 1 year ago

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

luis-pereira commented 1 year ago

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. 20181231230017480

yan12125 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 ;)