Le 10/03/2014 00:19, Bruce Dubbs a écrit :
> I've been working trying to understand Git a little better and trying to
> evaluate whether it is appropriate for LFS to migrate.
>
> What I've done is to copy the alfs repository to anduin and work with
> that copy.
>
> Note to Pierre: nothing has been changed on the lfs server.
>
> I had to reorganize the repo for best results because the process of
> migrating is fairly complex and time consuming. I chose ALFS because
> the repo is much smaller than either the LFS or BLFS.
>
> I also created a new name for the server: git.linuxfromscratch.org.
>
> What I suggest is for -devs to get a copy of this modified repo and play
> with it. The command is:
>
> git clone git://git.linuxfromscratch.org/alfs.git
>
> After download, you can 'cd alfs' and look around.
>
> A comparison of svn and git commands is at
> http://git-scm.com/course/svn.html
>
> The one thing you can't do right now is a 'git push' to update the
> remote repo. Otherwise most commands should work.
>
> If you want to be able to push changes back to the server, send me your
> ssh public key and I can set that up for you.
>
> If we do end up deciding (and that is far from a done deal) to use git,
> there will be a lot of work because a lot of scripts depend on svn. The
> editor's guide will need to be updated and the web pages too.
>
> 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.
>
Hi,
Just a few more notes about my experience about subversion and git
(more limited for the latter):
- about branching and merging: I created a branch with subversion
for the BLFS part of jhalfs. After moving directories around, I couldnot
merge anymore from the trunk, because the different tree layout
confused the merge. I had to cherry pick revisions from trunk to
branch, and that was just doubling the work. When I merged
everything at the end, it took quite a while to get everything right.
Of course, git is much better in this respect.
- I think the workflow associated to git is roughly analogous to
subversion+quilt:
svn co <--> git clone
svn up <--> git pull
quilt new <something> <--> git checkout -b <something>
(or nothing if working on the master branch)
quilt add <file> <--> git add <file>
(do it before editingfor quilt, after for git).
quilt pop <--> git checkout master
(or git stash save(master branch)
quilt push <--> git checkout <something>
(or git stash apply (master branch))
svn ci <--> git checkout master
+ git merge + git commit + git push
(or just git commit + git push (master branch))
&c
- about command duration in subversion: just try the gcc repo.
You'll drink a lot of coffee
- Learning curve: I like http://ndpsoftware.com/git-cheatsheet.html.
There are a lot of tutorials. Here is a translation of part of a tuto
in French (http://www.miximum.fr/enfin-comprendre-git.html), which
summarizes the reason for the steep learning curve:
"Q: How do I erase a modification to a file?
A: git checkout
Q: OK. How do I change branch?
A: git checkout
Q: OK. And how do I create a branch?
A: git checkout
Q: Hmm. OK. And how do I get rid of my branch?
A: git branch -d my_branch
Q: OK. And how do I get rid of a distant branch?
A: git push origin :my_branch
Errr...
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
