mob icon indicating copy to clipboard operation
mob copied to clipboard

Idea: Do not delete origin wip branch on done

Open gregorriegler opened this issue 2 years ago • 14 comments

@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.

gregorriegler avatar Jun 27 '22 08:06 gregorriegler

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.

mightyiam avatar Jun 27 '22 09:06 mightyiam

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.

hollesse avatar Mar 09 '23 19:03 hollesse

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?

simonharrer avatar Mar 09 '23 19:03 simonharrer

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 avatar Mar 11 '23 16:03 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.

mightyiam avatar Mar 15 '23 09:03 mightyiam

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

gregorriegler avatar Mar 18 '23 18:03 gregorriegler

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.

hollesse avatar Mar 18 '23 19:03 hollesse

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.

simonharrer avatar Mar 20 '23 07:03 simonharrer

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.

hollesse avatar Mar 22 '23 18:03 hollesse

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?

mightyiam avatar Mar 23 '23 00:03 mightyiam