This is really to scratch an itch I have when I break my worktrees and can’t
figure out which worktree dir is the one I’ve broken. For example, I organize
my code as follows:
projects/reviewboard/branches/<branch-name>/src/
django/
djblets/
reviewboard/
for each release branch I maintain (4 or 5 of them), where each of the above is
a worktree checkout of the correct branch. This is so I have all my
dependencies for the project at the right development version.
However, when I inevitably break a worktree for, e.g., Review Board, I have to
figure out which of reviewboard, reviewboard1, reviewboard2, etc. it is that
I’ve broken, instead of being able to just go into the worktree named for the
release branch.
Hope this clarifies things.
> On Jun 25, 2016, at 12:17 AM, Junio C Hamano <gits...@pobox.com> wrote:
>
> Barret Rennie <bar...@brennie.ca> writes:
>
>> Add the --name parameter to git worktree add that allows the user to set
>> the name of the created worktree directory. A worktree must not already
>> exist with the current name or creation will fail.
>
> Hmph. This strongly smells like "because we can add this feature",
> not "because we need to add this feature".
>
> What problem does it solve? Please do not give me "currently we
> cannot give a name and instead live with the automatically given
> one, and with this patch we can give arbitrary name" as the answer.
> That is what I called "because we can". Why is it bad that you have
> to live with the name automatically given to your new worktree?
--
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
