The following paragraphs are provisional content during the (doc) migration from dist-cvs to dist-git is happening.

+

{{autolang|base=yes}}

+

{{admon/important | Git config needs| A config problem has been discovered which may make <code>fedpkg push</code> or <code>fedpkg commit -p</code> or even <code>git push</code> not understand your intentions. As a short term work around, you can run: <code>git config --global push.default tracking</code>. This option tells git that when it gets a push request with no other arguments, see if it's tracking a remote branch. If it is, push to that remote branch. This seems like it will usually be safe no matter what git repository you are using.}}

−

{{admon/important | Git config needs| A config problem has been discovered which may make <code>fedpkg push</code> or <code>fedpkg commit -p</code> or even <code>git push</code> not understand your intentions. As a short term work around, you can run: <code>git config --global --add push.default tracking</code>. This option tells git that when it gets a push request with no other arguments, see if it's tracking a remote branch. If it is, push to that remote branch. This seems like it will usually be safe no matter what git repository you are using.}}

+

== Cookbooks ==

−

== Commands ==

+

Refer to [[Package_update_HOWTO |How to update a package]] if you want to update an existing package.

−

{{admon/note | Make sure you have updated to fedora-packager version 0.5.1 atleast before running any of these commands }}

|make build || fedpkg build || When successful on Koji, the build will trigger the package to be tagged with the corresponding tag (e.g., dist-f15 for Rawhide and dist-f14-updates-candidate for F14)

+

|make build || fedpkg build || When successful on Koji, the build will be tagged in koji with the corresponding koji tag (e.g., dist-f15 for Rawhide and dist-f14-updates-candidate for F14). No git tag will be created as of 2010-08-06. You can use <code>git tag $(fedpkg verrel) && git push --tags</code> to do this manually.

|-

|-

|BUILD_FLAGS="--nowait" make build || fedpkg build --nowait || See above. The --nowait option to the build command avoid your waiting (for the build to complete before freeing up the Shell)

|BUILD_FLAGS="--nowait" make build || fedpkg build --nowait || See above. The --nowait option to the build command avoid your waiting (for the build to complete before freeing up the Shell)

Line 40:

Line 43:

|-

|-

|make scratch-build || fedpkg scratch-build ||

|make scratch-build || fedpkg scratch-build ||

+

|-

+

|make srpm || fedpkg srpm ||

+

|-

+

|make srpm-scratch-build || fedpkg srpm<BR>fedpkg scratch-build --srpm <name of srpm> || Ideally this would be made a single "fedpkg srpm-scratch-build" command

If you need anonymous clone (checkout) without fedpkg, you can use git: <pre>git clone git://pkgs.fedoraproject.org/libfoo</pre> for package <code>libfoo</code>

=== Merging ===

=== Merging ===

+

Merging is one of the things that we can now do directly in the VCS that we had to do with an external diff program in CVS. Getting used to how it works may take a little adjustment though.

Merging is one of the things that we can now do directly in the VCS that we had to do with an external diff program in CVS. Getting used to how it works may take a little adjustment though.

+

+

==== Initial Merging ====

First, the way we imported from cvs means that we have to do a little work to make the older release branches "mergable" (F-14, since it branched after the conversion to git, doesn't need this).

First, the way we imported from cvs means that we have to do a little work to make the older release branches "mergable" (F-14, since it branched after the conversion to git, doesn't need this).

−

{{admon/note|Which branches should you this apply to?|For packages where F-12, F-13, the freshly branched F-14 and rawhide all have the same spec files and packages, merging all the branches together clearly makes sense. However, when, say F-12 and F-13 share a package NVR, and F-14 and rawhide do... what to do then? Merge the branches that are supposed to be the same, then.

+

{{admon/note|Which branches should you apply this to?|For packages where F-12, F-13, the freshly branched F-14 and rawhide all have the same spec files and packages, merging all the branches together clearly makes sense. However, when, say F-12 and F-13 share a package NVR, and F-14 and rawhide do... what to do then? Merge the branches that are supposed to be the same, then.

Now when you make changes on one branch and want to move them to a different branch, you can use git to merge those changes.

Now when you make changes on one branch and want to move them to a different branch, you can use git to merge those changes.

Line 96:

Line 112:

</pre>

</pre>

−

===== Resolving conflicts =====

+

==== Resolving merge conflicts ====

−

Resolving conflicts is only slightly different than in cvs. When you git merge and a conflict occurs you still edit the files that have conflicts. Remove the conflict markers in the files and merge the changes manually. Then you need to commit your changes. Do that with <code>git add CONFLICTEDFILES ; git commit</code>

+

+

When you git merge and a conflict occurs you still edit the files that have conflicts. Remove the conflict markers in the files and merge the changes manually. Then you need to commit your changes. Do that with <code>git add CONFLICTEDFILES ; git commit</code>

+

+

===== Using <code>git mergetool</code> to resolve conflicts =====

+

+

Git allows you to set a graphical diff program to help resolve conflicts. This can be handy for visualizing what changes have occurred and deal with them as a set.

+

<pre>

+

git config --global merge.tool meld

+

fedpkg switch-branch f13

+

git merge master

+

# Conflicts occurred

+

git mergetool # Opens up a meld showing a three way diff of the merge, working tree, and the last commit

+

# Resolved all the conflicts in the GUI

+

git add CONFLICTEDFILES

+

git commit

+

</pre>

== Branch names ==

== Branch names ==

Line 105:

Line 136:

| devel || origin/master || master || This is the default when you do fedpkg co

| devel || origin/master || master || This is the default when you do fedpkg co

|-

|-

−

| F-14 || origin/f14/master || f14 ||

+

| F-16|| origin/f16/master || f16 ||

|-

|-

−

| F-13 || origin/f13/master || f13 ||

+

| F-15 || origin/f15/master || f15 ||

|-

|-

−

| F-12 || origin/f12/master || f12 ||

+

| F-14 || origin/f14/master || f14 ||

|-

|-

| EL-6 || origin/el6/master || el6 ||

| EL-6 || origin/el6/master || el6 ||

Line 133:

Line 164:

Then you probably have some un-commited changes in master. If you want them, call:

Then you probably have some un-commited changes in master. If you want them, call:

<pre>

<pre>

−

# this "save" them

+

# this "saves" your changes

git stash

git stash

# switch to preferred branch, now possible

# switch to preferred branch, now possible

fedpkg switch-branch f13

fedpkg switch-branch f13

−

# apply "saved" changed in the current branch

+

# apply "saved" changes into the current branch

git stash apply

git stash apply

</pre>

</pre>

Line 143:

Line 174:

== ssh fingerprint ==

== ssh fingerprint ==

−

The recommend option is to include "<code>VerifyHostKeyDNS yes</code>" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct.

+

The recommended option is to include "<code>VerifyHostKeyDNS yes</code>" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct.

But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for pkgs.fedoraproject.org ended up in your ~/.ssh/known_hosts file.

But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for pkgs.fedoraproject.org ended up in your ~/.ssh/known_hosts file.

Revision as of 05:43, 26 February 2013

Git config needsA config problem has been discovered which may make fedpkg push or fedpkg commit -p or even git push not understand your intentions. As a short term work around, you can run: git config --global push.default tracking. This option tells git that when it gets a push request with no other arguments, see if it's tracking a remote branch. If it is, push to that remote branch. This seems like it will usually be safe no matter what git repository you are using.

Commands

Note that branches are not separated out by directory with this command. To switch to a different branch with this layout, run: fedpkg switch-branch f13

cvs checkout libfoo (ALTERNATE)

fedpkg clone -B libfoo

This command creates the same branch/directory layout that was used with cvs.

cvs update

fedpkg pull

Retrieve latest content from fedora git

cvs commit .

fedpkg commit -p

The -p option to commit invokes a push, just like with git, but you can separate these actions, as shown just below

cvs commit . (ALTERNATE)

fedpkg commit && fedpkg push

cvs commit -m 'breaking things' .

fedpkg commit -m 'breaking things' -p

cvs add foo bar

git add foo bar

make clog

fedpkg clog

Create the "clog" file from the %changelog of the specfile.

cvs commit -F clog .

fedpkg commit -F clog -p

Use the contents of file "clog" as the commit message.

make tag

N/A

Explicitly tagging source states for package builds is no longer necessary.

make build

fedpkg build

When successful on Koji, the build will be tagged in koji with the corresponding koji tag (e.g., dist-f15 for Rawhide and dist-f14-updates-candidate for F14). No git tag will be created as of 2010-08-06. You can use git tag $(fedpkg verrel) && git push --tags to do this manually.

BUILD_FLAGS="--nowait" make build

fedpkg build --nowait

See above. The --nowait option to the build command avoid your waiting (for the build to complete before freeing up the Shell)

make prep

fedpkg prep

make chain-build CHAIN='foo bar : baz'

fedpkg chain-build foo bar : baz

Just like before, the current directory package is always added to the end of the CHAIN list.

make scratch-build

fedpkg scratch-build

make srpm

fedpkg srpm

make srpm-scratch-build

fedpkg srpmfedpkg scratch-build --srpm <name of srpm>

Ideally this would be made a single "fedpkg srpm-scratch-build" command

Anonymous checkout

If you need anonymous clone (checkout) without fedpkg, you can use git:

git clone git://pkgs.fedoraproject.org/libfoo

for package libfoo

Merging

Merging is one of the things that we can now do directly in the VCS that we had to do with an external diff program in CVS. Getting used to how it works may take a little adjustment though.

Initial Merging

First, the way we imported from cvs means that we have to do a little work to make the older release branches "mergable" (F-14, since it branched after the conversion to git, doesn't need this).

Which branches should you apply this to?For packages where F-12, F-13, the freshly branched F-14 and rawhide all have the same spec files and packages, merging all the branches together clearly makes sense. However, when, say F-12 and F-13 share a package NVR, and F-14 and rawhide do... what to do then? Merge the branches that are supposed to be the same, then.

Resolving merge conflicts

When you git merge and a conflict occurs you still edit the files that have conflicts. Remove the conflict markers in the files and merge the changes manually. Then you need to commit your changes. Do that with git add CONFLICTEDFILES ; git commit

Using git mergetool to resolve conflicts

Git allows you to set a graphical diff program to help resolve conflicts. This can be handy for visualizing what changes have occurred and deal with them as a set.

git config --global merge.tool meld
fedpkg switch-branch f13
git merge master
# Conflicts occurred
git mergetool # Opens up a meld showing a three way diff of the merge, working tree, and the last commit
# Resolved all the conflicts in the GUI
git add CONFLICTEDFILES
git commit

Branch names

Old CVS

new remote git

fedpkg local branch names

Notes

devel

origin/master

master

This is the default when you do fedpkg co

F-16

origin/f16/master

f16

F-15

origin/f15/master

f15

F-14

origin/f14/master

f14

EL-6

origin/el6/master

el6

EL-5

origin/el5/master

el5

local branch namesIf you use git commands to branch and checkout directly, you can define whatever local branch names you want. If you use fedpkg switch-branch, it will default to creating the names listed in the table above. So you can do fedpkg clone firefox ; fedpkg switch-branch f14 and then you'll have a new local branch named f14

Display current branch in your shell promptIt is often helpful to know what branch you are working on at a glance. You can add this information to your bash prompt with the information here.

Errors

Access denied

During the next few days and weeks, occasional tweaking to the servers might cause short periods (seconds or minutes) when the git server refuses you access. Just try again.

Unable to switch

If you are trying switch to another branch by fedpkg switch-branch f13 and see this:
Unable to switch to another branch: Could not create branch f13

Then you probably have some un-commited changes in master. If you want them, call:

ssh fingerprint

The recommended option is to include "VerifyHostKeyDNS yes" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct.

But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for pkgs.fedoraproject.org ended up in your ~/.ssh/known_hosts file.