In order to reduce the amount of repeating describing your work on a ticket we want to integrate git to some extent.

New Package:

• lino_xl.lib.github
• github rather than 'git' for reasons of other git prodiers have thier own API. And while they are simaler, would be better to focus on github's.

new models:

• github.repo
• user #rep owner ursername
• repo name
• o-auth api-token [url github.com/settings/tokens/new] # Needed since without auth we are limited to 60 calls per hour, compaired to 5000/hour.
• github.commit
• FK:user
• FK:githup.repo
• git-user CHAR #Needed in the case of unknown users, we leave this blank if we know the user.
• commit sha
• commit date
• git-url #Either generate on the fly or store, the API automatically gives us the url, might as well use it.
• summary
• details #Git merges this but we should seperate them I think...
• comment #for when lino can't guess which ticket it belongs to...
• ticket

Users modifications:

• field injection: git-login name
• Might want to have this as a part of the repo_user, incase they use differnt users for differnt repos, however I think this is unlikly for most people and not the case for us.
• Eg: lsaffre, CylonOven
  
• Or use git-user id's [url caius.github.io/github_id/#lsaffre]

Tables:

• All Repos
• All commits
• My commits
• My Unasigned Commits
• commits By ticket
• commits by user
• commits by unknown user
• #tickets by commit

Memo:

• New memo [commit sha] > links to github 
• (git already does this, can just gen the link and if it dosn't work it's the users fault) Can do the lookup so that you only need to suply the first n chars of the sha and it will work, if more then one records are found because the sha is too short... do something. Either the first one, or error somehow.

Actions:

• Import repo:
• Work though all commits on Master branch via the api call
• Creat commit objects if SHA not in DB,
• Link commit
• look up commit author's sessions that were during the commit time.
• link commit with the session's ticket. 
• Check repo
• look up the last 100 ( too many? ) commits for each repo and inspect for new tickets
• on shedule for every 10 min

Questions for Luc:

• How is a ticket related to a git?
• First version have all tickets related to every git in the git.repo table.
• For the future have a  (repo <> gfks)?
• If so what should be related to the repo? Project, site, topic, user?
• I kind of like user, have a list of repos that this user works on and thus only those are looked up on their sessions
• Yes, users should have a list of repos that they work on, and lino uses their sessions in order to figure out which commits are for which ticket.
• Answer:
• No link between tickets or users to repos, for reasons of tediusness
• For the api-token would a [py lino.core.fields.PasswordField] work?
• Is it realisic to think that all commits should be linked with a ticket?

Remarks:

• Seems that the api call [url api.github.com/repos/lino-framework/noi/commits] collects from master, this is OK I guess
• If a commit is 'lost' by a destructive action it seems that github 'holds onto' the commit, see [url github.com/CylonOven/django-mailbox/commit/6d1470e36615c8490fc94a04e58936946ea3ce56] I created some commits, squashed them, then did a force push, making the previous commits no longer connected to the HEAD of any branch. Usually this means that the commits are lost, but it seems that github hold onto them. This means that if any commits are 'lost' it doesn't matter for us since the link will still work, infact this is a good thing since if for some reason we mess up and loose the data we might be able to find the commit this way.
• Might use [url this stackoverflow.com/questions/17311059/django-bulk-create-ignore-duplicates] to insert the commits