[Asterisk-code-review] build: Refactor the earlier "basebranch" commit (asterisk[16])

[George Joseph]

Attention is currently required from: N A.
Hello N A, Friendly Automation, 

I'd like you to reexamine a change. Please visit

    https://gerrit.asterisk.org/c/asterisk/+/18017

to look at the new patch set (#3).

Change subject: build: Refactor the earlier "basebranch" commit
......................................................................

build: Refactor the earlier "basebranch" commit

Recap from earlier commit:  If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch.  That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want.  It also constructs the URLs for downloading
external modules with that version, which will fail.

Fast-forward:

The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file.  So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.

This is a slighltly different approach that adds two methods to
determine the mainline branch:

1.  --- .develvars

Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch.  So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
 to push to that branch in Gerrit but wanted to pull the external
 modules for 16, you'd create the following .develvars file:

[branch "new-feature-work"]
    mainline-branch = 16

The .gitreview file would still look like:

[gerrit]
defaultbranch=development/16/new-feature

...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.

The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).

2.  --- Well Known Development Branch

If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.

3.  --- .gitreview

If neither of the 2 earlier conditions exist,
the .gitreview "defaultbranch" variable will be used just as
before.

Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
---
M .gitignore
M build_tools/make_version
2 files changed, 21 insertions(+), 5 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/17/18017/3
-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/18017
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
Gerrit-Change-Number: 18017
Gerrit-PatchSet: 3
Gerrit-Owner: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: N A <mail at interlinked.x10host.com>
Gerrit-Attention: N A <mail at interlinked.x10host.com>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20220221/bf31f93f/attachment.html>