hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [DISCUSS] Migrate from svn to git for source control?
Date Mon, 04 Aug 2014 17:32:45 GMT
Personally, I would love us to use something like gerrit.

My current review workflow requires me to download the patch, apply it on
latest trunk and look at the diff in an IDE. I still might want to do it
for big patches, but I would love to be able to just see the diff directly.
Also, it would be nicer to look at the diff between versions. I understand
RB provides most of these, but I felt and heard gerrit is somehow better.

I am not sure using gerrit to commit to different branches is possible
though. I heard about other ASF projects getting resistance because it is a
headless user (gerrit) committing and not a person.


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.
>

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