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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 4, 2014, 17:14 UTC
Message-ID: <xmqqmwafux3y.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqtx4nuy5k.fsf@gitster.dls.corp.google.com>

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

Show 16 quoted lines

> 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?

Show 7 quoted lines

> 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.