* worktree add already exists @ 2019-05-27 15:32 Ingo Wolf 2019-06-02 7:07 ` Eric Sunshine 0 siblings, 1 reply; 7+ messages in thread From: Ingo Wolf @ 2019-05-27 15:32 UTC (permalink / raw) To: git x@y MINGW64 ~/gittest $ ls bare/ barework/ x@y MINGW64 ~/gittest $ ls -a barework ./ ../ test.txt x@y MINGW64 ~/gittest $ git -C bare branch * master x@y MINGW64 ~/gittest $ git -C bare worktree add --no-checkout ../barework Preparing worktree (new branch 'barework') fatal: '../barework' already exists x@y MINGW64 ~/gittest $ git -C bare branch barework * master Why this doesn't just work and if not why is barework branch made then, why at all ? 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 can do that tricking around with a little dir renaming, new empty dir, move the .git file and rename back... ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: worktree add already exists 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 0 siblings, 1 reply; 7+ messages in thread From: Eric Sunshine @ 2019-06-02 7:07 UTC (permalink / raw) To: Ingo Wolf; +Cc: Git List On Mon, May 27, 2019 at 11:32 AM Ingo Wolf <ingo.wolf@gmx.de> wrote: > $ ls -a barework > ./ ../ test.txt > $ git -C bare worktree add --no-checkout ../barework > Preparing worktree (new branch 'barework') > fatal: '../barework' already exists > $ git -C bare branch > barework > * master > Why this doesn't just work and if not why is barework branch made then, > why at all ? It is by design that "git worktree add" (in general) fails if the target directory already exists and is non-empty. This is consistent with how "git clone" behaves. As for why your particular use-case isn't directly supported, it's likely that nobody has yet asked for it, and nobody thought about this particular case when --no-checkout was added (which came some time after basic "git worktree add" itself was implemented). It is an accident of implementation that the new branch gets created before "git worktree add" errors out due to the existing non-empty directory (and, likely, nobody complained about it, so it went unnoticed). This particular issue probably can be easily fixed now that the logic for checking if the target directory can be a valid worktree has been factored out of the code which actually creates the new directory[1]. [1]: 45059e6468 (worktree: prepare for more checks of whether path can become worktree, 2018-08-28) > 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(): if (file_exists(path) && !is_empty_dir(path)) die(_("'%s' already exists"), path); to: if (opts->checkout && file_exists(path) && !is_empty_dir(path)) die(_("'%s' already exists"), path); or something. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: worktree add already exists 2019-06-02 7:07 ` Eric Sunshine @ 2019-06-03 9:46 ` Duy Nguyen 2019-06-03 18:32 ` Eric Sunshine 0 siblings, 1 reply; 7+ messages in thread From: Duy Nguyen @ 2019-06-03 9:46 UTC (permalink / raw) To: Eric Sunshine; +Cc: Ingo Wolf, Git List On Sun, Jun 2, 2019 at 2:11 PM Eric Sunshine <sunshine@sunshineco.com> wrote: > > On Mon, May 27, 2019 at 11:32 AM Ingo Wolf <ingo.wolf@gmx.de> wrote: > > $ ls -a barework > > ./ ../ test.txt > > $ git -C bare worktree add --no-checkout ../barework > > Preparing worktree (new branch 'barework') > > fatal: '../barework' already exists > > $ git -C bare branch > > barework > > * master > > Why this doesn't just work and if not why is barework branch made then, > > why at all ? > > It is by design that "git worktree add" (in general) fails if the > target directory already exists and is non-empty. This is consistent > with how "git clone" behaves. As for why your particular use-case > isn't directly supported, it's likely that nobody has yet asked for > it, and nobody thought about this particular case when --no-checkout > was added (which came some time after basic "git worktree add" itself > was implemented). > > It is an accident of implementation that the new branch gets created > before "git worktree add" errors out due to the existing non-empty > directory (and, likely, nobody complained about it, so it went > unnoticed). This particular issue probably can be easily fixed now > that the logic for checking if the target directory can be a valid > worktree has been factored out of the code which actually creates the > new directory[1]. > > [1]: 45059e6468 (worktree: prepare for more checks of whether path can > become worktree, 2018-08-28) > > > 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(): > > if (file_exists(path) && !is_empty_dir(path)) > die(_("'%s' already exists"), path); > > to: > > if (opts->checkout && file_exists(path) && !is_empty_dir(path)) > die(_("'%s' already exists"), path); > > or something. 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"? -- Duy ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: worktree add already exists 2019-06-03 9:46 ` Duy Nguyen @ 2019-06-03 18:32 ` Eric Sunshine 2019-06-05 10:17 ` Duy Nguyen 0 siblings, 1 reply; 7+ messages in thread From: Eric Sunshine @ 2019-06-03 18:32 UTC (permalink / raw) To: Duy Nguyen; +Cc: Ingo Wolf, Git List On Mon, Jun 3, 2019 at 5:47 AM Duy Nguyen <pclouds@gmail.com> wrote: > On Sun, Jun 2, 2019 at 2:11 PM Eric Sunshine <sunshine@sunshineco.com> wrote: > > On Mon, May 27, 2019 at 11:32 AM Ingo Wolf <ingo.wolf@gmx.de> 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 ..." 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: worktree add already exists 2019-06-03 18:32 ` Eric Sunshine @ 2019-06-05 10:17 ` Duy Nguyen 2019-06-05 15:30 ` Ingo Wolf 0 siblings, 1 reply; 7+ messages in thread From: Duy Nguyen @ 2019-06-05 10:17 UTC (permalink / raw) To: Eric Sunshine; +Cc: Ingo Wolf, Git List On Tue, Jun 4, 2019 at 1:32 AM Eric Sunshine <sunshine@sunshineco.com> wrote: > > On Mon, Jun 3, 2019 at 5:47 AM Duy Nguyen <pclouds@gmail.com> wrote: > > On Sun, Jun 2, 2019 at 2:11 PM Eric Sunshine <sunshine@sunshineco.com> wrote: > > > On Mon, May 27, 2019 at 11:32 AM Ingo Wolf <ingo.wolf@gmx.de> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: worktree add already exists 2019-06-05 10:17 ` Duy Nguyen @ 2019-06-05 15:30 ` Ingo Wolf 2019-06-06 9:34 ` Duy Nguyen 0 siblings, 1 reply; 7+ messages in thread From: Ingo Wolf @ 2019-06-05 15:30 UTC (permalink / raw) To: Duy Nguyen, Eric Sunshine; +Cc: Git List Am 05.06.2019 um 12:17 schrieb Duy Nguyen: > "worktree add --no-checkout --keep-worktree" is quite readable worktree add --no-checkout -f (orce) I've expected to work on an not empty directory ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: worktree add already exists 2019-06-05 15:30 ` Ingo Wolf @ 2019-06-06 9:34 ` Duy Nguyen 0 siblings, 0 replies; 7+ messages in thread From: Duy Nguyen @ 2019-06-06 9:34 UTC (permalink / raw) To: Ingo Wolf; +Cc: Eric Sunshine, Git List On Wed, Jun 5, 2019 at 10:30 PM Ingo Wolf <ingo.wolf@gmx.de> wrote: > > Am 05.06.2019 um 12:17 schrieb Duy Nguyen: > > "worktree add --no-checkout --keep-worktree" is quite readable > > worktree add --no-checkout -f (orce) > > I've expected to work on an not empty directory Yeah --force works too. Not sure how it interacts with "--force --force". But --force is already overloaded, I don't think forcing harder is going to make it much worse. -- Duy ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-06-06 9:35 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2019-06-05 10:17 ` Duy Nguyen 2019-06-05 15:30 ` Ingo Wolf 2019-06-06 9:34 ` Duy Nguyen
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git 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).