As previously agreed, we will be moving the main Xen trees to git. The existing .hg trees will continue to exist, but as hg mirrors of the git history. Committers will push to the git repo. The new git tree will be this one: http://xenbits.xen.org/gitweb/?p=xen.git git://xenbits.xen.org/xen.git For committers it will be accessible via xenbits.xen.org:/home/xen/git/xen.git It has a branch corresponding to each xen*.hg tree: master xen-unstable.hg stable-4.0 xen-4.0-testing.hg stable-4.1 xen-4.1-testing.hg stable-4.2 xen-4.2-testing.hg staging staging/xen-unstable.hg staging-4.0 staging/xen-4.0-testing.hg staging-4.1 staging/xen-4.1-testing.hg staging-4.2 staging/xen-4.2-testing.hg We have some background infrastructure work which needs to be complete before we make this switch, but we are currently expecting/hoping this to be ready next week. We tentatively intend to make the switch on Thursday the 13th of February, assuming none of the committers object. Committers please note that if you have commits (patch queues) in hg at this point, they will need to be transferred into git somehow to be committed and pushed. After the switch it will not be possible to accept changes from hg, because we won''t have bidirectional mirroring. If at the point we make the change there are changes in staging that have not propagated to the corresponding stable or master tree, this situation will be preserved. However, revision history will be broken (by the difference in revision ids), which will slightly weaken the autotester''s push gate. I therefore recommend that we avoid making this change if we have a big or scary backlog in any staging tree. People posting and approving patches, including maintainers, are not directly affected. The process will be as follows: 1. Autotester push gate shut down 2. Announcement and coordination with committers 3. hg trees made read-only (other than by forthcoming git->hg mirror) 4. hg->git mirroring process stopped 5. git tree made writeable by committers. 6. git->hg mirror outputs checked for sanity 7. git->hg mirror enabled, pointing at old hg trees 8. Autotester push gate told to use git and restarted If any committer needs help getting git to work please feel free to ask. git has many advantages but its user interface has received very mixed reviews. We appreciate that you might need handholding. So if you get confused, or into trouble, do consult. Ian.
On 13/02/2013 17:08, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:> As previously agreed, we will be moving the main Xen trees to git. > The existing .hg trees will continue to exist, but as hg mirrors of > the git history. Committers will push to the git repo. > > The new git tree will be this one: > http://xenbits.xen.org/gitweb/?p=xen.git > git://xenbits.xen.org/xen.git > For committers it will be accessible via > xenbits.xen.org:/home/xen/git/xen.git > > It has a branch corresponding to each xen*.hg tree: > master xen-unstable.hg > stable-4.0 xen-4.0-testing.hg > stable-4.1 xen-4.1-testing.hg > stable-4.2 xen-4.2-testing.hg > staging staging/xen-unstable.hg > staging-4.0 staging/xen-4.0-testing.hg > staging-4.1 staging/xen-4.1-testing.hg > staging-4.2 staging/xen-4.2-testing.hg > > We have some background infrastructure work which needs to be complete > before we make this switch, but we are currently expecting/hoping this > to be ready next week. We tentatively intend to make the switch on > Thursday the 13th of February, assuming none of the committers object.Do you mean 14th Feb (tomorrow)? -- Keir> Committers please note that if you have commits (patch queues) in hg > at this point, they will need to be transferred into git somehow to be > committed and pushed. After the switch it will not be possible to > accept changes from hg, because we won''t have bidirectional mirroring. > > If at the point we make the change there are changes in staging that > have not propagated to the corresponding stable or master tree, this > situation will be preserved. However, revision history will be broken > (by the difference in revision ids), which will slightly weaken the > autotester''s push gate. I therefore recommend that we avoid making > this change if we have a big or scary backlog in any staging tree. > > People posting and approving patches, including maintainers, are not > directly affected. > > The process will be as follows: > 1. Autotester push gate shut down > 2. Announcement and coordination with committers > 3. hg trees made read-only (other than by forthcoming git->hg mirror) > 4. hg->git mirroring process stopped > 5. git tree made writeable by committers. > 6. git->hg mirror outputs checked for sanity > 7. git->hg mirror enabled, pointing at old hg trees > 8. Autotester push gate told to use git and restarted > > If any committer needs help getting git to work please feel free to > ask. git has many advantages but its user interface has received very > mixed reviews. We appreciate that you might need handholding. So if > you get confused, or into trouble, do consult. > > Ian.
Keir Fraser writes ("Re: Moving xen*.hg to
git"):> On 13/02/2013 17:08, "Ian Jackson"
<Ian.Jackson@eu.citrix.com> wrote:
> > We have some background infrastructure work which needs to be complete
> > before we make this switch, but we are currently expecting/hoping this
> > to be ready next week. We tentatively intend to make the switch on
> > Thursday the 13th of February, assuming none of the committers object.
>
> Do you mean 14th Feb (tomorrow)?
No, I meant the 21st, next week. I have no idea where "13th" came
from.
Ian.
Keir Fraser writes ("Re: Moving xen*.hg to
git"):> On 13/02/2013 17:08, "Ian Jackson"
<Ian.Jackson@eu.citrix.com> wrote:
> > It has a branch corresponding to each xen*.hg tree:
> > master xen-unstable.hg
> > stable-4.0 xen-4.0-testing.hg
> > stable-4.1 xen-4.1-testing.hg
> > stable-4.2 xen-4.2-testing.hg
>
> Is it possible to make these branches unpushable by committers?
I think so, with a pre-receive hook as described in git-receive-pack.
(This wouldn''t prevent someone deliberately bypassing the check, but
it would stop accidents.)
Ian.
Everything looks good and we intend to go ahead with the switch to git, tomorrow. We got a recent test push so the difference between master and staging isn''t too big. I''d appreciate it if committers would avoid throwing big or scary patches in until we get a post-switch push. I have just shut down the push gate for the xen-* trees. Thanks, Ian. Recap: As previously agreed, we will be moving the main Xen trees to git. The existing .hg trees will continue to exist, but as hg mirrors of the git history. Committers will push to the git repo. The new git tree will be this one: http://xenbits.xen.org/gitweb/?p=xen.git git://xenbits.xen.org/xen.git For committers it will be accessible via xenbits.xen.org:/home/xen/git/xen.git It has a branch corresponding to each xen*.hg tree: master xen-unstable.hg stable-4.0 xen-4.0-testing.hg stable-4.1 xen-4.1-testing.hg stable-4.2 xen-4.2-testing.hg staging staging/xen-unstable.hg staging-4.0 staging/xen-4.0-testing.hg staging-4.1 staging/xen-4.1-testing.hg staging-4.2 staging/xen-4.2-testing.hg Committers please note that if you have commits (patch queues) in hg at this point, they will need to be transferred into git somehow to be committed and pushed. After the switch it will not be possible to accept changes from hg, because we won''t have bidirectional mirroring. If at the point we make the change there are changes in staging that have not propagated to the corresponding stable or master tree, this situation will be preserved. However, revision history will be broken (by the difference in revision ids), which will slightly weaken the autotester''s push gate. I therefore recommend that we avoid making this change if we have a big or scary backlog in any staging tree. People posting and approving patches, including maintainers, are not directly affected. The process will be as follows: 1. Autotester push gate shut down 2. Announcement and coordination with committers 3. hg trees made read-only (other than by forthcoming git->hg mirror) 4. hg->git mirroring process stopped 5. git tree made writeable by committers. 6. git->hg mirror outputs checked for sanity 7. git->hg mirror enabled, pointing at old hg trees 8. Autotester push gate told to use git and restarted If any committer needs help getting git to work please feel free to ask. git has many advantages but its user interface has received very mixed reviews. We appreciate that you might need handholding. So if you get confused, or into trouble, do consult.
Ian Jackson writes ("Moving xen*.hg to git"):> 3. hg trees made read-only (other than by forthcoming git->hg mirror)
> 4. hg->git mirroring process stopped
This is now done. Please don''t try any longer to push to the hg
trees.
We''ll let you know again when the git trees are open for business.
Ian.
Ian Jackson writes ("Moving xen*.hg to git"):> The process will be as follows:
> 1. Autotester push gate shut down
> 2. Announcement and coordination with committers
> 3. hg trees made read-only (other than by forthcoming git->hg mirror)
> 4. hg->git mirroring process stopped
> 5. git tree made writeable by committers.
These have all been done. Committers may now push to the staging
branches.
You should
git clone xenbits.xen.org:/home/xen/git/xen.git xen.git
and then
git checkout staging
There is a safety catch which will reject attempts to push to
non-staging branches (and also reject bare ref tags).
> 6. git->hg mirror outputs checked for sanity
> 7. git->hg mirror enabled, pointing at old hg trees
> 8. Autotester push gate told to use git and restarted
We are working on these.
Ian.
On Thu, 2013-02-21 at 11:46 +0000, Ian Jackson wrote:> Ian Jackson writes ("Moving xen*.hg to git"): > > The process will be as follows: > > 1. Autotester push gate shut down > > 2. Announcement and coordination with committers > > 3. hg trees made read-only (other than by forthcoming git->hg mirror) > > 4. hg->git mirroring process stopped > > 5. git tree made writeable by committers. > > These have all been done. Committers may now push to the staging > branches. > > You should > git clone xenbits.xen.org:/home/xen/git/xen.git xen.git > and then > git checkout staging > > There is a safety catch which will reject attempts to push to > non-staging branches (and also reject bare ref tags). > > > 6. git->hg mirror outputs checked for sanity > > 7. git->hg mirror enabled, pointing at old hg trees > > 8. Autotester push gate told to use git and restarted > > We are working on these.Is the commit mailer bot thing on your list? Ian.
On Wed, 2013-02-13 at 17:08 +0000, Ian Jackson wrote:> As previously agreed, we will be moving the main Xen trees to git.Are we going to continue with the "Committed-by:" tag? git already tracks this bit of metadata separately from the author so it seems a bit redundant. It might be useful for folks using the mirror but in reality I expect it will mostly be the committers who need to look this up, and they will be using git... Ian.
>>> On 21.02.13 at 12:53, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Wed, 2013-02-13 at 17:08 +0000, Ian Jackson wrote: >> As previously agreed, we will be moving the main Xen trees to git. > > Are we going to continue with the "Committed-by:" tag? git already > tracks this bit of metadata separately from the author so it seems a bit > redundant. It might be useful for folks using the mirror but in reality > I expect it will mostly be the committers who need to look this up, and > they will be using git...+1 for no longer adding this tag. Jan
Ian Campbell writes ("Re: [Xen-devel] Moving xen*.hg to git [and 1 more
messages]"):> On Thu, 2013-02-21 at 11:46 +0000, Ian Jackson wrote:
> > We are working on these.
>
> Is the commit mailer bot thing on your list?
Yes, but it''s not critical in that it will keep working by virtue of
the mirror.
Ian.
Ian Campbell writes ("Re: [Xen-devel] Moving xen*.hg to
git"):> On Wed, 2013-02-13 at 17:08 +0000, Ian Jackson wrote:
> > As previously agreed, we will be moving the main Xen trees to git.
>
> Are we going to continue with the "Committed-by:" tag? git
already
> tracks this bit of metadata separately from the author so it seems a bit
> redundant. It might be useful for folks using the mirror but in reality
> I expect it will mostly be the committers who need to look this up, and
> they will be using git...
I wasn''t going to.
Ian.
>>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > If any committer needs help getting git to work please feel free to > ask. git has many advantages but its user interface has received very > mixed reviews. We appreciate that you might need handholding. So if > you get confused, or into trouble, do consult.So one thing I found very handy with hg was that there was a single line history with easy to look at changeset numbers. Is there any way to achieve the same with git? I''m asking particularly in the context of backporting: In order to pick changes from unstable (now master), so far I simply scanned the history, tracking (on a sheet of paper) at which c/s I last left off. Thanks, Jan
On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote:> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > If any committer needs help getting git to work please feel free to > > ask. git has many advantages but its user interface has received very > > mixed reviews. We appreciate that you might need handholding. So if > > you get confused, or into trouble, do consult. > > So one thing I found very handy with hg was that there was a > single line history with easy to look at changeset numbers. Is there > any way to achieve the same with git? I''m asking particularly in the > context of backporting: In order to pick changes from unstable (now > master), so far I simply scanned the history, tracking (on a sheet of > paper) at which c/s I last left off.Something like git log --oneline? You can also git log --pretty=format:%... Where there are various available %foo described in the manpage. git doesn''t really have a concept of the shorter sequential numbers which mercurial has. The closest I can think of is the sort of thing which git describe outputs. Ian.
I''ve no idea how, and you forgot to cc the list. I''ve added it back. On Thu, 2013-02-21 at 15:39 +0000, Wei Huang wrote:> Could you make http download available for xen.git (and others)? I can find > it through http://xenbits.xen.org/git-http, which is annoying. > > Thanks, > -Wei > > -----Original Message----- > From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell > Sent: Thursday, February 21, 2013 9:19 AM > To: Jan Beulich > Cc: Anthony Perard; Tim (Xen.org); Keir (Xen.org); Ian Jackson; > xen-devel@lists.xen.org > Subject: Re: [Xen-devel] Moving xen*.hg to git > > On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote: > > >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > > If any committer needs help getting git to work please feel free to > > > ask. git has many advantages but its user interface has received > > > very mixed reviews. We appreciate that you might need handholding. > > > So if you get confused, or into trouble, do consult. > > > > So one thing I found very handy with hg was that there was a single > > line history with easy to look at changeset numbers. Is there any way > > to achieve the same with git? I''m asking particularly in the context > > of backporting: In order to pick changes from unstable (now master), > > so far I simply scanned the history, tracking (on a sheet of > > paper) at which c/s I last left off. > > Something like git log --oneline? > > You can also git log --pretty=format:%... > > Where there are various available %foo described in the manpage. > > git doesn''t really have a concept of the shorter sequential numbers which > mercurial has. The closest I can think of is the sort of thing which git > describe outputs. > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >
>>> On 21.02.13 at 16:18, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote: >> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: >> > If any committer needs help getting git to work please feel free to >> > ask. git has many advantages but its user interface has received very >> > mixed reviews. We appreciate that you might need handholding. So if >> > you get confused, or into trouble, do consult. >> >> So one thing I found very handy with hg was that there was a >> single line history with easy to look at changeset numbers. Is there >> any way to achieve the same with git? I''m asking particularly in the >> context of backporting: In order to pick changes from unstable (now >> master), so far I simply scanned the history, tracking (on a sheet of >> paper) at which c/s I last left off. > > Something like git log --oneline? > > You can also git log --pretty=format:%...The question is whether these, just like the web interface, sort by commit time rather than commit order. And ideally it would be doable both locally and from the web interface, yet I don''t see the web interface having any way to control how it sorts its output.> Where there are various available %foo described in the manpage. > > git doesn''t really have a concept of the shorter sequential numbers > which mercurial has. The closest I can think of is the sort of thing > which git describe outputs.Again, it depends how the number produced here gets calculated, i.e. whether it remains stable over the lifetime of a tree regardless of what commits get pulled (and merges get done). Jan
On Thu, 2013-02-21 at 15:51 +0000, Jan Beulich wrote:> >>> On 21.02.13 at 16:18, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Thu, 2013-02-21 at 14:55 +0000, Jan Beulich wrote: > >> >>> On 20.02.13 at 16:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > >> > If any committer needs help getting git to work please feel free to > >> > ask. git has many advantages but its user interface has received very > >> > mixed reviews. We appreciate that you might need handholding. So if > >> > you get confused, or into trouble, do consult. > >> > >> So one thing I found very handy with hg was that there was a > >> single line history with easy to look at changeset numbers. Is there > >> any way to achieve the same with git? I''m asking particularly in the > >> context of backporting: In order to pick changes from unstable (now > >> master), so far I simply scanned the history, tracking (on a sheet of > >> paper) at which c/s I last left off. > > > > Something like git log --oneline? > > > > You can also git log --pretty=format:%... > > The question is whether these, just like the web interface, sort > by commit time rather than commit order.git rev-list mentions --topo-order and --date-order, and git log just forwards these on. I think --date-order is what you want? Not sure about the webterface.> And ideally it would be doable both locally and from the web > interface, yet I don''t see the web interface having any way to > control how it sorts its output. > > > Where there are various available %foo described in the manpage. > > > > git doesn''t really have a concept of the shorter sequential numbers > > which mercurial has. The closest I can think of is the sort of thing > > which git describe outputs. > > Again, it depends how the number produced here gets calculated, > i.e. whether it remains stable over the lifetime of a tree regardless > of what commits get pulled (and merges get done).That isn''t true of the Mercurial ones either. At least not in general, perhaps our not-very-branching structure makes it mostly true in practice.
Jan Beulich writes ("Re: Moving xen*.hg to
git"):> So one thing I found very handy with hg was that there was a
> single line history with easy to look at changeset numbers. Is there
> any way to achieve the same with git? I''m asking particularly in
the
> context of backporting: In order to pick changes from unstable (now
> master), so far I simply scanned the history, tracking (on a sheet of
> paper) at which c/s I last left off.
Of course you can do this
git-log <last>..master
or whatever to show all the commits which are included in master but
not in <last>.
Replace <last> with the hex commit id from your piece of paper, and
when you''re done write down the commit id of master. You can also get
git to remember where you got up to by making a local tag with
git-tag.
Ian.
Ian Jackson writes ("Moving xen*.hg to git"):> The process will be as follows:
> 1. Autotester push gate shut down
> 2. Announcement and coordination with committers
> 3. hg trees made read-only (other than by forthcoming git->hg mirror)
> 4. hg->git mirroring process stopped
> 5. git tree made writeable by committers.
> 6. git->hg mirror outputs checked for sanity
> 7. git->hg mirror enabled, pointing at old hg trees
> 8. Autotester push gate told to use git and restarted
The autotester has been a bit confused, trying to produce logs between
hg and git commit ids, etc. I think it''s sorted now but we''ll
see...
Ian.
On Wed, Feb 13, 2013 at 6:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> The new git tree will be this one: > http://xenbits.xen.org/gitweb/?p=xen.git > git://xenbits.xen.org/xen.gitIs there a http access to clone the tree? (mostly to be able to checkout the code behind a http proxy) Thanks, -- William
William Dauchy writes ("Re: [Xen-devel] Moving xen*.hg to
git"):> On Wed, Feb 13, 2013 at 6:08 PM, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote:
> > The new git tree will be this one:
> > http://xenbits.xen.org/gitweb/?p=xen.git
> > git://xenbits.xen.org/xen.git
>
> Is there a http access to clone the tree? (mostly to be able to
> checkout the code behind a http proxy)
I''m afraid there isn''t at present.
Ian.
On Fri, 2013-03-01 at 11:49 +0000, Ian Jackson wrote:> William Dauchy writes ("Re: [Xen-devel] Moving xen*.hg to git"): > > On Wed, Feb 13, 2013 at 6:08 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > > The new git tree will be this one: > > > http://xenbits.xen.org/gitweb/?p=xen.git > > > git://xenbits.xen.org/xen.git > > > > Is there a http access to clone the tree? (mostly to be able to > > checkout the code behind a http proxy) > > I''m afraid there isn''t at present.git://xenbits.xen.org/staging/qemu-xen-unstable.git becomes http://xenbits.xen.org/git-http/staging/qemu-xen-unstable.git But git://xenbits.xen.org/xen.git => http://xenbits.xen.org/git-http/xen.git fails with: fatal: http://xenbits.xen.org/git-http/xen.git/info/refs not found: did you run git update-server-info on the server? I added the symlink on xenbits and it seems to work now. Following the pattern I saw in qemu-xen-unstable.git I also added a post-update hook to call update-server-info (by renaming the post-update.sample which does exactly this). I also changed /etc/gitweb.conf: -@git_base_url_list = qw(git://xenbits.xen.org); +@git_base_url_list = qw(git://xenbits.xen.org http://xenbits.xen.org/git-http); which makes the http URLs appear on the webterface. Lastly I added a few words to http://wiki.xen.org/wiki?title=Xen_Repositories Ian.
Hi Ian, On Sat, Mar 2, 2013 at 4:18 AM, Ian Campbell <ian.campbell@citrix.com> wrote:> I added the symlink on xenbits and it seems to work now. Following the > pattern I saw in qemu-xen-unstable.git I also added a post-update hook > to call update-server-info (by renaming the post-update.sample which > does exactly this).There is still an issue for http://xenbits.xen.org/git-http/xen.git since the last commit I can get is: commit c23ea051ccee613e668b2a87817d49a28215ac8b Author: Ian Campbell <Ian.Campbell@citrix.com> Date: Tue Feb 5 15:47:41 2013 +0000 xen: enable stubdom on a per arch basis Maybe run a git-update-server-info and make sure post-update is executed for the next push. Thanks for your work, -- William
On Sat, 2013-03-02 at 16:13 +0000, William Dauchy wrote:> Maybe run a git-update-server-info and make sure post-update is > executed for the next push.Done. I tested cloning and got the latest stuff. Hopefully that is it now! Ian.