On Tue, Jun 4, 2019 at 1:32 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > On Mon, Jun 3, 2019 at 5:47 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > On Sun, Jun 2, 2019 at 2:11 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > > On Mon, May 27, 2019 at 11:32 AM Ingo Wolf <ingo.wolf@xxxxxx> 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. Or you could just git-clone directly to the place you unpacked the tarball. > 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 ..." > invocations. > > 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. Yeah I'm not suggesting we do anything immediately either. I still think though that we should change --no-checkout behavior. "worktree add --no-checkout --keep-worktree" is quite readable (and I assume this is not a popular use case that people will have to specify both options often) -- Duy
