Re: git fetch --dry-run changes the local repo and transfers data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks.  What threw me is that I expected it to be "very fast" and
"very cheap" . If I commit a multi-gig file on the server, I see the
dry-run fetch takes several seconds (clearly indicating some work
proportional to the server repo size).  I don't want to transfer that
file on a dry-run, I hoped the server and client were both
dry-running, andb the server could simply say "here's metadata for
what I _would have_ returned if this was real".  Not possible?

Tim

On Tue, Dec 27, 2022 at 4:52 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Tim Hockin <thockin@xxxxxxxxxx> writes:
>
> > I'm trying to test if a remote repo has a given SHA. `ls-remote` does
> > not work for this unless it is a tag or a HEAD (which is not
> > guaranteed for this case).
> >
> > `git fetch --dry-run $remote $rev` SEEMS to fit the bill, except it
> > changes local state. For example:
>
> Well, without changing the "local state", you cannot see if that
> report repository has or does not have the commit.
>
> > FETCH_HEAD was not updated (good)
>
> None of your refs are updated, either.
>
> There are things that are not reachable from your refs (or other
> anchoring points like the index and the reflog).  As far as Git is
> concerned, they don't exist [*], and that is why Git will happily
> remove them with "git gc", for example.  They are crufts and it is
> easier to think of them as not a part of "local data".
>
> So I suspect that ...
>
> > but the rev in question is now
> > present locally (bad),
>
> ... this complaint is a bit misguided.  After all, the procdure you
> gave above is exactly how you would ask the "I'm trying to test if a
> remote repo has a given SHA" question about commit f80f1b23b4ca.  If
> the operation did not transfer data, you would not be able to get
> the answer to that question.
>
> > Am I using --dry-run wrong (or misunderstanding its purpose)?
>
> Maybe (mis)understanding on Git's data model (see above [*]) is the
> root cause of this confusion.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux