git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Mark Levedahl <mlevedahl@gmail.com>,
	Mikael Magnusson <mikachu@gmail.com>
Subject: Re: [PATCH 10/16] worktree: make branch creation distinct from worktree population
Date: Sun, 12 Jul 2015 09:48:24 +0700	[thread overview]
Message-ID: <CACsJy8A8CeyeYZnMpbdWW-etohp3TWzGrro1khzD=8skydm6Cg@mail.gmail.com> (raw)
In-Reply-To: <CAPig+cSiPeJskyanLAv71LuFoqPirUJ2FL0B0BsoT8BEVrE3LA@mail.gmail.com>

On Sun, Jul 12, 2015 at 9:36 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Jul 11, 2015 at 9:20 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Sat, Jul 11, 2015 at 7:05 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> The plan is eventually to populate the new worktree via "git reset
>>> --hard" rather than "git checkout". Thus, rather than piggybacking on
>>> git-checkout's -b/-B ability to create a new branch at checkout time,
>>> git-worktree will need to do so itself.
>>>
>>> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
>>> ---
>>>
>>> I considered calling branch-related API, such as create_branch(),
>>> directly, however, git-branch provides extra value which may be useful
>>> in the future (such as when --track and --orphan get added to
>>> git-worktree), so it seemed wise to re-use git-branch's implementation
>>> rather than duplicating the functionality. If this proves the wrong
>>> choice, then the series can either be re-rolled or follow-on patches can
>>> address the issue.
>>
>> I don't know much about ref handling code (especially after the big
>> transaction update), so i may be wrong, but do we need to invalidate
>> some caches in refs.c after this? The same for update-ref in the other
>> patch. We may need to re-read the index after 'reset --hard' too if we
>> ever need to do touch the index after that (unlikely though in the
>> case of 'worktree add')
>
> I'm not sure I understand. Are you talking about this patch's
> implementation or a possible future change which uses the C API rather
> than git-branch?
>
> If you're talking about this patch, then I don't think we need to do
> anything more, as the "git branch" and "git reset --hard" invocations
> are separate process invocations which shouldn't affect the current
> worktree or the current "git worktree add" process.

The "shouldn't affect" is potentially a problem.If the current
'worktree add' process caches something (in ref handling, for example)
that the 'git branch' process changes, then we may need to invalidate
cache in 'worktree add' process after run_command(). I guess it's ok
in this case since all we do is run_command(), we do not lookup refs
or anything else afterwards.
-- 
Duy

  reply	other threads:[~2015-07-12  2:48 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-11  0:05 [PATCH 00/16] worktree: use "git reset --hard" to populate worktree Eric Sunshine
2015-07-11  0:05 ` [PATCH 01/16] checkout: avoid resolving HEAD unnecessarily Eric Sunshine
2015-07-11  0:05 ` [PATCH 02/16] checkout: name check_linked_checkouts() more meaningfully Eric Sunshine
2015-07-11  0:05 ` [PATCH 03/16] checkout: improve die_if_checked_out() robustness Eric Sunshine
2015-07-11  0:05 ` [PATCH 04/16] checkout: die_if_checked_out: simplify strbuf management Eric Sunshine
2015-07-11  0:05 ` [PATCH 05/16] checkout: generalize die_if_checked_out() branch name argument Eric Sunshine
2015-07-11  0:05 ` [PATCH 06/16] branch: publish die_if_checked_out() Eric Sunshine
2015-07-11  0:05 ` [PATCH 07/16] worktree: simplify new branch (-b/-B) option checking Eric Sunshine
2015-07-11  0:05 ` [PATCH 08/16] worktree: introduce options container Eric Sunshine
2015-07-11  0:05 ` [PATCH 09/16] worktree: make --detach mutually exclusive with -b/-B Eric Sunshine
2015-07-11  0:05 ` [PATCH 10/16] worktree: make branch creation distinct from worktree population Eric Sunshine
2015-07-12  1:20   ` Duy Nguyen
2015-07-12  2:36     ` Eric Sunshine
2015-07-12  2:48       ` Duy Nguyen [this message]
2015-07-12  3:10         ` Eric Sunshine
2015-07-12  3:14           ` Eric Sunshine
2015-07-12  3:27             ` Eric Sunshine
2015-07-12 10:03               ` Duy Nguyen
     [not found]               ` <CACsJy8BTTdWrCZNz=y686pgju5X8-2mPrNNQ-+z4ByeKD6O5Uw@mail.gmail.com>
2015-07-12 19:20                 ` Eric Sunshine
2015-07-11  0:05 ` [PATCH 11/16] worktree: add_worktree: construct worktree-population command locally Eric Sunshine
2015-07-11  0:05 ` [PATCH 12/16] worktree: detect branch symref/detach and error conditions locally Eric Sunshine
2015-07-11  0:05 ` [PATCH 13/16] worktree: make setup of new HEAD distinct from worktree population Eric Sunshine
2015-07-11  0:05 ` [PATCH 14/16] worktree: avoid resolving HEAD unnecessarily Eric Sunshine
2015-07-11  0:05 ` [PATCH 15/16] worktree: populate via "git reset --hard" rather than "git checkout" Eric Sunshine
2015-07-11  0:05 ` [PATCH 16/16] checkout: drop intimate knowledge of new worktree initial population Eric Sunshine
2015-07-13 18:36 ` [PATCH 00/16] worktree: use "git reset --hard" to populate worktree Junio C Hamano
2015-07-14  9:53   ` Michael J Gruber
2015-07-14 10:09     ` Duy Nguyen
2015-07-14 16:40     ` Eric Sunshine
2015-07-15  6:48   ` Eric Sunshine
2015-07-15  9:59     ` Duy Nguyen

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='CACsJy8A8CeyeYZnMpbdWW-etohp3TWzGrro1khzD=8skydm6Cg@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mikachu@gmail.com \
    --cc=mlevedahl@gmail.com \
    --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).