On Sep 1, 2011, at 3:15 PM, FlyLanguage wrote:>> Is that really true? I've heard of a lot of LLVM developers using git >> but it all seems very opaque right now. That's why I hope to get people >> talking so we can find out where everyone is and go from there. > > Yet, there's surprisingly little complaint about Subversion around here, > which is kinda unfortunate :)I know you're being facetious, but why is it unfortunate? SVN serves our workflow very well. The versioning system should get out of the way of development; it shouldn't "pull focus." SVN doesn't require you to spend a lot of time learning it and adapting to its way of doing things. (The learning curve for SVN was small for me. My initial (and subsequent) experiences with git are that it's very, very complex. And it gets in the way of most things I want to do. I still don't know what a "ref" or "object" is.) -bw
> On Sep 1, 2011, at 3:15 PM, FlyLanguage wrote: > >>> Is that really true? I've heard of a lot of LLVM developers using git >>> but it all seems very opaque right now. That's why I hope to get people >>> talking so we can find out where everyone is and go from there. >> >> Yet, there's surprisingly little complaint about Subversion around here, >> which is kinda unfortunate :) > > I know you're being facetious, but why is it unfortunate?Because you're missing so much. > I still don't know what a "ref" or "object" is.) Fortunately, that's about the only thing in a git repository, so there's not much more to learn :)
On Sat, Sep 3, 2011 at 8:01 AM, FlyLanguage <flylanguage at gmail.com> wrote:>> On Sep 1, 2011, at 3:15 PM, FlyLanguage wrote: >> >>>> Is that really true? I've heard of a lot of LLVM developers using git >>>> but it all seems very opaque right now. That's why I hope to get people >>>> talking so we can find out where everyone is and go from there. >>> >>> Yet, there's surprisingly little complaint about Subversion around here, >>> which is kinda unfortunate :) >> >> I know you're being facetious, but why is it unfortunate? > > Because you're missing so much.I am not very familiar with GIT so I have a question: Let's say I don't fork and I work 1 patch at the time. Then what are the advantages of GIT over svn?
FlyLanguage <flylanguage at gmail.com> writes:>> I still don't know what a "ref" or "object" is.) > > Fortunately, that's about the only thing in a git repository, so > there's not much more to learn :)And you don't need to learn it at all. -Dave
On Sep 3, 2011, at 5:01 AM, FlyLanguage wrote:>> On Sep 1, 2011, at 3:15 PM, FlyLanguage wrote: >> >>>> Is that really true? I've heard of a lot of LLVM developers using git >>>> but it all seems very opaque right now. That's why I hope to get people >>>> talking so we can find out where everyone is and go from there. >>> >>> Yet, there's surprisingly little complaint about Subversion around here, >>> which is kinda unfortunate :) >> >> I know you're being facetious, but why is it unfortunate? > > Because you're missing so much.I read Dave's document. It lists (rather complex) ways to use it, but it doesn't list why any of them are needed for our workflow. That would go more towards convincing me that it's a good thing.> > I still don't know what a "ref" or "object" is.) > > Fortunately, that's about the only thing in a git repository, so there's not much more to learn :)That doesn't tell me anything. And unfortunately they are used in many git commands. -bw
> > SVN doesn't require you to spend a lot of time learning it and adapting to > its way of doing things. (The learning curve for SVN was small for me.Git also doesn't require you to spend a lot of time learning it and adapting to its way of doing things, if all you want to do is use the subset set of functionality that SVN provides. If you're using Git to talk to a central repository and simply force all your pulls from that central repository to 'rebase' your changes so that they appear after what you pull down (this can be done by setting branch.autosetuprebase or branch.<name>,rebase), your daily workflow is almost identical to SVN (checkin is split into two steps 1. commit locally, and 2. push to the central repo). My initial (and subsequent) experiences with git are that it's very, very> complex. And it gets in the way of most things I want to do. I still don't > know what a "ref" or "object" is.) >This very short page explains these things relatively well. http://eagain.net/articles/git-for-computer-scientists/ The reality is that Git isn't complex at all, although the man pages might make it look that way because most commands have many sub-options that can be used to achieve very specific behavior. The reality is that you can ignore 90% of most man pages, especially if you all you want to is have an SVN-like workflow. I've heard this "SVN works great for my workflow" argument before (in fact recently), and if I go back 15 years I heard the "I don't need SCM/VCS - my workflow of manually copying around back-ups works just fine." from people working on small projects on their own. The reality is that I am skeptical that there is any good way to explain how much of a benefit you can get from Git or other DSCMs - it's one of those things you have to experience for yourself to understand. I know that as I use Git more and more, I appreciate it more and more. I invested a little time up front and it has paid off many times over. I have found that my workflow has evolved with that appreciation. One of the key benefits of Git is that it allows you to separate check-pointing your work from publishing it, making it easy to make many small changes and back out of some/all of them trivially. It makes it trivial to separate out changes into different lines of development as well (bug fixes vs. feature A vs. feature B) without having to pull up an editor and copy changes across separate checkouts of a repository - it actually makes supporting the small-patches philosophy of LLVM reviews much simpler than with SVN, which turns doing these things into manual and error prone tedium. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110903/8215861e/attachment.html>
Bill Wendling <wendling at apple.com> writes:> SVN doesn't require you to spend a lot of time learning it and > adapting to its way of doing things.Actually, SVN forces you to work in a particular way. - It forces you to commit any changes to the public repository. It won't let you keep a private copy for yourself. - It forces you to check out a separate copy of the repository for each project/bug fix/etc. that you work on simultaneously. Syncing those copies must be done through the public server, meaning that you go through all sorts of convulsions to share code among them. - God help you if you send a patch to llvm-commits and it needs editing. SVN has no support for integrating review feedback. git, on the other hand, has no particulr model to enforce. It is a set of tools that can be used to construct a development model. It should be flexible enough to allow us to work with it however we want. -Dave