Re: Git Debug Branch

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2025-04-11 11:05:28

Am 11.04.25 um 01:29 schrieb Robert Ramey via Boost:
> It's mostly a problem because I only engage in library maintenance 
> occasionally.  And truth is I forget a lot of stuff in the meantime. 
> I'm also not a git guru (and hardly a git hacker!) which also means an 
> amount of wasted time.
>
> I do think we would be better served by shifting more to the feature 
> branch way of doing things.  Once one does this, the develop branch 
> become superfluous.

Does "feature branch way of doing things" refer to: Develop a new 
feature in a branch, if done and tested merge that to "production"?
I see how this makes the develop branch pretty much superfluous. It is 
the equivalent to a "staging" branch though, i.e. the last point before 
it goes to production.

As you already test your changes against master and your CI tests them 
against develop when you open your usual PR what you could do is merge 
develop to master right after merging the PR.
Of course except during a release preparation where the last merge needs 
to wait.

This way your workflow has only a minor extra step but enables everyone 
else to maintain their workflow.
As a "bonus" you can continue to work even when master is closed which 
you couldn't with only one branch. At least you could not test multiple 
changes/PRs together.


To me it looks mainly like a communication issue: You look at your 
master branch after a while and see a non-merge commit you didn't do and 
were not aware of.
Now you'd need to do extra work to check that this commit is also in 
your develop branch, which is annoying I guess.
Would a compromise be acceptable for you that some "trusted 
contributors" (it seems only Peter does such cherry-picks) be allowed to 
merge develop to master when you didn't do that yet after merging a PR 
to develop?
As your workflow of testing against master is known, I think there is no 
risk in doing that instead of cherry-picks.
This way others are unblocked in case of "pending" changes from your 
side and you don't need to check anything extra if there are only merge 
commits in master.

Of course this doesn't solve the issue where your develop branch gets 
broken due to a change in some other library. But that would soon be in 
master too breaking also your master branch.
This is however not much different than when using a single-branch 
Boost-wide.


That being said I understand your concern about having 2 branches, 
especially with the many states the whole of Boost could be in when each 
library can have "pending" changes or not.
I've been bitten too waiting for changes that others didn't merge to 
master yet, but of course others are limited in their resources too.
Maybe we can improve that somehow.