remotemobprogramming/mob

Tool for smooth git handover.

mob's Issues

Proposing a config file approach

Hello folks, first thanks for the creation of this excellent tool, I'm using with my teammates in the company that I work, it's helping us a lot in this period of remote work.
To adapt the tool to some of our needs and daily uses, I've made a fork to implement some ideas and changes, and I would like to present this ideias as suggestions of features , most of them I've already implement in the fork but there's yet some minor adjustments to be made and test in windows.
So here goes the suggestions:

• Change the variable environment config approach to a file config approach:
  The configuration of mob tool is managed by environment variables, this approach imply in the necessity of make some setup in machines and keeps it synchronized with the configurations of the session's participants, this make the usability of the tool for us harder and complicated.
  So my suggestion is to use a json config file, which in my implementation I've called .mob_config.json , this file would be created with defaults config parameters when the mob start command was called for the first time and there's no config file present, this config file will be pushed for the entire mob session until the command mob done was called, in this moment the tool will delete the config file on the squash with the base branch.

• A mob setup command:
  A command to define all configuration, one by one, of the mob session instead to use the defaults configuration of the mob start command.

• The base default branch be the current branch:
  Instead use the master as default base branch use the current branch as default base branch.

• The wip default branch be a branch where the name is a composition of the base branch with a suffix.
  In our implementation we've used the suffix -wip, so if the base branch was called, for example, "feature" , the default wip branch is "feature-wip".

• A License file.
  I've noticed later that the project doesn't have a License file or written in the README file explicit, would be nice to define one license to the project and turn this explicit.

My fork (it's still a WIP, I need fix some errors and update the README file with the new commands and test with windows):
https://github.com/Richsan/mob

Using another branch (not master) as a base branch may lead to problems

mob works well when used with the master branch. Calling mob start on master switches to the wip branch mob-session. And calling mob start --branch=green on master switches to the wip branch mob/master/green. So far so good.

But it gets problematic when you are on a branch other than master. Let's assume you use main instead of master for your trunk. Calling mob start on main switches to the wip branch mob/main. Calling mob start --branch=green on main switches to the wip branch mob/main/green. So far so good.

Problem is: git doesn't allow a branch named mob/main and a branch named mob/main/green to coexist. This is because branches are mapped to the filesystem, and on the filesystem, mob/main cannot be a file and a directory at the same time. This means for the mob tool that whatever came first (mob/main or mob/main/green), the other branch cannot be created.

Not sure how to proceed. But I want that mob works well with a main branch too. I'm open for ideas.

automated homebrew release

Currently, releasing a new version of mob with homebrew is a manual process. I'd like this process to be fully automated using GitHub actions.

Move to .adoc for the README

while GitHub-flavoured markdown is not bad, specifying the documentation in AsciiDoctor would have some benefits:

• creating a table of contents (my main reason for suggesting it as the README is rather long and I love ToCs 😉)
• figures
• defintion lists
• rich tables
• ...

AsciiDoctor is mostly compatible to Markdown so everyone able to edit Markdown should be able to learing editing AsciiDoctor as well.
GitHub fully supports AsciiDoctor and will render its contents as it would with Markdown.

There is also a way to automatically convert md to adoc

As of now, GitHub Pages does not automatically support AsciiDoctor (the jekyll plugin is not white-listed) so additional steps are needed to push the static content to GitHub Pages such as calling Jekyll by yourself and publish it to Pages through GitHub Actions.

Make MOB_NEXT_STAY=true the new default

I plan to switch the default values. Instead of switching back to the base branch every time, the default would be to stay on the wip branch by default. The option can still be used to disable that behavior with MOB_NEXT_STAY=false.

Why? We work with Java, and if you add a new dependency in your wip branch and constantly switch back and forth, the IDE has a hard time syncing your build files. Also, syncing with file system changes is sometimes slow in some IDEs. This change would reduce that friction. Another point: sometimes one wants to look at the stuff already done during the mob session as part of the rest of the mob to contribute better to the discussion. This change would help as well, as some might not know the MOB_NEXT_STAY option and then would have to execute 'mob start' locally.

Would love to discuss how you feel about this.

Defaults read from config file

We have a develop branch as our default, which doesn't work that well with your default. Having a way of having that set as the branch default would remove a bit of manual git work that we have to do today.

A checked in .mobdefault would help :-)

Multiple WIP branches per base branch

The default way of working with 'mob' is using one WIP branch per base branch. Because of backwards compatibility, "master" and "mob-session" are special.

# base branch is 'master'
master $ mob start
mob-session $ mob done # return to 'master'

# base branch is 'feature1'
feature1 $ mob start
mob/feature1 $ mob done # return to 'feature1'

Multiple WIP branches per base branch is currently not possible anymore, as the config parameter for the base branch and the WIP branch have been removed.

The need for multiple wip branches per base branch is, however, there (see #15 and #27).

My suggestion would be as follows:

# base branch is 'master'
master $ mob start --branch green
mob/master/green $ mob done # return to 'master'

# base branch is 'feature1'
feature1 $ mob start -b green
mob/feature1/green $ mob done # return to 'feature1'

Because the base branch is encoded into the wip branch name, 'mob' knows the base branch when on the WIP branch without any additional files polluting any commits.

With MOB_NEXT_STAY=true, the subsequent 'mob start' calls wouldn't need the '--branch green' info, as one would already be on the wip branch named 'green'.

# base branch is 'master'
master $ mob start --branch green
mob/master/green $ MOB_NEXT_STAY=true mob next
mob/master/green $ mob start
mob/master/green $ mob done # return to 'master'

The mob reset command would need the --branch parameter as well, so that WIP branch can be nuked, too.

Would love your feedback @jlangr @OskarD @talesbaz

Add parameter to specify the working directory

Handover Focus

Problem

Handover includes handing over code but also the current focus. The current focus typically is the opened file, and maybe even the cursor position. Maybe also all opened files in the project.

Solution Idea for handover opened file

We can get the title of intellij window on osx via

osascript -e "tell application \"System Events\" to get the title of first window of process \"idea\""

From the title, we can deduct the last opened file. On mob next, we can put the filename in the commit message of the WIP commit. And on the next mob start we can look for a file with that name and open it.

Challenges

• two files with same name needs to be resolved somehow
• other operating systems require additional logic to get the window title, and the filename must be shown in the window title
• getting opened file and opening file requires knowledge of editor, and requires editor to be available on the terminal

Any thoughts on this? Not sure whether this is worth it, but found the idea interesting to think about at least.

Add doc to explain what to do if one forgot to do a mob next

See thread https://twitter.com/MarioKusek/status/1352862638808686594?s=20

os package (brew, pacman, apt, ...)?

Is there interest in making OS packages for mob?

For example:

• Arch: pacman -S mob
• Debian: apt install mob
• Windows: chocolatey install mob
• Mac: brew install mob
• etc

Has anybody looked into this? Are there problems?
As far as I can see the only dependencies are go and git. Am I missing something?

run git pull on mob start

mob start should run git pull instead of git fetch to make shure the mob session is started on HEAD

Start mob from different branch

Hey is there a functionality to start a mob session from a different Branch than master? In our project we have some branches for staging where we want to start our mob session.

Add better message when issuing a mob command outside a git repository

Expand "How to contribute" so that Code Contributions become easier

I am a go newbie, but I like this project and would like to help out more (if you would accept code contributions). But I struggle to understand the project setup. A short paragraph on how to setup the project as a go developer would be nice. In the end, it should allow to run the tests locally and compile the code. It should also include the Go version used.

Have mob next push if there are commits, but no changes

Problem

During a mob session, one of the developers created a commit while in her session. When she executed mob next, she had no additional changes after her last commit. Right now, the mob next command skips all git commands if no changes are found. So when the next person tried to mob start, we couldn't find her work.

Suggestion

As part of the mob next logic, check to see if the local branch is ahead of the remote branch. If so, push to remote.

Reasoning

We started doing some intermediate commits to have a working state of code to fall back on. This feels like a healthy practice to follow if you get a test working or a refactor completed prior to your session being complete.

If this is not a recommended practice for this tool, that might be helpful to include in the documentation.

mob start does not work if existing session is in progress and branch contains /

This is in reference to #56, but i opened a new issue, since part of the #56 issue was fixed in v0.0.24. Find a trace attached, unfortunately this still does not work.

In #56 I only tested with a new session, which works ok. Now it seems to go wrong when mob tries to find out the latest committers.
scratch_41.txt

Sound output sometimes not working on windows

We had issues with the sound output of mob. Hypothesis: if cortana is disabled it doesn’t work anymore. But that’s not verified.

Configurable mob branch name

If you are multiple mobs working on the same code base, but on different features, there will be conflicts because they are working on the same mob branch. Adding a parameter to the configuration with a branch name for the mob would solve this :)

script to determine download numbers using github api

I would like to know how often 'mob' is downloaded.

The github releases api provides download counts.

A script that would compute this per release and per platform would be interesting.

opt out on git some git actions

It could be useful in some cases to give the possibility to "opt out" of doing some of the git actions like --squash or fetch --prune. Just to give each team the flexibility of working like they are use to do it.

mob with 0.22 broken for my setup

Hello Simon,

while 0.20 worked really well, after the update to 0.22 using mob start and mob next now fails with this error message:

 ERROR git --no-pager log feature..mob/feature/removeDeployersYaml-DPL-2833 --pretty=format:%an --abbrev-commit
 ERROR fatal: ambiguous argument 'feature..mob/feature/removeDeployersYaml-DPL-2833': unknown revision or path not in the working tree.
 ERROR Use '--' to separate paths from revisions, like this:
 ERROR 'git <command> [<revision>...] -- [<file>...]'
 ERROR exit status 128

I have attached a full debug log of mob start --branch "". If I understand the latest changes correctly, I always have to specify the --branch if I am not on master. But maybe I am misunderstanding. If I omit it, there is an error message telling me, I have to add -- branch.

scratch_39.txt

Include mob in the official homebrew repository

It would be nice, if mob was part of the official homebrew repositories, which would make installing mob on mac and linux (with linuxbrew) easier and somebody that hears of the tool ("hey, have you heard of mob, it is a great cli tool for remote mob programmin") could intuitively run brew install mob.

In order to achieve this, the Formula for mob has to be adapted to comply with the Formula Cookbok. The biggest change in my opinion is, that homebrew/core only allows Formulas which build from source. Binaries are only allowed in cask, but a CLI tool should not really be put into Cask, because it is unnessecary, and in the end, mob really is a tool that works on all platforms. Here is an example: https://github.com/Homebrew/homebrew-core/blob/master/Formula/golang-migrate.rb

After changing the Formula in the described way, it should be enough to fork homebrew/core (acually, the command we use brew bump-formula-pr will also create the fork, if it has a GITHUB API TOKEN with sufficient permissions).

Looking at the examples in the wild, a lot of people write a Makefile for building their Golang app, probably to keep the Formula code as simple as possible. It is also a good practice to write a test, so that the Homebrew CI can check, if the Formula works and produces a valid binary. Any ideas?

mob start should start from the current branch instead of master

Current behavior

Currently, mob start will start the mob-session branch from master, regardless of what the currently checked out branch is. It is possible to control the base branch using MOB_BASE_BRANCH=mybranch mob start. However, this is non-intuitive and hard to remember.

Suggestion

mob start starts from the current checked out branch (if no mob-session exists and no local modifications, etc. same checks as before). You can still specify MOB_BASE_BRANCH to override that if you want.

The output would make it clear what branch was used and also tell the user how to undo, in case they did not want to start from the current branch, i.e. using mob done or mob reset.

Reasoning

Is there a particular reason or use case why it ignores the current branch and always starts mob-session based off of master?

In our experience, when you start the mob, you want to start it from your current branch. You might have already looked at the code before you actually run the mob start command, so there is IMO little chance that you want to start it from another branch (master). It also feels more natural to do

git checkout myfeature
mob start

than

MOB_BASE_BRANCH= myfeature mob start

Users will know git a lot better than the mob tool.

To given an example, we have been working on a feature branch that represents a more complex effort which we handle in the mob. This took many days and we don't necessarily do a mob every day. That means we split up some work in the meantime, contributed that back to the feature branch and the next day would do a mob and work on the integration. All the time the work focuses on that feature branch, not master.

OTOH, I feel that mob-session is not a feature branch, but just a "the mob is working on this today" temporary working branch, as there can only be 1, you don't really want to do a PR from mob-session and it's easy to loose the work using mob done or even mob reset.

Add badge for latest version number to mob.sh

I want to see the latest version number of mob as a badge.

mob not installable/upgradable on MacOS Big Sur

Hi,

maybe it's the wrong place to tell, but the installation/upgrade process with Homebrew does currently not work anymore:

Cheers
Jan

Current install process does not work on Windows

The curl -sL install.mob.sh | sh install command does not work on Windows whether in PowerShell or GitBash. The old instructions for Windows were also incomplete:

### Windows

- Install [Golang](https://golang.org/): Download and execute MSI from Download page
- Open console and execute following commands

bash
> git clone https://github.com/remotemobprogramming/mob
> cd mob
> .\install.cmd
# Now, you can use the mob tool from anywhere directory in the terminal

^ Is a good start, but mob.exe is not correctly added to the PATH so it cannot be found. So these instructions plus a note about manually updating the PATH would be better.

Avoid unnecessary pull after fetch?

Hi!

I saw this git pull:

mob/mob.go

Line 395 in 43d0aed

git("pull", "--ff-only")

Whis is executed after a git fetch:

mob/mob.go

Line 376 in 43d0aed

git("fetch", configuration.RemoteName, "--prune")

Since git pull is nothing else than a git fetch && git merge FETCH_HEAD, the pull could be replaced with a git merge --ff-only FETCH_HEAD.

Is there a reason for the git pull --ff-only?

In-memory git repositories for testing?

https://github.com/go-git/go-git

At some point, these tests will become a bottleneck. I propose experimenting with go-git to run tests with an in-memory file system. Of course, I don't know how risky this is compared to testing with a real file system.

Automatically Populate Co-Authored-By lines

Because each of the WIP commits is generated by the authors in the group, it is trivial to aggregate the WIP commits and generate a unique list of Co-Author lines. I have written a little wrapper script in bash that does this when I call the done command.

CURRENT_BRANCH=`git rev-parse --abbrev-ref HEAD`
FROM_BRANCH=master
if [[ "$CURRENT_BRANCH" != "mob-session" ]]
then
  FROM_BRANCH=`echo "$CURRENT_BRANCH" | awk -F/ '{print $2}'`
fi

CO_AUTHOR_LINES=$(git log $FROM_BRANCH.. --pretty=format:"Co-Authored-By: %an <%ae>" | sort | uniq | grep -v `git config user.email`)

mob done

printf "\nRecommended Co-Author Lines have been copied to your clipboard:\n\n"
printf "$CO_AUTHOR_LINES"
printf "\n\n\n$CO_AUTHOR_LINES" | pbcopy

I think it would be cool to integrate this into mob done command. I am possibly willing to submit a PR but wanted to get a sense of the maintainers' opinion on this before I put in the effort.

Some things to consider:

• My implementation is not very robust at computing branch names. It is sufficient for my needs. If integrated into the mob done command, then of course this would be improved.
• Right now all I am doing is copying it to the user's clipboard. I'm assuming OSX and therefore using pbcopy. If integrated into mob done, I would need a cross-platform solution for this.
• Ideally, I would love to auto-populate this into a template so it just automatically shows up in the user's editor when they do their next commit. I haven't figured out a way to do this though. Maybe copying to the clipboard is the best we can do, but I'm curious if any git masters out there know a way to make this more seamless.

Remove 'mob reset' command

I'm thinking of removing the 'mob reset' command as I've only used it like 4 times in 2 years. Not sure, it's that helpful.

Installing & running on Windows

h1. Actual behavior:

After installing go, I ran the installation as documented and got some strange output. The mob executable is there but I am not sure if it is really the expected behavior:

C:\Users\****\repos\mob>.\install.cmd
Installing 'mob' ...

SUCCESS: Specified value was saved.
The filename, directory name, or volume label syntax is incorrect.
Directory "" created.
        0 file(s) copied.
'mob.exe' installed to ""
'mob' successfully installed.
Press any key to continue . . .

Then I started mob:

C:\Users\****\repos\mob>mob
 > you aren't mobbing right now
 ❗ text-to-speech disabled because 'say' not found

h1. Expected Behavior

• I was expected the output as documented without the "0 files copied" etc.
• Maybe there should be added a hint that "say" is not available on Windows

h1. Environment

• Windows 10 Enterprise 1809
• go1.14.1 windows/amd64
• Executed on cmd.exe

go.mod breaks release pipeline

@gregorriegler

Update docs

The docs need to be updated as #14 has been implemented.

Show warning for still using removed configs

However ultimately, I think it would have helped most, when an error would be raised when setting the MOB_BASE_BRANCH and MOB_WIP_BRANCH env variables, because afaik they are no longer respected by mob.

Getting started

create a getting started video with the mob tool

README Credits section shows some raw tags

In the Credits section of the README, as displayed at https://github.com/remotemobprogramming/mob there are some html tags rendered as text.

I'm not sure how to fix those elements, while preserving their intended function.

troubles with say on ubuntu due to exit code = 1

Using the default voice command "say" from gnustep-gui-runtime results in a strange behaviour on my Ubuntu 18.04 machine. Instead of displaying desktop notifications via notify-send, the notification script ends after saying "Mob Next".

After some analysis I found out that say is at fault. Instead of returning exit code 0 (as it is working) it returns 1.

Show case:

say "Hello, World!" || echo "Fail!"

My workaround is to install an alternative speech engine (espeak-ng-espeak produces better sound anyway) . Either by setting the environment variable MOB_VOICE_COMMAND or even better, by writing a wrapper called say (which allows me to use other voice files):

#!/bin/sh
# please install espeak-ng-espeak and mbrola-us-1 for this to work!
espeak -v us-mbrola-1 "$@"

feature request: add license to binary tarball

While setting up the arch package mobsh-bin I had to download the LICENSE file manually because it is not included in the binary tarball https://github.com/remotemobprogramming/mob/releases/download/v1.1.0/mob_v1.1.0_linux_amd64.tar.gz (it currently only includes the mob binary).

Since this is my first arch package I asked for feedback in the arch forum: https://bbs.archlinux.org/viewtopic.php?pid=1947520#p1947520

eschwartz, an experienced arch user, gave me this advice:

Usually one would wish the LICENSE file to be shipped in the binary tarball, consider opening an upstream bug.

It seems to be common / good practice to include a license file in binary tarballs. From https://wiki.archlinux.org/index.php/PKGBUILD

Mandatory variables are [...]. license is not strictly necessary to build a package, but is recommended for any PKGBUILD shared with others, as makepkg will produce a warning if not present.

Is it possible to include the LICENSE file in the binary tarball in upcoming releases?

Mob start/next throws when a hyphen is included in the branch name

Hello 👋

Version: v1.1.0

First of all, thanks for creating this tool - it's been super useful for our team!

Since upgrading to v1, an error is thrown when including a hyphen (-) in our WIP branch name. When calling the following:

mob start -b test-branch
mob next

An error is thrown:

 ERROR git --no-pager log master-test..mob/master-test-branch --pretty=format:%an --abbrev-commit
 ERROR fatal: ambiguous argument 'master-test..mob/master-test-branch': unknown revision or path not in the working tree.
 ERROR Use '--' to separate paths from revisions, like this:
 ERROR 'git <command> [<revision>...] -- [<file>...]'
 ERROR exit status 128

On first glance it looks like the hyphen is causing some function to interpret the base branch as master-test instead of master.

It's a minor issue, but helpful when naming our branches against JIRA tickets 😄

Thanks

Add wipBranch as a parameter of start

As the most part of parameters, except timer and wip-branch, doesn't change between developing cycles. What you think if the start function receives a second parameter "wip-branch" and in that sense avoiding the need to export the variable to the env.
I can perform the change, just need a "good to go" signal.

In time, Thx for the tool!

Remove go-release.action from release workflow

I feel that it would be worth it to get rid of the forked Github Action to release Go artifacts. As of today, all the necessary steps are available as ready to use actions. I would compose them in the following way:

1. setup go in the desired version (https://github.com/actions/setup-go)
2. run a build
3. upload a release (https://github.com/actions/upload-release-asset)

If you @simonharrer agree, I would prepare a corresponding PR. But maybe I am overlooking a reason to use the custom Action other than legacy?!

superfluous double quotes on commit message with MOB_WIP_COMMIT_MESSAGE

Current behaviour I observe:

export MOB_WIP_COMMIT_MESSAGE="MAGIC-JIRA-STUFF tmp"
../mob start 10

touch test

../mob next
>   git add --all
>   git commit --message "MAGIC-JIRA-STUFF tmp" --no-verify
....
>  ERROR remote: refs/heads/mob-session: 05bc5e5802d97062973fd1a3be48bb9e7a1d91e6: > commit message doesn't match regex: ([A-Z0-9\-]+)\s(?s:.*)

git show --oneline
> 05bc5e5 (HEAD -> mob-session) "MAGIC-JIRA-STUFF tmp"

I also tried changing
export MOB_WIP_COMMIT_MESSAGE="MAGIC-JIRA-STUFF tmp"
to:
export MOB_WIP_COMMIT_MESSAGE='MAGIC-JIRA-STUFF tmp'
export MOB_WIP_COMMIT_MESSAGE=MAGIC-JIRA-STUFF\ tmp

but it all showed me the superfluous double quotes around the commit message subject.
Which will be then rejected because our... tight rules regarding commit message subjects for all branches.

I would expect that what will be placed in MOB_WIP_COMMIT_MESSAGE will be used and not be wrapped in double quotes.

Also I would ask you to please reconsider your intention in this comment to remove this option. As I know some companies applying filters to commit message subjects.

Implement mob moo

The mob tool is not able to moo yet.
It should be able to moo (speak engine) when typing mob moo

mob next checking out master is confusing

If you regularly rotate, the fact that mob next checks out master can get in the way:

• you get back to a state before the mob session, thereby loosing all the code you have already written in the session (but you might want to look at it on your computer to research something)
• it can confuse any open IDE if any new files are all removed
• if a .gitignore was added part of the mob session, then mob next removes it, but leaves around whatever is ignored (e.g. a node_modules folder), which in turn will make the next mob start of the typist fail, as that one does not like any non-added and non-committed files lying around
• if you started from a different branch than master, it's confusing that it does not return to the same one (for a typist who didn't start the first mob start and who did not set MOB_BASE_BRANCH)

IMO for the typical mob rotation it would be nice if:

• mob next commits & pushs but stays in the mob-session branch
• the next mob start will simply git pull the new commits from the mob-session branch

could not start mob from feature/featurename

It is not possible to start a mob session from a branch feature/featurename.

The console says the following:

 DEBUG on branch feature/featurename => BASE feature WIP mob/feature/featurename
 > starting new mob session from origin/feature
 DEBUG git checkout -B mob/feature/featurename origin/feature
 DEBUG fatal: 'origin/feature' is not a commit and a branch 'mob/feature/featurename' cannot be created from it
 ERROR git checkout -B mob/feature/featurename origin/feature
 ERROR fatal: 'origin/feature' is not a commit and a branch 'mob/feature/featurename' cannot be created from it
 ERROR exit status 128

It looks like the currentBaseBranch in determineBranches is not right...

always commit everything within repo

using git add . should be a a git add everything in repository regardless of which directory this command was executed.

Keep intermediate commits

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?

Run tests via GitHub actions

• run tests on each commit and notify if tests fail
• run tests before each release to ensure that only releases with successful tests can be built

Platform independent Timer

https://github.com/blang/thymer could be integrated to be platform independent.