remote: compatibility with git version > 2.10

[wusisu]

I found that a little change which affects the behavior of git.remote.FetchInfo as git version greater than or equal with 2.10.x. It case git.test.test_remote.TestRemote.test_base fails.

I figure out that a commit of git changes git fetch --tags's output.
And it seems that that commit first appeared in git 2.10.0

➜  git git:(master) git log --oneline v2.9.3..v2.10.0 | grep 2cb0
2cb040b fetch: change flag code for displaying tag update and deleted ref

I have almost no contribution on github. Beg pardon if I am not doing it well.

[Byron]

Thanks a lot for your contribution, and please know that I am sorry for getting back to this project with such a delay.

There is just one question left, and once clarified this PR should be ready to merge.

[Byron]

I wonder why this change was required.

[wusisu]

Maybe I make a mistake because I may not understand the project deeply.

I make this change for 3 reasons:

1. In the project before this commit, there is no difference between set(PushInfo._flag_map.keys()) & set(FetchInfo._flag_map.keys()) and set(FetchInfo._flag_map.keys()).
   PushInfo._flag_map.keys() == ['X', '-', '*', '+', ' ', '=', '!'] and FetchInfo._flag_map.keys() == ['!', '+', '-', '*', '=', ' '], and these two _flag_map are considered unchangable.

2. It seems that there is no need to make an intersection between Push and Fetch.
   The only two usages of this function is fetch and pull. As the function (named _get_fetch_info_from_stderr) has the word fetch in its name, its duty is to parse data from fetch messages, and thus should only use FetchInfo._flags_map.
   So, I think use set(FetchInfo._flag_map.keys()) is just the right way.

3. Push command has no 't'.
   Accoding to the documents of git-fetch and git-push, fetch has more command than push now, make an intersection will make this function loss some types of records.

That's way I think I could and have to make this change.

[Byron]

Thanks a lot for the clarification @wusisu , that makes sense.
Interestingly I took this intersection as union, and was afraid that something gets lost without it.