Re: [PATCH 00/11] nd/worktree-move update

Duy Nguyen [off-list ref] writes:

On Fri, Feb 3, 2017 at 3:21 AM, Junio C Hamano [off-list ref] wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

Also, the more important reply was Peff's reply that suggested that the
proposed fix was incomplete, as it misses --unpack-unreachable:
https://public-inbox.org/git/20160601160143.GA9219@sigill.intra.peff.net/

While I think that --unpack-unreachable thing is a symptom of the
basic approach of patching things up at the wrong level, if you are
hinting that fix to the issue that gc does not pay attention to
various anchoring point in other worktrees is more important than
adding new commands to "worktree", I fully agree with that.

Just to make it clear. It's not like I put new worktree commands on
higher priority.

Good; we are on the same page.

"worktree move/remove" was more or less ready for a
long time and the gc problem was blocked by ref-iterator series (which
entered master a few moths ago, but then I was busy with other things
and couldn't get right back to the gc issue).

OK.

You didn't answer Johannes's rhetoric question though: "It should be
possible to do that redesign work while having a small workaround in
place that unbreaks, say, me?"

I do not recall seeing that.  I however deliberately ignored another
statement because I thought it enough to answer, which was:

    Given that
    https://public-inbox.org/git/xmqqy46ntrhk.fsf@gitster.mtv.corp.google.com/
    seems to have expected something to happen within a reasonable time frame,
    and that 8 months is substantially longer than a reasonable time frame, I
    am not sure that that position can still be defended.

In the message xmqqy46ntrhk is a response to, Michael enumerated the
issues need to be solved with priorities, and listed reachability
from the index and per-worktree detached HEAD are more important
than others.  I was hoping that even these "relatively more
important" ones would turn out be of less importance compared to
fixing all on the right foundation as long as it won't take forever,
but I do agree with Dscho that 8 months is way too long.

I assume "the right way" is still updating refs subsystem so that we
can have a ref iterator to traverse all refs, or just one worktree,
etc. Should I keep looking for a middle ground (maybe better than the
linked series) to "unbreak Johannes"? I ignored all those comments
(about --unpack-reachable and bisect refs) because I saw no chance of
an updated series getting in git.git anyway.

So, you may have seen no chance 8 months ago; after we have been
waiting for a better fix, which hadn't materialized for a while, I
am very much open to change the priority.

Even if you think "the right way" is to add to the iterators, I
suspect that we can still do incremental fixes?  I agree with the
order of importance Michael listed in his message (i.e. the index
and the HEAD first, and then other per-worktree hierarchies at lower
priority), and I suspect you do, too.  I am not sure that is what
you called "middle ground", but I think such an incremental approach
is totally fine.

On Sat, Feb 4, 2017 at 1:25 AM, Junio C Hamano [off-list ref] wrote:

Even if you think "the right way" is to add to the iterators, I
suspect that we can still do incremental fixes?  I agree with the
order of importance Michael listed in his message (i.e. the index
and the HEAD first, and then other per-worktree hierarchies at lower
priority), and I suspect you do, too.  I am not sure that is what
you called "middle ground", but I think such an incremental approach
is totally fine.

Yeah index should be fixed independently. Sorry that thought did not
occur to me. I counted HEAD as a ref too (i.e. to be managed/iterated
by refs subsystem) but I guess it's special enough to be dealt with
without ref iterator. I will try to fix these two first.

By middle ground, I was thinking that, now that we have ref iterator
interface, we more or less know what the api should look like for a
ref user like rev-list, so perhaps we could add a custom (ugly)
iterator for per-worktree refs (including reflog). The ugliness is
probably buried in refs/files-backend.c again until we clean it up.
-- 
Duy