Hi Phil,

On Saturday, December 9, 2017 at 2:00:39 PM UTC+1, Phillip Lord wrote:
> 
> phillord@fuel:~/scratch/git-test$ git init 
> Initialised empty Git repository in /home/phillord/scratch/git-test/.git/ 
> phillord@fuel:~/scratch/git-test$ touch README 
> phillord@fuel:~/scratch/git-test$ git add README 
> phillord@fuel:~/scratch/git-test$ git commit 
> [master (root-commit) 86b7232] Initial Commit 
>  1 file changed, 0 insertions(+), 0 deletions(-) 
>  create mode 100644 README 
> phillord@fuel:~/scratch/git-test$ ls 
> README 
> phillord@fuel:~/scratch/git-test$ git checkout --orphan temp 
> Switched to a new branch 'temp' 
> phillord@fuel:~/scratch/git-test$ ls 
> README 
> phillord@fuel:~/scratch/git-test$ git status 
> On branch temp 
> 
> Initial commit 
> 
> Changes to be committed: 
>   (use "git rm --cached <file>..." to unstage) 
> 
>         new file:   README 
> 
> I would have expected README to disappear since it's not on this 
> branch. 
> 
> > but if it is about leaving index and working tree in the same state as 
> > where you left off (I guess "master", in your case), that is by 
> > design, and it can be easily cleaned-up with `git rm -rf .`, if 
> > desired (see `git-checkout 
> > 
<https://git-scm.com/docs/git-checkout#git-checkout---orphanltnewbranchgt> 
> > --orphan` docs[1] 
> > 
<https://git-scm.com/docs/git-checkout#git-checkout---orphanltnewbranchgt> 
> > for more info). 
> 
> I guess it is this that is confusing me, yes. 

>From what I`ve learned so far myself, some Git commands might have 
more or less unexpected default behavior - but that is only because 
default behavior is usually optimized for the most common use-case, 
as docs[1] are explaining to be the case here as well.

Once overcoming the initial confusion, one may actually start to 
appreciate it - unless his workflow differs too much from what is 
considered a common practice, of course, but that is yet a different 
topic.

> > On top of everything said above, I may suggest a possibly more 
> > satisfying alternative: 
> > 
> >     git worktree add --detach ../my-new-branch 
> > 
> > We can inspect the current worktree state: 
> > 
> >     $ git worktree list 
> >     /test-repo                   273bf25 [master] 
> >     /my-new-branch               273bf25 (detached HEAD) 
> > 
> > Now, you can go to that worktree and do this: 
> > 
> >     git checkout --orphan my-new-branch 
> > 
> > Inspecting the situation again, we get this: 
> > 
> >     $ git worktree list 
> >     /test-repo                   273bf25 [master] 
> >     /my-new-branch               0000000 [my-new-branch] 
> > 
> 
> Ah, that's interesting. You're creating the worktree to a unnamed 
> branch, then switching branches to the one you wanted. I guess this 
> would also be a good way of implementing 
> 
> git worktree add --orphan ../my-new-branch 
> 
> which would seem to be what I really want. 

Indeed, might be worth bringing up to the main Git mailing list[2], 
hopefully someone could find it interesting enough to implement it... 
or you could give it a try yourself :)

> Thanks for the help! 

No problem, I`ve learned something new as well ;)

Regards, Buga

[1] https://git-scm.com/docs/git-checkout#git-checkout---orphanltnewbranchgt
[2] g...@vger.kernel.org

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to