Re: [BuildStream] Merging 'git_tag' and 'git'

[Jürg Billeter <j bitron ch>]

Hi Tom,

On Mon, 2020-01-06 at 15:22 +0000, Tom Mewett via buildstream-list
wrote:
> [...]
>
> [!1774] 
> https://gitlab.com/BuildStream/buildstream/merge_requests/1774
>
> The main additions to 'git_tag' are:
>
> 1.  It will fetch only the given ref when given an exact tag ref
>     (*-0-g*)
> 2.  It can be configured to choose the latest tagged commit when
>     tracking
> 3.  It can track multiple branches; it chooses the latest
>     commit/tag found on any when tracking
>
> As I see it, (1) and (3) are uncontroversial and could be added right
> away. I welcome any comments on this.

Can you please elaborate on the use case for (3)? I can't currently
think of a scenario where tracking the latest commit/tag from multiple
branches (by comparing commit dates) would be useful and robust.

If you specify multiple release branches that are all being maintained
or master + a release branch, wouldn't this risk `bst source track`
jumping between branches?

E.g., let's say we're tracking master and a release branch (1.8). A
release is tagged in the release branch, 1.8.2. `bst source track` will
use that tag. On the next day 1.9.1 is tagged in master. `bst source
track` will thus switch to 1.9.1. A week later the release branch gets
a bugfix release, 1.8.3. Now `bst source track` will switch from 1.9.1
to 1.8.3, which doesn't make sense to me.

Is there a way this feature can be used without this issue?

I did suggest tracking of multiple branches in #220 almost two years
ago, however, with a difference. I suggested the list of branches to be
considered candidate branches and the first branch that exists would be
tracked. The idea of this was that it would allow specifying release
branches that haven't been created yet. This should be more robust
(assuming the upstream project does not delete release branches).

Cheers,
Jürg