Nguyễn Thái Ngọc Duy [off-list ref] writes:
As explained in the document. This option has an advantage over the
command sequence "git worktree add && git worktree lock": there will be
no gap that somebody can accidentally "prune" the new worktree (or soon,
explicitly "worktree remove" it).
"worktree add" does keep a lock on while it's preparing the worktree.
If --lock is specified, this lock remains after the worktree is created.
Suggested-by: David Taylor <redacted>
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
A patch that adds --lock may look like this.
This looks more like "I do believe the idea by David is a useful
addition and here is how I did it to the best of my ability---let's
make sure we polish it for eventual inclusion" than a mere "it may
look like so---do whatever you want with it" patch.
To me "git worktree add --lock" somehow sounds less correct than
"git worktree add --locked", but I'd appreciate if natives can
correct me.
Thanks.
On Fri, Apr 14, 2017 at 5:50 AM, Junio C Hamano [off-list ref] wrote:
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted
As explained in the document. This option has an advantage over the
command sequence "git worktree add && git worktree lock": there will be
no gap that somebody can accidentally "prune" the new worktree (or soon,
explicitly "worktree remove" it).
"worktree add" does keep a lock on while it's preparing the worktree.
If --lock is specified, this lock remains after the worktree is created.
Suggested-by: David Taylor <redacted>
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
A patch that adds --lock may look like this.
This looks more like "I do believe the idea by David is a useful
addition and here is how I did it to the best of my ability---let's
make sure we polish it for eventual inclusion" than a mere "it may
look like so---do whatever you want with it" patch.
It is a good addition, which is why I added tests and documents, so it
may have a chance for inclusion. I would not strongly defend it though
if there's objection.
To me "git worktree add --lock" somehow sounds less correct than
"git worktree add --locked", but I'd appreciate if natives can
correct me.
That was my first choice too. Then I saw --detach (instead of
--detached). I didn't care much and went with a verb like the rest.
--
Duy
On Thu, Apr 13, 2017 at 3:50 PM, Junio C Hamano [off-list ref] wrote:
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted
As explained in the document. This option has an advantage over the
command sequence "git worktree add && git worktree lock": there will be
no gap that somebody can accidentally "prune" the new worktree (or soon,
explicitly "worktree remove" it).
"worktree add" does keep a lock on while it's preparing the worktree.
If --lock is specified, this lock remains after the worktree is created.
Suggested-by: David Taylor <redacted>
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
A patch that adds --lock may look like this.
This looks more like "I do believe the idea by David is a useful
addition and here is how I did it to the best of my ability---let's
make sure we polish it for eventual inclusion" than a mere "it may
look like so---do whatever you want with it" patch.
To me "git worktree add --lock" somehow sounds less correct than
"git worktree add --locked", but I'd appreciate if natives can
correct me.
Thanks.
I think either "--lock" or "--locked" works for me. "--locked'
suggests "this is the state I want the tree in" while "--lock"
suggests "this is the action I want taken on the tree".
Thanks,
Jake
From: Duy Nguyen [mailto:pclouds@gmail.com]
Sent: Friday, April 14, 2017 9:01 AM
To: Junio C Hamano
Cc: Git Mailing List; taylor, david
Subject: Re: [PATCH] worktree add: add --lock option
On Fri, Apr 14, 2017 at 5:50 AM, Junio C Hamano [off-list ref]
wrote:
quoted
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted
As explained in the document. This option has an advantage over the
command sequence "git worktree add && git worktree lock": there will be
no gap that somebody can accidentally "prune" the new worktree (or
soon,
quoted
quoted
explicitly "worktree remove" it).
"worktree add" does keep a lock on while it's preparing the worktree.
If --lock is specified, this lock remains after the worktree is created.
Suggested-by: David Taylor <redacted>
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
A patch that adds --lock may look like this.
This looks more like "I do believe the idea by David is a useful
addition and here is how I did it to the best of my ability---let's
make sure we polish it for eventual inclusion" than a mere "it may
look like so---do whatever you want with it" patch.
It is a good addition, which is why I added tests and documents, so it
may have a chance for inclusion. I would not strongly defend it though
if there's objection.
quoted
To me "git worktree add --lock" somehow sounds less correct than
"git worktree add --locked", but I'd appreciate if natives can
correct me.
That was my first choice too. Then I saw --detach (instead of
--detached). I didn't care much and went with a verb like the rest.
While I personally would prefer --locked, I also prefer keeping it 'parallel
construction' with --detach. That is either [--detach][--lock] or
[--detached][--locked]. But, ultimately, my intended use is within a script,
so even if it was --totally-non-mnemonic-option I would cope.
A stronger desire, regardless of whether it's Duy's implementation, mine, or
someone elses, is to have something acceptable to the community so that
we are not maintaining a fork with the attendant need to merge changes
in each time we upgrade.
--
Duy