Comment 6 for bug 1702960

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?