On Mar 9, 2014, at 6:19 PM, Bruce Dubbs wrote: > I've been working trying to understand Git a little better and > trying to > evaluate whether it is appropriate for LFS to migrate. >
Here is an article which presents why a person should move to GIT. http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git And as you looking for an answer, it may help you understand why git would be better suited for a project than subversion in some instances. > The biggest issue with git from my perspective is the learning curve. > It's a completely different paradigm. It seems to me that it takes > more > commands to do things than with svn, but the main advantages are > that it > brings us up to what so many other open source projects are using and > that it makes merging easier for coordinating the systemd version of > lfs > with the main version. This would be especially important if we > want to > create a systemd version of BLFS. It depends what you are doing between GIT and subversion for the commands to be more complex or not. Overall, we definitely like using GIT for CLFS than Subversion, although subversion is still good in some instances, such as our patch repo. With the amount of development that occurs with LFS, it's rather busy every day. You will find that after a week or so and when all of the developers understand how to use git and aren't afraid of messing up a repo, using git from day to day will be second nature. Granted, I've used it for over 4 years and I'm still learning how to do things. Recently I setup my own git server and installed cgit and learned to mirror repos. Most commonly I'll pull, and make some changes, and if I don't like them, I'll reset head back to the last pull, or if I need to work on something else, I'll stash my changes and then pull, work on something, then push. Then I can resetore my stash and continue work. Or, I'll make a git diff of what I'm doing, restore the diff later depending if it is needed. Then once changes are all well, run a test render and make sure the book validates, then I push the changes. It is good to have quality control. Make sure how changes will be committed and how the commit messages will be formatted. Do you change one file and commit and put exactly what was changed, or change a bunch of files and one commit and make a huge message about what was changed or a summary, etc?. A standard way of commits is very helpful. I don't think CLFS set this up, and I think LFS would benefit greatly from it. I mostly had to go off what the early development with git commits were. Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
