Include readme like information for local imports

This should be safe to do as 2) by putting a commit on the orphan master branch, where you stay after the nofetch/nopush import.

Thank you for the report!

On Wed, Jul 19, 2017 at 08:57:12AM -0000, Konrad Zapałowicz wrote:
> 1) for case mentioned above print short informational msg on the console
> that would describe the current state and give insights on how to move
> forward. kind-of a very quick start guide.

I favour this option, as I'd prefer the result inside the git repository
to be exactly the same between the push and no-push modes.

On Wed, Jul 19, 2017 at 3:56 PM, Robie Basak <email address hidden> wrote:
> Thank you for the report!
>
> On Wed, Jul 19, 2017 at 08:57:12AM -0000, Konrad Zapałowicz wrote:
>> 1) for case mentioned above print short informational msg on the console
>> that would describe the current state and give insights on how to move
>> forward. kind-of a very quick start guide.
>
> I favour this option, as I'd prefer the result inside the git repository
> to be exactly the same between the push and no-push modes.

I wonder if in the --no-push case, it would be sufficient to checkout
a local branch to ubuntu/devel from namespace/importer/ubuntu/devel
and leave the repo in that state. We could also checkout to a detached
HEAD state, but that might be more surprising (but would mean the
'repo' state in push and no-push modes is identical). That will be
roughly the same commitsh as the bot importer running at the same time
and then `git ubuntu clone`?

On Wed, Jul 19, 2017 at 04:59:13PM -0000, Nish Aravamudan wrote:
> I wonder if in the --no-push case, it would be sufficient to checkout
> a local branch to ubuntu/devel from namespace/importer/ubuntu/devel
> and leave the repo in that state.

I agree. Konrad, would that be acceptable?

@Robie, @Nish, I think it will be acceptable.

Additionally, for inspiration, check out how we have implemented one of our tools. It outputs some kind of handy info when it is done with it's work https://pastebin.canonical.com/193942/ My original idea was sth like this. What do you think?

There's a TAOUP principle that commands should be silently successful and only noisy on failure. Otherwise scripts become extremely noisy. And a familiar user loses the value of backscroll because it's too noisy too. So there's a balance that needs to be struck I think.

(also, being noisy hides errors)

Good point. However I have been thinking just about this part:

At this point you are on a feature/new-snap branch with all the
necessary files created and commited. Your job now is to fill them
with valid data.

There is also 'master' branch available with an empty README.md
commited (but not pushed) there.

I have not pushed anything and it is your job to do so. Make sure
that you follow the way-of-working that is:
 - First git push origin master
 - Add your own remote pointing to your repository and push
   feature/new-snap there.
 - Submit your snap as a MP against master branch that you just have
   pushed directly

Have fun!

In your case it would be even shorter. Nevertheless I will not strong argue about it.