Re: [PATCH] builtin/worktree.c: add option for setting worktree name
- From
Barret Rennie <barret@brennie.ca>
- Date
- Jun 29, 2016, 04:45 UTC
- Message-ID
- <89E234AF-9498-4425-812B-BB0DED4216DA@brennie.ca>
- In-Reply-To
- <CAPig+cSEwib1iFyWE5h8-qTbsAC+zsaSDSYQnv6otWoOOjWAeA@mail.gmail.com>
Show 28 quoted lines
> On Jun 27, 2016, at 5:11 PM, Eric Sunshine <sunshine@sunshineco.com> wrote: > > [snip] > > 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
Yes, it does seem like `git worktree move` will solve all my issues and is a much more elegant solution. Thanks for pointing it out to me and looking at this patch.
I may write a patch to print out the worktree tag name instead and submit that later.
Regards, Barret Rennie