Rename detection in status()

[jacquesg]

I've implemented a WIP for rename detection. Please have a look at it and let me know what you think.

It's actually a little bit tricky, considering that a file may be renamed in the index and in the working tree at the same time. The current data model where we return ex. {'file' => [ '*_modified']} cannot capture renames.

[jacquesg]

This is still a WIP, figuring out exactly how to handle all the possibilities.

[ghedo]

I merged my status implementation into master now, can you please rebase your changes against that? Note that I also fixed the stupid bug where the git_status_options wasn't actually used, so you may have some conflicts.

[jacquesg]

Rebased.

[ghedo]

So, if I understand this correctly, now status() returns something like:

{
  'file1' => {
    'flags' => [...]
  },
  'file2' => {
    'flags' => [...],
    'index' => {
      'old_file' => ...
    }
  },
  'file3' => {
    'flags' => [...],
    'worktree' => {
      'old_file' => ...
    }
  }
}

Where file2 is renamed in the index, and file3 is renamed in the worktree. Looks good to me. Is there anything missing?

(also, I'm not sure why path_is_ignored() is in this PR)

[jacquesg]

That is exactly what it will return. Looks like there is still a bug in libgit2 where if a file is renamed in the index (git mv old new), and then also moved in the work tree (mv new new.wt), it just gives a OID error, so for now the renames in the working directory don't work (this is git's behaviour).

I'll move the path_is_ignored to a separate pull request. Had it here because it was missing and of the form git_status_*.

[jacquesg]

I'm almost done with this PR and busy with #31, should finish it this week. Is it possible to do a new release later this week? I would like to synchronise internally with all the changes that are now upstream.

[ghedo]

Sure, I can do a release whenever you are ready.

[jacquesg]

I think this one is done :)

[ghedo]

Merged, thanks!