On 18/01/2023 22:40, Jacob Abel wrote:
On 23/01/16 10:47AM, Phillip Wood wrote:
Hi Jacob
On 14/01/2023 22:47, Jacob Abel wrote:
On 23/01/13 10:20AM, Phillip Wood wrote:
Hi Jacob
[...]
I'll reply to this message with the one-off patch to get feedback. Since this is
essentially a discrete change on top of v8, I can either keep it as a separate
patch or reroll depending on how much needs to be changed (and what would be
easier for everyone).
git worktree add --orphan -b topic main
git worktree add --orphan -B topic main
I am hesitant to add these as they break away from the syntax used in
`git switch` and `git checkout`.
When I wrote my original email I wrongly though that --orphan did not
take an argument for "git checkout". While I think it is a mistake for
checkout and switch to have --orphan take an argument they do at least
always need a branch name with that option. "git worktree" add already
has the branch name in the form of the worktree directory in the common
case.
Understood.
I'm not entirely opposed to making this change to OPT_BOOL but I have to wonder
how often `--orphan` will actually be used by a given user and whether the
slightly shorter invocation will be used regularly.
With the base `git worktree add $path`, the shorthand/DWYM makes sense as it's
used regularly but I don't see users working with `--orphan` outside of trying
to create the first branch in a repository.
Your example use in the commit message shows the user using the same
name for the branch and worktree. If that really is the likely use than
I think we should make --orphan OPT_BOOL. If it is not the likely use
perhaps you could update the commit message to show how you think it
will be used.
And I'd like that operation of creating the first branch in a repo to eventually
"just work" with the base command, i.e. `git worktree add main/`. The reason I
hadn't yet added that is because I've yet to figure out how to get it to work
without accidentally introducing potentially confusing situations and I didn't
want to hold up introducing the core functionality itself.
Once that main use-case "just works", I don't see users utilising `--orphan`
except in very rare circumstances. Doubly so since the average user likely
shouldn't be using `--orphan` in most cases.
This brings us back to the question that we discussed earlier of whether
we need --orphan at all. If we can get the main use-case working without
it we'd perhaps be better doing that rather than adding an option no one
ends up using.
Best Wishes
Phillip
Hence the question of whether this change would be worth it vs the existing
`--orphan $branchname $path` which is (for better or worse) consistent with `-b`
and `-B`.
Also apologies for the tangent but while researching this path, I noticed that
--orphan behaves unexpectedly on both `git switch` and `git checkout` when mixed
with `-c` and `-b` respectively.
% git switch --orphan -c foobar
fatal: invalid reference: foobar
% git switch -c --orphan foobar
fatal: invalid reference: foobar
% git checkout -b --orphan foobar
fatal: 'foobar' is not a commit and a branch '--orphan' cannot be created from it
% git checkout --orphan -b foobar
fatal: 'foobar' is not a commit and a branch '-b' cannot be created from it
The messages for checkout look better than the switch ones to me as they
show the branch name which makes it clearer that we're treating what
looks like an option as an argument. What in particular is unexpected
here - --orphan and -b take an argument so they'll hoover up the next
thing on the commandline whatever it is.
Best Wishes
Phillip
[...]
Agreed. I wasn't sure if this would be something worth addressing in a patch but
at the very least I can work on putting together a small patch for `git switch`
since it doesn't seem to be hoovering the flags like `git checkout` does.
