I'd say learning curve for git is shorter than for svn, especially for newcomers, since git is widely adopted and used (afaik most people use git mirror for development even now, and only use svn to push). svn in my experience makes it hard to do things, as a general principle. I've had to write bash scripts to replace one git command (e.g. git clean), and branching is difficult.
On Wed, Sep 17, 2014 at 9:31 AM, 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 -- 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.
