git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Tao Klerks <tao@klerks.biz>, git <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Taylor Blau <me@ttaylorr.com>, Patrick Steinhardt <ps@pks.im>
Subject: Re: Is "bare"ness in the context of multiple worktrees weird? Bitmap error in git gc.
Date: Tue, 5 Sep 2023 01:43:54 -0400	[thread overview]
Message-ID: <CAPig+cRJhrGmnBRm2dporcXiRr4SzRmpM2LTMm0S7wo0XbOU9Q@mail.gmail.com> (raw)
In-Reply-To: <xmqqedjdtoh5.fsf@gitster.g>

On Mon, Sep 4, 2023 at 9:09 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > This is not accurate. There is no default location for new worktrees;
> > git-worktree creates the new worktree at the location specified by the
> > user:
> >
> >     git worktree add [<options>] <path> [<commit>]
> >
> > where <path> -- the only mandatory argument -- specifies the location.
>
> All correct.  The per-worktree part of the repository data does live
> in a subdirectory of the ".git" directory and that was probably what
> Tao had in mind, though.

That could be. I read Tao's explanation as meaning that people do this:

    git clone foo.git foo
    cd foo
    git worktree add bar
    git worktree add baz

rather than (perhaps) this:

    git clone foo.git foo
    cd foo
    git worktree add ../bar
    git worktree add ../baz

But it's possible I misunderstood.

> >> Is it the case that this contrib script predates the current "git
> >> worktree" support?
> >
> > git-new-workdir predates git-worktree by quite a few years and, as I
> > understand it, remains in-tree because it fills a niche not entirely
> > filled by git-worktree.
>
> I actually think there is no longer a valid workflow whose support
> by "worktree" is still insufficient and the script has outlived its
> usefulness.  I have been a heavy user of the new-workdir script to
> maintain my build environments, but I always have the HEAD of these
> workdir's detached, so I can easily switch my arrangement to use the
> "git worktree" without losing any flexibility.

My response was based upon my recollection of the periodic message
which shows up on the mailing list reporting a bug or submitting an
improvement for git-new-workdir, accompanied by a statement that
git-new-workdir is still a better fit for the user's particular
use-case. But I've never used it myself, so it's good to hear from
someone (you) who does use it.

> Perhaps we should remove it, possibly leaving a tombstone file like
> how we removed stuff from the contrib/examples directory.

Perhaps.

  reply	other threads:[~2023-09-05 16:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-04 14:41 Is "bare"ness in the context of multiple worktrees weird? Bitmap error in git gc Tao Klerks
2023-09-04 14:59 ` Tao Klerks
2023-09-04 15:29   ` Tao Klerks
2023-09-04 17:42     ` Kristoffer Haugsbakk
2023-09-04 17:56 ` Kristoffer Haugsbakk
2023-09-05  0:38   ` Eric Sunshine
2023-09-06 16:00     ` Kristoffer Haugsbakk
2023-09-06 16:39       ` Sergey Organov
2023-09-06 17:59         ` Kristoffer Haugsbakk
2023-09-06 18:04           ` Tao Klerks
2023-09-06 20:26             ` Junio C Hamano
2023-09-06 22:00               ` Sergey Organov
2023-09-06 22:15                 ` Junio C Hamano
2023-09-06 22:34                   ` Sergey Organov
2023-09-07  4:53               ` Tao Klerks
2023-09-07  6:33                 ` Sergey Organov
2023-09-07 20:11                 ` Kristoffer Haugsbakk
2023-09-07 15:07               ` Kristoffer Haugsbakk
2023-09-07 18:23                 ` Junio C Hamano
2023-09-06 17:52       ` Junio C Hamano
2023-09-06 18:08         ` Kristoffer Haugsbakk
2023-09-06 19:10         ` Junio C Hamano
2023-09-06 22:11           ` Sergey Organov
2023-09-05 15:48   ` Tao Klerks
2023-09-05  0:26 ` Eric Sunshine
2023-09-05  1:09   ` Junio C Hamano
2023-09-05  5:43     ` Eric Sunshine [this message]
2023-09-05 15:13       ` Junio C Hamano
2023-09-05 16:25         ` Tao Klerks
2023-09-06 17:29           ` Kristoffer Haugsbakk
2023-09-05 16:10   ` Tao Klerks

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=CAPig+cRJhrGmnBRm2dporcXiRr4SzRmpM2LTMm0S7wo0XbOU9Q@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=ps@pks.im \
    --cc=tao@klerks.biz \
    /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 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 NNTP newsgroup(s).