remotemobprogramming / mob

Tool for smooth git handover.

Fast git handover with mob

#StandWithUkraine donate here #StandWithUkraine

Fast git handover for remote pair/mob programming.

• mob is an open source command line tool written in go
• mob is the fastest way to hand over code via git
• mob keeps your branches clean and only creates WIP commits on temporary branches
• mob has a shared team timer timer.mob.sh
• mob is on 'assess' in the Thoughtworks Technology Radar
• mob has VSCode integration

What people say about mob

Sometimes you come across a tool that you didn't realize you needed until you do; mob is just such a tool. Living as we do in a world where remote pair programming has become the norm for many teams, having a tool that allows for seamless handover either between pairs or a wider group as part of a mob programming session is super useful. mob hides all the version control paraphernalia behind a command-line interface that makes participating in mob programming sessions simpler. It also provides specific advice around how to participate remotely, for example, to "steal the screenshare" in Zoom rather than ending a screenshare, ensuring the video layout doesn't change for participants. A useful tool and thoughtful advice, what's not to like? — Technology Radar Volume 25, thoughtworks

"Mob has allowed us to run fast-paced, engaging, and effective sessions by enabling sub-10-second handover times and otherwise getting out of the way. A simple but great tool!" — Jeff Langr, developer

"I love it, it is a quantum leap in our collaboration." — Vasiliy Sivovolov, Senior Software Engineer

"What a great tool to organise remote working." — Jennifer Gommans, IT Consultant

"I was recently introduced to mob.sh for remote pairing/mobbing collaboration and I absolutely love it. The timer feature is really a selling point for me. Kudos" — Fabien Illert, IT Consultant

How to install

The recommended way to install mob is as a binary via the provided install script:

# works for macOS, linux, and even on windows in git bash
curl -sL install.mob.sh | sh

On macOS via homebrew:

brew install remotemobprogramming/brew/mob

# upgrade to latest version
brew upgrade remotemobprogramming/brew/mob

On Windows via Scoop:

scoop install mob

or via Chocolatey

choco install mob

On Arch Linux via yay:

yay -S mobsh-bin

On Nix through declarative installation

{ pkgs, ... }:
{
  # Either for all users
  environment.systemPackages = with pkgs; [ mob ];

  # Or for an explicit user
  users.users."youruser".packages = with pkgs; [ mob ];
}

On NetBSD, macOS, SmartOS, Linux, FreeBSD, OpenBSD, and more, via pkgsrc:

# if there's a binary package for your platform
pkgin install mob

# otherwise, for any platform
cd pkgsrc/devel/mob && bmake install clean

On Ubuntu there's an EXPERIMENTAL snap package with a known limitation (ssh-agent not working):

sudo snap install mob-sh
sudo snap connect mob-sh:ssh-keys

Using go tools

If you have go 1.20+ you can install and build directly from source:

go install github.com/remotemobprogramming/mob/v4@latest

or pick a specific version:

go install github.com/remotemobprogramming/mob/[email protected]

or to install latest unreleased changes:

go install github.com/remotemobprogramming/mob/v4@main

How to use

You only need three commands: mob start, mob next, and mob done.

Switch to a separate branch with mob start and handover to the next person with mob next. Repeat. When you're done, get your changes into the staging area of the main branch with mob done and commit them.

Here's a short example on how the two developers Carola and Maria code a feature together and push it in the end.

# Carola
main $ mob start
mob/main $ echo "hello" > work.txt
mob/main $ mob next

# Maria
main $ mob start
mob/main $ cat work.txt # shows "hello"
mob/main $ echo " world" >> work.txt
mob/main $ mob next

# Carola
mob/main $ mob start
mob/main $ cat work.txt # shows "hello world"
mob/main $ echo "!" >> work.txt
mob/main $ mob done
main $ git commit -m "create greeting file"
main $ git push

And here's the man page of the tool:

mob enables a smooth Git handover

Basic Commands:
  start              start session from base branch in wip branch
  next               handover changes in wip branch to next person
  done               squashes all changes in wip branch to index in base branch
  reset              removes local and remote wip branch
  clean              removes all orphan wip branches

Basic Commands(Options):
  start [<minutes>]                      Start a <minutes> timer
    [--include-uncommitted-changes|-i]   Move uncommitted changes to wip branch
    [--branch|-b <branch-postfix>]       Set wip branch to 'mob/<base-branch>-<branch-postfix>'
    [--create]                           Create the remote branch
    [--room <room-name>]                 Set room name for timer.mob.sh once
  next
    [--stay|-s]                          Stay on wip branch (default)
    [--return-to-base-branch|-r]         Return to base branch
    [--message|-m <commit-message>]      Override commit message
  done
    [--no-squash]                        Squash no commits from wip branch, only merge wip branch
    [--squash]                           Squash all commits from wip branch
    [--squash-wip]                       Squash wip commits from wip branch, maintaining manual commits
  reset
    [--branch|-b <branch-postfix>]       Set wip branch to 'mob/<base-branch>/<branch-postfix>'

Timer Commands:
  timer <minutes>           Start a <minutes> timer
    [--room <room-name>]    Set room name for timer.mob.sh once
  timer open                Opens the timer website
    [--room <room-name>]    Set room name for timer.mob.sh once
  start <minutes>           Start mob session in wip branch and a <minutes> timer
  break <minutes>           Start a <minutes> break timer

Short Commands (Options and descriptions as above):
  s                  alias for 'start'
  n                  alias for 'next'
  d                  alias for 'done'
  b                  alias for 'branch'
  t                  alias for 'timer'

Get more information:
  status             show the status of the current session
  fetch              fetch remote state
  branch             show remote wip branches
  config             show all configuration options
  version            show the version
  help               show help

Other
  moo                moo!

Add --debug to any option to enable verbose logging


Examples:
  # start 10 min session in wip branch 'mob-session'
  mob start 10

  # start session in wip branch 'mob/<base-branch>/green'
  mob start --branch green

  # handover code and return to base branch
  mob next --return-to-base-branch

  # squashes all commits and puts changes in index of base branch
  mob done

  # make a sound check
  mob moo

If you need some assistance when typing the subcommands and options, you might want to have a look at fig which gives you autocompletion in your shell.

Best Practices

• Say out loud
  • Whenever you key in mob next at the end of your turn or mob start at the beginning of your turn say the command out loud.
  • Why? Everybody sees and also hears whose turn is ending and whose turn has started. But even more important, the person whose turn is about to start needs to know when the previous person entered mob next so they get the latest commit via their mob start.
• Steal the screenshare
  • After your turn, don't disable the screenshare. Let the next person steal the screenshare. (Requires a setting in Zoom)
  • Why? This provides more calm (and less diversion) for the rest of the mob as the video conference layout doesn't change, allowing the rest of the mob to keep discussing the problem and finding the best solution, even during a Git handover.
• Share audio
  • Share your audio when you share your screen.
  • Why? Sharing audio means everybody will hear when the timer is up. So everybody will help you to rotate, even if you have missed it coincidentally or deliberately.
• Use a timer
  • Always specify a timer when using mob start (for a 5 minute timer use mob start 5)
  • Why? Rotation is key to good pair and mob programming. Just build the habit right from the start. Try to set a timer so everybody can have a turn at least once every 30 minutes.
• Set up a global shortcut for screensharing
  • Set up a global keyboard shortcut to start sharing your screen. In Zoom, you can do this via Zoom > Preferences > Keyboard Shortcuts. More tips on setting up Zoom for effective screen sharing.
  • Why? This is just much faster than using the mouse.
• Set your editor to autosave
  • Have your editor save your files on every keystroke automatically. IntelliJ products do this automatically. VS Code, however, needs to be configured via "File > Auto Save toggle".
  • Why? Sometimes people forget to save their files. With autosave, any change will be handed over via mob next.

The Perfect Git Handover

The perfect git handover is quick, requires no talking, and allows the rest of the team to continue discussing how to best solve the current problem undisturbed by the handover. Here's how to achieve that.

• Situation Maria is typist sharing the screen, Mona is next
• Maria runs mob next
  • keeps sharing the screen with the terminal showing the successful run of mob next
  • does nothing (i.e., no typing, no mouse cursor movement, no window switching)
• Mona steals screenshare using keyboard shortcut, and, afterwards, runs mob start
• Maria checks her twitter

Complementary Scripts

mob-start feature1 creates a new base branch feature1 to immediately start a wip branch mob/feature1 from there.

mob-start() { git checkout -b "$@" && git push origin "$@" --set-upstream && mob start --include-uncommitted-changes; }

Useful Aliases

alias ms='mob start'
alias mn='mob next'
alias md='mob done'
alias moo='mob moo'

Use the name you like

mob version
#v1.11.0
alias ensemble='mob' # introduce alias
export MOB_CLI_NAME='ensemble' # makes it aware of the alias
ensemble next
#👉 to start working together, use
#
#  ensemble start
#

And starting with v1.12.0, mob is symlink aware as well:

mob version
#v1.12.0
ln -s /usr/local/bin/mob /usr/local/bin/ensemble
ensemble next
#👉 to start working together, use
#
#  ensemble start
#

Automatically set the timer room when using ticket numbers as branch modifiers

Say you're a larger team and work on the same git repository using ticket numbers as branch modifiers. It's easy to forget exporting the room that enables the integration with timer.mob.sh. Just set the configuration option MOB_TIMER_ROOM_USE_WIP_BRANCH_QUALIFIER=true in ~/.mob for that.

Automatically open the last modified file of the previous typist

When you are rotating the typist, you often need to open the file, which the previous typist has modified last. Mob supports you and can automate this step. You just need the configuration option MOB_OPEN_COMMAND with the command to open a file in your preferred IDE.

For example if you want use IntelliJ the configuration option would look like this: MOB_OPEN_COMMAND="idea %s"

More on Installation

Known Issues

• When you have an ssh key with a password and you running mob on windows in powershell, you will not be able to enter a password for your ssh key. You can circumvent this problem by using the git bash instead of powershell.

Linux Timer

(This is not needed when installing via snap.)

To get the timer to play "mob next" on your speakers when your time is up, you'll need an installed speech engine. Install that on Debian/Ubuntu/Mint as follows:

sudo apt-get install espeak-ng-espeak mbrola-us1

or on Arch Linux as follows:

sudo pacman -S espeak-ng-espeak
yay -S mbrola-voices-us1

Create a little script in your $PATH called say with the following content:

#!/bin/sh
espeak -v us-mbrola-1 "$@"

If you use WSL2 on windows, install eSpeak as windows tool and Create a little script in your $PATH called say with the following content:

#!/bin/sh
/mnt/c/Program\ Files\ \(x86\)/eSpeak/command_line/espeak.exe "$@"

make sure that the path to the windows espeak.exefits your installation. You can avoid the long path by adding it to your windows path variable.

How to configure

Show your current configuration with mob config:

MOB_CLI_NAME="mob"
MOB_REMOTE_NAME="origin"
MOB_WIP_COMMIT_MESSAGE="mob next [ci-skip] [ci skip] [skip ci]"
MOB_START_COMMIT_MESSAGE="mob start [ci-skip] [ci skip] [skip ci]"
MOB_GIT_HOOKS_ENABLED=false
MOB_REQUIRE_COMMIT_MESSAGE=false
MOB_VOICE_COMMAND="say \"%s\""
MOB_VOICE_MESSAGE="mob next"
MOB_NOTIFY_COMMAND="/usr/bin/osascript -e 'display notification \"%s\"'"
MOB_NOTIFY_MESSAGE="mob next"
MOB_NEXT_STAY=true
MOB_START_CREATE=false
MOB_STASH_NAME="mob-stash-name"
MOB_WIP_BRANCH_QUALIFIER=""
MOB_WIP_BRANCH_QUALIFIER_SEPARATOR="-"
MOB_WIP_BRANCH_PREFIX="mob/"
MOB_DONE_SQUASH=squash
MOB_OPEN_COMMAND="idea %s"
MOB_TIMER=""
MOB_TIMER_ROOM="mob"
MOB_TIMER_ROOM_USE_WIP_BRANCH_QUALIFIER=false
MOB_TIMER_LOCAL=true
MOB_TIMER_USER="sh"
MOB_TIMER_URL="https://timer.mob.sh/"

Override default value permanently via a .mob file in your user home or in your git project repository root. (recommended)

Override default value permanently via environment variables:

export MOB_NEXT_STAY=true

Override default value just for a single call:

MOB_NEXT_STAY=true mob next

Integration with timer.mob.sh

For your name to show up in the room at timer.mob.sh you must set a timer value either via the MOB_TIMER variable, a config file, or an argument to start.

How to uninstall

Mob can simply be uninstalled by removing the installed binary (at least if it was installed via the http://install.mob.sh script).

Linux

rm /usr/local/bin/mob

Windows (Git Bash)

rm ~/bin/mob.exe

MacOS

brew uninstall remotemobprogramming/brew/mob

How to contribute

Propose your change in an issue or directly create a pull request with your improvements.

# PROJECT_ROOT is the root of the project/repository

cd $PROJECT_ROOT

git version # >= 2.17
go version # >= 1.15

go build # builds 'mob'

go test # runs all tests
go test -run TestDetermineBranches # runs the single test named 'TestDetermineBranches'

# run tests and show test coverage in browser
go test -coverprofile=cover.out && go tool cover -html=cover.out

Design Concepts

• mob is a thin wrapper around git.
• mob is not interactive.
• mob owns its wip branches. It will create wip branches, make commits, push them, but also delete them.
• mob requires the user to do changes in non-wip branches.
• mob provides a copy'n'paste solution if it encounters an error.
• mob relies on information accessible via git.
• mob provides only a few environment variables for configuration.
• mob only uses the Go standard library and no 3rd party plugins.

Who is using 'mob'?

• INNOQ
• BLUME2000
• REWE Digital
• Amadeus IT Group
• FlixMobility TECH (FlixBus)
• And probably many others who shall not be named.

Credits

Created by Dr. Simon Harrer in September 2018.

Currently maintained by Gregor Riegler and Joshua Töpfer, and to some limited degree still by Dr. Simon Harrer.

Contributions and testing by Jochen Christ, Martin Huber, Franziska Dessart, Nikolas Hermann and Christoph Welcz. Thank you!

Logo designed by Sonja Scheungrab.

mob's Issues

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.

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 "$@"

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 :)

Getting started

create a getting started video with the mob tool

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

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.

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

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.

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

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.

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.

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.

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.

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.

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?

Update docs

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

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.

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.

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.

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?

Add parameter to specify the working directory

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

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

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.

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 :-)

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

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

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

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

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.

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.

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?

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?!

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.

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?

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!

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.

Implement mob moo

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

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.

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

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

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.

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

Add badge for latest version number to mob.sh

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

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.

go.mod breaks release pipeline

@gregorriegler

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?

Platform independent Timer

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

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

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.