Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

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

Junio C Hamano <gitster@pobox.com> writes:

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> * nd/multiple-work-trees (2014-07-29) 39 commits
>>>
>>>  Reroll posted, but haven't picked up yet.  How would this interact
>>>  with rr/transaction series which is pretty much all about the refs?
>>
>> Haven't checked out that topic yet. But ref changes in
>> multiple-work-trees are to make sure ref path construction goess
>> through git_path(), and some cleaning up after strbuf_git_path() is
>> introduced. So basically textual conflicts only.
>
> Up to the point that is queued on 'pu', the other topic(s) still
> keep the assumption that all refs are files in $GIT_DIR/refs/, and I
> think I managed the textual conflicts correctly in 'pu' before.

One point that caused unnecessary conflict resolution was that the
transaction series lacked "let's use strbuf to hold paths".  This
had two immediate side effects, i.e. "instead of returning upon
errors, jump to the end with 'goto done/fail' for necessary
clean-up" and "get rid of git_snpath and use strbuf_git_path", both
of which are good general clean-ups, even if they weren't related to
the multiple worktrees feature, that conflicted with the transaction
series when getting merged.

You can see the interactions by checking

    $ git show 'pu^{/^Merge branch .nd/multi}' refs.c

Perhaps these three changes, without the addition of the multiple
worktree feature, should come first as a general clean-up on top of
which both topics can be built?

> But starting from $gmane/255476 the assumption gradually gets lifted
> and eventually we may have refs and reflogs expressed in a different
> backend, without these files that represent the refs at all.
>
> I am not yet sure how this "I have $GIR_DIR/ but that is not a real
> one but borrows most of the stuff from elsewhere" meshes with that
> new world.