From: Junio C Hamano <gitster@pobox.com>
To: Caleb White via B4 Relay <devnull+cdwhite3.pm.me@kernel.org>
Cc: git@vger.kernel.org, Caleb White <cdwhite3@pm.me>
Subject: Re: [PATCH v3 2/3] worktree: link worktrees with relative paths
Date: Tue, 08 Oct 2024 16:09:51 -0700 [thread overview]
Message-ID: <xmqqmsjexkcg.fsf@gitster.g> (raw)
In-Reply-To: <20241007-wt_relative_paths-v3-2-622cf18c45eb@pm.me> (Caleb White via's message of "Mon, 07 Oct 2024 22:12:31 -0500")
Caleb White via B4 Relay <devnull+cdwhite3.pm.me@kernel.org> writes:
> From: Caleb White <cdwhite3@pm.me>
>
> Git currently stores absolute paths to both the main repository and
As always, drop "currently".
The usual way to compose a log message of this project is to
- Give an observation on how the current system work in the present
tense (so no need to say "Currently X is Y", just "X is Y"), and
discuss what you perceive as a problem in it.
- Propose a solution (optional---often, problem description
trivially leads to an obvious solution in reader's minds).
- Give commands to the codebase to "become like so".
in this order.
> linked worktrees. However, this causes problems when moving repositories
The above claim is way too strong. When relative references are
used, you can move directories without problems only if you move all
the worktrees and the repository in unison without breaking their
relative locations, which is an exception and not the norm.
The repository knows where its extra worktrees are by their
absolute paths (and vice versa) to allow discovery of each
other. When a directory is moved, "git worktree repair" must be
used to adjust these references.
It however becomes possible, in a narrow special case, to do
without "git worktree repair". When the repository and the
worktrees move in parallel without breaking their relative
location, the repair operation becomes unneeded if we made them
refer to each other using relative paths (think: tarring up both
the reposity and the worktrees at the same time, and then
untarring the result at a different place).
or something, perhaps.
> Although Git now writes relative paths, existing repositories with
> absolute paths are still supported. There are no breaking changes
> to workflows based on absolute paths, ensuring backward compatibility.
Good. Being able to work with existing repositories is an absolute
requirement. Are there good test cases? I would imagine that you
would need to force a worktree and its repository to refer to each
other using absolute paths and then try to access with the updated
code, perhaps moving one of such "old-style" directory and then
using the updated "git worktree repair" and observing the result.
To allow such a test possible, you might even need an option to "git
worktree" to allow it to create these linkages using absolute paths,
not relative (and if you need to keep both possibilities anyway, you
might make the newer "relative" layout an optional feature,
triggered by a command line option given to "git worktree add" and
friends).
Have we considered how badly existing third-party tools, that has
learned to assume that the paths are aboslute, may break with this
change, though? Or is this "we won't know until we inflict it on
real users and see who screams"?
Thanks.
next prev parent reply other threads:[~2024-10-08 23:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 3:12 [PATCH v3 0/3] Link worktrees with relative paths Caleb White via B4 Relay
2024-10-08 3:12 ` [PATCH v3 1/3] worktree: refactor infer_backlink() to use *strbuf Caleb White via B4 Relay
2024-10-10 15:52 ` shejialuo
2024-10-10 16:41 ` Caleb White
2024-10-10 17:26 ` shejialuo
2024-10-10 17:52 ` Caleb White
2024-10-10 20:03 ` Junio C Hamano
2024-10-10 20:24 ` Caleb White
2024-10-10 19:14 ` Junio C Hamano
2024-10-08 3:12 ` [PATCH v3 2/3] worktree: link worktrees with relative paths Caleb White via B4 Relay
2024-10-08 23:09 ` Junio C Hamano [this message]
2024-10-09 18:34 ` Caleb White
2024-10-09 19:10 ` Junio C Hamano
2024-10-09 19:19 ` Caleb White
2024-10-09 23:37 ` Junio C Hamano
2024-10-10 17:30 ` Caleb White
2024-10-11 4:03 ` Caleb White
2024-10-22 4:32 ` Caleb White
2024-10-09 10:11 ` Phillip Wood
2024-10-09 18:49 ` Caleb White
2024-10-08 3:12 ` [PATCH v3 3/3] worktree: add test for path handling in linked worktrees Caleb White via B4 Relay
2024-10-08 4:48 ` [PATCH v3 0/3] Link worktrees with relative paths Caleb White
2024-10-08 19:00 ` Junio C Hamano
2024-10-08 21:55 ` Caleb White
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=xmqqmsjexkcg.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=cdwhite3@pm.me \
--cc=devnull+cdwhite3.pm.me@kernel.org \
--cc=git@vger.kernel.org \
/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 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 NNTP newsgroup(s).