mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <>
To: Duy Nguyen <>
Cc: Ingo Wolf <>, Git List <>
Subject: Re: worktree add already exists
Date: Mon, 3 Jun 2019 14:32:01 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jun 3, 2019 at 5:47 AM Duy Nguyen <> wrote:
> On Sun, Jun 2, 2019 at 2:11 PM Eric Sunshine <> wrote:
> > On Mon, May 27, 2019 at 11:32 AM Ingo Wolf <> wrote:
> > > I would like to attach an existing dir to git (make it a workdir) and
> > > then update the index with git reset and checkin the differences.
> >
> > I haven't thought through the possible ramifications, but the actual
> > implementation might be as simple as changing this code in
> > builtin/worktree.c:validate_worktree_add():
> Coming from "git clone" background I would still expect --no-checkout
> to abort on non-empty directory (i.e. we always start at a good known
> state). Maybe another option can be used in combination with
> --no-checkout for this. And do we want the same option in "git clone"?

Taking a potential use-case into account, it might be more appropriate
to compare this suggested behavior to git-init rather than to
git-clone. Say, for instance, someone downloads a "tarball" of a
project (with no .git/ directory), experimentally hacks on it for a
while and then decides that that work is worthy of being submitted to
the project as patches or a pull-request. One could imagine that a way
to accomplish this would be to "git clone ..." the project, and then
"git worktree add --no-checkout /path/to/my/hacking", followed by a
series of "git add ..." and "git commit ..." invocations to formalize
the changes into discreet commits.

This is analogous to how you might start hacking from scratch on a new
experimental project before you know if it will pan out, and before
you know if it will be worthy of placing under revision control. If it
does pan out, then you "git init" the existing populated directory,
and follow with a series of "git add ..." and "git commit ..."

I'm not sure how common such a use-case is, though. I recall being in
such a situation once or twice over the years, but that's not
necessarily a good metric. So, I'm not suggesting that such a feature
should or need be added to git-worktree, but the above thought
experiment perhaps provides some context for possible behavior.

  reply	other threads:[~2019-06-03 18:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27 15:32 worktree add already exists Ingo Wolf
2019-06-02  7:07 ` Eric Sunshine
2019-06-03  9:46   ` Duy Nguyen
2019-06-03 18:32     ` Eric Sunshine [this message]
2019-06-05 10:17       ` Duy Nguyen
2019-06-05 15:30         ` Ingo Wolf
2019-06-06  9:34           ` 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:

  List information:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \

* 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

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