[Proj] Github migration complete

[Elliott Sales de Andrade]

Hi Howard,

Howard Butler <howard <at> hobu.co> writes:
>
> All,
>
> Thanks to Thomas Bonfort, the proj.4 migration to github is complete. I
would like to invite you to take a
> look at
>
> https://github.com/OSGeo/proj.4
>

There are a few minor things to clean up that I think would be good to
do before calling this complete. They would modify the commit hashes and
require all forks to be recreated, so it is best to do them early.

 * Flatten the directory structure. In git, you get the entire history,
   so moving the docs to the directory on the side doesn't really change
   anything. You can fix this with some `git filter-branch` calls.

 * Most tags are made on an extra commit with no changes. The tags can
   be moved back one commit to the one on master. Then the tags become
   ancestors of most commits for better logging and such.
   * 4.9.0 (twice)
   * 4.8.0 (twice)
   * 4.7.0 (twice)
   * proj_4_5_0
   * proj_4_4_9
   * proj_4_4_7
   * proj_4_4_6
   * proj_4_4_5
   * NOTE: These empty commits will be automatically removed by calling
     git filter-branch.

 * Some tags contain an extra commit, but I think they can be removed:
   * proj_4_6_1 - This commit adds some files that were removed
                  (renamed) about 10 commits earlier. I _think_ the
                  commit should not exist.
   * proj_4_6_0 - This commit also adds some files that were removed
                  about 8 commits earlier. Again, I _think_ the commit
                  should not exist.
   * proj_4_4_8 - This commit duplicates some changes on another commit
                  that is on master. I think this tag can simply be
                  _moved_ to the commit on master since the two trees
                  are equivalent.

 * There are a couple of puzzling tags
   * proj_4_4_4 or 4.4.4 do not exist
   * proj_4_4_3 - This tag contains one extra commit that occurs 3 years
                  after its parent and even after proj_4_4_7. It even
                  includes changes that are some mix of 4.4.8. I don't
                  think this commit should exist either, as it seems to
                  be some kind of Frankenstein commit.

 * You need to create a .gitignore file. This can be done with
   git svn show-ignore > .gitignore
   Unfortunately, I have never been able to figure out an easy way to
   apply this retroactively.

 * Are you intending to keep the Subversion repository around and in
   sync? If not, you can remove the "git-svn-id" from the commit message
   that would just be clutter in an independent git repository.

To confirm my suspicions about the tags, I would go looking at the
tarballs, but the trac instance does not seem to be working for me at
the moment.

To show you how this would look (except for the .gitignore and
git-svn-id suggestions, as those should be done when converting from
svn), I have uploaded a cleaned repo [1] and, for reference, the
commands I used to produce it [2].

> and if there are no major issues identified in the next few days, we will
declare it complete and
> decommission the Trac instance at OSGeo.
>
> Howard

[1] https://github.com/QuLogic/proj4-clean
[2] https://gist.github.com/QuLogic/ed9d5f5c4a8b0dbc794f