Hi,
Why should I have to `git rm -rf .` after a `git checkout --orphan`? What sort of misfeature/ incomplete feature is this?
Ram
threads / discuss / 32860
Subject: `git checkout --orpan` leaves a dirty worktree
Hi,
Why should I have to `git rm -rf .` after a `git checkout --orphan`? What sort of misfeature/ incomplete feature is this?
Ram
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
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.
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.
Re: `git checkout --orpan` leaves a dirty worktree
Am 08.02.2013 21:17, schrieb Junio C Hamano:
> 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?
Re: `git checkout --orpan` leaves a dirty worktree
Jonathan Nieder <jrnieder@gmail.com> writes:
> 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 ;-)
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:
> 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
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.