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

[David Turner <dturner@twopensource.com>]

On Mon, 2015-08-31 at 07:36 -0700, Junio C Hamano wrote:
> Christian Couder <christian.couder@gmail.com> writes:
> 
> >> * dt/refs-bisection (2015-08-28) 5 commits
> >>  - bisect: make bisection refs per-worktree
> >>  - refs: make refs/worktree/* per-worktree
> >>  - SQUASH???
> >>  - path: optimize common dir checking
> >>  - refs: clean up common_list
> >>
> >>  Move the refs used during a "git bisect" session to per-worktree
> >>  hierarchy refs/worktree/* so that independent bisect sessions can
> >>  be done in different worktrees.
> >>
> >>  Will merge to 'next' after squashing the update in.
> >
> > Sorry if I am missing something or repeating what myself or someone
> > else like Michael already said, but in the current doc there is:
> >
> >        Eventually there will be no more revisions left to bisect, and
> > you will have been left with the first bad kernel revision in
> >        "refs/bisect/bad".
> >
> > If we now just use "refs/worktree/bisect/bad" instead of
> > "refs/bisect/bad", it might break scripts that rely using
> > "refs/bisect/bad".
> 
> 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 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".