[question/feature] Flag to disable feature branch push for `git town sync`

[defunctzombie]

The documentation and help for git town sync say the following happens when running on feature branches:

When run on a feature branch:
- syncs all ancestor branches
- pulls updates for the current branch
- merges the parent branch into the current branch
- pushes the current branch

I would like a way to disable the last step. Here's my workflow:

I come back to a feature branch I had previously started, maybe a work-in-progress. I know I will be making changes to the code. I do a checkout to get to that feature branch and run git town sync so I can have the latest changes from upstream branches. The current behavior will correctly sync everything and then push my feature branch. This is unfortunate for me since it can kick off CI on any PRs I have open with this branch when I am about to make more changes and don't have a need to run CI since I will push those changes soon.

This is a minor thing but having a flag for git town sync that could avoid pushing the current branch since I am about to work on it could be nice. I definitely put this in the niche nice-to-have category and don't consider it wrong that the default is to push.

[kevgo]

Git Town has just the thing for you! Run git town observe on the branch. Now when you run git sync, it won't push your local changes to the tracking branch. See the end-to-end test for what exactly happens.

To make this observed branch a "normal" feature branch again (that gets pushed), run git hack on it.

[defunctzombie]

At first glance I feel like I would accidentally observe a branch and then forget to un-observe it. In the case I describe, I have done a git checkout to start work on the existing branch and want to bring it up-to-date locally and then will push the changes once I'm done working. For this flow I am in the mindset of sync and work; observe takes me off that path.

If this doesn't align with how you imagine folks use sync or prefer to push the observe workflow feel free to close this. If you would entertain a flag for sync I am happy to try my hand at a PR proposing the change.

[kevgo]

Thanks for the additional details. Yes, git town observe is intended as a long-term setting, and there is a risk of forgetting to un-observe a branch that isn't really an observed branch. Sounds like what you need is a --no-push option for git sync to skip pushing occasionally.

This is definitely a useful setting, and I would accept a PR that introduces this feature. Some guidance how to implement it:

• add a new NoPushFlag flag to the sync command, similar to the DryRunFlag
• There is an (internal) config flag whether to push the branch or not here. This is currently always set to true. You need to add code to set it to false if the NoPushFlag is set.

That should be it!

Bonus points if you add an end-to-end test for this, following the one for the push-hook as a template. But don't let that stop you if that's too much work, I'm happy to add these tests myself once your PR goes in.

Happy hacking and please hit me up with any questions you run into along the way!

[stephenwade]

@defunctzombie Are you still working on a PR for this feature?

[stephenwade]

I'd like this feature to include a setting to avoid pushing by default. I only want to push branches when I'm ready to propose them. ~(This might conflict with https://github.com/git-town/git-town/issues/3632 since propose would need to run git push.)~

[kevgo]

#3632 just means propose no longer pulls in updates from the parent branch. It would still create the tracking branch if needed, and/or push currently unpushed local commits to it.

[defunctzombie]

@defunctzombie Are you still working on a PR for this feature?

I have not started yet but it remains on my todo list - so I have not abandoned the desire to do it either :)

[kevgo]

Please note that #3646 is an alternative idea to implement the functionality that you want here.

[defunctzombie]

Please note that #3646 is an alternative idea to implement the functionality that you want here.

Thanks - I read the notes there and it won't address my needs or workflow. The branches in question here might already be pushed (in fact I often push early work). For me this feature isn't about avoiding a push on the branch at all and avoiding it when I've sat down to work on that specific branch and don't need it pushed when I start work, only once I am done making my changes.

[defunctzombie]

@kevgo I've opened https://github.com/git-town/git-town/pull/3648 so we can discuss around a concrete code change proposal. I attempted my hand at writing a test file but I'm pretty sure I did not do it correctly :D

[kevgo]

@defunctzombie thanks for all the feedback and the PR, this helps me understand your situation better!

[kevgo]

For me this feature isn't about avoiding a push on the branch at all and avoiding it when I've sat down to work on that specific branch and don't need it pushed when I start work, only once I am done making my changes.

Just to cover all the bases here - is making the pull request a draft an option for you here?

[kevgo]

This is now shipped in v14.3.0. Please try it out!

Please note that omitting the push only works with the merge setting for sync-feature-strategy right now. Rebasing your feature branches without force-pushing the new commits to origin results in having multiple versions of the same commits, which would lead to mixing old and new commits on the next regular sync (without --no-push).

Relevant end-to-end tests:

• when using the merge strategy: https://github.com/git-town/git-town/tree/main/features/sync/current_branch/feature_branch/merge_sync_strategy/no_push
• when using the rebase strategy: https://github.com/git-town/git-town/tree/main/features/sync/current_branch/feature_branch/rebase_sync_strategy/no_push

If this behavior is a problem for you, let's brainstorm more.

[stephenwade]

Please note that omitting the push only works with the merge setting for sync-feature-strategy right now. Rebasing your feature branches without force-pushing the new commits to origin results in having multiple versions of the same commits, which would lead to mixing old and new commits on the next regular sync (without --no-push).

Hmm, I want to use this feature with rebase, but I understand why it would cause conflicts on the next sync. Could it be changed to work with rebase if the branch has never been pushed? Until #3646 is done, I expect to always use git town sync --no-push (I'll probably make an alias for that in my Bash config), and if a branch has never been pushed then there would be no conflict between the origin and my local branch.

[kevgo]

@stephenwade you make good points, thanks! I guess if a user takes on --no-push it's reasonable to leave resolving the resulting duplicate commits up to them.

Btw #3646 is still on top of the backlog. While building it I just ran into some questions that I needed to think through first.

[kevgo]

https://github.com/git-town/git-town/pull/3721 makes --no-push work with the rebase sync strategy.

[kevgo]

This is released now.

[kevgo]

v14.4 now also contains #3646.

[kevgo]

A dedicated config setting for disabling all pushes is now available as part of Git Town 22.