Currently we have these two documents for gentoo developers on how to work with the cvs base portage tree. Comparable documents for a git based tree need to be created. http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml this one only needs minimal changes. http://www.gentoo.org/doc/en/cvs-tutorial.xml A similar tutorial for git is a must.
> A similar tutorial for git is a must. I've never understood this. Every project that I've seen switch to git insists on writing a tutorial for git, when there are plenty of git tutorials available. Does our git tutorial need something unique to gentoo? Or would a simple link to an existing tutorial suffice?
I am considering becoming a developer once this migration has happened. I don't know CVS and don't really want to. I know plenty about git since I use it every day but I suspect there are certain procedures and rules about what you should and shouldn't do when it comes to using git with the Portage tree. git is a powerful tool, I think we ought to ensure it gets used in the right way.
(In reply to comment #1) > > A similar tutorial for git is a must. > > I've never understood this. Every project that I've seen switch to git insists > on writing a tutorial for git, when there are plenty of git tutorials > available. > > Does our git tutorial need something unique to gentoo? Or would a simple link > to an existing tutorial suffice? I see a point in having an introduction to Git as long as it illustrates a workflow with the portage tree. 'Learning to git' is something else and we should link to other existing pages such as the very easy to understand gitref.org >
CC'ing overlays, i'm going to write a small git how to in overlays docs
(In reply to comment #0) > ... > http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml > http://www.gentoo.org/doc/en/cvs-tutorial.xml We also have this: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=4
(In reply to comment #2) > I suspect there are certain procedures and rules about what > you should and shouldn't do when it comes to using git with the Portage > tree. git is a powerful tool, I think we ought to ensure it gets used in the > right way. I think this needs to be the emphasis in our guides. Many people know how to use git. However, the Gentoo implementation of git will involve lots of conventions like: 1. How does data get from git into rsync. Presumably the master branch is what gets mirrored there. Maybe not. It needs to be spelled out in any case. 2. Do we want people working directly on master, or do we want lots of branching going on? What is the preferred workflow? 3. How should tree-wise changes be implemented? These don't need 30 pages of step-by-step detail. It might just be a few sentences each. A 10 second git tutorial wouldn't hurt either. You have a new or modified ebuild, and you want to get it committed, so what do you do? No need to do a full intro to git course.
(In reply to comment #6) > 2. Do we want people working directly on master, or do we want lots of > branching going on? What is the preferred workflow? if people are expected to test branches of other people before they are merged into master, we'll need support from portage to do that if it is missing. > These don't need 30 pages of step-by-step detail. It might just be a few > sentences each. > > A 10 second git tutorial wouldn't hurt either. You have a new or modified > ebuild, and you want to get it committed, so what do you do? No need to do > a full intro to git course. agreed overall.
So, to summarize, we need a quick "how do I add something to the tree with git" in the vein of the add/move/remove section of [1]. That much I can bash out easily. However, who exactly would decide on the conventions that Rich suggested in comment 6? I'd like to talk to them and get that written down too so we can get this closed. [1] http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html
if bug 502062 comment 10 gets implemented, a note should be made about how to fetch those notes. (In reply to Richard Freeman from comment #6) > 1. How does data get from git into rsync. Presumably the master branch is > what gets mirrored there. Maybe not. It needs to be spelled out in any > case. > > 2. Do we want people working directly on master, or do we want lots of > branching going on? What is the preferred workflow? > > 3. How should tree-wise changes be implemented? I think these should be decided on -scm@, or possibly -dev@, not here.
Have no clue why this is assigned to overlays@. I think it's RESO/OBSO but let's let docs-team decide.
(In reply to Michał Górny from comment #10) > Have no clue why this is assigned to overlays@. I think it's RESO/OBSO but > let's let docs-team decide. nothing to do with us; not sure why you assigned it to us. the original request was project-specific material for the infra or devmanual teams; they would have written their own guides. we now have the wiki if they want to do something that's not already covered by existing docs. marked RESO OBSOLETE as requested.
