Re: [libvirt] Switch from CVS to GIT is done

2009-07-07 Thread Atsushi SAKAI
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 veill...@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/
 dan...@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


--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-07 Thread Daniel Veillard
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/
dan...@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


[libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Daniel Veillard

  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/
dan...@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


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Mark McLoughlin
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.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Jim Meyering
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=a...@sigxcpu.org ;;
  aliguori) n=Anthony Liguori e=aligu...@us.ibm.com ;;
  clalance) n=Chris Lalancette e=clala...@redhat.com ;;
  crobinso) n=Cole Robinson e=crobi...@redhat.com ;;
  danms) n=Dan Smith e=da...@us.ibm.com ;;
  dlesko) n=David L. Leskovec e=dle...@linux.vnet.ibm.com ;;
  meyering) n=Jim Meyering e=meyer...@redhat.com ;;
  sakaia) n=Atsushi SAKAI e=sak...@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

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Daniel P. Berrange
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:
 
   http://live.gnome.org/Git/ChangeLog

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 :|

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Jim Meyering
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:

   http://live.gnome.org/Git/ChangeLog

+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.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Daniel Veillard
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:
 
http://live.gnome.org/Git/ChangeLog
 
 +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/
dan...@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


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Jim Meyering
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 

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Mark McLoughlin
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.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Jim Meyering
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

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Mark McLoughlin
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:
 
   http://meyering.net/code/tmp/coreutils-ChangeLog

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.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Jim Meyering
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:

   http://meyering.net/code/tmp/coreutils-ChangeLog

 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.

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Daniel P. Berrange
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 :|

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] Switch from CVS to GIT is done

2009-07-06 Thread Garry Dolley
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

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list