limit pulling in updates from the parent branch

[kevgo]

Git Town is built around the idea that the more all Git branches are kept in sync with the rest of the world, the better. This is the correct behavior for most scenarios. This approach has limits in large monorepos. Git Town as a tool to help scale Git to large development teams (the size of a small town) should support this use case better.

The problem

Large monorepos have a busy main branch, i.e. there are updates on main each time a developer runs hack, append, or sync. In some monorepos, each update causes lengthy compiler runs, database migrations, or the need to execute "yarn install", which disrupt the developer workflow.

1. A developer creates child branches of an existing feature branch. This pulls in updates from the main branch, which cause slowdowns. #2657

2. Multiple people pair on a feature branch and want to sync their commits on that branch. git sync pulls in updates from the main branch, which causes slowdowns. https://github.com/git-town/git-town/issues/2673#issuecomment-1829983692

Possible solutions

1. Make the affected feature branch perennial. Git Town should make this easier by providing a command to make the current branch perennial or not perennial. A challenge with this approach is that the branch isn't really perennial. It will be shipped at some point. Before it can be proposed or shipped, it must be made non-perennial because Git Town (rightfully) disallows proposing or shipping perennial branches.

2. Mark particular feature branches as "this is a feature branch but don't pull in updates from the parent branch".

3. Add a config setting that disables pulling in updates from main for all feature branches.

Possible values for the setting could be to sync with the parent never, once an hour, once a day, once a week, etc.

[vectro]

Another use case for this is that in GitLab, pulling in commits from the target branch will remove any approvals on an MR. So you may think you have an MR that is ready to go, run git-town sync, and then find that you need to get new approvals.

[kevgo]

Great point, thanks for the feedback!

[kevgo]

Possible name for the command or config setting:

git town disinherit makes the current branch no longer "inherit" updates from its parent branch when being synced. The branch still exchanges updates with its own peers (tracking branch) and children.

git town reinherit removes the disinheritage from the current branch.

[kevgo]

Other possible name: inherit-frequency.

[kevgo]

As of v12.1 one can also stop pulling in updates from the parent branch by making the branch a contribution branch or an observed branch.

[kevgo]

Shorter possible name: throttling

> git town throttle 4 hours
> git town throttle 1 day

[kevgo]

Any branch can be throttled/inherit-frequency-limited, even though it only makes sense for:

• main branch
• perennial branches

It makes little sense for:

• feature branches
• observed branches
• contributing branches

It is redundant with:

• parked branches

[kevgo]

Valid settings for throttling/inherit-frequency are:

• (not set) or null: Don't throttle this branch, i.e. sync it every time git sync is called on it or git sync --all is called anywhere.
• "never": Never sync this branch, even when calling git sync on it directly. That's the point of this setting: Allow people to limit syncing while they work on a branch.
• 1 hour: sync this branch only once every hour
• 4 hours: sync this branch only once ever 4 hours
• 1 day: sync this branch only once every day

[kevgo]

Inherit-frequency/throttling appylies always, even if the user runs git sync directly on an inherit-limited branch. That's the point of this setting: to allow people to work normally on a branch, and it limits the frequency at which this branch is updated from its ancestry to reduce yak shaving.

This also meaningfully distinguishes throttling from parked branches.

Users can override throttling at call time if they want to force a sync:

> git sync --always

> git sync --all --always

[kevgo]

Limiting pulling updates from any parent branch is probably over-engineering. All that was requested in #2657 was limiting pulling the main development branch. Let's just implement that much simpler idea for now. Hopefully that's all that monorepo users need.