HBase recently made the leap from SVN to Git. Our early experience is positive, I think. My observations:
When you commit a merge in git, the software will generate a merge commit message in the target branch's history. HBasers decided these pollute history - although an option to 'git log' can elide them - so instead of using 'git merge' for merging we are using alternate workflows that build on 'git rebase'. Rebasing has sharper edges. Occasionally a committer will forget and we will have a merge commit in history. Now and then isn't much of an issue. As committers migrate from svn to git you will need to deal with the occasional botch in history, though. Git allows you to rewrite history but there are consequences to that and default protections in place to prevent it. Infra has something set up to protect against force pushing to certain protected branch names, such as "master" and "trunk". Otherwise you are able to force push by default. I think you will want to work with Infra to prevent force pushing to your branch-* branches as well. Conversely, a force push after rebasing a feature branch on trunk will not be an issue, if you exclude feature branches from this protection. That could be a good thing. If for some reason someone pushes toxic waste to a protected branch, it's easy to work with Infra to temporarily relax force push protections for cleanup. Finally, a force push will cause issues with any checkout tracking the old history, so you'll want to notify all committers in advance so they can take steps. This isn't an issue with SVN, so that's a consideration, but force pushes should be rare outside of feature branches (we haven't had one yet for ~months over in HBase). I found it convenient to tag a release candidate in SVN, then commit CHANGES.txt and other release specific modifications to the tag, since in SVN a tag is a branch is a tag, rather than mix release mechanics with the rest of branch history. This may be an unorthodox practice. I only mention it because with git tags don't work that way. I think it is possible to emulate this by pushing a temporary branch and the desired tag pointing to a commit on that branch, and then another push that removes the temporary branch, leaving only the tag as a ref to that part of history. If you like. We are having some minor discussions about commit formats, how we'd like to do contributor attribution. (This is my fault.) As with everything else about git, there are a couple of ways to do it. On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur <t...@cloudera.com> wrote: > merging a multi jiras feature from one branch to another is much easier in > git, you can keep all jiras as single commits, you can do any necessary > rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and > squash as necessary, check everything locally, iterate, then push when > things are ready. > > adopting gerrit would be gr8 too. > > thx > > Alejandro > (phone typing) > > > On Aug 4, 2014, at 2:36, Steve Loughran <ste...@hortonworks.com> wrote: > > > > I'm =0 on convenience, but like you said, that's because most people have > > drifted into public/private git repos for development of branches (though > > that's partly to avoid the ongoing review-before-each commit overhead) > > > > -moving to Git could encourage more in-ASF branch dev by committers > > -if we adopt gerrit then code review would be significantly easier > > -it'd reduce the latency from an svn commit to a git pull on the > > git.apache.org repo > > -we could take (compressed) "git am" patches with provenance. Other ASF > > projects (Twill) do this. > > -could maybe field git pull requests from outside > > > > I didn't think cherry picking did lineage so well, and svn merge does > that > > too. It's just a bit more fiddly. > > > > Given the overhead of actually applying patches to 2+ branches, I'm > > grateful for anything that improves this. > > > > But...for a move to git, I'd like to see what the big gains are, which > > seems to me to be in Gerrit. > > > > > > > > > > > >> On 2 August 2014 00:43, Karthik Kambatla <ka...@cloudera.com> wrote: > >> > >> Hi folks, > >> > >> From what I hear, a lot of devs use the git mirror for > development/reviews > >> and use subversion primarily for checking code in. I was wondering if it > >> would make more sense just to move to git. In addition to subjective > liking > >> of git, I see the following advantages in our workflow: > >> > >> 1. Feature branches - it becomes easier to work on them and keep > >> rebasing against the latest trunk. > >> 2. Cherry-picks between branches automatically ensures the exact same > >> commit message and tracks the lineage as well. > >> 3. When cutting new branches and/or updating maven versions etc., it > >> allows doing all the work locally before pushing it to the main > branch. > >> 4. Opens us up to potentially using other code-review tools. (Gerrit?) > >> 5. It is just more convenient. > >> > >> I am sure this was brought up before in different capacities. I believe > the > >> support for git in ASF is healthy now and several downstream projects > have > >> moved. Again, from what I hear, ASF INFRA folks make the migration > process > >> fairly easy. > >> > >> What do you all think? > >> > >> Thanks > >> Karthik > > > > -- > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or entity > to > > which it is addressed and may contain information that is confidential, > > privileged and exempt from disclosure under applicable law. If the reader > > of this message is not the intended recipient, you are hereby notified > that > > any printing, copying, dissemination, distribution, disclosure or > > forwarding of this communication is strictly prohibited. If you have > > received this communication in error, please contact the sender > immediately > > and delete it from your system. Thank You. > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
