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
{{ message }}
Repository navigation
Add support for the --since flag to the add command #477
In a monorepo that uses gitflow (multiple target branches), the baseBranch config option isn't flexible enough and can result in the wrong changed packages detection when using the add command.
Proposed solution
Add support for the --since flag (used with the status command) to the add command.
Sounds good to me. Could you describe in more detail how baseBranch doesn't cover your use case though? Assuming a standard gitflow - couldn't u just configure baseBranch to develop?
So for us, we don't always have a single "baseBranch", PRs are either branched from masterordevelop so for us to pick just a single one in the config would lead to incorrect "changed package detection".
I'm wondering if we want --since or if we should maybe have the flag reflect the current config name --baseBranch possibly including other config options there and flattening them at run time? (Presumably preferring cli options over config options).
Any strong opinions @Andarist / @Noviny ? For now, we're working around it by wrapping the changesets CLI and editing the config file on the fly which is obviously... Not great 🤣
to better understand the situation u are facing - u branch from the master only for hotfixes and similar work, right? I mean - most of your work is still branched off from develop?
From my understanding, having the lists of changed packages be accurate when you're generating changesets is super useful, particularly in repositories with more than, say, 20 packages.
I'd be fine with calling it baseBranch so it accurately reflects the flag it's overriding, and the chance could be relatively easy to implement as such.
Activity
Andarist commentedon Oct 21, 2020
Sounds good to me. Could you describe in more detail how
baseBranchdoesn't cover your use case though? Assuming a standard gitflow - couldn't u just configurebaseBranchtodevelop?lukebatchelor commentedon Oct 26, 2020
G'day @Andarist
So for us, we don't always have a single "baseBranch", PRs are either branched from
masterordevelopso for us to pick just a single one in the config would lead to incorrect "changed package detection".I'm wondering if we want
--sinceor if we should maybe have the flag reflect the current config name--baseBranchpossibly including other config options there and flattening them at run time? (Presumably preferring cli options over config options).Any strong opinions @Andarist / @Noviny ? For now, we're working around it by wrapping the changesets CLI and editing the config file on the fly which is obviously... Not great 🤣
Andarist commentedon Oct 26, 2020
to better understand the situation u are facing - u branch from the
masteronly for hotfixes and similar work, right? I mean - most of your work is still branched off fromdevelop?Noviny commentedon Oct 27, 2020
From my understanding, having the lists of
changedpackages be accurate when you're generating changesets is super useful, particularly in repositories with more than, say, 20 packages.I'd be fine with calling it
baseBranchso it accurately reflects the flag it's overriding, and the chance could be relatively easy to implement as such.acao commentedon Feb 1, 2021
this can also be useful in weird CIs that mess with the git ref, where you need to specifically target the
--sinceref.Andarist commentedon Feb 6, 2021
@acao we could use a hand with implementing this 😉
feat(cli): add --since flag to add command
Add `--since` flag to `add` command (#1840)
Add `--since` flag to `add` command (changesets#1840)