[libvirt] Switch from CVS to GIT is done
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary Unfortunately Jim had to clean up the conversion from CVS that was used previously at git://git.et.redhat.com/libvirt.git so the two are not compatible and the best is to clone a new tree using git clone git://libvirt.org/libvirt.git and then copying over your set of patches with "git format-patch" in the old dir and "git am" to paste them into the new cloned-dir (Jim can certainly provide more details if needed). Let us know if you see something weird in the new tree or on the web site, I have updated the download informations at http://libvirt.org/downloads.html A few things may change but I guess the switch is done at this point, Many thanks to Jim for maintaining the old tree and the migration ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, 2009-07-06 at 14:42 +0200, Daniel Veillard wrote:
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
Cool stuff! Any thoughts on what to do about ChangeLog? As an example of a sensible plan, GNOME dropped ChangeLog but some modules still generate a ChangeLog for tarball releases. See here: http://live.gnome.org/Git/ChangeLog Also, HACKING should gain some tips for commit messages e.g. http://live.gnome.org/Git/CommitMessages Personally, I've grown to hate ChangeLog entries and love git commit messages :-) Cheers, Mark.
On Mon, Jul 06, 2009 at 02:13:46PM +0100, Mark McLoughlin wrote:
On Mon, 2009-07-06 at 14:42 +0200, Daniel Veillard wrote:
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
Cool stuff!
Any thoughts on what to do about ChangeLog?
As an example of a sensible plan, GNOME dropped ChangeLog but some modules still generate a ChangeLog for tarball releases. See here:
We can't really drop the existing ChangeLog file since it contains much much more data than the historical commit messages. We need to really auto-generate only new changelog entries, Preferably only generating 'ChangeLog' when doing a 'make dist'. Could probably just do a rename of existing file to ChangeLog.old, and then just generate a new ChangeLog file from the switch over date. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Mark McLoughlin wrote:
On Mon, 2009-07-06 at 14:42 +0200, Daniel Veillard wrote:
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
Cool stuff!
Any thoughts on what to do about ChangeLog?
As an example of a sensible plan, GNOME dropped ChangeLog but some modules still generate a ChangeLog for tarball releases. See here:
+1 I stopped maintaining-in-VC the ChangeLog file for GNU coreutils, too. However, a usable ChangeLog file still appears in each release tarball. It's generated at "make dist" time from commit logs via this rule from Makefile.am: gen_start_date = 2008-02-08 .PHONY: gen-ChangeLog gen-ChangeLog: if test -d .git; then \ $(top_srcdir)/build-aux/gitlog-to-changelog \ --since=$(gen_start_date) > $(distdir)/cl-t; \ rm -f $(distdir)/ChangeLog; \ mv $(distdir)/cl-t $(distdir)/ChangeLog; \ fi If you want to continue using a version-controlled ChangeLog file, you'll definitely want to start using this tool from gnulib (just build it and install it in your path, following instructions in the C file): http://git.sv.gnu.org/cgit/gnulib.git/plain/lib/git-merge-changelog.c It helps you avoid almost all ChangeLog-related conflicts. The alternative (no vc'd ChangeLog file) is to generate it from commit logs. That's what I do in coreutils, even though conflicts are no longer much of an issue, because I don't like having to keep ChangeLog and commit-log in sync with duplicate info.
On Mon, Jul 06, 2009 at 03:41:34PM +0200, Jim Meyering wrote:
Mark McLoughlin wrote:
On Mon, 2009-07-06 at 14:42 +0200, Daniel Veillard wrote:
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
Cool stuff!
Any thoughts on what to do about ChangeLog?
As an example of a sensible plan, GNOME dropped ChangeLog but some modules still generate a ChangeLog for tarball releases. See here:
+1
I stopped maintaining-in-VC the ChangeLog file for GNU coreutils, too. However, a usable ChangeLog file still appears in each release tarball. It's generated at "make dist" time from commit logs via this rule from Makefile.am:
gen_start_date = 2008-02-08 .PHONY: gen-ChangeLog gen-ChangeLog: if test -d .git; then \ $(top_srcdir)/build-aux/gitlog-to-changelog \ --since=$(gen_start_date) > $(distdir)/cl-t; \ rm -f $(distdir)/ChangeLog; \ mv $(distdir)/cl-t $(distdir)/ChangeLog; \ fi
If you want to continue using a version-controlled ChangeLog file, you'll definitely want to start using this tool from gnulib (just build it and install it in your path, following instructions in the C file): http://git.sv.gnu.org/cgit/gnulib.git/plain/lib/git-merge-changelog.c It helps you avoid almost all ChangeLog-related conflicts.
The alternative (no vc'd ChangeLog file) is to generate it from commit logs. That's what I do in coreutils, even though conflicts are no longer much of an issue, because I don't like having to keep ChangeLog and commit-log in sync with duplicate info.
yeah, I think moving ChangeLog to ChangeLog.CVS and generating the logs starting from today at "make dist" time is probably the best, it will avoid copying over redundant informations. On the other hand we should try to keep the git log output coherent with the previous format. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Daniel Veillard wrote:
The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
On a related note, I've installed a so-called git "update" hook that prevents one from pushing a merge commit. That same hook also prohibits pushing any commit that adds trailing blanks. I.e., if you accidentally commit (locally) such a change, when you try to push, it'll point at the offending lines and refuse to push. Then you'll have to use commit --amend -a to fix it (if it's the topmost commit) or "git rebase -i ...".
On Mon, 2009-07-06 at 16:19 +0200, Daniel Veillard wrote:
yeah, I think moving ChangeLog to ChangeLog.CVS and generating the logs starting from today at "make dist" time is probably the best, it will avoid copying over redundant informations.
Cool.
On the other hand we should try to keep the git log output coherent with the previous format.
FWIW, I think it's best to switch to a new format that better suits git. e.g. "git log --pretty=oneline" can be very useful, but only where people properly summarise the commit on the first line. If we used the typical ChangeLog format, it would be useless. Also, we don't need the date and author information twice. II think git commit messages generally more genuinely useful information than a ChangeLog entry - it seems to encourage people to more fully explain what they're doing. If we switch formats, 'git log --stat' is fine for Changelog - you get author, date, files changed etc. Cheers, Mark.
Mark McLoughlin wrote:
On Mon, 2009-07-06 at 16:19 +0200, Daniel Veillard wrote:
yeah, I think moving ChangeLog to ChangeLog.CVS and generating the logs starting from today at "make dist" time is probably the best, it will avoid copying over redundant informations.
Cool.
On the other hand we should try to keep the git log output coherent with the previous format.
FWIW, I think it's best to switch to a new format that better suits git.
e.g. "git log --pretty=oneline" can be very useful, but only where people properly summarise the commit on the first line. If we used the typical ChangeLog format, it would be useless. Also, we don't need the date and author information twice.
II think git commit messages generally more genuinely useful information than a ChangeLog entry - it seems to encourage people to more fully explain what they're doing.
If we switch formats, 'git log --stat' is fine for Changelog - you get author, date, files changed etc.
Hi Mark, What do you think of coreutils' logs? It's generated and still ChangeLog-conforming, yet with an added one-line summary and sometimes (for larger changes) more prose: http://meyering.net/code/tmp/coreutils-ChangeLog
On Mon, 2009-07-06 at 17:22 +0200, Jim Meyering wrote:
Mark McLoughlin wrote:
On Mon, 2009-07-06 at 16:19 +0200, Daniel Veillard wrote:
yeah, I think moving ChangeLog to ChangeLog.CVS and generating the logs starting from today at "make dist" time is probably the best, it will avoid copying over redundant informations.
Cool.
On the other hand we should try to keep the git log output coherent with the previous format.
FWIW, I think it's best to switch to a new format that better suits git.
e.g. "git log --pretty=oneline" can be very useful, but only where people properly summarise the commit on the first line. If we used the typical ChangeLog format, it would be useless. Also, we don't need the date and author information twice.
II think git commit messages generally more genuinely useful information than a ChangeLog entry - it seems to encourage people to more fully explain what they're doing.
If we switch formats, 'git log --stat' is fine for Changelog - you get author, date, files changed etc.
Hi Mark,
What do you think of coreutils' logs? It's generated and still ChangeLog-conforming, yet with an added one-line summary and sometimes (for larger changes) more prose:
Looking at the git commits e.g. http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=24c727d3 it doesn't duplicate date/author and has a good first line summary, so it's pretty good. The one question I'd have is whether listing of per-file changes has any value. IMHO, it tends to restrict the explanation people give about about their commits. Looking at projects that don't do this, I think you tend to get much more background on why the change is being made, not just what changed. Cheers, Mark.
Mark McLoughlin wrote:
What do you think of coreutils' logs? It's generated and still ChangeLog-conforming, yet with an added one-line summary and sometimes (for larger changes) more prose:
Looking at the git commits e.g.
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=24c727d3
it doesn't duplicate date/author and has a good first line summary, so it's pretty good.
The one question I'd have is whether listing of per-file changes has any value. IMHO, it tends to restrict the explanation people give about about their commits. Looking at projects that don't do this, I think you tend to get much more background on why the change is being made, not just what changed.
IMHO it's more about habit than which format you use. I find the ChangeLog discipline is worthwhile, because it forces me to go back through the patch and write something for each changed file. Besides, if you use a tool like vc-chlog to write the template for you (http://www.gnu.org/software/vc-dwim/) it removes the pain of enumerating affected files and function names. Also, the companion, vc-dwim, has saved me regularly by telling me when a file I'm about to commit has unsaved changes -- it detects editor temporary files. It's caught emacs buffers with changes that weren't saved at least 2 or 3 times in the last week or so. coreutils is in a mode for which one-liners are often enough, but I do admit that the log messages are sometimes too light on prose.
Daniel Veillard wrote:
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
To create that new repository, I rewrote the git repository from et.redhat.com to correct a few minor problems. In case anyone is interested, here are the details. --------------------------------------- Some commits had incomplete names. Run this to see all 64 commits: $ git log --pretty=format:%h:%an|grep -v ' ' Here's a summary: $ git log --pretty=format:%an|grep -v ' '|sort|uniq -c 1 aliguori 13 clalance 3 crobinso 8 danms 5 dlesko 23 meyering 11 sakaia ============================ Note that rewriting changes nearly all SHA1 values, so any reference to an SHA1 in a commit log should be updated to point to the new SHA1. There are a few: $ git log|grep -E '\b[0-9a-f]{7,40}\b'|grep -v '^commit' This regressed via commit 4c3f3b4d. [043d702f] "use virAsprintf instead of asprintf" introducted The 'getVer' fix introducted in d88d459d [Allow remote://hostname/ Bug introduced in 895d0fdf5bef358fafb91c672609190b3088097b. ==================================================== Run the following long(!) command to rewrite the "master" branch, preserving tags (but not signed ones), fixing bogus author names and preserving SHA1 references like the above: git filter-branch -d $TMPDIR/.git-rewrite \ --tag-name-filter cat \ --env-filter ' case $GIT_AUTHOR_NAME in agx) n="Guido Günther" e="agx@sigxcpu.org" ;; aliguori) n="Anthony Liguori" e="aliguori@us.ibm.com" ;; clalance) n="Chris Lalancette" e="clalance@redhat.com" ;; crobinso) n="Cole Robinson" e="crobinso@redhat.com" ;; danms) n="Dan Smith" e="danms@us.ibm.com" ;; dlesko) n="David L. Leskovec" e="dlesko@linux.vnet.ibm.com" ;; meyering) n="Jim Meyering" e="meyering@redhat.com" ;; sakaia) n="Atsushi SAKAI" e="sakaia@jp.fujitsu.com" ;; *) n=$GIT_AUTHOR_NAME e=$GIT_AUTHOR_EMAIL ;; esac export GIT_AUTHOR_EMAIL=$e GIT_AUTHOR_NAME=$n export GIT_COMMITTER_EMAIL=$e GIT_COMMITTER_NAME=$n ' --msg-filter ' cat > t.msg ref=$(perl -ne "/\b([0-9a-f]{7,40})\b/ and print \$1" t.msg) test -n "$ref" && sha=$(git rev-parse $ref) && { len=$(printf $ref|wc -c) new_sha=$(map $sha) short_sha=$(printf %.${len}s $new_sha) perl -pi -e "s/$ref/$short_sha/" t.msg } cat t.msg ' master I tested it on this tiny repository: git init -q; : > j; git add j; git ci -q --author='meyering <meyering>' -m. -a c=$(git log --pretty=%h) echo a > j; git ci -q -m "fix bug in $c" -a ==================================================== The above preserves regular tags, but not the signed ones. Reapply the signed vM.N.O tags: for i in $(git tag -l 'LIBVIRT_*'); do v=$(echo $i|sed 's/LIBVIRT_/v/;s/_/./g') echo $v git tag -f -s -m$v $v $i done ==================================================== With the above changes, we've bloated the repository by ~50%, increasing its size from 22M to 34M. Remove the cruft: git for-each-ref --format="%(refname)" refs/original/ \ | xargs -n 1 git update-ref -d git reflog expire --expire=now --all git gc --prune=now And that brings it back down to 23M. Run this function git-repo-compress() { local d=$1 du -sh "$d"; start=$(date); /usr/bin/time \ git --git-dir=$d repack -afd --window=250 --depth=250 echo started $start; date; du -sh "$d" } to compress a few remaining bits. Final size: 21M. Push to libvirt.org: git push libvirt.org:/git/libvirt.git master:master git push --tags libvirt.org:/git/libvirt.git ==================================================== After I'd pushed all of the above, Dan Berrange noticed that the new signed tags were out of order and had all been created today. Back-date the signed tags so that each has the same date as its unsigned counterpart: for i in $(git tag -l 'LIBVIRT_*'); do v=$(echo $i|sed 's/LIBVIRT_/v/;s/_/./g') date=$(git log --pretty=%ci -1 $i) echo $v GIT_COMMITTER_DATE="$date" git tag -f -s -m$v $v $i done # And push (now we need the -f option): git push -f --tags libvirt.org:/git/libvirt.git
On Mon, Jul 06, 2009 at 02:42:59PM +0200, Daniel Veillard wrote:
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
FYI, since the main repository is now using GIT, there is little benefit in having the other related repositories under Mercurial. So I have converted the 3 that I own over to use GIT too http://libvirt.org/git/?p=libvirt-glib.git;a=summary http://libvirt.org/git/?p=libvirt-perl.git;a=summary http://libvirt.org/git/?p=libvirt-tck.git;a=summary Also note that since the CVS repository is no longer updated, the automatic CVS -> Mercurial mirror is also now inactive. Anyone who was relying on the HG mirror of libvirt CVS should switch to GIT. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
On Mon, Jul 06, 2009 at 02:42:59PM +0200, Daniel Veillard wrote: ...
The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
FYI, since the main repository is now using GIT, there is little benefit in having the other related repositories under Mercurial. So I have converted the 3 that I own over to use GIT too
http://libvirt.org/git/?p=libvirt-glib.git;a=summary http://libvirt.org/git/?p=libvirt-perl.git;a=summary http://libvirt.org/git/?p=libvirt-tck.git;a=summary
Also note that since the CVS repository is no longer updated, the automatic CVS -> Mercurial mirror is also now inactive. Anyone who was relying on the HG mirror of libvirt CVS should switch to GIT.
On a similar note, the libvirt.git repository on et.redhat.com is no longer being updated. I expect to move it aside (rename to libvirt-old.git, and eventually to remove it) and to make libvirt.git a mirror of the official repository.
On Tue, Jul 07, 2009 at 09:29:17AM +0200, Jim Meyering wrote:
Daniel P. Berrange wrote:
On Mon, Jul 06, 2009 at 02:42:59PM +0200, Daniel Veillard wrote: ...
The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
FYI, since the main repository is now using GIT, there is little benefit in having the other related repositories under Mercurial. So I have converted the 3 that I own over to use GIT too
http://libvirt.org/git/?p=libvirt-glib.git;a=summary http://libvirt.org/git/?p=libvirt-perl.git;a=summary http://libvirt.org/git/?p=libvirt-tck.git;a=summary
Also note that since the CVS repository is no longer updated, the automatic CVS -> Mercurial mirror is also now inactive. Anyone who was relying on the HG mirror of libvirt CVS should switch to GIT.
On a similar note, the libvirt.git repository on et.redhat.com is no longer being updated.
I expect to move it aside (rename to libvirt-old.git, and eventually to remove it) and to make libvirt.git a mirror of the official repository.
Okay, I was wondering how to fix the download page, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Jul 06, 2009 at 02:42:59PM +0200, Daniel Veillard wrote:
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
Unfortunately Jim had to clean up the conversion from CVS that was used previously at git://git.et.redhat.com/libvirt.git so the two are not compatible and the best is to clone a new tree using
git clone git://libvirt.org/libvirt.git
and then copying over your set of patches with "git format-patch" in the old dir and "git am" to paste them into the new cloned-dir (Jim can certainly provide more details if needed).
Let us know if you see something weird in the new tree or on the web site, I have updated the download informations at http://libvirt.org/downloads.html
A few things may change but I guess the switch is done at this point,
Many thanks to Jim for maintaining the old tree and the migration !
Now that we're using git, we can make a distinction between Author and Committer, automatically. When people create patches with 'git format-patch' and send them to this list for inclusion, the patch will include them as the Author. When Daniel, et. al. then applies the patch (with 'git am' or similar method), they will be the Committer. This is nice because 'git log', 'git shortlog', etc... will give the appropriate credit to the author, and the committer doesn't need to keep writing in the commit msg who the patch came from. Just an FYI to those new to git. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st
Hi, Daniel I am happy to hear this, since I am primaly tracking libvirt via git.
From seeing http://libvirt.org/git/, only 4 packages are controlled under git. (libvirt, libvirt-glib, libvirt-perl, libvirt-tck) Will other libvirt related tools goes to the directory in future?
Thanks Atsushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
Thanks to Jim Meyering we now have a new git repository, I deprecated the CVS repository, it's read only, you should still be able to keep it around to make patches for a few weeks if needed. The new repo is at: http://libvirt.org/git/?p=libvirt.git;a=summary
Unfortunately Jim had to clean up the conversion from CVS that was used previously at git://git.et.redhat.com/libvirt.git so the two are not compatible and the best is to clone a new tree using
git clone git://libvirt.org/libvirt.git
and then copying over your set of patches with "git format-patch" in the old dir and "git am" to paste them into the new cloned-dir (Jim can certainly provide more details if needed).
Let us know if you see something weird in the new tree or on the web site, I have updated the download informations at http://libvirt.org/downloads.html
A few things may change but I guess the switch is done at this point,
Many thanks to Jim for maintaining the old tree and the migration !
Daniel
-- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jul 07, 2009 at 10:08:12PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
I am happy to hear this, since I am primaly tracking libvirt via git.
From seeing http://libvirt.org/git/, only 4 packages are controlled under git. (libvirt, libvirt-glib, libvirt-perl, libvirt-tck) Will other libvirt related tools goes to the directory in future?
Hum, I need to switch libvirt-java , for other projects that depends on their maintainers :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (6)
-
Atsushi SAKAI -
Daniel P. Berrange -
Daniel Veillard -
Garry Dolley -
Jim Meyering -
Mark McLoughlin