Skip to content

Avoid git fetch --all#35

Closed
JackPGreen wants to merge 3 commits intohazelcast:masterfrom
JackPGreen:avoid-fetch-all-5
Closed

Avoid git fetch --all#35
JackPGreen wants to merge 3 commits intohazelcast:masterfrom
JackPGreen:avoid-fetch-all-5

Conversation

@JackPGreen
Copy link
Copy Markdown
Contributor

We shouldn't need to fetch every unrelated branch from the repo to backport changes between two branches - this may be non-trivial for big repos.

Example execution & resultant PR.

We shouldn't need to fetch _every_ unrelated branch from the repo to backport changes between two branches - this may be non-trivial for big repos.

[Example execution](https://github.com/JackPGreen/backport-test/actions/runs/20109278003) & [resultant PR](JackPGreen/backport-test#252).
log_info "Pushing $BRANCH_NAME to origin"
# https://github.com/cli/cli/issues/1718#issuecomment-748292216
git pull
git push -u origin HEAD
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did we have this git pull?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was added in #6, but shouldn't have been.

Specifically - the backport action a makes a new branch (e.g. backport-pr-5543-5.6.z) - there should be no need to pull a branch we just made.
However, the branch name isn't very unique - if you run the action again by clicking Rerun in the GitHub UI it will use the same branch name as last time and then complain there's a branch on the remote with the same name as your local one - but they aren't the same branch because you didn't pull it.
During development I didn't realise this and thought we always had to pull - but actually it's only needed if you re-run, which is really only a development task.

The generated branch names probably should be more unique but it's not really a problem.

# Add explicit "upstream" remote as required by backport script
git remote add upstream "${{ github.event.repository.clone_url }}"
git fetch --all
git fetch upstream --unshallow "${{ matrix.branch }}"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why --unshallow ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why --unshallow ?

It didn't work otherwise.

You get a conflict during cherry-pick:

error: could not apply 531d15a... Create 173 (#265)

@nishaatr
Copy link
Copy Markdown

does this improve efficiency?
do you have before and after timings?
change is fine but Google says it will bring entire history of the given branch as opposed to getting most recent history for all branches so just wondering

@JackPGreen
Copy link
Copy Markdown
Contributor Author

does this improve efficiency? do you have before and after timings?

Difficult to benchmark in a real repo with a large history without merging arbitrary PRs, but...

Previously took 104 seconds in the Backport step, setting up the repo before it even starts running the backport script (i.e. up to Backporting the last commit from), but with this change it drops to 57 seconds.

@JackPGreen
Copy link
Copy Markdown
Contributor Author

I'm not convinced the problem this PR is trying to address is solvable - Git requires commit history to effectively compute a diff for cherry-pick.

We do a shallow checkout and then a bunch of fetch workarounds to deepen it which is confusing, but this PR does something similar with --unshallow and it's not really an improvement.

@JackPGreen JackPGreen closed this Dec 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants