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

[Christian Couder <christian.couder@gmail.com>]

On Mon, Aug 31, 2015 at 10:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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)?

Yeah, it's the latter.