On Mon, Jun 27, 2016 at 1:52 AM, Barret Rennie <barret@xxxxxxxxxx> wrote:
> On Jun 26, 2016, at 5:00 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>> 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
--
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