Junio C Hamano wrote: > Michael Haggerty <mhag...@alum.mit.edu> writes:
>> We will want to be able to hold the lockfile for `packed-refs` even >> after we have activated the new values. So use a separate tempfile, >> `packed-refs.new`, as a place to stage the new contents of the >> `packed-refs` file. For now this is all done within >> `commit_packed_refs()`, but that will change shortly. >> >> Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu> >> --- > > The layout created by "contrib/workdir/git-new-workdir" will be > broken by this line of change. "git worktree" is supposed to know > that refs/packed-refs is a shared thing and lives in common-dir, > so it shouldn't be affected. > > Do we care about the ancient layout that used symlinks to emulate > the more modern worktree one? I think we do care. In the context of people's changing workflows, "git worktree" is a relatively new tool. Breaking the older git-new-workdir (and tools that emulate it) would affect a large number of users that don't necessarily know how to clean up the result. Thanks, Jonathan
