tl;dr: This post proposes a new way of importing a new package in the Fedora dist-git tree which allows to also import the whole back-and-forth changes made during the review request.

The recommended way to import a new package in Fedora is to do the following:

1. build an SRPM and submit that along with the spec file as a review request
2. wait for comments from a reviewer
3. fix the spec/srpm as per the reviewers comments
4. repeat steps 2 and 3 until the package gets approved
5. ask for the dist-git module to be created

6. clone the dist-git moodule once obtained:

   $ fedpkg clone $module
   

7. import the approved srpm in the dist-git module:

   $ fedpkg import $module-x.x.x.src.rpm$ git commit -m "Initial import (#nnnnnn)."
   

8. push, build, submit an update,...

However, all the comment/fix process as part of the review is only available in one place: Bugzilla. The package effectively starts its life in Fedora at the moment the srpm is imported.

Wouldn't it be nice to also keep all the history from the review process as part of the Git history of the module? Fortunately that's possible thanks to Git. :-)

First, create your module git tree:

$ mkdir $module
$ cd $module
$ git init

Here comes the trick. Once you will be working with the Fedora Git, there will be a master branch (for Rawhide). To avoid any future pain, let's rename the current branch as tmpmaster:

$ sed -i 's/master/tmpmaster/' .git/HEAD

Now is time for the second trick: to ease the rest of the process, the first commit must include the same changes as the first commit in the Fedora repository:

$ touch sources .gitignore
$ git add sources .gitignore
$ git commit -m "Initial setup of the local repo"

You can now start working on your new package as you would normally do:

• write your spec file
• add some patches
• make the required changes as part of the review process
• commit your changes all the way

Note that you must not commit the sourcearchive, since it will be added to the lookaside cache later on.

Hopefully, at some point, the package will be approved and the Fedora Git module created. Instead of starting at step 6 above, let's do something a bit smarter.

First, make the Fedora remote tree available to your local tree:

$ git remote add origin ssh://$fas_account@pkgs.fedoraproject.org/$module
$ git fetch origin

Then apply your work to the Fedora master branch:

$ git checkout tmpmaster
$ git branch master -t origin/master
$ git rebase master

Finally, switch to the master branch and fast-forward it to the state of the tmpmaster branch:

$ git checkout master
$ git merge tmpmaster

Check that everything is fine with your favorite Git visualization tool, and when you're ready, just remove the tmpmaster branch:

$ git branch -D tmpmaster

At this point, everything will look like you had been working inside the Fedora Git tree since the beginning, as if it had been creating before the review. You get to keep in one place the history of your package, including the history of its life before entering Fedora. :)

Finally just upload your sources with fedpkg, build your package on Koji, and more generally just go on working on your package as you would normally do after a fedpkg clone (that was step 7 above).

What would really be awesome is if fedpkg could grow the capability to add new remotes and do this trick by itself. Hmmm, I wonder...