Re: [lfs-dev] [blfs-dev] LFS and Git]
- Forwarded message from Ken Moffat zarniwh...@ntlworld.com - #?^€^ ! I managed to send the reply to blfs instead of lfs. On Sun, Mar 09, 2014 at 09:16:42PM -0500, Bruce Dubbs wrote: 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 merge. My back story : I used to contribute to CLFS, but I dropped out when it went to git beccause at that stage i only knew enough to break things. Since then, I've moved my own buildscripts to git. I've broken things a couple of times in my own merges, but now I feel fairly confident in using it. For me, git merge --no-ff -m some message lets me put a message in my git log (probably not relevant ot LFS/BLFS), and when merges fail (e.g. because I put a fix in my master branch, then later put a better fix in my development branch), git status ; git diff file-with-problemshows what needs to be fixed. The great benefit of git is in branches - in svn, a branch is cast in stone and is a PITA. In git, branches are just pointers. If you want to maintain a stable branch, you can cherry-pick specific commits from another branch (such as master). To do that on LFS or BLFS, I suspect that things might work better if date changes in general.ent were separated from other changes - I think CLFS has usually done that. There have been at least two occasions in the past when I've thought about branching BLFS, but in svn it didn't seem worth the pain. As has been said, with git you can stash changes, work on fixing something else, and then go back to them. That is often a great benefit. The big benefit of svn is increasing decimal revision numbers. Mercurial seems to provide that (as well as hashed commit numbers), but I cannot see any reason to move to mercurial. When CLFS changed to git, it appeared that a gatekeeper was needed to pull changes, but freedesktop.org, or at least the xorg parts, appear to have many people commiting to the master branches. I understand why alfs is a good place to try out changes, but it isn't something I can use (/sources on my development machines is an nfs mount from my server, I _really_ don't fancy the time it would take to build there). Also, I think Igor has an svn-git feed to github ? I would welcome his comments. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page - End forwarded message - -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] LFS and Git]
Ken Moffat wrote: - Forwarded message from Ken Moffat zarniwh...@ntlworld.com - #?^€^ ! I managed to send the reply to blfs instead of lfs. On Sun, Mar 09, 2014 at 09:16:42PM -0500, Bruce Dubbs wrote: 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 merge. My back story : I used to contribute to CLFS, but I dropped out when it went to git beccause at that stage i only knew enough to break things. Since then, I've moved my own buildscripts to git. I've broken things a couple of times in my own merges, but now I feel fairly confident in using it. For me, git merge --no-ff -m some message lets me put a message in my git log (probably not relevant ot LFS/BLFS), and when merges fail (e.g. because I put a fix in my master branch, then later put a better fix in my development branch), git status ; git diff file-with-problemshows what needs to be fixed. The great benefit of git is in branches - in svn, a branch is cast in stone and is a PITA. In git, branches are just pointers. If you want to maintain a stable branch, you can cherry-pick specific commits from another branch (such as master). To do that on LFS or BLFS, I suspect that things might work better if date changes in general.ent were separated from other changes - I think CLFS has usually done that. There have been at least two occasions in the past when I've thought about branching BLFS, but in svn it didn't seem worth the pain. cd ~/BLFS/trunk/BOOK cd ../../branches svn cp ../trunk/BOOK my-new-branch #edit as required svn commit -m Added new branch.. Well maybe you can do that in git in one line, but how often is that needed? The only time I need that is to do a release. As has been said, with git you can stash changes, work on fixing something else, and then go back to them. That is often a great benefit. The big benefit of svn is increasing decimal revision numbers. Mercurial seems to provide that (as well as hashed commit numbers), but I cannot see any reason to move to mercurial. When CLFS changed to git, it appeared that a gatekeeper was needed to pull changes, but freedesktop.org, or at least the xorg parts, appear to have many people commiting to the master branches. I understand why alfs is a good place to try out changes, but it isn't something I can use (/sources on my development machines is an nfs mount from my server, I _really_ don't fancy the time it would take to build there). Also, I think Igor has an svn-git feed to github ? I would welcome his comments. Me too. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] LFS and Git]
On Mar 9, 2014, at 10:46 PM, Ken Moffat wrote: The big benefit of svn is increasing decimal revision numbers. I saw a while back this for a pre-commit hook. What you could end up with is a pre-commit hook which would include in the comment a revision number, with an algo not involving looking up the all history of a branch to determine the correct number. I read that Bazaar does that. I do agree with you about this benefit. Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] LFS and Git]
On Sun, Mar 09, 2014 at 11:06:42PM -0500, Bruce Dubbs wrote: Ken Moffat wrote: The great benefit of git is in branches - in svn, a branch is cast in stone and is a PITA. In git, branches are just pointers. If you want to maintain a stable branch, you can cherry-pick specific commits from another branch (such as master). To do that on LFS or BLFS, I suspect that things might work better if date changes in general.ent were separated from other changes - I think CLFS has usually done that. There have been at least two occasions in the past when I've thought about branching BLFS, but in svn it didn't seem worth the pain. cd ~/BLFS/trunk/BOOK cd ../../branches svn cp ../trunk/BOOK my-new-branch #edit as required svn commit -m Added new branch.. Well maybe you can do that in git in one line, but how often is that needed? The only time I need that is to do a release. My impression, from looking at the Red Book when I first thought about this, is that maintaining branches in svn is _hard_. Perhaps I'm wrong, but with svn I've seen nothing to suggest that branching is trivial. With git, multiple branches are definitely trivial. The result, from my POV, is that in svn people avoid branches unless they _have_ to use them, whereas in git they are no big deal. You have used an svn branch for a relase, but I'm not willing to set up an svn branch _unless_ I'm intending to use it to make a release. Perhaps svn branches are easier than the Red Book implies - if so, they ought to fix their docs :-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] LFS and Git]
Ken Moffat wrote: On Sun, Mar 09, 2014 at 11:06:42PM -0500, Bruce Dubbs wrote: Ken Moffat wrote: The great benefit of git is in branches - in svn, a branch is cast in stone and is a PITA. In git, branches are just pointers. If you want to maintain a stable branch, you can cherry-pick specific commits from another branch (such as master). To do that on LFS or BLFS, I suspect that things might work better if date changes in general.ent were separated from other changes - I think CLFS has usually done that. There have been at least two occasions in the past when I've thought about branching BLFS, but in svn it didn't seem worth the pain. cd ~/BLFS/trunk/BOOK cd ../../branches svn cp ../trunk/BOOK my-new-branch #edit as required svn commit -m Added new branch.. Well maybe you can do that in git in one line, but how often is that needed? The only time I need that is to do a release. My impression, from looking at the Red Book when I first thought about this, is that maintaining branches in svn is _hard_. Perhaps I'm wrong, but with svn I've seen nothing to suggest that branching is trivial. With git, multiple branches are definitely trivial. The result, from my POV, is that in svn people avoid branches unless they _have_ to use them, whereas in git they are no big deal. You have used an svn branch for a relase, but I'm not willing to set up an svn branch _unless_ I'm intending to use it to make a release. Perhaps svn branches are easier than the Red Book implies - if so, they ought to fix their docs :-) I agree. They want you to make the branch directly in the remote repository and you need to remember the syntax for that. Ugly. Later I developed the above technique for creating a branch. It's not as elegant as git branches, but it's not as ugly as the SVN book. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
