As we're now at a point where the project is about to submit "Informal Draft" content to DISA, it may be a good time to clean up our git branching/tagging model (err.. create one).
My thoughts: (1) For every project within SSG, create a unique branch. Currently this would set us up as:
MASTER |--- JBossEAP5 |--- RHEL6
(2) Each project is responsible for their own release tags. MASTER |--- JBossEAP5 |--- RHEL6 | |--- InformalDraft
Comments?
On 10/26/12 1:14 PM, Shawn Wells wrote:
As we're now at a point where the project is about to submit "Informal Draft" content to DISA, it may be a good time to clean up our git branching/tagging model (err.. create one).
My thoughts: (1) For every project within SSG, create a unique branch. Currently this would set us up as:
MASTER |--- JBossEAP5 |--- RHEL6
(2) Each project is responsible for their own release tags. MASTER |--- JBossEAP5 |--- RHEL6 | |--- InformalDraft
Comments?
Talked this over with Jeff on the phone, decided to proceed. We now have two unique branches in the code:
MASTER |--- JBoss EAP5 |--- RHEL6
We did this to support additional incoming content, such as for RHEL7 and JBossEAP6. This change also allows each project to create their own release tags, without effecting other content developers.
The recommended way to clone moving forward will be to checkout only the project you want to play with. For example: * **To checkout $branchName with commit access (if you have it):* git clone -b $branchName ssh://<your_fedora_username>@git.fedorahosted.org/git/scap-security-guide.git * **To checkout $branchName without commit access:* git clone -b $branchName http://git.fedorahosted.org/git/scap-security-guide.git
Options for $branchName: JBossEAP5 RHEL6
This happened before I pushed my last two commits, and I was wondering why git suddenly exploded. I'm seeing unmerged paths referring to the files that were sitting in the aforementioned commits.
Are the instructions below pertinent to this situation, or just for those joining on the project from this point forward? Apologies for the (likely) newbie-ish question.
On 10/26/2012 03:38 PM, Shawn Wells wrote:
On 10/26/12 1:14 PM, Shawn Wells wrote:
As we're now at a point where the project is about to submit "Informal Draft" content to DISA, it may be a good time to clean up our git branching/tagging model (err.. create one).
My thoughts: (1) For every project within SSG, create a unique branch. Currently this would set us up as:
MASTER |--- JBossEAP5 |--- RHEL6
(2) Each project is responsible for their own release tags. MASTER |--- JBossEAP5 |--- RHEL6 | |--- InformalDraft
Comments?
Talked this over with Jeff on the phone, decided to proceed. We now have two unique branches in the code:
MASTER |--- JBoss EAP5 |--- RHEL6
We did this to support additional incoming content, such as for RHEL7 and JBossEAP6. This change also allows each project to create their own release tags, without effecting other content developers.
The recommended way to clone moving forward will be to checkout only the project you want to play with. For example:
**To checkout $branchName with commit access (if you have it):* git clone -b $branchName ssh://<your_fedora_username>@git.fedorahosted.org/git/scap-security-guide.git
**To checkout $branchName without commit access:* git clone -b $branchName http://git.fedorahosted.org/git/scap-security-guide.git
Options for $branchName: JBossEAP5 RHEL6
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 10/26/12 3:46 PM, David Smith wrote:
This happened before I pushed my last two commits, and I was wondering why git suddenly exploded. I'm seeing unmerged paths referring to the files that were sitting in the aforementioned commits.
Are the instructions below pertinent to this situation, or just for those joining on the project from this point forward? Apologies for the (likely) newbie-ish question.
I figured there would be a few people caught in this situation. Kick your patches over to the list and I'll push them, at which point you can re-clone.
Sounds great -- it's just the two from midday today (macro modification + test tags).
On 10/26/2012 04:07 PM, Shawn Wells wrote:
On 10/26/12 3:46 PM, David Smith wrote:
This happened before I pushed my last two commits, and I was wondering why git suddenly exploded. I'm seeing unmerged paths referring to the files that were sitting in the aforementioned commits.
Are the instructions below pertinent to this situation, or just for those joining on the project from this point forward? Apologies for the (likely) newbie-ish question.
I figured there would be a few people caught in this situation. Kick your patches over to the list and I'll push them, at which point you can re-clone. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Given that our initial submission to DISA did not pass muster for a variety of reasons (such as SRG mappings), the tagging seems a bit premature.
Also, until there is sustained development in more than one project on scap-security-guide, the branching is solving a problem that does not exist. Should that occur, however, this is certainly the model we'll want to follow (and update all wiki instructions for participants accordingly).
On 10/26/2012 03:46 PM, David Smith wrote:
This happened before I pushed my last two commits, and I was wondering why git suddenly exploded. I'm seeing unmerged paths referring to the files that were sitting in the aforementioned commits.
Are the instructions below pertinent to this situation, or just for those joining on the project from this point forward? Apologies for the (likely) newbie-ish question.
On 10/26/2012 03:38 PM, Shawn Wells wrote:
On 10/26/12 1:14 PM, Shawn Wells wrote:
As we're now at a point where the project is about to submit "Informal Draft" content to DISA, it may be a good time to clean up our git branching/tagging model (err.. create one).
My thoughts: (1) For every project within SSG, create a unique branch. Currently this would set us up as:
MASTER |--- JBossEAP5 |--- RHEL6
(2) Each project is responsible for their own release tags. MASTER |--- JBossEAP5 |--- RHEL6 | |--- InformalDraft
Comments?
Talked this over with Jeff on the phone, decided to proceed. We now have two unique branches in the code:
MASTER |--- JBoss EAP5 |--- RHEL6
We did this to support additional incoming content, such as for RHEL7 and JBossEAP6. This change also allows each project to create their own release tags, without effecting other content developers.
The recommended way to clone moving forward will be to checkout only the project you want to play with. For example:
**To checkout $branchName with commit access (if you have it):* git clone -b $branchName ssh://<your_fedora_username>@git.fedorahosted.org/git/scap-security-guide.git
**To checkout $branchName without commit access:* git clone -b $branchName http://git.fedorahosted.org/git/scap-security-guide.git
Options for $branchName: JBossEAP5 RHEL6
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org mailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
David Smith -
Jeffrey Blank -
Shawn Wells