Menu
▾
▴
Re: [Geotools-devel] An eventual move to git: please discuss
|
From: Andrea A. <and...@ge...> - 2012-01-21 17:45:35
|
On Sat, Jan 21, 2012 at 5:45 PM, Justin Deoliveira <jde...@op...>wrote: > Thanks for refreshing the topic Andrea. I too agree that the move to git > is eventually inevitable and coming sooner rather than later. Some random > thoughts. > > I think it will be key to have some good docs in the developer guide about > git. Nothing too crazy, but a quick little reference guide for git given > within the context of geotools. Some basic commands with a list of does and > dont's. > There is a number of basic intros and cheat-sheets around, what would be geotools specific? I guess the way we manage branches, forks, and who can commit where? > > I have used git for vcs on other projects and there can certainly be > pitfalls and ways you can shoot yourself in the foot. One is with rebasing. > I don't know about others but I love git rebasing. I really like it when I > am on a branch doing a bunch of changes that show up as various commits > over time, i like the ability to be able to do an update, or merge with > another branch, but stick all my changes at the very end, keeping the > history clean. Or interactive rebasing where you can merge two commits > together, remove commits, etc... Well as many know this rewrites history in > the repo, so if that branch is shared with someone else you have just > screwed them for the next merge. > Yep, I'm an avid user of interactive rebasing me too. First commit as one sees fit, even with stuff not compiling, while coding and (inevitably) jumping from one branch to the other to follow this and that project/customer, then cleanup with an interactive rebase to come up with something presentable to the rest of the community. Working against svn makes this somewhat easy, in fact I don't believe the usual "git pull" would keep the local history at the end, wouldn't it? > > The release guide will have to be updated, but also we will have to tweak > our release process a little bit. Like how exactly does one do a release? > Do I create a branch from the branch we are releasing from, do all the > release work on the branch, and then merge back into master? Or do we > simply keep the branch around, update README / pom etc... and then tag that > branch? Things like that. > Yep > > This is more an issue for geoserver but there is no exact parallell for > svn externals in git. Git has submodules, which are quite a different > beast. The main difference is that while svn externals let you point to any > place in a repository, git submodules force you to bring in an > entire repository. So this will take some updating. > Right. I guess most of the reason for externals in svn was to allow people with bad internet connections to download the data and documentation? However with git one has to download the whole repo, so the reason for some of the externals would cease to exist (also, the data area is not growing and internet connection speed went up significantly in the last 5 years). > > Then there is the question of hosting. I have really only used github, > which i can't say anything bad about... well except maybe that the issue > tracker is a bit too limited, but getting better. I know udig uses > gitorious, curious to here from them as to why they went that route. From > what I can read online comparing the two it seems github has more features > and is better supported. > > [1] > http://stackoverflow.com/questions/78991/why-is-github-more-popular-than-gitorious > A bit old. To be honest I never looked at gitorious but I believe uDig had a rough ride with it and eventually switched to github? The fact that one can also host private company repos and public open repos on the same platform is also a plus to me. > > The question of issue tracker is an interesting as well. While the github > issue tracker is not nearly as fully featured as jira, would we even > consider switching? One major benefit would be the integrated issue > commenting with the ability to make a comment on in issue in a commit > message, or even close an issue from a commit message. I am guessing this > won't be enticing enough... we actually had this setup for a while in > hudson and jira and i don't think it saw much use, certainly noone > complained when it went away. > Ugh, the bug tracker at github is pathetic to say the least, it's ok if you have 10 open issues, but when you have hundreds, give me jira any day :-) > > Finally yes, I definitely think a poll would be a great idea to hear from > the community on this one. > Cool, a few more +1 on the idea and I'll setup one Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- |