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

Re: [RFC/PATCH] worktree: replace "checkout --to" with "worktree new"

From
MMMikael Magnusson <mikachu@gmail.com>
Date
Jul 1, 2015, 04:48 UTC
Message-ID
<CAHYJk3QFpaiCvYfZixtKac6nfrYOWrrewy=sLCVe123GTe+zBw@mail.gmail.com>
In-Reply-To
<xmqqtwtobzn0.fsf@gitster.dls.corp.google.com>
On Wed, Jul 1, 2015 at 12:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 27 quoted lines
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>> On Tue, Jun 30, 2015 at 12:56 AM, Eric Sunshine <sunshine@sunshineco.com> wrote
>> Speaking of "git worktree new --force", should we revisit "git
>> checkout --ignore-other-worktrees" before it gets set in stone? In
>> particular, I'm wondering if it makes sense to overload git-checkout's
>> existing --force option to encompass the functionality of
>> --ignore-other-worktrees as well. I don't think there would be any
>> semantic conflict by overloading --force, and I do think that --force
>> is more discoverable and more intuitive.
>
> "git checkout -f" is to throw-away local changes, which is a very
> sensible thing to do and I can see why that would be useful, but
> does --ignore-other-worktrees have the same kind of common-ness?
>
> It primarily is a safety measure, and if the user wants to jump
> around freely to different commits in multiple worktrees, a more
> sensible thing to do so without getting the "nono, you have that
> branch checked out elsewhere" is to detach HEADs in the non-primary
> worktrees that may want to have the same commit checked out as the
> current branch of the primary worktree.
>
> I would mildly object to make --ignore-other-worktrees more
> discoverable and moderately object to make that feature more
> accessible by overloading it into "--force".  I personally would not
> mind if we removed "--ignore-other-worktrees", but that might be
> going too far ;-)

This probably falls under "not common", but one of my uses for git new-workdir is to check out the current branch in another directory, rebase it to upstream, delete that worktree, and then git reset --hard in the original checkout. The result is a rebased branch that touches a minimum of source files so the rebuild is faster. (In some projects I have a lot of local commits that get rebased, but maybe upstream only touched a single .c file).

-- 
Mikael Magnusson
Previous: Junio C HamanoNext: Mark Levedahl
Message 10 of 27 in “worktree: replace "checkout --to" with "worktree new"”
  1. worktree: replace "checkout --to" with "worktree new"Eric Sunshine, Jun 30, 2015
  2. Duy NguyenJun 30, 2015
  3. Junio C HamanoJun 30, 2015
  4. Duy NguyenJul 1, 2015
  5. Eric SunshineJun 30, 2015
  6. Eric SunshineJul 1, 2015
  7. Junio C HamanoJun 30, 2015
  8. Eric SunshineJun 30, 2015
  9. Junio C HamanoJun 30, 2015
  10. Mikael MagnussonJul 1, 2015
  11. Mark LevedahlJun 30, 2015
  12. Junio C HamanoJul 1, 2015
  13. Eric SunshineJul 1, 2015
  14. Eric SunshineJul 1, 2015
  15. Junio C HamanoJul 1, 2015
  16. Eric SunshineJul 1, 2015
  17. Junio C HamanoJul 1, 2015
  18. Duy NguyenJul 2, 2015
  19. Eric SunshineJul 2, 2015
  20. Duy NguyenJul 2, 2015
  21. Duy NguyenJul 2, 2015
  22. Eric SunshineJul 2, 2015
  23. Duy NguyenJul 2, 2015
  24. Eric SunshineJul 2, 2015
  25. Eric SunshineJul 2, 2015
  26. Eric SunshineJul 2, 2015
  27. Eric SunshineJul 2, 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.