coapp-developers team mailing list archive

[Vincent Povirk <madewokherd@xxxxxxxxx>]

I think we should make it a policy to never convert other projects'
revision control to git, if they're not already git, because the extra
software it requires packagers to learn, install, and use does not
convey any extra benefits. (And I REALLY don't want to have to install
bzr or hg or perforce on my machine to update a package, EVER.)

git-svn (which is something completely different from git-svn-mirror)
might get a pass because it's not an extra thing to install and I
already mostly know how to use it, but dammit it's still an extra
thing to learn and it still doesn't help us.

The way I see it, we need source control to help us do the following things:
 * Publish the code we're using and the changes we've made.
 * Separate the changes we've made from the pristine, upstream version.
 * Trace each one of our changes to an individual author, and
preferably learn something about why each change was made.
 * Update our version of the code with new code from upstream, while
still keeping our changes intact.
 * Maintain multiple stable branches for projects that have multiple
stable revisions that we need to care about. Most importantly, our set
of changes will be very similar for each branch, but not identical,
and our source control should help us keep it straight.
 * Backport important fixes that have not yet made it to an upstream
release, or that are not present on an older stable branch that we
still care about.

In order to do everything consistently and with the same tools, we're
using git for everything. This requires us to get code from projects
not using git into git somehow. There are two possible approaches to
doing this. One is to import the project's entire history, in whatever
original form it takes, using some automated tool. I've already
explained why I don't like this approach. I think we should instead
import snapshots of the project into git manually as needed (in most
cases, I would advocate for doing this every release, but every
project is different and some may not have releases or may not have
them often enough).

That approach looks like this:
 * Create a new Git repository with a branch named 'upstream' (or
something like upstream-2.6 if we need to track multiple upstream
branches).
 * Download a tarball of a release of this project, dump the files in
the repository (without the project-version prefix they usually add),
and commit them.
 * Create a master branch based on the upstream branch, and do the
packaging work.
 * Create a repository in the coapp-packages organization containing
both the master and the upstream branch. You can have mirrors in your
own github account if that is how you like to use github. I won't
judge.

To update:
 * Checkout the upstream branch (if you prefer to keep a separate
repository for every branch, you're doing it wrong, but git will let
you), remove all the files, add the new files, and commit.
 * Checkout the master branch.
 * Merge the new upstream branch into the master branch.
 * Test to make sure you didn't completely break things.
 * Push it to coapp-packages or make a pull request or whatever it is
you kids with your githubs are doing these days.

As for the idea of keeping one's private repository separate as a
"testing" stage, this is entirely separate from the question of
importing changes from a foreign RCS. I think that if there's a need
for this, it should be done with separate branches in the same
repository. That is what branches are for. Private repositories are
for changes you have made that are not yet approved to go in the
official repository.