enforce linear history?

Description

We had this discussion already some time ago. There are three options for merging into master: merge commits, rebase merging, squash merging.

I think that with squash merging git suppresses the history of the branch that is merged into master. This feels a bit awkward (to me) since it might be useful to retrieve the history of that branch, in order to retrieve the thinking of the developer. However, I think that one can retrieve the branch from the successful pull request. So it would not be gone, but removed from view. (What happens if we ever move out of github is a different discussion.)

I am wondering if this might be a step in the direction of changelogs that Sebastian wants.

It would be easy: We would just switch on "enforce linear history" in the github settings.

Environment

None

Activity

Show:
Michal Maciejewski
December 7, 2019, 3:34 PM

I am wondering if this might be a step in the direction of changelogs that Sebastian wants.

Technically, we could also use PRs (merged to master) for changelogs.

Marcel Rieser
December 17, 2019, 9:29 AM

(But as mentioned, the old branches are kept on GitHub under PRs, so maybe this is a reasonable workaround…)

Are they really? I think there was also a discussion that merged branches should get deleted (see ) . GitHub offers to restore deleted branches for a while, but I think once they get garbage collected by Git, they are gone, and so are the original commits.

Michal Maciejewski
December 17, 2019, 11:48 AM

GitHub stores them internally. You can restore the branch of all merged/closed PRs. Even for our first one:

Sebastian Hörl
December 19, 2019, 10:02 AM

We just had a quick discussion with Michal. We came to the conclusion that this could be a viable way to go:

  • Disable rebasing for the whole repository (global setting)

  • Enforce linear history for the master branch

This would mean that one can only "Squash" to the master branch, which basically means rebasing and then combining all the new stuff to one commit. This way we can get a clean change log from the commits, actually. I would say we could try this.

I was checking some tools, e.g.
https://github.com/github-changelog-generator/github-changelog-generator

It creates a quite nice change logs using the Github API, where you have all the commits and also links to the respective PRs. This way it is easy to check what has actually changed for one entry in the CHANGELOG and one can even go back to the related PR discussion.

Kai Nagel
December 19, 2019, 2:32 PM

Sebastian and I just talked about it again, and would vote for switching it on. We don’t know if github or git will eventually lose the deleted branches. We would, however, argue that sometimes it is not a disadvantage to clean up a bit. So if nobody is militantly opposed, we would switch that on and see what happens.

Assignee

Unassigned

Reporter

Kai Nagel

Labels

None

Priority

Major
Configure