On Tue, Nov 15 2022, Eric Sunshine wrote: > On Thu, Nov 10, 2022 at 6:32 PM Jacob Abel <jacobabel@xxxxxxxxxx> wrote: >> While working with the worktree based git workflow, I realised that setting >> up a new git repository required switching between the traditional and >> worktree based workflows. Searching online I found a SO answer [1] which >> seemed to support this and which indicated that adding support for this should >> not be technically difficult. >> >> * adding orphan branch functionality (as is present in `git-switch`) >> to `git-worktree-add` > > I haven't had a chance yet to read v3, but can we take a step back for > a moment and look at this topic from a slightly different angle? > Setting aside the value of adding --orphan to `git worktree add` > (which, I'm perfectly fine with, as mentioned earlier), I have a > question about whether the solution proposed by this series is the > best we can do. > > As I understand it, the actual problem this series wants to solve is > that it's not possible to create a new worktree from an empty bare > repository; for instance: > > % git init --bare foo.git > % git -C foo.git worktree add -b main bar > Preparing worktree (new branch 'main') > fatal: not a valid object name: 'HEAD' > % > > This series addresses that shortcoming by adding --orphan, so that the > following works: > > % git init --bare foo.git > % git -C foo.git worktree add --orphan main bar > Preparing worktree (new branch 'main') > % > > However, is this really the best and most user-friendly and most > discoverable solution? Is it likely that users are somehow going to > instinctively use --orphan when they see the "fatal: not a valid > object name: 'HEAD'" error message? > > Wouldn't a better solution be to somehow fix `git worktree add -b > <branch>` so that it just works rather than erroring out? I haven't > delved into the implementation to determine if this is possible, but > if it is, it seems a far superior "fix" for the problem shown above > since it requires no extra effort on the user's part, and doesn't > raise any discoverability red-flags (since nothing needs to be > "discovered" if `-b <branch>` works as expected in the first place). > > If fixing `-b <branch>` to "just work" is possible, then --orphan is > no longer a needed workaround but becomes "icing on the cake". That's a really good point, and we *could* "fix" that. But I don't see how to do it without overloading "-b" even further, in a way that some users either might not mean, or at least would be confusing. E.g. one script "manually clones" a repo because it does "git init", "git remote set-url", "git fetch" etc. Another one makes worktrees from those fresh checkouts once set up. If we "DWYM" here that second step will carry forward the bad state instead of erroring early. I haven't fully thought this throuh, so maybe it's fine, just wondering... ...an alternate way to perhaps to do this would be to detect this situation in add(), and emit an advise() telling the user that maybe they want to use "--orphan" for this?
