Idea: Do not delete origin wip branch on done

[gregorriegler]

@mightyiam made the suggestion for mob done to not delete the origin wip-branch, and to leave this for the mob. In this mob we used mob done to make an intentional commit to the mainline after which we would resume our mob session.

As far as I understand it, the motivation is to not loose anything by accident when mobbers get into git trouble and to avoid reflog fiddling. We solved such a situation with one of the mobbers force pushing their changes to the wip branch, as they still had the correct version on their computer.

[mightyiam]

Yes, that is my suggestion.

I've hit this issue multiple times. mob done and a change of mind... What do you do? Not a biggie. Just a bit of a hassle.

[hollesse]

does that make sense? I see the point, that if you get in some trouble you could resume on that branch, but normally you wouldn't continue working on that branch correct? For that edge case in my opinion it is ok to use that workaround. but if you want to work after mob done on the same mob-branch as before this would not work as there would be all the wip commits and not the final commit.

[simonharrer]

We could print out how to restore the wip-branch after a mob done in case there are errors. Or simply print out the hash of the latest commit of the wip branch just right before the merge. Then, the user could restore it. Would this help?

[mightyiam]

In Mobus Operandi I work regularly with participants who don't use mob.sh often. And mob done is a less frequent command. There were erroneous mob done incidents. "Oops. No big deal. Just do this and this and now this.". I'd like a mob done to be reversible. And not reversible only by the same participant who just executed mob done. Reversible even if that person vanishes right after a mob done.

"Reversible" can mean, well, simply not deleting the mob/ branch. Or it can mean renaming that branch to mob-done/some-refactor.

End of thoughts.

[mightyiam]

I just did

$ mob done
$ git commit -m'some message'

Thereby losing the Co-Authored-By lines.

No big deal, is it? But I want to restore those lines.

git reflog doesn't show the deletion of the WIP branch.

I'm not sure how to restore this information.

[gregorriegler]

@simonharrer @hollesse do you see any disadvantage in not deleting the origin branch on mob done ? mob clean would delete it, right?

[hollesse]

No mob clean would do it if we just delete the branch on origin. If we do not delete the mob branch on origin it won't work. But I think we should add an option for this and we should not change the default behavior. As at least my team and me would not be interested in the mob branches after mob done. If we think about making this default behavior we should implement it that way that mob clean would work to clean these branches. And that we do not have these branches on origin such that these branches will not be reused when doing mob start on the same base branch again.

[simonharrer]

Status Quo:

• The remote wip branch is the leading branch. If this exists, there is a mob session going on and on mob start everybody will join this particular session. If it doesn't exist, there is no mob session going on, and a new session would be created and pushed to this remote wip branch. mob done ends a mob session.
• The origin wip branch is basically the sync of the remote wip branch. A git fetch --prune will automatically create or destroys this branch. Nothing we should do here.
• The wip branch is the current state we code in during a mob session locally.

Ideas:

• on mob done, rename the branch before merging locally. This would require a cleanup mechanism. As we do not want everybody to now have to cleanup, this means we need another config variable. I'm not convinced about the benefit/cost ratio of this.
• on mob done, display the hash in the console. If one wants to have access to the branches, they are still there. We could even print the git command to restore if this makes it any better. I'd rather go with this.
• keep everything as it is.

[hollesse]

I totally agree that I don't see a good cost/benefit ratio for option one. Option 2 sounds like a good idea. Printing the hash is in my honest opinion a good idea. We could also build a wrapper for the restoring of the mob branch. Like mob restore <hash>. I like that idea.

[mightyiam]

Give me an option mob done --retain-wip-branch, please?

I'd make it default, because it's safer and that matters sometimes, when mobbing with individuals new to this tool or who don't use it frequently to be careful about mob done.

But this is the point, right? We shouldn't have something destructive to be careful about.

What if during a remote session, a developer does mob done and before committing loses internet or power or something urgent comes up so that they cannot participate suddenly?

How does the mob commit that change? How does the mob restore that change?

[hollesse]

@mightyiam is there still the need for this feature? If so I would like to discuss again. As I see risks in your proposed --retain-wip-branch option.

[mightyiam]

I still don't like the risk involved with deletion. Especially not by default.

[hollesse]

The problem in retaining the branch is that it just makes sense to retain it in origin, because as all the team members should then be able to restore but this would lead to new problems when doing a mob start afterwards as there is a mob branch on origin and you would continue to use this branch. What do you think about the supposed idea of @simonharrer to print the hash and have a function mob restore which could bring back the branch? Do you see any disadvantages here?

[mightyiam]

Printing would be nicer than status quo. But still... If that person drops offline at that moment...