git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [BUGREPORT] Why is git-push fetching content?

From
Sean Allred <allred.sean@gmail.com>
Date
Jul 8, 2023, 08:39 UTC
Message-ID
<m0pm52eqg5.fsf@epic96565.epic.com>
In-Reply-To
<m0zg46eueb.fsf@epic96565.epic.com>

Following up with the results of my bisect (more discussion below). I'm forced to conclude this may somehow have never worked as I'm expecting (even though I do recall it working well in a long-gone environment), but I'm very much hoping I just did the bisect incorrectly. (It's not a feature I need to use much.)

So, is this a bug or is this working as intended for a good reason?
Sean Allred <allred.sean@gmail.com> writes:
Show 31 quoted lines
> Thanks for the replies. I'd like to bump this up again. This has come up
> in a new context and I don't see a viable workaround for us that doesn't
> involve a rewrite of the process and an excessive amount of new
> infrastructure.
>
> I have a feeling this is somehow a general issue with promisor remotes,
> though I don't know enough about how they work to know where to start
> investigation. I've got what I believe to be minimal reproduction steps
> below.
>
> [...]
>
> I believe the following can be used with git-bisect to determine if this
> truly ever worked or is a regression:
>
>     setup:
>         #!/bin/bash
>
>         repo="https://github.com/vermiculus/testibus.git"
>         repo_dir="~/path/to/repo"
>
>         git clone --no-checkout --depth=1 --no-tags --filter=tree:0 "$repo" "$repo_dir"
>         git -C "$repo_dir" remote set-url origin unreachable
>
>     bisect script:
>         git -C "$repo_dir" rev-list --objects --all
>
>         (obviously using the just-built git)
>
> I'm going to start running this bisect, but I suspect it will take a
> while, so I wanted to get this out there.
I ended up using a bisect script that looks like this
    #!/bin/bash
    make clean
    NO_GETTEXT=1 make -j8 || exit 125
    ./bin-wrappers/git -C "$1" rev-list --objects --all || exit 1
    git rev-parse HEAD >> ../good-commits
and running
    git bisect start main 637fc4467e57872008171958eda0428818a7ee03
    git bisect run ../bisect-script.sh ~/tmp/testibus/

It took less time than I thought, but unfortunately I was never able to actually find a 'good' commit. I arbitrarily chose "partial-clone: design doc" (Jeff Hostetler, Dec 14 2017) as the first commit to the partial-clone design document (under the assumption that it worked at some point). If potentially lying to git-bisect in this way is especially liable to bust it, I can start the exponentially-more- expensive process of testing every commit along --first-parent, but I suspect this may have never worked as I'm expecting.

-- Sean Allred

Previous: Sean AllredNext: Sean Allred
Message 6 of 7 in “[BUGREPORT] Why is git-push fetching content?”
  1. Sean AllredFeb 21, 2023
  2. brian m. carlsonFeb 21, 2023
  3. Sean AllredFeb 22, 2023
  4. Tao KlerksJun 20, 2023
  5. Sean AllredJul 8, 2023
  6. Sean AllredJul 8, 2023
  7. Sean AllredFeb 22, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.