On Tue, Jul 14, 2015 at 5:53 AM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: >> Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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. -- 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