threads / discuss / 32860

`git checkout --orpan` leaves a dirty worktree

Subject: `git checkout --orpan` leaves a dirty worktree

## tl;dr

8 messages between Feb 8, 2013 and Feb 10, 2013.

replies: 7people: 5as markdown or json

Jonathan Nieder· Feb 8, 2013, 20:04 UTC · re: Ramkumar Ramachandra · lore

Re: `git checkout --orpan` leaves a dirty worktree

Ramkumar Ramachandra wrote:
> Why should I have to `git rm -rf .` after a `git checkout --orphan`?
> What sort of misfeature/ incomplete feature is this?

One designed for the "going open source" use case, where you have existing code that you want to put into a new branch without history. When there is no existing code, it seems simpler to do

	cd ..
	git init code-that-has-nothing-to-do-previous-cwd
	cd code-that-*
	... hack hack hack ...
	git commit
	git remote add origin <url>
	git push -u origin master

BTW, I suspect a clearer way to say what you meant is "Sounds like a misfeature" which is gentler and more focused than an implied "What kind of idiot designed this?" Even if you are thinking the latter. :)

Hope that helps, Jonathan

Ramkumar Ramachandra· Feb 8, 2013, 20:11 UTC · re: Jonathan Nieder · lore

Re: `git checkout --orpan` leaves a dirty worktree

Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
> One designed for the "going open source" use case, where you have
> existing code that you want to put into a new branch without history.
> BTW, I suspect a clearer way to say what you meant is "Sounds like a
> misfeature" which is gentler and more focused than an implied "What
> kind of idiot designed this?"  Even if you are thinking the latter. :)
Yes, I do feel stupid now.

BTW, Is there a better way to clean out the worktree than `git rm -rf .`, since that fails for submodules? The impulsive `reset --hard` obviously fails because there is no HEAD.

Thanks.
Junio C Hamano· Feb 8, 2013, 20:17 UTC · re: Ramkumar Ramachandra · lore

Re: `git checkout --orpan` leaves a dirty worktree

Ramkumar Ramachandra <artagnon@gmail.com> writes:
> BTW, Is there a better way to clean out the worktree than `git rm -rf
> .`, since that fails for submodules?  The impulsive `reset --hard`
> obviously fails because there is no HEAD.

I _think_ the "git rm" is one of the things on Jens's roadmap. Also I think "reset --hard" these days does know what to do when you do not have any history yet.

Jens Lehmann· Feb 10, 2013, 20:10 UTC · re: Junio C Hamano · lore

Re: `git checkout --orpan` leaves a dirty worktree

Am 08.02.2013 21:17, schrieb Junio C Hamano:
Show 7 quoted lines
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
> 
>> BTW, Is there a better way to clean out the worktree than `git rm -rf
>> .`, since that fails for submodules?  The impulsive `reset --hard`
>> obviously fails because there is no HEAD.
> 
> I _think_ the "git rm" is one of the things on Jens's roadmap.

Hmm, "git rm" does remove submodules since 1.8.1 (but they have to be cloned with Git 1.7.8 or newer). Or is there something special about the orphan checkout I'm missing here?

Junio C Hamano· Feb 8, 2013, 20:12 UTC · re: Jonathan Nieder · lore

Re: `git checkout --orpan` leaves a dirty worktree

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 20 quoted lines
> Ramkumar Ramachandra wrote:
>
>> Why should I have to `git rm -rf .` after a `git checkout --orphan`?
>> What sort of misfeature/ incomplete feature is this?
>
> One designed for the "going open source" use case, where you have
> existing code that you want to put into a new branch without history.
> When there is no existing code, it seems simpler to do
>
> 	cd ..
> 	git init code-that-has-nothing-to-do-previous-cwd
> 	cd code-that-*
> 	... hack hack hack ...
> 	git commit
> 	git remote add origin <url>
> 	git push -u origin master
>
> BTW, I suspect a clearer way to say what you meant is "Sounds like a
> misfeature" which is gentler and more focused than an implied "What
> kind of idiot designed this?"  Even if you are thinking the latter. :)
So true ;-).  

Especially when you may an answer that may make _you_ look like an idiot ;-)

Martin von Zweigbergk· Feb 8, 2013, 20:31 UTC · re: Ramkumar Ramachandra · lore

Re: `git checkout --orpan` leaves a dirty worktree

I'm curious what your use case is.

The behavior has been inconvenient for me too, but I have only used it in test cases; I have no real use case where I wanted to create an unborn/orphan branch.

On Fri, Feb 8, 2013 at 11:50 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 10 quoted lines
> Hi,
>
> Why should I have to `git rm -rf .` after a `git checkout --orphan`?
> What sort of misfeature/ incomplete feature is this?
>
> Ram
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ramkumar Ramachandra· Feb 8, 2013, 20:38 UTC · re: Martin von Zweigbergk · lore

Re: `git checkout --orpan` leaves a dirty worktree

Martin von Zweigbergk wrote:
> I'm curious what your use case is.

A couple of them off the top of my head: the gh-pages branch in GitHub, restarting a project but keeping the old history around for reference.

← back to recent threads