You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per default, comin searches for the main branch, defined via services.comin.remotes.*.branches.main.name (default main) and for a specific feature branch called testing-${config.services.comin.hostname}, defined via services.comin.remotes.*.branches.testing.name.
When developing with merge requests, usually we do not want to use the same feature branch twice. If at this point, we want to use a differently named feature branches, we first have to commit the feature branch name to this host's main. Only then can we start developing on that branch.
Only then can we start developing on the feature branch and use the testing branch feature.
To ease this process, I would like to introduce another option called services.comin.remotes.*.branches.testing.nameRegex or services.comin.remotes.*.branches.testing.nameGlob (or both).
With that, we can define a pattern for all future feature branches.
In that case, a user could define their flake e.g. as:
With that, the user could then create feature branches like testing/myMachine/new-feature-afix/myMachine/bug-in-service-xy.
With that, a new question arises though: A branch selection algorithm.
As long as only a single feature branch exists at a time, there should not be any issues. That is because comin only accepts feature branches that are based on the current main HEAD.
If two branches follow that pattern, we could:
a) throw an error and exit
b) use the branch that matches first alphabetically
c) use the branch that has the most recent changes
Before I start testing and developing such a feature, I would like to ask, if this idea is acceptable. Thank you very much.
The text was updated successfully, but these errors were encountered:
I'm not convinced this could be easily used since it would be really hard to know on which branch your machine is. I also think it's a bit risky to let your machine switching between branches when you submit PRs.
Moreover, this would make the comin implementation more complex, for a specific use case.
So, i'm currently not in favor of this feature but we could let this issue open to see what other people think about it.
Per default, comin searches for the main branch, defined via
services.comin.remotes.*.branches.main.name
(defaultmain
) and for a specific feature branch calledtesting-${config.services.comin.hostname}
, defined viaservices.comin.remotes.*.branches.testing.name
.When developing with merge requests, usually we do not want to use the same feature branch twice. If at this point, we want to use a differently named feature branches, we first have to commit the feature branch name to this host's main. Only then can we start developing on that branch.
Only then can we start developing on the feature branch and use the testing branch feature.
To ease this process, I would like to introduce another option called
services.comin.remotes.*.branches.testing.nameRegex
orservices.comin.remotes.*.branches.testing.nameGlob
(or both).With that, we can define a pattern for all future feature branches.
In that case, a user could define their flake e.g. as:
With that, the user could then create feature branches like
testing/myMachine/new-feature-a
fix/myMachine/bug-in-service-xy
.With that, a new question arises though: A branch selection algorithm.
As long as only a single feature branch exists at a time, there should not be any issues. That is because comin only accepts feature branches that are based on the current main HEAD.
If two branches follow that pattern, we could:
a) throw an error and exit
b) use the branch that matches first alphabetically
c) use the branch that has the most recent changes
Before I start testing and developing such a feature, I would like to ask, if this idea is acceptable. Thank you very much.
The text was updated successfully, but these errors were encountered: