Re: What's cooking in git.git (Aug 2015, #05; Fri, 28)

[Junio C Hamano <gitster@pobox.com>]

David Turner <dturner@twopensource.com> 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)?