> On Jun 27, 2016, at 5:11 PM, Eric Sunshine <sunsh...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
