> From: Duy Nguyen [mailto:pclouds@xxxxxxxxx] > 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 <gitster@xxxxxxxxx> > wrote: > > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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 <David.Taylor@xxxxxxxx> > >> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> > >> --- > >> 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. 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