[lfs-dev] LFS and Git

William Harrington kb0iic at berzerkula.org
Sun Mar 9 18:27:21 PDT 2014

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.


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.


William Harrington

More information about the lfs-dev mailing list