Support default email domain about git-mob HOT 10 CLOSED

Example structure

{
  "coauthors": {
    "rk": {
      "name": "Richard Kotze",
      "email": "[email protected]"
     },
  },
  "default_email_domain": "gmail.com"
}

from git-mob.

Part of this issue we will stop support for .git-author YAML and replace it with a json format, related to is #3

from git-mob.

How about we change the .git-coauthors json format to something like:

{
  "coauthors": {
    "ad": "Amy Doe; [email protected]",
    "bd": "Bob Doe; [email protected]",
    "ja":  "Jane Anderson; janderson"
  },
  "default_email_domain": "gmail.com"
}

Should make for an easier transition from yaml to json.

from git-mob.

Changed focus to be on a default email address since we already support different emails.

from git-mob.

To better support default email, the coauthors will have a new prop username. This will be the first part of the email address. If this property is there then it will use the default email domain.

The below example will output: Richard Kotze <[email protected]>

{
  "coauthors": {
    "rk": {
      "name": "Richard Kotze",
      "username": "richard"
     },
  },
  "default_email_domain": "gmail.com"
}

username will have priority over email. If both there then username and default email will be used.

from git-mob.

I think the above proposal has some drawbacks.

• Without reading docs, it's not obvious that the username property is tied to the email. Could there be a better property name?
• What benefit does adding a username property have over a more explicit email property?
• Config overrides are confusing - is there a solution that's obvious without referring to the docs?

from git-mob.

My thoughts were kind of along the same lines as yours in terms of minimising confusing.

By calling a property email and saying it can also just be the first part might also be confusing. Maybe a better name is the solution?

Wikipedia about email address calls it local-part. Not saying this is the prop to use, but the idea of the prop being explicit about what it does could be good.

What you're thoughts on this?

from git-mob.

My thoughts are to defer this until people start asking for it 😄

I now think of it as a minor optimisation that's not worth increasing the tool's complexity.

from git-mob.

I agree 👍

from git-mob.

Might bring back, if requested or voted up.

from git-mob.