Fixes a bug that occurs when attempting to created nested subdirs

[stsquared99]

Fixes a bug that occurs when trying to create a subrepo inside of another subrepo.

Steps to reproduce:

$ find | grep -v '.git'
.
./foo
./foo/bar
./foo/bar/Bar
./foo/Foo

$ git subrepo init foo
Subrepo created from 'foo' (with no remote).

$ git branch

• master
  subrepo/foo

$ git subrepo init foo/bar
git-subrepo: Command failed: 'git branch subrepo/foo/bar'.

$ find | grep -v '.git'
.
./Bar

'git branch subrepo/foo/bar' fails because '.git/refs/heads/subrepo/foo' already exists as a file instead of a directory. Furthermore, when git branch fails, there is no catch, so the HEAD is stuck in the subdirectory-filter.

This PR properly handles the failed 'git branch' command, and prevents a subdir from being created inside of another subdir entirely.
Hopefully the test I wrote is in accordance with your standards.

Thanks

[ingydotnet]

Great PR. Thanks. Only problem is I'm not sure there is a problem.

I can run:

git subrepo init ext/bashplus/test

in the git-subrepo directory itself and it works fine.

Should we prevent init-ing subrepos inside subrepos? I'm not sure.

[stsquared99]

The reason it works is because the 'subrepo/ext/bashplus' branch doesn't exist yet in your local repo. If you run 'git subrepo branch ext/bashplus', pull or push with processed commits, or run 'git subrepo init ext/bashplus' for the first time, the branch will then exist, which will block 'git subrepo init ext/bashplus/test'. It took me a while to realize this myself while I was trying to trace the issue.

Try running 'git subrepo branch ext/bashplus', then run 'git subrepo init ext/bashplus/test' and you will see the problem.

Thanks

[ingydotnet]

Thanks for the explanation. BTW, I like working with existing public repos to
recreate these issues and replication strategies.

The thing is, that with your patch I can't init ext/bashplus/test and I think
that I want that to be possible. I ran into a situation where I was writing
code in a subdir of some project and I started thinking, this will be a subrepo
later, and parts of it might become subrepos too.

There are still a few open issues around subsubrepos. I'd like to get those
resolved with tests to keep them from regressing.

I'll add a test to protect my use case above and then you can adjust your patch
to make it work under that constraint.

[stsquared99]

I see, that makes sense. It is rather restrictive to not allow any subrepos you are using to not have subrepos of their own.
The only thing standing in the way of that is the branch names that are being used, due to the dir vs file problem (subrepo/foo & subrepo/foo/bar, foo being a file in the former case and a dir in the latter). If we can find a way around that, then subrepos can be nested without a problem.

Perhaps we should move this discussion to an issue?

In the meantime, I will send you a separate pull with just the commit that catches and resets after a failed git branch.
Thanks

[ingydotnet]

@stsquared99 see https://gist.github.com/2b1c142254fdf83a114b

git-subrepo already has a sub-subrepo, as you can see.

The thing is that the status command can't see them yet (unless you specify them explicitly).

See #132. If you could work on that one too, I'd appreciate it. Else I will eventually...

[ingydotnet]

#136 and #84 are the other open status related issues. Just FYI...

[ingydotnet]

Also #82 is the nested subrepo issue.

Regarding the dir vs file thing, I think just issuing a message to do a clean command first when conflicts happen should be enough.

[stsquared99]

Ah, I think that clarified things for me now, thanks. I'll take a look at those issues and play around with nested subrepos some more.