hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajat Ratewal <rajatrate...@gmail.com>
Subject Re: moving Hive to git
Date Wed, 17 Sep 2014 17:14:35 GMT
Can we look at how this is done in Hbase or Hadoop. If these projects
migrated on git then I am sure that they might have faced similar issues.
On 17 Sep 2014 22:37, "E.L. Leverenz" <e.l.leverenz@att.net> wrote:

> This is the rest of the message I meant to send on the "moving Hive to
> git" thread, but then did an accidental send.  Apache rejected several
> attempts as spam, so I'm sending this from a different email account.
>
> This list summarizes the previous discussion, with my questions/comments:
>         1. "... git is more powerful and easy to use (once you go past the
> learning curve!)" [Thejas] -- that learning curve still intimidates me,
> which suggests it might also be daunting for newcomers.
>         2. "Switching to git from svn seems to be a proposal slightly
> different from that of switching to pull request from the head of the
> thread. Personally I'm +1 to git, but I think patches are very portable and
> widely adopted in Hadoop ecosystem and we should keep the practice."
> [Xuefu] -- could someone explain the patch issue?
>         3. "We need to keep patches in Jira  ... having a patch in the
> jira is critical I feel. We must at least have a perma link to the
> changes." [Edward] -- again, how are patches different in git?
>         4. "In my read of the Apache git - github integration blog post we
> cannot use pull requests as patches. Just that we'll be notified of them
> and could perhaps use them as code review." [Brock] -- okay, perhaps this
> answers my patch question.
>         5. "One additional item I think we should investigate is disabling
> merge commits on trunk and feature branches." -- uh oh, I'm slipping
> backwards on the learning curve.
>         6. "I do not think we want Pull Requests coming at us. Better way
> is let someone open a git branch for the changes, then we review and merge
> the branch." [Edward] -- okay, creeping back up the learning curve.
>         7. "I'm +1 on switching to git, but only if we can find a way to
> disable merge commits to trunk and feature branches. I'm -1 on switching to
> Github since, as far as I know, it only supports merge based workflows."
> [Carl]
>         8. "Agree with Carl about git merge commits, they make the changes
> hard to follow. But it should be OK, if there is no way to disable it in
> the main git repo, it is a small set of active committers, we can make a
> policy and expect people to follow it. But we should certainly disable 'git
> push -f' (and anything as distruptive)." [Thejas]-- that small set of
> committers is growing larger all the time.
> -- Lefty

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