* Git pull without fetch
@ 2023-02-18 0:09 ronan
[not found] ` <CAPx1Gvd8vizeyveKgE2o2GStQsiGxN4aaASqYc81Nk28ogFLJg@mail.gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: ronan @ 2023-02-18 0:09 UTC (permalink / raw)
To: git
Dear maintainers,
I use the git-maintenance prefetch task with a certain repo to periodically
fetch updates from the remote. I'm trying to figure out a way to have git
"complete" a prefetch on command, via an option, alias, or other extension that
mimics the behavior of git pull, but does not fetch from the remote. By
comparison, `git pull` or `git fetch && git rebase` would fetch the remote and
fast-forward my local copy to match, but I don't want to fetch the remote.
Instead I want to fast-forward my current branch (and the remote tracking
branch) to the prefetched tip as if git pull had been run at the time of the
last prefetch.
For example, suppose my local copy has a branch master that tracks the remote
branch master from origin. Suppose that the local copy (and the remote tracking
branch) have commits A--B, the remote has commits A--B--C--D, and commit C has
been prefetched and is pointed to by refs/prefetch/remotes/origin/master. The
desired effect could be accomplished, I think, by:
git update-ref refs/remotes/origin/master refs/prefetch/remotes/origin/master refs/heads/master &&
git rebase origin/master master
My question is, how can I calculate the correct remote tracking branch to
accomplish this operation in the general case, just as git pull without argument
would have done? Or is there a simpler way to achieve my goal?
Cheers,
Ronan
^ permalink raw reply [flat|nested] 4+ messages in thread[parent not found: <CAPx1Gvd8vizeyveKgE2o2GStQsiGxN4aaASqYc81Nk28ogFLJg@mail.gmail.com>]
* Re: Git pull without fetch [not found] ` <CAPx1Gvd8vizeyveKgE2o2GStQsiGxN4aaASqYc81Nk28ogFLJg@mail.gmail.com> @ 2023-02-18 2:02 ` ronan 2023-02-18 2:46 ` Junio C Hamano 0 siblings, 1 reply; 4+ messages in thread From: ronan @ 2023-02-18 2:02 UTC (permalink / raw) To: Chris Torek, git February 17, 2023 6:46 PM, "Chris Torek" <chris.torek@gmail•com> wrote: > `git pull` = `git fetch` followed by a second command, either `git merge` or `git rebase`. If you > don't want the `git fetch` step, run the *second* command, instead of running *both* commands: it's > really just that simple. No it isn't. Sorry, but I think you have misunderstood the problem. I'm well aware of the behavior of git pull. In the scenario described, `git rebase` will always report "Already up to date" because the head of the current branch and the head of the remote tracking branch are the same. The prefetched reference lives under refs/prefetch/* and is unnoticed by git rebase. This is why I used `git update-ref ...` first: to update the remote tracking branch from the prefetched copy. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Git pull without fetch 2023-02-18 2:02 ` ronan @ 2023-02-18 2:46 ` Junio C Hamano 2023-02-18 4:33 ` ronan 0 siblings, 1 reply; 4+ messages in thread From: Junio C Hamano @ 2023-02-18 2:46 UTC (permalink / raw) To: ronan; +Cc: Chris Torek, git ronan@rjp•ie writes: > In the scenario described, `git rebase` will always report "Already up to date" > because the head of the current branch and the head of the remote tracking > branch are the same. The prefetched reference lives under refs/prefetch/* and is > unnoticed by git rebase. This is why I used `git update-ref ...` first: to > update the remote tracking branch from the prefetched copy. That is very much working as designed. Prefetching is merely a performance thing---until the user explicitly says "I want to update my view of the other side by fetching and updating the remote tracking branches" with "git fetch", it will not disrupt refs/remotes/origin/* refs, and because of prefetching, when the user finally gets around to say that, observation of the other side with a real fetch would go faster, requiring fewer objects to be transmit. And if somebody wants to lie to the system and say "pretend we did not fetch anything", then yes, _knowing_ that implementation detail of refs/prefetch/* hierarchy and taking advantage of it by using "update-ref" would be a way to achieve that. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Git pull without fetch 2023-02-18 2:46 ` Junio C Hamano @ 2023-02-18 4:33 ` ronan 0 siblings, 0 replies; 4+ messages in thread From: ronan @ 2023-02-18 4:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: Chris Torek, git > That is very much working as designed. Yes, I realize. I'm not reporting a bug. I guess I just think it would be handy to more conveniently reach the prefetched updates when I'm offline, and I gather from conversation there is no method builtin to git. For now I've settled on this to be "pretend fetch": $ git for-each-ref refs/prefetch/ --format='update refs/%(refname:lstrip=2) (refname)' | git update-ref --stdin which I can follow-up with a no-argument `git rebase`, similar to a `git pull` if the remote was available. In my original question I had intended only to update the upstream of my current branch, but I've decided that's not necessary for me. However, I have found that it is possible to get the upstream reference for the current branch like so: $ git rev-parse --symbolic-full-name '@{upstream}' refs/remotes/origin/master using this it should be possible to find the corresponding prefetched reference in refs/prefetch if it exists and only update that reference without parsing "branch.<name>.remote", "remote.<name>.fetch", and "branch.<name>.merge" myself. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-02-18 4:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-02-18 0:09 Git pull without fetch ronan
[not found] ` <CAPx1Gvd8vizeyveKgE2o2GStQsiGxN4aaASqYc81Nk28ogFLJg@mail.gmail.com>
2023-02-18 2:02 ` ronan
2023-02-18 2:46 ` Junio C Hamano
2023-02-18 4:33 ` ronan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox