Keep intermediate commits

[koeberlue]

It would be nice if you could keep all commits that were not created by mob next.

We are used to make very fine grained commits, like write a failing test, commit, write code to pass test, commit. Discussing commit messages is usually part of the mobprogramming. So it would be really nice to have a way to keep intermediate commits when calling mob done.

Alternatively there could be a way to call mob done without actually ending the mob session. Something like mob commit "some message" which would effectively do:

mob done && git commit -m "some message" && git push && mob start <remaining timer>

This would solve our problem for now but i can see that this probably would not work for all teams.

What do you think? Would this be a useful feature or do the frequent commits just break the flow to much?

[simonharrer]

Hi. Interesting approach. I wouldn’t use frequent commits as it breaks the flow. Not sure how the tool can help here. Also, the tool doesn’t create commits in nonwip branches by design - only in wip branches. I would like to keep it that way. What could help would be a mob next -m „custom message“ parameter. So you can name the commits. And mob done —merge could merge all the commits back to the base branch. What do you think?

[koeberlue]

Hi. Great suggestions. That would really help with our workflow.

Thinkig of it, creating commits only on WIP branches is probably a pretty good idea for most users. I can totally get behind that.

Using mob done --merge in combination with mob next -m "message" would solve almost all problems we are having right how, since we can always do (and keep) a normal git commit inbetween.

I'm just currently thinking about two additions to the approach, which I'm not 100% sure about.

1. When calling mob next without a message, we probably don't want to keep that specific commit. Should the following mob next -m "message" (and mob done --merge) squash all commits containing the default message? If yes, maybe a mob commit -m "message" would be helpful to do the squashing without the need to call mob next -m "message"
2. Should mob done (without --merge) fail, if there are custom commits inbetween? Then one would require an additional parameter to force a squash. So maybe mob done --squash

Both ideas would assume, that all team members have the same default commit message configured, so I'm not quite sure. What's your opinion?

[simonharrer]

Detecting custom commits sounds quite fragile. Don’t like this approach to be honest.

[simonharrer]

Sorry for the short answers but I’m on vacation right now... :-)

[koeberlue]

Detecting custom commits sounds quite fragile. Don’t like this approach to be honest.

Yeah, I totally understand. Wasn't quite sure myself.

So, to sum up, you would be okay with the following additions?

• mob next -m "commit message" would set a custom commit message
• mob done --merge would switch back to the base branch and merge all intermediate commits of the wip branch

Sorry for the short answers but I’m on vacation right now... :-)

No worries. Enjoy your time off and stay healthy out there :)

[simonharrer]

Thanks. :-)

The option —message should also be supported, not only the shorthand.

Regarding the merge option, I am not entirely sure. It still makes a change in the base branch of the user. Maybe this should be done by the user instead? So basically the tool does everything except the actual merge, but displays a command to copy if one wants to do that. Something like: to complete the merge, enter this command and the following commits with those commit messages will be part of your base branch. What do you think?

[simonharrer]

On second thought, the standard mob done also makes a change to the base branch - although only to the index and no commit. So this might be ok, I guess.

[simonharrer]

Back now. Do you want to have a go at the two additions? I'd be happy to review it. :-)

[koeberlue]

Sorry, we had some dead lines looming and I just forgot to answer.

Yeah, I'll give it a try. I don't have that much time currently so this could take a while (also my first time writing in Go).

The option —message should also be supported, not only the shorthand.

Good point. Thinking of it, should there be a shorthand for the --merge as well? -m might be confusing when available for both commands with different meaning.

to complete the merge, enter this command and the following commits with those commit messages will be part of your base branch. What do you think?

Personally I'd prefer the --merge option because it would feel more satisfying (?) when you are done mobprogramming and don't have to fiddle around with some additional git commands.

Thinking of it since mob done removes the wip branch, would a manual merge even be possible?

[simonharrer]

Awesome. Looking forward your PR.

I would refrain for having a shortcut for merge, as this is somewhat dangerous and I don’t want to make this too easy. :-)

[simonharrer]

I want to release a new version soon. So I had a go at the --message option - I hope that's okay with you. Have a look at 4302e89 if you like.

[koeberlue]

Wow, thank you very much! Sorry I didn't find the time for a PR. My son's sleep schedule is currently out of order and I'm really exhausted in my spare time.

Looking at your commit I realise, that I also overestimated the amount of work needed for such a change 😄

Again thank you very much. I hope everything will be more relaxed here in the next few weeks, so I may have a look at the merge option. But of course it's no problem for me if someone else wants to implement it before me :)

[simonharrer]

No worries. I do have two children of my own, and I know how important their sleep schedule is to my well being. :-)

[gregorriegler]

one idea comes to mind:
what if i want to commit 3 times before making a handover.

[koeberlue]

@simonharrer Plesse correct me if I'm wrong, but you should be able to just use a normal git add and git commit for this. mob next should keep those commits