All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>,
	rappazzo@gmail.com, kyle@kyleam.com,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X
Date: Tue, 03 Nov 2015 11:54:33 -0800	[thread overview]
Message-ID: <xmqqmvuudfk6.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CACsJy8Csjgcv_L+TW9YPTs5V=T2XD+eqo1w1PO4jpfDoHLQKpQ@mail.gmail.com> (Duy Nguyen's message of "Tue, 3 Nov 2015 06:48:31 +0100")

Duy Nguyen <pclouds@gmail.com> writes:

> The whole prune strategy is a bit messy trying to cover all cases
> while still keeping out of the user's way. Perhaps if we implement
> "git worktree mv", or even "worktree fixup" so the user can do it
> manually (back when the prune strategy commit was implemented, there
> was no git-worktree), then we don't need this magic any more.
>
> So, which way to go?

I'd prefer to see "conservative and minimal first and carefully
build up" instead of "snapping something together quickly and having
to patch it up in rapid succession before people get hurt." and that
is not limited to the "worktree" topic.

I think "if you move, you are on your own, do not do it." would be a
good starting point.  The user education material would say: if you
create worktree B out of the primary A, and if you do not like the
location B, you "rm -fr B" and then create a new C out of the
primary A at a desired place, and do not reuse location B for any
other purpose.  The list of worktrees kept somewhere in A would then
name the old location B, and it is OK to notice the staleness and
remove it, but we do not have to.  At that point, the magic can and
should go.

After setting the user expectation that way, it is fine to design
how we would give "worktree rm" and "worktree mv".  As long as
users' initial expectation is set to "you do not mv, ever", these
can be introduced without hurting their established use pattern that
would involve no 'mv'.

  reply	other threads:[~2015-11-03 19:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-27 22:04 What's the ".git/gitdir" file? Kyle Meyer
2015-10-27 22:22 ` Stefan Beller
2015-10-27 22:42   ` Randall S. Becker
2015-10-27 22:54     ` Stefan Beller
2015-10-27 22:54 ` Junio C Hamano
2015-10-27 23:26   ` Mike Rappazzo
2015-10-28 16:23     ` Junio C Hamano
2015-11-02 19:08       ` [PATCH] setup: do not create $X/gitdir unnecessarily when accessing git file $X Nguyễn Thái Ngọc Duy
2015-11-02 20:01         ` Eric Sunshine
2015-11-02 20:35         ` Jeff King
2015-11-02 20:51           ` Junio C Hamano
2015-11-02 20:52             ` Jeff King
2015-11-03  5:48             ` Duy Nguyen
2015-11-03 19:54               ` Junio C Hamano [this message]
2015-12-27  3:43                 ` [PATCH] worktree: stop supporting moving worktrees manually Nguyễn Thái Ngọc Duy
2015-12-28  6:22                   ` Eric Sunshine
2015-12-29 13:55                     ` Duy Nguyen
2015-12-31  5:59                       ` Eric Sunshine

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=xmqqmvuudfk6.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kyle@kyleam.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=rappazzo@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.