git for strace

Roland McGrath roland at redhat.com
Wed Jun 3 01:10:28 UTC 2009


How would folks feel about switching from CVS to GIT?
(All the other kids are doing it.)

While we consider this, please nobody do any CVS commits or git pushes.
If Dmitry and Denys are happy with git, then I'll declare the deed done.

I've enabled the git repository on sourceforge, so now both cvs and git are
enabled.  I've done the initial migration from the CVS history and pushed it.
See the sourceforge page for git access instructions (which are obvious).
	git://strace.git.sourceforge.net/gitroot/strace
	ssh://yourname@strace.git.sourceforge.net/gitroot/strace

Note there is no 'master' branch in git yet, til we decide about this.
(Read on below.)

I put some old branches imported from cvs under obsolete/* names.
I don't think we'll ever care about these, but it preserves the
branch history for posterity.

I used the option to convert "v1_2_3" tags to "v1.2.3" so we have those for
all the past releases (at least the ones since I've been maintainer,
earlier tags I can't vouch for).  There were a couple of other ancient cvs
tags that didn't seem useful, to I didn't save them as git tags.

Note all the release tags are unannotated so "git describe" doesn't see them.
You can use "git describe --tags".  Perhaps later I'll replace some or all
with annotated or signed tags.

I tested that the cvs checkouts and git checkouts from corresponding
release tags match up.  I didn't really stare much harder than that at the
converted CVS history to verify the importer got things right.

There are now these three branches:

* from-cvs
  This has the raw conversion from CVS, full history.

* rebase
  This is a rejiggered history that diverges from from-cvs a bit after 4.5.18.
  It excludes all the commits that I wish Denys had never made.
  I did this with 'git rebase', so they are gone from the history,
  not just from the tip.

* revert
  This tree matches 'rebase' exactly but is done as a single reversion
  commit on 'from-cvs'.  So, it excises everything I excluded but it
  preserves the true history of what got into CVS and then came out.

In making 'rebase', I dropped commits doing changes I didn't approve,
and then fixed up by hand the conflicts from reapplying later changes.
In a few cases, I dropped a commit that I didn't necessarily want excluded
but where it was nontrivial to resolve the conflicts.

I would prefer to have 'rebase' become the git master, pretend that the
alternative history in CVS never happened, and go on from there.  But if
others would strongly prefer to have 'revert' be the master so we preserve
all the exact CVS history since 4.5.18, I can accept that.

Denys, please eyeball the tree (and perhaps each individual commit listed
by "git log -p $(git merge-base from-cvs rebase)..rebase") to make sure
that I didn't flub anything in excising those changes.  I did a build and
smoke test on x86-64, but no other testing of the 'rebase' tree.

Denys, you can use git to find the dropped commits if you like.
What I'd do is:

	git checkout -b vda/hacks from-cvs
	git rebase rebase

That will get a few wrong ones that you want to "git rebase --skip" because
they are nonexact after I did some fixups.  But you might want to inspect
each such case and make sure I did not omit anything in my fixup.  You'll
have others to do manual fixup on in between.  (Or you might want to use
"git rebase -i" and use "squash" on some.)

Then your local vda/hacks branch will have a series of patches that you can
consider anew to propose for review.


Thanks,
Roland




More information about the Strace-devel mailing list