Re: [PATCH 22/32] checkout: support checking out into a new working directory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 5, 2014 at 10:26 AM, Scott Schmit <i.grok@xxxxxxxxxxx> wrote:
>> Each linked working tree has a private sub-directory in the repository's
>> $GIT_DIR/worktrees directory.  The private sub-directory's name is usually
>> the base name of the linked working tree's path, possibly appended with a
>> number to make it unique.  For example, when `$GIT_DIR=/path/main/.git` the
>> command `git checkout --to /path/other/test-next next` creates the linked
>> working tree in `/path/other/test-next` and also creates a
>> `$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1`
>> if `test-next` is already taken).
>
> As a user, this leaves me with one other question -- what happens when
> I'm done with the test-next working tree and want to delete/rename it?

If you rename it, the link remains and you can still continue to use
test-next with its new name. If you move it, or rename on a filesystem
without hardlink support, then you may need to run something from the
linked worktree for it to fix up the link to main checkout. If you
move it on the same filesystem that supports hardlink, it's all good.

If you delete it, the part in $GIT_DIR/worktrees remains and can be
cleaned up using "git prune --repos" (which I should rename to "git
prune --worktrees" as well). At some point in future, this pruning
should be part of git-gc. See patch 25/32 [1] for detail. I know I
haven't added some user documentation about pruning. You're welcome to
write up something about this ;)

Note to self, you someone moves the _main_ checkout away, then they're
screwed. Should probably make a note about that somewhere in
documents.

> Is that cleaned up automatically, or do I need to register that I'm
> getting rid of/renaming it?  (Another use case is if I put the working
> tree on removable media for some reason.)

Removable media is covered in [1] as well. Though you'll need to
"lock" the worktree in order to stop it from being pruned. In earlier
iterations, this locking could be done automatically at "git checkout
--to" time, if it detects that the new worktree is on a different
filesystem than the main one. But that got dropped. We can add it back
when this feature matures a bit.

[1] http://article.gmane.org/gmane.comp.version-control.git/256236
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]