RE: [PATCH v2 0/3] Ensure unique worktree ids across repositories

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Nov 30, 2024, 17:16 UTC
Message-ID: <010801db434b$ac0ec960$042c5c20$@nexbridge.com>
In-Reply-To: <D5ZN60S3JMS8.UXLUSM5IOFCX@pm.me>

On November 30, 2024 11:08 AM, Caleb White wrote:

Show 21 quoted lines

>On Fri Nov 29, 2024 at 6:38 PM CST, rsbecker wrote:
>> On November 29, 2024 7:09 PM, Caleb White wrote:
>>>If the `develop` directory is deleted, cleanup detection is handled by
>>>the `git worktree prune` command, which will remove worktrees under
>>>`.git/worktrees/*` that are no longer valid. This happens
>>>automatically after the expiry time or it can be executed manually. Of
>>>course, executing `git worktree remove develop` will also remove the worktree
>and its associated worktree id.
>>
>> This last bit is an assumption, and not necessarily valid. Scripts
>> that use worktrees may maintain lists or their own pointers. It is
>> important to be able to emulate cleanup functions - something I
>> discovered early in the worktree functions when released. I need to
>> make sure that cleanup will continue to have enough information -
>> prior to git worktree cleanup - to function correctly. This will need
>> coordination with people who have such scripts in my community. It
>> probably will not impact you, but I would have appreciated more than one release
>notice on this capability.
>
>I'm not sure I understand the specific use-case you're talking about.
>Could you provide an example?

Speaking as a professional product manager...

I'm not expressing "maintaining compatibility for 2 releases" or something like that is a reasonable use case. There are customers who depend on things working in a particular way. It is fine if you want to change it and improve it, and I am supportive. However, when making a change that causes git to behave differently without allowing people to plan for such a change is impolite. People outside this list do not read each patch looking for compatibility breaking changes - they only get told in release notes. A statement like "this is going to change with 2.49" for a breaking enhancement is what I would expect - unless it is a defect correction.

>However, I suppose I can add a config / env variable to be able to disable this new
>functionality.

That would be very helpful although an opt-in is generally better than an opt-out.

I think we should have this as a general policy, not just for this series.

Thanks, Randall