branching a standalone branch complains that the repository does not support submodules

Bug #951494 reported by Wouter van Heyst
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar Git Plugin
Fix Released
Medium
Jelmer Vernooij

Bug Description

As reported by mathrick on irc, with current lp:bzr and lp:bzr-git:

>> bzr branch -Derror --standalone git://github.com/brutall/brut.apktool.git /tmp/apktool
bzr: ERROR: bzrlib.plugins.git.fetch.SubmodulesRequireSubtrees: The repository you are fetching from contains submodules. To continue, upgrade your Bazaar repository to a format that supports nested trees, such as 'development-subtree'.

Traceback (most recent call last):
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/commands.py", line 930, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/commands.py", line 1141, in run_bzr
    ret = run(*run_argv)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/commands.py", line 673, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/commands.py", line 697, in run
    return self._operation.run_simple(*args, **kwargs)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/cleanup.py", line 136, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/cleanup.py", line 166, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/builtins.py", line 1489, in run
    source_branch=br_from)
  File "/home/larstiq/.bazaar/plugins/dev/git/dir.py", line 140, in sprout
    mapping=source_branch.mapping)
  File "/home/larstiq/.bazaar/plugins/dev/git/fetch.py", line 719, in fetch_objects
    limit)
  File "/home/larstiq/.bazaar/plugins/dev/git/fetch.py", line 517, in import_git_objects
    target_git_object_retriever, trees_cache)
  File "/home/larstiq/.bazaar/plugins/dev/git/fetch.py", line 410, in import_git_commit
    False))
  File "/home/larstiq/.bazaar/plugins/dev/git/fetch.py", line 299, in import_git_tree
    lookup_file_id, allow_submodules=allow_submodules)
  File "/home/larstiq/.bazaar/plugins/dev/git/fetch.py", line 302, in import_git_tree
    raise SubmodulesRequireSubtrees()
SubmodulesRequireSubtrees: The repository you are fetching from contains submodules. To continue, upgrade your Bazaar repository to a format that supports nested trees, such as 'development-subtree'.

As a workaround `bzr init-repo --development-subtree repo; bzr branch git://github.com/brutall/brut.apktool.git repo/apktool` works.

Related branches

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

This seems like correct behaviour to me - we never create development formats silently, to prevent users from hitting bugs in experimental formats.

I'm inclined to mark this as dupe of bug 402814, which is about the support in bzr core to support nested trees.

What do you think?

Changed in bzr-git:
status: Confirmed → Incomplete
Revision history for this message
Maciej Katafiasz (mathrick) wrote :

If the subtrees are not supported in anything but development-subtree, then it certainly makes sense not to expose users to that without making it explicit. While yhe option you mentioned of just erroring out without mentioning other formats does have some basis, I think not mentioning a possible solution at all won't fix things completely.

How about saying something ominous and not immediately applicable without proper consideration, such as:

"The repository you are fetching from contains submodules. This requires support for nested trees, which is currently incomplete. You can proceed by using 'bzr init' explicitly to create a tree with subtree support, then using 'bzr pull git://github.com/brutall/brut.apktool.git ', but you do so at your own risk."

?

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

19:08 < mathrick> jelmer: does that kind of message sound sensible to you?
19:17 < jelmer> mathrick: That message is more correct for your case, but the original was more appropriate for other situations (e.g. when you have a clone of
                a git branch and a pull operation would pull in submodules that have recently been introduced upstream)
19:18 < mathrick> hmm
19:18 < mathrick> well, it'd still work in that case
19:18 < mathrick> ahh, I see what you mean
19:18 < jelmer> mathrick: I think at this point it might be better to just say "sorry, submodules don't work" instead of suggesting to users that they somewhat
                do only to find out that stuff breaks later
19:19 < mathrick> fair enough
19:20 < jelmer> admittedly the original message is pretty bad because it just tells users to upgrade, rather than making a note about the consequences of using
                development-* formats

Revision history for this message
Wouter van Heyst (larstiq) wrote :

The current message is hard to interpret when one isn't branching into an exisiting repository. Just stating that submodules are not supported yet would be better I'd agree.

Bug 402814 being fixed (by 2.6b1? \o/) would of course make this bug moot too.

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

2.6b1 is a bit optimistic I think, but hopefully before 2.6.0... :-)

I've updated the error message.

Changed in bzr-git:
status: Incomplete → Fix Committed
assignee: nobody → Jelmer Vernooij (jelmer)
milestone: none → 0.6.8
Jelmer Vernooij (jelmer)
Changed in bzr-git:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.