Re: [PATCH] builtin/worktree.c: add option for setting worktree name

On Mon, Jun 27, 2016 at 1:52 AM, Barret Rennie [off-list ref] wrote:

On Jun 26, 2016, at 5:00 PM, Eric Sunshine [off-list ref] wrote:

quoted

One thing which hasn't been explained, and about which I'm still
confused even after reading this thread in its entirety, is what
Barret means when he says that he "breaks" his worktrees. What is the
nature of this breakage? Depending upon that answer, would "git
rev-parse --git-dir" be sufficient for your needs? Or, would "git
worktree list" be able to give you the desired information? (As
envisioned, "git worktree list" was intended to provide much more
information than it currently does, such as the .git/worktree dir
name, and such an enhancement might be welcome.)

My worktree breakages are usually the result of my reorganizing my projects,
usually because a branch changes name (for example, if branch release-1 gets
pushed back to release-2). Then I go and rename all my directories and git
gets unhappy and I have to manually fix them or re-create the worktrees.

Quoting from your earlier email justifying why you consider this patch
desirable:

    ...when I break my worktrees and can’t figure out
    which worktree dir is the one I’ve broken.

But, doesn't "git rev-parse --git-dir" from within a "broken" worktree
answer that question? Or, wouldn't an enhanced "git worktree list"
answer the question from the opposite side?

Having `git worktree list` give the worktree directory would be very useful,
but I still would like the ability to change the name of a worktree.

My knee-jerk reaction is that the directory name under .git/worktrees
is an implementation detail (and could easily have been an arbitrary
ID, such as .git/worktrees/7ba84ec0) and rather than exposing it
further and encouraging people to muck around in it manually, we
should be providing higher-level solutions so that they don't have to.

Even without the higher-level solutions, it seems like "git rev-parse
--git-dir" should satisfy your needs, and if someone enhances "git
worktree list" to provide the additional worktree tag name (as
envisioned all along), then you'd likewise have sufficient information
to "fix" your worktrees.

As an example of higher-level solutions, Duy's "git worktree move"
series[1] would, I think, be exactly what you need to avoid such
breakage in the first place (assuming you can retrain your fingers or
fix your scripts, if they are doing the worktree renaming).

I don't know how Duy and Junio feel about it, but my response to this
patch and what it wants to accomplish (even with Junio's input) is
fairly negative. I'd much rather see more missing high-level worktree
features implemented rather than see patches further exposing
git-worktree's internals.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/298194