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

Suggestion: allow all remote branches to be fetched via config? #381

Open
n-tucker opened this issue Aug 23, 2023 · 3 comments
Open

Suggestion: allow all remote branches to be fetched via config? #381

n-tucker opened this issue Aug 23, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@n-tucker
Copy link

n-tucker commented Aug 23, 2023

First off, thank you for creating this project. It's helped me out tremendously!

Describe the bug
I have a use case where I want to use multi-gitter to operate on different remote branches. Within my script, I want to check-out multiple remote branches and perform some steps so I can compare the differences later. However to my initial confusion, the only remote branch I'm able to access is the default branch

To Reproduce
Steps to reproduce the behavior:

  1. Have a multi-gitter script that runs git fetch and git branch -a
  2. Run the script on a repo
    Screenshot 2023-08-23 at 4 24 13 pm

Expected behavior
I expected to see all remote branches (similar to what I'd see running git branch -a locally). It wasn't until I did some searching that I found the CloneOptions here. My understanding is that this only clones a single branch?

Is it possible to make the SingleBranch bool configurable? (if that's the root cause, happy to be corrected if it isn't!)

Additional context
If you're happy to accept contributions, I can raise something similar to this PR to make the property configurable!

I fully understand that my specific use case is on the more bizarre end and probably not what multi-gitter was intended for, hence why I'm asking about this first. TIA!

@n-tucker n-tucker added the bug Something isn't working label Aug 23, 2023
@lindell lindell added enhancement New feature or request and removed bug Something isn't working labels Aug 23, 2023
@lindell
Copy link
Owner

lindell commented Aug 23, 2023

Could you describe your exact use-case a bit more? And are you using run or print?

I do think this could potentially be added. But in that case, we also need to ensure that the user will get appropriate error messages if, for example, they do multi-gitter run and leave the checked-out branch to not be the expected one.

@n-tucker
Copy link
Author

n-tucker commented Aug 24, 2023

Absolutely, at a high level we're looking to verify an organisation-wide upgrade of one of our key dependencies. Since this is a breaking change and a substantial number of our repos don't have adequate snapshot testing, we decided that the best approach is to create a PR to show the diff pre and post-upgrade.

To do this, we run the following operations in our script:

  • Checkout the default branch (main/master)
  • Produce a snapshot, push this to a before-upgrade branch
  • Checkout our upgrade branch (branch with a static name)
  • Produce a snapshot, push this to an after-upgrade branch
  • Create a PR, with the changes of after-upgrade based off the before-upgrade branch
  • Add a comment to a static PR, linking to the newly-created PR

The reason that we're creating the PR ourselves and not using multi-gitter is that we need the PR to compare the diff between before-upgrade and after-upgrade, but to get this diff we need the base branch to initially be main/master. Also adding the reference comment requires us to know the PR link in advance.

And we're using run to execute our script against repos. We're using --dry-run, as the script is creating all the GitHub artifacts

@n-tucker
Copy link
Author

I've been able to work around this by running the following in my script before checking out the upgrade branch:

git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
git fetch --unshallow

If this functionality is required by others I'm happy to add this, but I'll leave this up to your judgement as to whether to close this issue or not!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants