mainThe GNU Bourne-Again SHell - Support: sr #110734, Bash has a config management...


sr #110734: Bash has a config management problem.

Submitter:  Kaz Kylheku <kkylheku>
Submitted:  Wed 28 Sep 2022 07:58:26 PM UTC
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Works For Me
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup

Mon 03 Oct 2022 08:36:42 PM UTC, comment #3: 

If you want to bisect between 5.1 and 5.2, it's not that difficult to find the devel commit immediately following the master 5.1 commit (by date) and the devel commit immediately following or before the master 5.2 commit (by date) and use git bisect from there.

I never use git bisect myself, but I realize that few others have bash builds going back several years just hanging around.

If you wanted to add devel branch tags you consider interesting, sure I'd look at it. Something like devel-[release name] would be fine as a tagging naming scheme:


and so on (you get the idea).

Chet Ramey <chet>
Group administrator
Mon 03 Oct 2022 05:00:30 PM UTC, comment #2: 

> 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

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?

Kaz Kylheku <kkylheku>
Mon 03 Oct 2022 02:40:25 PM UTC, comment #1: 

The commits to the devel branch detail ongoing development. There is usually, but not always, a devel branch commit corresponding to a particular major or minor version release. This branch exists for people who want to track development and look at bug fixes, or to check when an individual issue was addressed.

The master branch is for formal releases. This branch is for the vast majority of users and vendors, who want those releases but are not particularly interested in the path to get there. There are files in the distribution that provide detail about the changes in each release.

The two branches serve different purposes and audiences.

Chet Ramey <chet>
Group administrator
Wed 28 Sep 2022 07:58:26 PM UTC, original submission:  

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:

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

Kaz Kylheku <kkylheku>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by kkylheku (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-03 chet StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code