[blfs-dev] [lfs-dev] LFS and Git
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.
> 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
>> 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
>> 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
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
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
More information about the blfs-dev