RE: git worktrees must exist even if locked

2017-05-15 Thread taylor, david
The original report was against Git v2.12.2.  I have since tried v2.12.3, 
v2.13.0,
and the next branch.  All exhibit the same symptoms.

Even if you ignore the original scenario for creating the problem, if I do a 
'rm -rf' or 'mv'
of a tree that contains within it worktrees, that should not break the use of 
Git with
worktrees that live elsewhere nor commands that don't require a repository.

> -Original Message-
> From: taylor, david
> Sent: Wednesday, May 10, 2017 4:25 PM
> To: git@vger.kernel.org
> Subject: git worktrees must exist even if locked
> 
> The Git documentation in describing worktrees says that one reason
> why you might want to lock a worktree is to prevent it from being pruned
> if it is on a removable media that isn't currently mounted.
> 
> So, my expectation was that if the worktree is inaccessible (and locked), Git
> would pretend that there is no worktree by that name.
> 
> In reality, if you have such a worktree, Git gets an error.
> 
>  On local systems, /home is local to a machine; home directories are
> elsewhere.
> Home directories are NFS mounted; /home is not.
> 
> . create a repository in /my/home/dir/my-repo.git with
> 
> git clone --bare 
> 
> . create an empty directory /home/somedir/worktree-tests
> 
> . use 'git worktree add' to add /home/somedir/worktree-tests/ name>
>   as a worktree on branch .  It gets populated with the correct
>   content.
> 
> . lock it using'git worktree lock'
> 
> So far, so good.  Now, go to a different computer -- one on which
> /home/somedir/worktree-tests does not exist (and therefore
> /home/somedir/worktree-tests/ does not exist).
> 
> . cd /my/home/dir/my-repo.git
> 
> Now, try issuing Git commands.  Many will fail.
> 
>   git fetch ==> fails:
> 
>   fatal: Invalid path '/home/somedir/worktree-tests': No such file or 
> directory
> 
>   git status ==> fails -- same error as above
>   git help worktree ==> fails -- same error as above


git worktrees must exist even if locked

2017-05-10 Thread taylor, david
The Git documentation in describing worktrees says that one reason
why you might want to lock a worktree is to prevent it from being pruned
if it is on a removable media that isn't currently mounted.

So, my expectation was that if the worktree is inaccessible (and locked), Git
would pretend that there is no worktree by that name.

In reality, if you have such a worktree, Git gets an error.

 On local systems, /home is local to a machine; home directories are elsewhere.
Home directories are NFS mounted; /home is not.

. create a repository in /my/home/dir/my-repo.git with

git clone --bare 

. create an empty directory /home/somedir/worktree-tests

. use 'git worktree add' to add /home/somedir/worktree-tests/
  as a worktree on branch .  It gets populated with the correct
  content.

. lock it using'git worktree lock'

So far, so good.  Now, go to a different computer -- one on which
/home/somedir/worktree-tests does not exist (and therefore
/home/somedir/worktree-tests/ does not exist).

. cd /my/home/dir/my-repo.git

Now, try issuing Git commands.  Many will fail.

  git fetch ==> fails:

  fatal: Invalid path '/home/somedir/worktree-tests': No such file or directory

  git status ==> fails -- same error as above
  git help worktree ==> fails -- same error as above


RE: [PATCH] worktree add: add --lock option

2017-04-24 Thread taylor, david

> From: Duy Nguyen [mailto:pclo...@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 <gits...@pobox.com>
> wrote:
> > Nguyễn Thái Ngọc Duy  <pclo...@gmail.com> 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.tay...@dell.com>
> >> Signed-off-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
> >> ---
> >>  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


git work trees

2017-04-11 Thread taylor, david
We are using Git in a distributed environment.

In the United States, we have the master repository in one state and a build 
cluster in a different state.
In addition to people in the US doing builds, we have people in other countries 
(Ireland, India, Israel,
Russia, possibly others) doing builds -- using the build cluster.

The local mirror of the repository is NFS accessible.  The plan is to make 
builds faster through the use
of work trees.  The build cluster nodes involved in the build will have a 
worktree in RAM -- checked out
for the duration of the build.  Since the worktree is in RAM, it will not be 
NFS accessible.

[Cloning takes 20+ minutes when the network is unloaded.  Building, with 
sources NFS mounted, takes
5-10 minutes.]

This presents a few problems.

When we are done with a work tree, we want to clean up -- think: prune.  But, 
you cannot prune just
one worktree; you have to prune the set.  And no machine has access to all the 
worktrees.  So, no
machine knows which ones are prunable.

There is no 'lock' option to 'add'.  If someone does a 'prune' after you do an 
'add' and before you do a
'lock', then your 'add' is undone.

Are there any plans to add a '[--lock]' option to 'add' to create the worktree 
in the locked state?  And/or
plans to add a [...] option to prune to say 'prune only this path / these 
paths'?

If there are no plans, is the above an acceptable interface?  And if we 
implemented it, would it be looked
upon favorably?

Thanks.