On Mon, Aug 31, 2015 at 10:06 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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)? Yeah, it's the latter. -- 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