Comment 7 for bug 1702960

On 18.09.2017 [10:12:10 -0000], Robie Basak wrote:
> On Thu, Sep 07, 2017 at 09:05:22PM -0000, Nish Aravamudan wrote:
> > On Tue, Sep 5, 2017 at 7:41 AM, Robie Basak <email address hidden> wrote:
> > > What if "git ubuntu clone" were the only command that creates a new
> > > local repository (creating a subdirectory etc) and all other subcommands
> > > only operate on an existing repository except with a really explicit
> > > option (eg. --create or --clone)?
> >
> > I believe right now, the only commands that "create" a local
> > repository are clone/import* (the latter is really 3 subcommands). I
> > think it's fine for the importer to create a repository without an
> > explicit option, as it's not really an importer otherwise. And reusing
> > a directory is the rarer case, IMO.
>
> I hadn't really thought about the import subcommand. I'm not sure it's
> consistent for it to do what it does now, but let's not worry about that
> for 1.0. I think it's enough of a corner case for CLI UX to not be so
> important for it.
>
> > > This would make which behaviour is
> > > about to happen very predictable.
> > >
> > > Then this functionality might be in "git ubuntu review" if it exists on
> > > an existing cloned repository (eg. you already have a clone on it but
> > > would like to review an MP from someone else), but you could still have
> > > an automatic clone with either "git ubuntu review --clone ..." or "git
> > > ubuntu clone <MP URL>".
> >
> > Agreed on the former option. I don't like implementing code that will
> > have to parse the argument to `git ubuntu clone` to decide if it's a
> > srcpkg name or an MP URL.
>
> Implementing it may be a little ugly, but I think that "do what I mean"
> is fine if not ambiguous from a CLI UX perspective and there would be no
> ambiguity here. But that doesn't mean that we have to implement it, so
> if you aren't convinced then there's no need for us to implement it for
> 1.0 so we can defer any decision about it.
>
> > To be clear, to enable this, we would have a --clone flag for `git
> > ubuntu review` and would probably need `git ubuntu review` without the
> > --clone flag to fetch both the source and target remotes (adding them
> > as necessary) (if the latter is ~usd-import-team, then fetch pkg
> > instead) and running the lint on the requested branch?
>
> If I understand you correctly, yes. So:
>
> Without --clone: fail if not in repository (whatever "in" means). Fetch
> source and target as you said, with magic for ~usd-import-team -> pkg.
> Run lint.
>
> With --clone: fail if in a respository (or at least require --force). Do
> equivalent of "git ubuntu clone". Go into directory. Also fetch source
> if not ~usd-import-team. Fetch target. Run lint.
>
> Does that seem right to you?

Yeah, I think this is what we landed last week :)