Re: [PATCH v3 2/6] notes: replace pseudorefs with real refs
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 30, 2015, 16:24 UTC
- Message-ID
- <xmqqoait7gwt.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CALKQrgeLMWCKzEnPfv_WeL1-=eDQYtEk=tOejSG4JwPaoEGt=Q@mail.gmail.com>
Johan Herland <johan@herland.net> writes:
Show 7 quoted lines
>> Actually, the name "linked worktree" is probably a misnomer. >> ... > Makes sense, although currently, IINM, those multiple $GIT_DIRs must > be associated with strictly different branches, which is completely > unrelated to the desired notes-merge restriction (which applies to > notes refs - not branches). But this has been discussed to death, > already.
Yeah, when we enhance "linked worktree" to make it easier to create "bare worktree", we'd need to make sure it is easy to make them in the detached HEAD state, i.e. not tied to any particular branch.
Show 13 quoted lines
>> The user could attempt to start different notes merges in her >> multiple $GIT_DIRs. The question is to what degree we want to >> support her. >> >> Is it sufficient to have these per $GIT_DIR, when the user has two >> $GIT_DIRs connected to the same repository and wants to do two >> "notes merge" acting on different ref in refs/notes/*? Or are there >> some other states in the shared part kept, which would be stomped on >> by simultaneously running "notes merge" instances in different >> $GIT_DIRs, that make this not to work? Any other problems in the >> remainder of the current implementation of "notes merge"? > > Still, I believe the answer is "No".
Good. So the following would be a viable way forward.
Show 9 quoted lines
>> But if there isn't, "[PATCH] notes: handle multiple worktrees" is >> the absolute minimum thing we could >> do to make "notes merge" usable by making sure that the user does >> not attempt merging the same refs/notes/commits in two different >> places. > > Sure. There's no point in delaying a patch that works well in practice > just because I have a delusion of a theoretically cleaner solution > that won't make any difference in practice.
I think the part of that patch that refactors the mechanism to notice and disallow symrefs pointing at the same thing (with various tweaks suggested during the review) is a good idea in the longer term. If we were to switch to a "you can do multiple notes merges inside a single repository without any additional linked worktree" paradigm in the future, we would not want (or need) to use that "avoid pointing this symref to the same thing" code for notes merge codepath, but that is not something we need to decide now.