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