On Sat, Nov 19 2022, Jacob Abel wrote: > On 22/11/17 11:00AM, Ævar Arnfjörð Bjarmason wrote: >> >> 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? >> > > Prior to writing this patch, I tried to determine if there was a succinct way > to make `-b` "just work" however I wasn't able to find one that wouldn't > introduce unintuitive behavior. My conclusion was that it was probably best > to break it out into a separate command as the other tools had. > > I'd support adding an `advise()` for at least the basic case where you try to > create a worktree and no branches currently exist in the repository. > i.e. something like this: > > % git init --bare foo.git > % git -C foo.git branch --list > > % git -C foo.git worktree add foobar/ > hint: If you meant to create a new initial branch for this repository, > hint: e.g. 'main', you can do so using the --orphan option: > hint: > hint: git worktree add --orphan main main/ > hint: > fatal: invalid reference: 'foobar' > > and > > % git init --bare foo.git > % git -C foo.git --no-pager branch --list > > % git -C foo.git worktree add -b foobar foobardir/ > hint: If you meant to create a new initial branch for this repository, > hint: e.g. 'main', you can do so using the --orphan option: > hint: > hint: git worktree add --orphan main main/ > hint: > fatal: invalid reference: 'foobar' I think those would make sense, yes. > but not in the following circumstances: > > % git init --bare foo.git > % ... > % git -C foo.git --no-pager branch --list > + foo > bar > % git -C foo.git worktree add foobar/ > Preparing worktree (new branch 'foobar') > HEAD is now at 319605f8f0 This is a commit message > > or > > % git init --bare foo.git > % ... > % git -C foo.git --no-pager branch --list > + foo > bar > % git -C foo.git worktree add -b foobar foobardir/ > Preparing worktree (new branch 'foobar) > HEAD is now at 319605f8f0 This is a commit message *nod* > Would there be any other circumstances where we'd definitely want an `advise()`? > Generally I'd assume that outside of those two circumstances, most users will > rarely intend to make an orphan without already knowing they absolutely need to > make an orphan. I'm not familiar enough with the use-cases & workflow around "worktree" to say, sorry.
