GIT: Monotonically increasing trunk and release branch ids

Joseph Myers
Fri Jan 10 17:05:00 GMT 2020

On Fri, 10 Jan 2020, Jakub Jelinek wrote:

> We would need to add some tags (I wouldn't bother with pre-GCC 5 era,
> because that doesn't have single number version numbers in the branch
> names), like:
> for r in 10 9 8 7 6; do
>   git tag branchpoints/gcc-$r `git rev-list $(git merge-base origin/master origin/releases/gcc-$(expr $r - 1))..origin/master | tail -1`
> done
> git tag branchpoints/gcc-5 `git rev-list $(git merge-base origin/master origin/releases/gcc-4.9)..origin/master | tail -1`

Those look like the start of GCC version N development (just after the 
branchpoint for N-1), not the branchpoint as commonly understood; naming 
them "branchpoints" seems confusing.

> I'm sorry for my limited git-fu, could those branchpoints
> tags be something that is fetched by default (given they would be added only
> once a year for each trunk commit after the branching, usually the
> BASE-VER bumping to N+1.0.0)?

Any tag in refs/tags is fetched by default.

I think the existing git hook configuration expects you to push only 
annotated tags, not lightweight tags (so you'd need to use -a / -s / -u 
when creating those tags).

> As it is short, could it be something we'd put as first thing in the gcc-cvs
> mail subjects (of course, only for trunk and release branch commits; like
> the current svn mails start with rNNNNNN - ), and somewhere before or after the hash
> in the body which also makes it into bugzilla?

This seems like another thing that would need new features in the hooks to 
support configuring email subjects and contents like that.

Joseph S. Myers

More information about the Gcc mailing list