git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Jul 14, 2015, 16:40 UTC
Message-ID
<CAPig+cS9RVvLd8+uY1CsJzFYmLsNn9S0Z=FLQvpLQYYDX0LiBw@mail.gmail.com>
In-Reply-To
<55A4DC1C.90908@drmicha.warpmail.net>

On Tue, Jul 14, 2015 at 5:53 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 8 quoted lines
>> 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
Show 10 quoted lines
> , 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).

Show 6 quoted lines
> [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.

Previous: Duy NguyenNext: Eric Sunshine
Message 28 of 31 in “worktree: use "git reset --hard" to populate worktree”
  1. 00/16 worktree: use "git reset --hard" to populate worktreeEric Sunshine, Jul 11, 2015
  2. 01/16 checkout: avoid resolving HEAD unnecessarilyEric Sunshine, Jul 11, 2015
  3. 02/16 checkout: name check_linked_checkouts() more meaningfullyEric Sunshine, Jul 11, 2015
  4. 03/16 checkout: improve die_if_checked_out() robustnessEric Sunshine, Jul 11, 2015
  5. 04/16 checkout: die_if_checked_out: simplify strbuf managementEric Sunshine, Jul 11, 2015
  6. 05/16 checkout: generalize die_if_checked_out() branch name argumentEric Sunshine, Jul 11, 2015
  7. 06/16 branch: publish die_if_checked_out()Eric Sunshine, Jul 11, 2015
  8. 07/16 worktree: simplify new branch (-b/-B) option checkingEric Sunshine, Jul 11, 2015
  9. 08/16 worktree: introduce options containerEric Sunshine, Jul 11, 2015
  10. 09/16 worktree: make --detach mutually exclusive with -b/-BEric Sunshine, Jul 11, 2015
  11. 10/16 worktree: make branch creation distinct from worktree populationEric Sunshine, Jul 11, 2015
  12. Duy NguyenJul 12, 2015
  13. Eric SunshineJul 12, 2015
  14. Duy NguyenJul 12, 2015
  15. Eric SunshineJul 12, 2015
  16. Eric SunshineJul 12, 2015
  17. Eric SunshineJul 12, 2015
  18. Duy NguyenJul 12, 2015
  19. 11/16 worktree: add_worktree: construct worktree-population command locallyEric Sunshine, Jul 11, 2015
  20. 12/16 worktree: detect branch symref/detach and error conditions locallyEric Sunshine, Jul 11, 2015
  21. 13/16 worktree: make setup of new HEAD distinct from worktree populationEric Sunshine, Jul 11, 2015
  22. 14/16 worktree: avoid resolving HEAD unnecessarilyEric Sunshine, Jul 11, 2015
  23. 15/16 worktree: populate via "git reset --hard" rather than "git checkout"Eric Sunshine, Jul 11, 2015
  24. 16/16 checkout: drop intimate knowledge of new worktree initial populationEric Sunshine, Jul 11, 2015
  25. Junio C HamanoJul 13, 2015
  26. Michael J GruberJul 14, 2015
  27. Duy NguyenJul 14, 2015
  28. Eric SunshineJul 14, 2015
  29. Eric SunshineJul 15, 2015
  30. Duy NguyenJul 15, 2015
  31. Eric SunshineJul 12, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.