David Turner <dturner@xxxxxxxxxxxxxxxx> writes: >> Christian, thanks for raising this one. >> >> I do recall the thread and I might be the somebody like Michael you >> remember, e.g. $gmane/275105---which did mention that "git bisect" >> would not need changing if we kept refs/bisect/. >> >> What was the reason why we chose to move to refs/worktree/ again? I >> do not think there was an issue that we cannot keep refs/* in >> general shared while having one (or more) subhierarchy of it per >> worktree (otherwise we would not be using refs/worktree/*, but using >> something outside refs/, like $GIT_DIR/worktree-refs/). Was there an >> objection to refs/bisect being private from aesthetics point of view >> (i.e. forcing everything per-worktree in refs/worktree/ would prevent >> proliferation of refs/this and refs/that that need to be private >> case by case), ignoring the practical issue of compatibility issues >> around existing tools? > > That is correct. IIRC, on one of these patch sets, I proposed accepting > both new and old refs, but you said that would be unnecessary (it might > have been the notes/merge one instead of this one). I suspect it was notes-merge thing, but anyway, if you asked me right now, I certainly would say it is not OK to drop the old location but I may still say it is not worth having old and new with funny directory symlink like thing, because refs backend thing cannot say "I'll follow the symbolic link refs/bisect that points at refs/worktrees/bisect". But the reason why I say it is not worth is not because I do not think we need refs/bisect, but because I do not think we need refs/worktree/ at this point. In other words, throwing new hierarchies that are private to worktree into refs/worktree/ is fine if we discover the need for some new hierarchies in the future, but being able to access the bisection points as refs/worktree/bisect is not necessary. If people and tools are familiar with it being in refs/bisect, that location is fine. >> I think one example of script, "gitk --bisect", does want to show >> the DAG limited by bisect refs, but it does so using plumbing >> without having to say refs/bisect/bad itself. Perhaps the thinking >> (or lack of enough of it) went that no other uses by scripts need to >> peek directly into refs/bisect/ hierarchy? > > I did a quick search on github, and did not see any scripts that said > "refs/bisect". That's one data point, but not a very confidence-building one. Christian, did you see your private script break with this change, or as one of the larger stakeholder of "bisect" subsystem you wanted to proceed with caution (the latter I myself would share, actually)? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html