Re: [PATCH v5 3/4] worktree add: add --orphan flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jacob Abel <jacobabel@xxxxxxxxxx> writes:

> Adds support for creating an orphan branch when adding a new worktree.
> This functionality is equivalent to git switch's --orphan flag.
>
> The original reason this feature was implemented was to allow a user
> to initialise a new repository using solely the worktree oriented
> workflow.
>
> Current Behavior:
>
> % git init --bare foo.git
> Initialized empty Git repository in /path/to/foo.git/
> % git -C foo.git worktree add main/
> Preparing worktree (new branch 'main')
> fatal: not a valid object name: 'HEAD'
> %
>
> New Behavior:
>
> % git init --bare foo.git
> Initialized empty Git repository in /path/to/foo.git/
> % git -C foo.git worktree add --orphan main main/
> Preparing worktree (new branch 'main')
> %

Hmph, I suspect that in reviews for the previous rounds someboddy
must have brought this up, but I wonder if we can detect the case
automatically and behave as if "--orphan" were given.  In other
words, shouldn't the desired outcome (i.e. "worktree add" can be run
to create an orphan branch even when the original were on an unborn
branch) become the new behaviour WITHOUT having the user learn new
option?

If the point of "--orphan" is to create a worktree that checks out a
yet-to-be-bork branch, whether the original is an empty repository
or a populated one, then the user may need "--orphan" option, but
the above illustration is very misleading if that is the intention.

Rather, you should start from a populated repository and explain
that "worktree add" without "--orphan" (i.e. the current behaviour)
does not give you an empty tree with empty history, so run an extra
"switch --orphan" after that.  Then illustrate that you can lose the
last step with the new option "--orphan".

Or something like that.

> Signed-off-by: Jacob Abel <jacobabel@xxxxxxxxxx>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>

This e-mail coming from you and not from Ævar, with you apparently
being the author of the patch, makes these two S-o-b lines
questionable.  What's the chain of custody of the change?  If Ævar
showed some code changes, and you swallowed that into a larger piece
of work (i.e. this patch), then the above two lines are swapped.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux