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