Skip to content

Add support for the --since flag to the add command #477

Description

@itsjackgardner

Affected Packages

@changesets/cli

Problem

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.

cc: @lukebatchelor @Noviny

Activity

  1. Andarist commented on Oct 21, 2020

    @Andarist
    Member

    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?

  2. lukebatchelor commented on Oct 26, 2020

    @lukebatchelor

    G'day @Andarist

    So for us, we don't always have a single "baseBranch", PRs are either branched from master or develop 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 🤣

  3. Andarist commented on Oct 26, 2020

    @Andarist
    Member

    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?

  4. Noviny commented on Oct 27, 2020

    @Noviny
    Contributor

    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.

  5. acao commented on Feb 1, 2021

    @acao

    this can also be useful in weird CIs that mess with the git ref, where you need to specifically target the --since ref.

  6. Andarist commented on Feb 6, 2021

    @Andarist
    Member

    @acao we could use a hand with implementing this 😉

  7. added theissue type on Dec 12, 2025
  8. added a commit that references this issue on Feb 6, 2026
    b18a146
  9. added a commit that references this issue on Feb 24, 2026
    057cca2
  10. added a commit that references this issue on Apr 16, 2026
    9b327db
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions