Re: [PATCH 00/16] worktree: use "git reset --hard" to populate worktree

[Eric Sunshine <sunshine@sunshineco.com>]

On Tue, Jul 14, 2015 at 5:53 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>> This is a follow-on series to [1], which migrated "git checkout --to"
>>> functionality to "git worktree add". That series continued using "git
>>> checkout" for the initial population of the new worktree, which required
>>> git-checkout to have too intimate knowledge that it was operating in a
>>> newly created worktree.
> Related to that, I'm interested in "worktree list", and I'm wondering
> how many more worktree commands we foresee[...]

The ones I and others came up with (beyond 'add' and 'prune') are
'list', 'remove', 'mv', and 'lock' (for locking and unlocking). I
specifically added a BUGS section to the documentation[1] as a
reminder.

[1]: http://article.gmane.org/gmane.comp.version-control.git/273431

> , and therefore how much
> refactoring should be done: Currently, the parsing of the contents of
> .../worktrees/ into worktree information is done right in prune-spcefic
> functions. They will have to be refactored. The following questions come
> to my mind:
>
> - Is a simple funtion refactoring enough, or should we introduce a
> worktree struct (and a list of such)?
> - Should each command do its own looping, or do we want
> for_each_worktree() with a callback?

for_each_worktree() might be overkill at this time, as I think only
'prune' and 'list' would benefit directly. 'remove', 'lock', and 'mv'
probably just want to lookup a particular worktree (with 'mv', when
renaming, also possibly looking up the destination worktree to check
if it already exist).

> - Is a fixed output format for "list"[1] enough, or do we want something
> like for-each-ref or log formats (GSOC project...)?
> - Finally: Who will be stepping on whose toes doing this?

I had considered working on some of the commands as time permits, but
don't currently have concrete plans to do so. You're welcome to jump
in and tackle these ideas (but perhaps let us know, so toes don't get
trod upon).

> [1] Something like:
>
> * fooworktree (master)
>   barworktree (HEAD detached from deadbeef)
>
> with "*" denoting the worktree you're in (if any) and (optionally?)

Considering that "git worktree list" can be invoked from the main
worktree or any linked worktree, it would be a good idea to include
the main worktree in the output as well.

> adding the "on" info from "git branch" in parentheses after each
> worktree (checked out branch name, or detached info). Maybe the path, too?

I also had something very much like this in mind, possibly extending
the output either with --verbose or custom format capability (keeping
the GSoC project in mind), but otherwise hadn't put much thought into
it.

Showing the path seems quite important, so I'd say yes to that
question, probably by default.