[lfs-dev] LFS and Git

Bruce Dubbs bruce.dubbs at gmail.com
Sun Mar 9 19:16:42 PDT 2014

William Harrington wrote:
> 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.

Well there is a difference between LFS and BLFS.  Although there are 
several devs authorized to commit to LFS, in the last cycle only Matt 
and I did so.  BLFS had seven committers in the same cycle.  Generally 
the only collisions I see are in the changelog or possibly general.ent 
and then not very often.

When I analyze my activities with svn, I find I only use 10 commands:
checkout (rarely), update, add, mv, delete, copy, commit, status, 
propset (rarely), and diff.  Creating a branch is only a copy inside my 
local sandbox and a commit.  Note that only three of those require 
network communication.

Occasional diffs from Trac are about the only thing I do from the server 
other than commits and updates.

I did read the document you reference.

"Now stop for a moment and try to remember how many times you’ve gone to 
get a cup of coffee while Subversion has been running some command."

My answer: never.

Backups may be an issue, but I think Gerard does that daily.  Generally 
on a RAID system you have to have more than one drive to go bad to lose 
everything and since higgs is now on Linode, bringing up a new system is 
pretty fast.

Merging is generally not needed by me, but that may be the reason Armin 
wants to move to git.  I can't remember the last time I needed to do a 

   -- Bruce

More information about the lfs-dev mailing list