All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>, Duy Nguyen <pclouds@gmail.com>
Subject: Re: [PATCH v2] Documentation/git: fix stale "MULTIPLE CHECKOUT MODE" reference
Date: Fri, 17 Jul 2015 14:09:35 -0700	[thread overview]
Message-ID: <xmqqfv4m1ofk.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAPig+cQvVA0Cb60AxA=9RAUj6bBN419FQHObM6PARiDwGLiHow@mail.gmail.com> (Eric Sunshine's message of "Fri, 17 Jul 2015 16:52:46 -0400")

Eric Sunshine <sunshine@sunshineco.com> writes:

>> Thanks.  I have two comments.
>>
>> "if using Cogito etc.", which is totally outside the topic of this
>> patch, is way outdated. Perhaps we would want to remove or replace
>> it.
>
> Do you want me to re-roll the current patch to also include the
> "Cogito" change as a "while here..." add-on?

No.  That is totally outside the topic of this patch series.

> Also, I have v3 of "rid git-checkout of too-intimate knowledge of new
> worktree"[1] ready to roll. Do you want me to fold the current
> patch[2] and its brother [3] into v3?

I think I took them and merged them to 'master' today.

> ... since he plans
> on adding more tests[4] when fixing the can't-clone-a-linked-worktree
> problem.)

I saw that issue myself yesterday, too, I think, with a failed
attempt to fetch from one.  I do not think it is such a huge issue
in a sense that we can always say "don't do that", as cloning and
fetching only from the primary location is not something that would
make users feel unnatural.  After all, we sell this as "allowing
secondary checkout", meaning that it is perfectly OK for us to keep
secondaries second-class citizens compared to the primary one.  So
being able to fetch from and clone from is "nice to have".

> Other than that, the only consumer of GIT_COMMON_DIR seems to be
> setup.c, and, based upon a quick scan, it looks like it can be easily
> dropped, thus alleviating your concerns (but hopefully as a series
> separate from v3 of [1] which I'd like to see land).

One step at a time is perfectly fine.  We will be cautioning users
to avoid storing the only copy of their data in repositories that
employ this feature for a few releases until it matures by marking
it experimental exactly so that we can tweak external interfaces
like that incrementally.

Thanks.

  reply	other threads:[~2015-07-17 21:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17  0:17 [PATCH v2] Documentation/git: fix stale "MULTIPLE CHECKOUT MODE" reference Eric Sunshine
2015-07-17  0:19 ` Eric Sunshine
2015-07-17 17:03 ` Junio C Hamano
2015-07-17 20:52   ` Eric Sunshine
2015-07-17 21:09     ` Junio C Hamano [this message]
2015-07-18  7:57   ` Duy Nguyen
2015-07-18 20:56     ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=xmqqfv4m1ofk.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.