Redesign the set of mgit commands

[Reinmar]

Right now we have a pretty messy situation where we have mgit bootstrap, mgit update, mgit co. The first two are quite similar, but none actually follows git pull and git fetch.

The initial idea was to follow Lerna's naming. But after a time we see that mgit should follow git's naming. Ideally, pretty much 1:1.

So, it could look like:

• mgit pull – does what git pull does + clones missing repos
• mgit co – checks out to branches listed in mgit.json
• mgit co <branch> – checks out all repos to the given branch
• mgit co -b <branch> – creates new branches (in all repos in which you have changes?)
• mgit fetch – does what git fetch dies (+ clones missing repos?)
• mgit push – does what git push does
• mgit commit <params...> – does what git commit does
• mgit save --branches – saves current configuration of branches to mgit.json
• mgit save --hashes – saves hashes to mgit.json
• mgit st – like today
• mgit diff – like today
• mgit exec – like today
• mgit merge – to simplify closing multi-repo PRs

However, what we need to understand is whether these commands do match our workflow. I mean here the old mgit update which was actually a sum of the new mgit co && mgit pull. Are we ok with the fact that now you'll have to think more about what branches you're on and that mgit pull is not all if you were on some completely different setup previously?

[jodator]

From the above I'd like to see (as I'm missing those tasks):

• mgit save --branches
• mgit co -b <branch> but only if it will "creates new branches (in all repos in which you have changes" - I've got mass branch creation in IDE
• mgit pull with "+ clones missing repos"

The other are either meh (for me) or I have similar functionality in the IDE - like mgit co <branc> or mgit commit or mgit push - all are nicely supported by the Web/PHPStorm.

[oleq]

mgit commit <params...> – does what git commit does

Would it commit in all packages or just the ones which are different than mgit.json, or... what?

[adelura]

All of those sounds very reasonable for me, I think that it's a good approach to think about this tool as multi git rather than lerna tool. It can be used with lerna easily but it can be transparent about it.

Currently I'm using mgit just for bootstrap command, I will be pleased when I see commands like, commit, push, checkout and even stash.

====

To automate the workflow even more I would like see that my hashes in mgit.json are updated automatically when I execute mgit commit (for all nested repositories) and on root repository it will commit my mgit file as well.

[Reinmar]

To automate the workflow even more I would like see that my hashes in mgit.json are updated automatically when I execute mgit commit (for all nested repositories) and on root repository it will commit my mgit file as well.

Interesting idea. Mgit could automatically update hashes if it had hashes stored in mgit.json previously. And could save there branches if you... used branches.

The tricky thing is – can it know when to do that and when not? I'm often jumping between repos and branches in these repos and I don't want mgit to constantly change my mgit.json.

[Reinmar]

Would it commit in all packages or just the ones which are different than mgit.json, or... what?

All changes that you've done. A shorthand for mgit exec 'git commit -a -m ...'?

Which reminded me about mgit merge :D I'll add it to the list.

[ma2ciek]

Interesting idea. Mgit could automatically update hashes if it had hashes stored in mgit.json previously. And could save there branches if you... used branches.

The tricky thing is – can it know when to do that and when not? I'm often jumping between repos and branches in these repos and I don't want mgit to constantly change my mgit.json.

Maybe we can provide some flag to explicitly save branches, hashes or don't commit changes in the main repo at all?
Like mgit commit --update-main-repo=hashes ...

[Reinmar]

Would it work like a watcher? Or would it change some property in mgit.json? And what if you'd do:

cd packages/ckeditor5-engine
git co t/foo

[adelura]

Which reminded me about mgit merge :D I'll add it to the list.

Don't forget about mgit rebase -i 😎

I'm often jumping between repos and branches in these repos and I don't want mgit to constantly change my mgit.json.

This is where the "watch mode" comes into action and convenient saving state will help. Generally speaking - if developer is going to do some "illegal" action like you mentioned above:

cd packages/ckeditor5-engine
git co t/foo

I would warn user with message like: "Hey men! You are trying to checkout|commit|rebase directly into 'ckeditor5-engine' repository. Do you want to save your changes first?"

====

The other are either meh (for me) or I have similar functionality in the IDE - like mgit co or mgit commit or mgit push - all are nicely supported by the Web/PHPStorm.

@jodator How do you commit to multiple repositories? Do you use some plugin?

<probably-offtopic>

By the way also I found it annoying when I checkout hashes, so I lost track of branch to which I want to commit to. Not sure, how your workflow looks like, but did you had similar issues?

There might be possibility to keep track of both - branches and hashes in mgit.json. As far as I remember current syntax is:

{ "repo-name": "user/repo-name#d4da809"}

it might be resolved by storing both:

{ "repo-name": "user/repo-name#master#d4da809"}

It might be helpful when you want to commit changes.

</probably-offtopic>