public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: ronan@rjp•ie
Cc: "Chris Torek" <chris.torek@gmail•com>, git@vger•kernel.org
Subject: Re: Git pull without fetch
Date: Fri, 17 Feb 2023 18:46:56 -0800	[thread overview]
Message-ID: <xmqqo7prk7vj.fsf@gitster.g> (raw)
In-Reply-To: <fc7d9fdde0443532eb9c32f26f9f054e@rjp.ie> (ronan@rjp.ie's message of "Sat, 18 Feb 2023 02:02:21 +0000")

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.

  reply	other threads:[~2023-02-18  2:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2023-02-18  4:33       ` ronan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqo7prk7vj.fsf@gitster.g \
    --to=gitster@pobox$(echo .)com \
    --cc=chris.torek@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=ronan@rjp$(echo .)ie \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox