Re: [PATCH v3 2/6] notes: replace pseudorefs with real refs
- From
Johan Herland <johan@herland.net>
- Date
- Jul 28, 2015, 23:43 UTC
- Message-ID
- <CALKQrgfxc83-yjrCWZqC+pyPhbQDgYbrpCDSaBk78YypO=BXOg@mail.gmail.com>
- In-Reply-To
- <xmqqpp3bc2u6.fsf@gitster.dls.corp.google.com>
On Wed, Jul 29, 2015 at 12:52 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> Johan Herland <johan@herland.net> writes: >> However, in any case, notes merges are always per _repo_ and never per >> _worktree_, so this is all unrelated to the current patch/discussion >> AFAICS. > > Thanks for chiming in, but I actually think you are confused. > > "git merge" is always per _repo_ in the sense that the result of a > merge of a topic to the 'master' is recorded in the 'master' which > is per-repo. In the multi-worktree world order, that does not > change. What changes is that you could have different worktrees > that check out different branches. Worktree A may have 'master' > checked out and do the merge there to update the tip of 'master'. > But while worktree A is doing that, worktree B may have 'next' > checked out and do an unrelated merge there. Once worktree A leaves > 'master' by checking out another branch, worktree B is free to check > out 'master' and do further merges there. Merging into 'master' is > per _repo_, but the act of merging is per worktree.
Agreed thus far.
> I think merges of refs/notes/commits and refs/notes/someotherthing > works exactly the same way. In worktree A, you may decide to merge > a notes tree refs/notes/commits with somebody else's.
Here is where we start to differ. I would say that starting a notes merge is completely unrelated to your worktree. Consider this:
When you start a "regular" (non-notes) merge in worktree A, that merge will "occupy" worktree A for the purpose of completing the merge, e.g. conflicting files will be checked out inside worktree A, and it is obvious that you cannot do other/unrelated things in worktree A until you have resolved the conflicts and completed the merge. As such, a regular merge is inextricably bound to a specific worktree.
This is not the case for notes merges. If I start a notes merge from worktree A, there is no "occupation" of that worktree. Before the notes merge is resolved, I can do whatever I want in worktree A (including checking out a different branch, performing a rebase, whatever...). Instead, the notes merge creates its own worktree (that is "occupied" until the notes merge is completed), which is completely unrelated to worktree A.
Show 5 quoted lines
> It may > conflict and you may need to "lock" refs/notes/commits from being > touched by other worktrees while resolving that, but that does not > mean other worktrees cannot do a merge of refs/notes/someotherthing > at all.
In principle, I agree that an ongoing notes-merge into refs/notes/someotherthing should be able to coexist with an ongoing notes-merge into refs/notes/commits. However, it does not make sense to bind those notes-merges to a specific worktree.
Let's say I have two worktrees, A and B, and from worktree A, I have started a notes-merge into refs/notes/commits. Now:
- From worktree B I should NOT be able to start another notes-merge into refs/notes/commits.
- From worktree B I SHOULD be able to start another notes-merge into refs/notes/someotherthing
But this doesn't really have anything to do with worktree B. I can just as easily say:
- From worktree A I should NOT be able to start another notes-merge into refs/notes/commits.
- From worktree A I SHOULD be able to start another notes-merge into refs/notes/someotherthing
My conclusion is therefore that binding a notes merge to a specific worktree does not make any sense. Preventing simultaneous notes merges into the same notes ref is something that must be solved per _repo_ (and not per worktree), and since the worktree plays no part in the resolution/completion of the notes merge, it makes more sense to place all the notes-merge-related refs/files inside the _repo_, and not inside the worktree.
Now, we do not yet support simultaneous notes merges at all, but my follow-on point is that the addition of such support is wholly independent of the multi-worktree support. For now, it would make more sense to only allow a single notes-merge across all worktrees. I.e. when starting a notes-merge from ANY worktree, it should simply fail if there is an existing unresolved notes merge (no matter which worktree started that unresolved notes merge).
> The temporary area you use for merging notes, i.e. the > working tree as far as notes merge is concerned, is private to > worktree A and does not need to be seen by other worktrees.
Disagree. The private area used to resolve notes merges should be per _repo_, not per worktree. That is IMHO the only sane way to (in the future) prevent simultaneous notes merges going into the same notes ref.
Show 6 quoted lines
> So while you are working on merging and resolving, that intermediate > state is *NOT* per _repo_ at all. It is at most per worktree (Yes > you could extend and have one notes_merge_ref per each refs/notes/* > ref to make it even finer grained to allow more than one notes merge > going on inside a single worktree, but I do not think it is worth > it).
As stated above, my position is that while you are resolving a notes merge, the worktree from which you started that notes merge is completely irrelevant. In fact, you can easily do a notes merge in a _bare_ repo...
...Johan
-- Johan Herland, <johan@herland.net> www.herland.net