[Proj] Github migration complete
Elliott Sales de Andrade
quantum.analyst at gmail.com
Sat May 23 03:22:40 EST 2015
Howard Butler <howard <at> hobu.co> writes:
> Thanks to Thomas Bonfort, the proj.4 migration to github is complete. I
would like to invite you to take a
> look at
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)
* NOTE: These empty commits will be automatically removed by calling
* 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
* 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
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  and, for reference, the
commands I used to produce it .
> 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.
More information about the Proj