hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <t...@cloudera.com>
Subject Re: [DISCUSS] Migrate from svn to git for source control?
Date Mon, 04 Aug 2014 19:26:14 GMT
neat, didn't know about the selective force push.


On Mon, Aug 4, 2014 at 10:43 AM, Andrew Purtell <apurtell@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 <tucu@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 <stevel@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 <kasha@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message