> The two [ed. or more] branches serve different purposes and audiences.

I understand that a Bash release cannot just be a tagged development commit, because of the way things work; there are materials that need to be generated so that it can be built without "make boostrap" and all that.

The devel branch should at least be tagged to indicate where a given release or test release is being cut.

Suppose some behavior changed between 5.1. and 5.2. I want to "git bisect" between the two to see if it can be traced to a commit?

Which audience am I in, and how can I do that?

I should just be able to do

git bisect start
git checkout devel-5.2  # or whatever naming convention
git bisect bad
git checkout devel-5.1
git bisect good
+verbatim+

and go from there.

If someone retroactively went through devel and prepared a pull request which adds tags that identify interesting points, would you review and upstream that?

If so, what would be a good naming for, say, the tag on a devel commit which most closely corresponds to release 5.2? Or 5.2 prerelease 4?

When we look at the GNU Bash git repository, we see that test releases and releases are being produced by a squash merge process.

The detailed commits are in a devel branch.

The squash commits do not list the commits or range commits that went into them.

The devel branch contains no tags which indicate where the releases are cut.

For instance 5.2 was released recently. I can't tell which specific devel commit that is.

The 5.2 release is a commit on master. Its parent is 5.1, and that's it.

Going by dates and content, I can infer that this devel commit:

https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=bdfa4b088eb4c35bdaff832d7e18b3159953986f

titled "minor updates for release" must be 5.2.   There shouldn't be any guesswork required.