I can see 2 potential flows

1. mob start --with <> ; Take the git mob approach and set state for the mob session. This would require some way of communicating the members of the mob via git, which doesn't feel right.
2. mob done --with <>; Stateless flag at finish where mob members can be listed manually

However the more I talk this out the less I like it, specially in context of automatic parsing from users of next. It would require some mental energy to remember who had not used next...

Maybe the solution is to make tools like git mob work well together with mob? They both solve different problems somehow. What do you think?

Indeed. They do solve slightly different, though related, problems.
It seems that git mob writes to .git/.gitmessage which is the standard commit template location,
whereas mob ends up setting .git/COMMIT_EDITMSG (via --ff-only) which doesn't appear to respect .git/.gitmessage when git commit is finally run.

What if mob done prepended .git/.gitmessage onto .git/COMMIT_EDITMSG

I see this as not only working with git mob (kind of a secondary benefit), but also respecting teams which have a common commit template. I imagine that not many users are keeping the

mob next [ci-skip] [ci skip] [skip ci]

commits in their final history.

It actually appears that git-mob provides a sample hook which sets co-authors on COMMIT_EDITMSG,
https://github.com/findmypast-oss/git-mob/blob/master/hook-examples/prepare-commit-msg-nodejs

This works, but requires set up between users. The reality is that getting shared config between devs is a hard problem. I'd prefer to see some native support in mob.

I'm almost coming back to wanting the UX to be like

1. =>
   a. mob start --with al,sh
   b. mob start --with "Alex Launi <alauni1@ford.com>, Simon Harrer <i@didntlook.com>"
2. mob next
3. ...
4. mob done # Parses authors & co-authors for final commit

the shorthand version leads to "how is that defined?" A quick search shows 2 common tools, git mob and git team which each do it differently.

In my perfect world:

• mob start --with "Alex Launi <alauni1@ford.com> as al, Simon Harrer <i@didntlook.com> as sh"
  • would only need to be run once during a mob, sets Co-authored-by on a WIP commit.
  • If someone new joins they can be added with another mob start --with "Hi Friend < ... >"
  • When mob done is run it parses authors/co-authors from the WIP commits and nicely appends everyone who worked in the mob

We've started implementing the --with workflow based on @stevegt 's branch. https://github.com/lamalex/mob/tree/append-coauthors

I just now noticed, however, that the actual code to merge coauthor is not implemented.

Makes sense.

Is this in lieu of mob done, or in addition to?

Hm, it could be combined with --no-squash via a parameter. But I think this might be an issue independent of attribution.

@gregorriegler what about the situation where you only have WIP commits. What does the script do in this case? I hope it doesn't merge everything in the starting commit from the main branch :-D

Maybe we need to focus this on user stories and how we actually want it to work rather than how we want to implement it.

As a member of a mob
Given all members have committed code
I want all members of my mob to appear as co-authors

As a member of a mob who has not committed code
I want to appear in co-authors

@gregorriegler what about the situation where you only have WIP commits. What does the script do in this case? I hope it doesn't merge everything in the starting commit from the main branch :-D

if there is only one wip commit, it will leave it.
if there are many, but only wip commits, it will try to squash them, setting an empty commit message, which fails the rebase, but that's all.
so i make sure that there is a manual commit in the end