All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git Mailing list <git@vger.kernel.org>
Subject: Re: man page for "git-worktree" is a bit confusing WRT "prune"
Date: Mon, 13 Nov 2017 16:06:31 -0500 (EST)	[thread overview]
Message-ID: <alpine.LFD.2.21.1711131603340.6299@localhost.localdomain> (raw)
In-Reply-To: <CAPig+cRLcJ2a=QKyKAkaNiewoWMQvKr_AWePKYVpGS5S9g-i1Q@mail.gmail.com>

On Mon, 13 Nov 2017, Eric Sunshine wrote:

> On Mon, Nov 13, 2017 at 9:48 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:

... snip ...

> >   finally, the prune "--expire" option is truly confusing:
> >
> >     --expire <time>
> >         With prune, only expire unused working trees older than <time>.
> >
> > suddenly, we encounter the verb "expire", which means ... what?
> > how does "expiring" a worktree differ from "pruning" a worktree?
> > and what makes a worktree "unused"? the normal meaning of "unused"
> > is that you haven't, you know, *used* it lately. in this context,
> > though, does it mean deleted? and if it means deleted, what does
> > it mean for it to be older than some time if it's already gone?
>
> This dates back to the original behavior of automatically pruning
> administrative information for deleted worktrees. As discussed
> elsewhere in the document, a worktree may be placed on some
> removable device (USB drive, memory stick, etc.) or network share
> which isn't always mounted. The "expire time" provides such
> not-necessarily-mounted worktrees a grace period before being pruned
> automatically.

  how is this "expire time" measured? relative to what? i've looked
under .git/worktrees/<wtname>, and i see a bunch of files defining
that worktree, but it's not clear how a worktree stores the relevant
time to be used for the determination of when a worktree "expires".

  oh, and is it fair to assume that if a worktree is temporaily
missing, and is subsequently restored, the expire time counter is
reset? otherwise, it would get kind of weird.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

  reply	other threads:[~2017-11-13 21:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 14:48 man page for "git-worktree" is a bit confusing WRT "prune" Robert P. J. Day
2017-11-13 17:39 ` Eric Sunshine
2017-11-13 21:06   ` Robert P. J. Day [this message]
2017-11-14  3:26     ` Eric Sunshine
2017-11-14  8:47       ` Robert P. J. Day

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.1711131603340.6299@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --cc=git@vger.kernel.org \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.