All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Yoichi NAKAYAMA via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Yoichi Nakayama <yoichi.nakayama@gmail.com>
Subject: Re: [PATCH v3] worktree repair: detect relative path in .git file correctly
Date: Fri, 21 Aug 2026 15:20:56 -0700	[thread overview]
Message-ID: <xmqq4ignyv1z.fsf@gitster.g> (raw)
In-Reply-To: <xmqq8q5zyvwd.fsf@gitster.g> (Junio C. Hamano's message of "Fri, 21 Aug 2026 15:02:42 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Among these three, the last one obviously belongs here.  Leaving the
> relative path relative was the reason why we wanted to add
> read_gitfile_raw() in the first place.
>
> But moving the other two to here is a bit iffy.  The worktree repair
> job used to call read_gitfile_gently(), which means it used to
> depend on what the first two did for it, namely, to make the
> relative path after "gitdir:" from the .git file relative to the
> current process to make it usable, and to ensure that the directory
> pointed at by .git is indeed a git directory.  Is it correct to drop
> these from the caller, which now calls read_gitfile_raw() instead?
>
> IOW, I am not sure if the two functions are split correctly.  I
> expected that the only two things read_gitfile_gently() would do
> after read_gitfile_raw() are (1) upon error, jump to cleanup_return,
> and (2) otherwise call strbuf_realpath().

Actually, I take half of that back.  If we pretend the leading part
of the "path", which could be absolute, the result will lose the
relative-ness of the original.  Keeping the tweaking of the relative
path in read_gitfile_gently() is reasonable.  As is_git_directory()
needs to be called on a usable path, if the relative path tweaking
cannot be done inside read_gitfile_raw(), it cannot check if the
directory is is_git_directory(), either.

So, the change to setup.c is fine as is.  I didn't look at the
changes to worktree.c, though.

Thanks.

      reply	other threads:[~2026-08-21 22:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-15 13:11 [PATCH] worktree repair: detect relative path in .git file correctly Yoichi NAKAYAMA via GitGitGadget
2026-08-17 17:21 ` Junio C Hamano
2026-08-17 21:27   ` Yoichi Nakayama
2026-08-20 15:46 ` [PATCH v2] " Yoichi NAKAYAMA via GitGitGadget
2026-08-21  2:09   ` Junio C Hamano
2026-08-21 20:36 ` [PATCH v3] " Yoichi NAKAYAMA via GitGitGadget
2026-08-21 22:02   ` Junio C Hamano
2026-08-21 22:20     ` Junio C Hamano [this message]

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=xmqq4ignyv1z.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=yoichi.nakayama@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.