[Proj] Github migration complete
Elliott Sales de Andrade
quantum.analyst at gmail.com
Sat May 23 03:22:40 EST 2015
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
More information about the Proj
mailing list