From: Luke Diamand <luke@diamand.org>
To: Stefan Beller <sbeller@google.com>
Cc: Git Users <git@vger.kernel.org>, Duy Nguyen <pclouds@gmail.com>,
Jeff King <peff@peff.net>
Subject: Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?
Date: Wed, 15 Nov 2017 21:38:26 +0000 [thread overview]
Message-ID: <CAE5ih79TojvBv4OZnHejm3Huypg=6KVmDqJURGN+uk+izkH0xw@mail.gmail.com> (raw)
In-Reply-To: <CAGZ79kZrZckX=xTgTH4cMper6BPAQ-_LT_x721SBEBB+Ks06jw@mail.gmail.com>
+Jeff King
On 13 November 2017 at 22:15, Stefan Beller <sbeller@google.com> wrote:
> On Mon, Nov 13, 2017 at 2:03 PM, Luke Diamand <luke@diamand.org> wrote:
>> On 13 November 2017 at 19:51, Luke Diamand <luke@diamand.org> wrote:
>>> Hi!
>>>
>>> I think there may be a regression caused by this change which means
>>> that "git fetch origin" doesn't work:
>>>
>>> commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad)
>>> Author: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>>> Date: Wed Aug 23 19:36:59 2017 +0700
>>>
>>> revision.c: --all adds HEAD from all worktrees
>>>
>>> $ git fetch origin
>>> fatal: bad object HEAD
>>> error: ssh://my_remote_host/reponame did not send all necessary objects
>>>
>>> I used git bisect to find the problem, and it seems pretty consistent.
>>> "git fetch" with the previous revision works fine.
>>>
>>> FWIW, I've got a lot of git worktrees associated with this repo, so
>>> that may be why it's failing. The remote repo is actually a git-p4
>>> clone, so HEAD there actually ends up pointing at
>>> refs/remote/p4/master.
>>>
>>> Thanks,
>>> Luke
>>
>> Quite a few of the worktrees have expired - their head revision has
>> been GC'd and no longer points to anything sensible
>> (gc.worktreePruneExpire). The function other_head_refs() in worktree.c
>> bails out if there's an error, which I think is the problem. I wonder
>> if it should instead just report something and then keep going.
>
> Also see
> https://public-inbox.org/git/CAGZ79kYP0z1G_H3nwfmSHraWHMBOcik5LepUXKj0nveeBrihiw@mail.gmail.com/
So is this a bug or user error on my part?
Surely at the very least "git fetch" shouldn't give a cryptic error
message just because one of my git worktrees has expired!
next prev parent reply other threads:[~2017-11-15 21:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 19:51 Bug in "revision.c: --all adds HEAD from all worktrees" ? Luke Diamand
2017-11-13 22:03 ` Luke Diamand
2017-11-13 22:15 ` Stefan Beller
2017-11-15 21:38 ` Luke Diamand [this message]
2017-11-17 22:03 ` Jeff King
2017-11-15 22:08 ` Junio C Hamano
2017-11-16 1:06 ` Luke Diamand
2018-03-12 21:39 ` Ævar Arnfjörð Bjarmason
2018-03-13 11:22 ` Duy Nguyen
-- strict thread matches above, loose matches on Subject: below --
2018-03-13 18:23 Stan Hu
2018-03-13 20:29 ` Ævar Arnfjörð Bjarmason
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE5ih79TojvBv4OZnHejm3Huypg=6KVmDqJURGN+uk+izkH0xw@mail.gmail.com' \
--to=luke@diamand.org \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).