"--prune" option for "git sync"

[kevgo]

• git sync --prune syncs the current branch and removes it if it is empty
• git sync --all --prune syncs all branches and removes those that are empty

git sync and git sync --all can be run without thinking and only do safe deletes. git sync --prune deletes more branches, including ones that are empty without having been shipped, at the risk of deleting branches that weren't obsolete, for example empty branches that the user just created in order to do something with them.

For ergonomics an -ap switch that enables --all and --prune should work.

To implement this, the behavior of how branches get synced needs to be slightly adjusted:

• sync each local branch but don't push the updates to its tracking branch yet
• see if the branch should be deleted and do so
• push to the tracking branch only if the branch didn't get deleted

[charlierudolph]

Note. For my usage, I still want to be able to prune branches without syncing all my branches (changelog mentioned potentially deleting that command)

[kevgo]

Charlie!! 🎉 Please note the updated terminology for "prune" that this ticket proposes. The old prune-branches command deleted branches whose tracking branch is gone, i.e. branches that were shipped or deleted at the remote. This functionality has been merged into git sync, as proposed by you in #1209 (comment). The old prune-branches command was removed in v10.0 as it is now redundant.

This ticket proposes a new meaning for prune: it now means "delete branches that contain no changes". Even branches that still have their tracking branch can be pruned if the output of git diff-parent is empty.

There were some requests to bring the old prune-branches command back: #2673. I'm open to that, but haven't heard a convincing need for it. I'm curious what you would use this command for. Can you please outline your use case for prune-branches without syncing?

[charlierudolph]

The downside with the current to me is that in order to prune branches I need to sync all my other feature branches. I often use prune-branches more as a cleanup than anything and don't want to deal with syncing other branches at the time.

My preference would be running git sync on any branch also prunes branches. And thus anytime I get auto-cleanup vs needing to use a dedicated command to cleanup things

[kevgo]

Thanks for the helpful feedback 🙏

I often use prune-branches more as a cleanup than anything and don't want to deal with syncing other branches at the time.

Can you please outline why syncing feature branches is a chore to you that you want to postpone at times in your situation? Does it incur extra effort beyond updating the branch (like running a lengthy npm install or recompile)? If yes, would something like limiting pulling updates from the parent (#2711) to something like once a day be a solution for your situation?

My preference would be running git sync on any branch also prunes branches.

git sync now prunes the branch it syncs if the tracking branch is gone (feature spec). Syncing one branch cannot prune other branches because pruning now performs a local sync as a security feature to avoid pruning unshipped changes (changes in the local branch that aren't in the main branch). (feature spec)

WDYT?

[charlierudolph]

Can you please outline why syncing feature branches is a chore to you that you want to postpone at times in your situation?

• I sometimes checkout feature branches belonging to other developers to help debug something. Prefer not to push to them unless I sync with the developer.
• I sometimes have saved local only branches on my local that are small experiments or hold reference code
• I sometimes have a branch with some changes on it but its not a priority at the moment and something I'm not getting back to for a few weeks.

In both of the above cases and the general, the main issue is I don't think its worth my time to deal with merge conflicts if they exist as the branches aren't important at the moment.

Hypothetically I could mark those I want to skip as perennial or have some new status that allows me to sync them with master but be excluded from sync all. However, I generally am focusing my time on one branch at a time and just use prune branches to auto cleanup my local to make it easier to find the branch I care about.

git sync now prunes the branch it syncs if the tracking branch is gone (feature spec)

Nice, that will avoid me accidentally re pushing a branch that should be deleted

pruning now performs a local sync as a security feature to avoid pruning unshipped changes (changes in the local branch that aren't in the main branch). (feature spec)

Hmm, think there are cases I won't like this as sometimes use the UI to rebase changes to pickup a fix in the master branch (vs doing local sync and then reset in order to maintain as one commit).

Based on your arguments I think I'd prefer to keep a prune-branches command or something like git sync --all-tracking-deleted which filters to syncing just the branches with tracking deleted. I'd also like prompts if their are uncommitted changes on branches asking user if want to keep or delete (something I'd be happy to implement)

[kevgo]

Thanks for the detailed feedback! Your use cases are pretty representative for how staff-level engineers work. Git Town should support such use cases fully without requiring workarounds. I have brainstormed support for three additional branch types in #3095 that address all the needs you describe. The goal is that even people like you who have broader responsibilities can run git sync and git sync --all at any time and Git Town does the right thing with each branch. None of this is implemented yet, this is in the readme-driven development stage. I'm very curious what you think about this.

I sometimes checkout feature branches belonging to other developers to help debug something. Prefer not to push to them unless I sync with the developer.

This would be addressed by making this branch an "observer branch". You can check out a branch as an observer branch by running git observe <branch name> instead of git checkout <branch name> or by running git observe on the branch if it already exists on your machine. When syncing an observer branch, Git Town would only rebase against updates from the tracking branch (no pulling from the parent, no pushing to the tracking branch) and delete this branch as soon as its tracking branch is gone (without syncing to check for unshipped changes).

• I sometimes have saved local only branches on my local that are small experiments or hold reference code
• I sometimes have a branch with some changes on it but its not a priority at the moment and something I'm not getting back to for a few weeks.

In both of the above cases and the general, the main issue is I don't think its worth my time to deal with merge conflicts if they exist as the branches aren't important at the moment.

This would be addressed by making these branches "parked branches". git sync --all ignores parked branches. Running git sync on a parked branch syncs it like a normal feature branch.

I generally am focusing my time on one branch at a time and just use prune branches to auto cleanup my local to make it easier to find the branch I care about.

There could be an auto-park feature that parks all new branches, or only branches that match (or don't match) a regex.

sometimes I use the UI to rebase changes to pickup a fix in the master branch (vs doing local sync and then reset in order to maintain as one commit).

Note that you can now set the sync-feature-strategy to rebase and then Git Town rebases your feature branches against their parent and tracking branches, thereby keeping your single commits single. A survey at GitLab revealed that most developers prefer to rebase their feature branches, so Git Town offers this now. There is also the idea for a compress command that sqashes all commits on a feature branch into a single commit.

Would you find these features useful in your work?

PS: Until the new branch types are implemented, here is a Bash snippet that deletes all branches with deleted remotes (I haven't tested this so proceed with caution):

LC_ALL=C git branch -vva | grep 'gone]' | awk '{ print $1 }' | xargs git br -D

[kevgo]

@charlierudolph Git Town 12.1 implements new branch types that support the use cases you outlined above: https://www.git-town.com/advanced-syncing

I sometimes checkout feature branches belonging to other developers to help debug something. Prefer not to push to them unless I sync with the developer

Run git observe on such branches and git sync will no longer push your local commits to the tracking branch. It will also not pull updates from the parent branch. It still pulls updates from tracking branch, always rebasing your local commits no matter what the sync-feature-strategy is. When the tracking branch is gone, git sync will delete the local branch even if it contains unshipped commits.

I sometimes have saved local only branches on my local that are small experiments or hold reference code
I sometimes have a branch with some changes on it but its not a priority at the moment and something I'm not getting back to for a few weeks.

Run git park on such branches and they will no longer be synced at all when you run git sync --all. When you run git sync directly on a parked branch, it syncs the branch normally.

To unpark a parked branch you run git hack on it.

Notice the ability to change branch types in bulk by running git park branch-1 branch-2 branch-3. With all branches properly categorized, you should be able to run git sync --all without worrying too much and Git Town will do the right amount of syncing and not syncing on each branch.

Curious what you think!