Handling of commit history

[reintroducing]

I wrote a tool based on this tool for my current job. It worked fantastic, until others started to publish around the same time. The issue was as follows:

Dev 1 and Dev 2 create branches off of master.

Dev 1 pushes a commit (commit A-1) in his branch.

Later in the day, Dev 2 pushes a commit (commit B-1) in his, opens a PR, and merges into master.

Dev 2 publishes his package.

Dev 1 adds another commit (commit A-2) in his branch, opens a PR, and merges into master.

Dev 1 publishes his package.

The changelog does not show commit A-1 because the tool is checking newest commits from the last tag in HEAD. Because that particular commit was created before Dev 2 created their tag and published, it is just completely lost out of the Changelog.

I have been pouring over the source code, and while in my package I've modified the source pretty heavily, I THINK i'm still mostly aligned on these steps. So in this scenario, I was wondering how eslint-release would handle this situation?

I realize this is not a bug but I wasn't sure how else to ask this so I apologize if this is not the place.

[not-an-aardvark]

Hi, thanks for creating an issue.

I'm not sure eslint-release handles this case at all -- in all of our projects, we squash commits when merging them into master, so this hasn't been a problem for us.

I imagine one workaround in your case could be to look at all commits that are on master for the given release that weren't on master for the previous release. In other words, you could decide whether to include something based on reachability in the commit graph, rather than the time that a commit was created.

[reintroducing]

@not-an-aardvark Thanks for your answer Teddy. In this scenario, Dev 1 did a Squash and merge in GH using the button/dropdown option of the PR but it set his squash merge, for whatever reason, to be before the Tag on master was created.

In doing a bit more research, I think the Rebase and merge option (the last one in the button/dropdown) would be our saving grace here. It sounds like it would pull in latest master and then put the commits in the PR branch to be latest on top of that and then merge them in. In reading the ESLint PR contribution guidelines (https://eslint.org/docs/developer-guide/contributing/pull-requests) it sounds like that is the part I/we missed in the process (the rebasing). I think this is how ESLint gets around having this issue, if I'm not mistaken.

How do you guys squash your commits (meaning, what does that look like in code?) Or do you use the PR buttons?

Really appreciate you taking the time to clarify these things for me, its not easy to find answers for some of this stuff and a conversation is much clearer to help understand it.

[not-an-aardvark]

We use GitHub's "squash and merge" button.

[reintroducing]

Got it, thanks.