git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johan Herland <johan@herland.net>
Cc: David Turner <dturner@twopensource.com>,
	Git mailing list <git@vger.kernel.org>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Philip Oakley <philipoakley@iee.org>
Subject: Re: [PATCH v3 2/6] notes: replace pseudorefs with real refs
Date: Thu, 30 Jul 2015 09:24:02 -0700	[thread overview]
Message-ID: <xmqqoait7gwt.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CALKQrgeLMWCKzEnPfv_WeL1-=eDQYtEk=tOejSG4JwPaoEGt=Q@mail.gmail.com> (Johan Herland's message of "Thu, 30 Jul 2015 08:05:15 +0200")

Johan Herland <johan@herland.net> writes:

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

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

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

  reply	other threads:[~2015-07-30 16:24 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-28 18:12 [PATCH v3 0/6] pseudorefs David Turner
2015-07-28 18:12 ` [PATCH v3 1/6] refs: Introduce pseudoref and per-worktree ref concepts David Turner
2015-07-28 18:12 ` [PATCH v3 2/6] notes: replace pseudorefs with real refs David Turner
2015-07-28 19:00   ` Junio C Hamano
2015-07-28 19:24     ` David Turner
2015-07-28 19:44     ` Junio C Hamano
2015-07-28 21:23       ` [PATCH] notes: handle multiple worktrees David Turner
2015-07-28 21:42         ` David Turner
2015-07-28 22:00           ` Junio C Hamano
2015-07-28 22:12         ` Junio C Hamano
2015-07-28 22:50           ` Johan Herland
2015-08-03 13:27             ` Duy Nguyen
2015-07-28 22:17         ` Eric Sunshine
2015-07-28 22:38       ` [PATCH v3 2/6] notes: replace pseudorefs with real refs Johan Herland
2015-07-28 22:52         ` Junio C Hamano
2015-07-28 23:43           ` Johan Herland
2015-07-29  0:33             ` Junio C Hamano
2015-07-29  0:56               ` Michael Haggerty
2015-07-29  1:23                 ` Jacob Keller
2015-07-29  1:24                 ` Johan Herland
2015-07-29  2:25                   ` Junio C Hamano
2015-07-29  2:00                 ` Junio C Hamano
2015-07-29  2:53                   ` Johan Herland
2015-07-29  5:00                     ` Junio C Hamano
2015-07-29  2:34               ` Johan Herland
2015-07-29  5:01                 ` Junio C Hamano
2015-07-29 13:19                   ` Johan Herland
2015-07-29 16:37                     ` Junio C Hamano
2015-07-29 16:58                       ` Junio C Hamano
2015-07-30  6:05                       ` Johan Herland
2015-07-30 16:24                         ` Junio C Hamano [this message]
2015-07-29  2:17             ` Junio C Hamano
2015-07-29  2:37               ` Johan Herland
2015-07-28 18:12 ` [PATCH v3 3/6] refs: add ref_type function David Turner
2015-07-29  6:32   ` Eric Sunshine
2015-07-28 18:12 ` [PATCH v3 4/6] pseudorefs: create and use pseudoref update and delete functions David Turner
2015-07-29  6:38   ` Eric Sunshine
2015-07-28 18:12 ` [PATCH v3 5/6] rebase: use update_ref David Turner
2015-07-28 18:12 ` [PATCH v3 6/6] sequencer: replace write_cherry_pick_head with update_ref David Turner
2015-07-28 19:01 ` [PATCH v3 0/6] pseudorefs Junio C Hamano
2015-07-28 19:07   ` David Turner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqoait7gwt.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    --cc=mhagger@alum.mit.edu \
    --cc=philipoakley@iee.org \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).