Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

limit pulling the main branch #2657

Open
heyitsaamir opened this issue Nov 14, 2023 · 13 comments
Open

limit pulling the main branch #2657

heyitsaamir opened this issue Nov 14, 2023 · 13 comments

Comments

@heyitsaamir
Copy link

First of all, this probably shouldn't be a github issue, but I'm not sure where else to ask this! I'm just getting started with git town so this might be a basic question --

I work in a big repo with lots of contributors. I created a new branch and set-parent to an existing branch. I'd have liked to just have rebased on top of that branch without pulling the latest master (when master gets pulled, i need to do a full yarn to download packages etc). Is this possible to do with sync?

@kevgo
Copy link
Contributor

kevgo commented Nov 14, 2023

Hey Amir, that's a great question and an interesting use case! Here are two ideas that might get you want you want in your situation. I'm using your terminology, i.e. "new branch" for the branch that you created, and "existing branch" for the branch that is the parent of "new branch".

You could make the "existing branch" a perennial branch. Perennial branches are long-lived standalone branches like master, production, development, staging, etc. What separates them from feature branches is that they don't receive updates from the main branch.

git town config perennial-branches update

In the dialog that shows up when you run this command, enable the checkbox next to the "existing branch" name. Now you can run git sync and it does what you want: it pulls updates from the remote of the "existing branch", but it doesn't update master and it doesn't pull master into "existing branch" and "new branch". You can create pull requests for your "new branch" and ship it into this "existing" (and now perennial) branch as usual. To create pull requests or ship the "existing branch", you have to remove it from the perennial branches.

Another idea is to put Git Town into offline mode. In offline mode, Git Town doesn't pull any updates from the network. It just syncs the branches in your local workspace with each other. In this scenario you would have to run git pull or git pull --rebase manually on the branches you want to fetch updates for. Then any git sync should be safe in the sense that it doesn't pull any additional updates from the network.

git town config offline on

@heyitsaamir
Copy link
Author

Thank you! I had actually tried the offline mode, but it doesn't seem to be working for me. It's actually doing the fetch and pull. I'm not sure if I'm doing something wrong 🤔

@heyitsaamir
Copy link
Author

For your reference -- notice how it rebases on top of origin/master.

image

Hmm, it's not doing a fetch, but I think my vscode periodically does a fetch, so maybe that combo is broken

@heyitsaamir
Copy link
Author

FWIW, the perennial-branches is a great workaround. I'll probably write up a script so that this is easy to set up and sync when I need to

@kevgo
Copy link
Contributor

kevgo commented Nov 16, 2023

Some background on how Git works might help understand what's going on here. Due to the nature of Git as a distributed version control system, your local clone contains the entire repo content including all commits and all branches from the server. origin/master is the local copy of the master branch that exists at the origin server.

Git operations like merge and rebase happen on local copies of branches. git rebase origin/master updates your local master branch with commits in the local copy of the master branch from origin.

Then you periodically download updates from the server to your local client (git fetch) and upload updates made on your local client to the server (git push). git pull --rebase is a convenience command that runs git fetch and git rebase origin/<branch> under the hood.

The way offline mode works right now is that it simply doesn't fetch. It still syncs what your local repo is aware of, including local copies of remote branches. This does what it should do as long as you never fetch manually.

If you or VSCode runs git fetch periodically under the hood, then your local Git repo contains unsynced updates of the remote branches, and Git Town syncs them even if offline mode is enabled. Because offline mode is enabled, it doesn't push them up to the server.

You can verify whether you have successfully enabled offline mode by running git town config offline.

@kevgo
Copy link
Contributor

kevgo commented Nov 29, 2023

FYI there have been a number of reports requesting this feature. I'm collecting them and ideas how to address your use case better in #2711.

@kevgo kevgo closed this as completed Nov 29, 2023
@kevgo kevgo reopened this Nov 29, 2023
@kevgo
Copy link
Contributor

kevgo commented Nov 29, 2023

@heyitsaamir assuming Git Town has a feature that allows you to avoid pulling in updates from the master branch. Would you enable this behavior for all your feature branches, or just for a few that you manually select?

@heyitsaamir
Copy link
Author

@heyitsaamir assuming Git Town has a feature that allows you to avoid pulling in updates from the master branch. Would you enable this behavior for all your feature branches, or just for a few that you manually select?

I'd probably enable it by default. I'm used to graphite's model where they only pull things if you explicitly run a sync command. I generally prefer this because:

  1. It works better for me for larger codebases (faster)
  2. Less cognitive overhead that i'm in offline mode or not
  3. I work while travelling (airplanes etc), so sometimes my access to wifi is slow. This is when i can get a lot of focused work done, so I'd rather not kick off a git pull if i can help it.

@kevgo
Copy link
Contributor

kevgo commented Nov 30, 2023

Thanks this is helpful, and graphite looks cool! Follow-up question to help me fully understand what you have in mind here.

I'm used to graphite's model where they only pull things if you explicitly run a sync command.

How is this different from Git Town? Git Town also only pulls things if you run a sync command.

[when my internet is slow during traveling] I'd rather not kick off a git pull if i can help it

Simply don't run git pull or git sync then? Do you mean that you would want to sync only the local branches when traveling, and only pull updates over the network when running the explicit "sync" command?

I'm sure I'm missing something here. Can you please describe in more detail which exact Git operations you would like to be run (roughly) in each of the scenarios you describe (office with fast internet, traveling with slow internet)? How would an ideal Git Town tool behave in your use case? Thanks! 🙏

@kevgo
Copy link
Contributor

kevgo commented Mar 25, 2024

New features added in v12.1 improve the developer experience around this:

  • make the existing branch a contributing branch
  • now when you run git sync it does what OP suggests: it updates new branch only with commits made to existing branch and not with commits added to master

@kevgo kevgo changed the title Is it possible to not pull master when appending branches? limit pulling the main branch Mar 26, 2024
@kevgo
Copy link
Contributor

kevgo commented Mar 28, 2024

Possible implementation: a user-specific config setting sync-root.

  • only in Git metadata since it's user-specific

If set to true (default): git sync works normally

If set to false:

  • git sync syncs everything except pulling updates from the root branch origin.
    • It does not pull updates from origin/main into main.
  • To pull updates from the root origin:
    • run git sync on the root branch
    • run git sync --root

@kevgo
Copy link
Contributor

kevgo commented Mar 28, 2024

Additional request for this in #2673 (comment)

@kevgo
Copy link
Contributor

kevgo commented Apr 14, 2024

Possible idea to implement this: #2171

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants