Support including authors as Co-authored-by

[ipsi]

Add a config option, git-together.co-authored, which will switch
git-together from using Signed-off-by to Co-authored-by.

This makes it easier to support mobbing, as all authors are included in
the commit message, and this is supported by GitHub (c.f.
https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors
). This is mutually exlusive with signing off commits - you have to
choose one or the other. This is mostly because it doesn't make sense to
include a single extra committer as the one who signed it off, but it
also means that, in the event that a commit must be signed off, e.g.,
when committing to the Linux Kernel, you don't lose information.

This is a little fragile, as we are parsing multiple git options, and
potentially reading from stdin, as there are at least six different ways
to create a commit message in Git, four of which we care about, and two
of which we should at least acknowledge, even though we don't modify
them in any way.

This also fixes #20 by excluding --signoff from the list of args when
using --amend.

Removed #![feature(slice_patterns)] as that's now available on stable - therefore, git-together also now builds on stable. Nightly not required!

[kejadlen]

I'm not sure I want to add this additional functionality into git-together when it can be implemented on top of git-together.

@xinzweb has done this in the form of pivotal/git-author, though I can understand if you don't want to add additional tooling on top of git-together as well.

For now, I think I'll add a section to the README pointing at the whole suite of git-pair, duet, author, and your fork?

[ipsi]

I think adding some links to the readme would be great.

Looking specifically at git-author, it has some limitations, namely:

• It only works if you use the editor for your commit message as it relies on message templates.
• It does not work if you use the -m/--message option(s)
• It does not work if you use the -F/--file option

As a consequence, it won't work from within an IDE, for example, while including it in git-together will.

Including it in git-together feels like the right place - git-together is already having to modify the commit, this is just changing precise nature of that modification. Building it on top of git-together in a way that handles all the different options to pass in a commit message will require building another wrapper around git, and I foresee that causing all sorts of fun problems with people forgetting to put in the correct alias, not putting git-together on the path, somehow managing to create an infinite alias loop, etc, etc. Plus I definitely prefer only having one tool to install.

If you really don't want to include it in GT, it would probably be best done as a stand-alone fork, for all that the amount of duplicated code makes me twitch!

[bastiandoetsch]

Hey Alpha, I would love this addition, too, as the commit/author cycling in git-together makes pairing hard - github expects the person mentioned in signed-off by to be the person that actually signs the commit - which is only the case in 50% of the cases, when author and committer cycle.