On November 30, 2024 11:08 AM, Caleb White wrote: >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
