neat, didn't know about the selective force push.
On Mon, Aug 4, 2014 at 10:43 AM, Andrew Purtell <apurt...@apache.org> wrote: > 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) > -- Alejandro
