New Git repository is up.

New Git repository is up.

[Eric S. Raymond]

I repacked, push-mirrored it, then recloned.  It looks correct as far as
I can tell in the limited time I've had to inspect it.

If we later find conversion flaws, they should be fixable with much less
effort than the initial conversion.

Commits are open. Have at it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: New Git repository is up.

[Paul Eggert]

Thanks a lot for doing the conversion.

A problem I noticed: the last two commits in the trunk bzr (118359 and 118360) 
are not in the git master branch.  Similarly, the last commit in the emacs-24 
bzr (117703, a backport) is not in the git emacs-24 branch.  Perhaps one last 
pass to apply these last-second bzr changes to the git version?  Or should we 
ask the authors of those patches to reapply them?

Re: New Git repository is up.

[Eric S. Raymond]

Paul Eggert <eggert@cs.ucla.edu>:
> Thanks a lot for doing the conversion.
> 
> A problem I noticed: the last two commits in the trunk bzr (118359
> and 118360) are not in the git master branch.  Similarly, the last
> commit in the emacs-24 bzr (117703, a backport) is not in the git
> emacs-24 branch.  Perhaps one last pass to apply these last-second
> bzr changes to the git version?  Or should we ask the authors of
> those patches to reapply them?

That "last pass" would cost a minimum of temn hours of repo downtime.
I'm willing to do that if we find problems with the converted history
that have to be surgically corrected, but fotr this it would be less 
work to just grab the patches from bzr and apply them.

Sorry.  I suspect I dropped those two commits while I was trying to 
bring the transition-day patch up to date.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: New Git repository is up.

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

I noticed a few references to bzr revisions are still in the history. They
all refer to merges from the emacs-24 branch. I am not sure if it worth
fixing though.

git log --online, press '/' to search and search for 'emacs-24'.

Example: git rev 0121d32

On Wed, Nov 12, 2014 at 10:01 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> Paul Eggert <eggert@cs.ucla.edu>:
> > Thanks a lot for doing the conversion.
> >
> > A problem I noticed: the last two commits in the trunk bzr (118359
> > and 118360) are not in the git master branch.  Similarly, the last
> > commit in the emacs-24 bzr (117703, a backport) is not in the git
> > emacs-24 branch.  Perhaps one last pass to apply these last-second
> > bzr changes to the git version?  Or should we ask the authors of
> > those patches to reapply them?
>
> That "last pass" would cost a minimum of temn hours of repo downtime.
> I'm willing to do that if we find problems with the converted history
> that have to be surgically corrected, but fotr this it would be less
> work to just grab the patches from bzr and apply them.
>
> Sorry.  I suspect I dropped those two commits while I was trying to
> bring the transition-day patch up to date.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
>

[-- Attachment #2: Type: text/html, Size: 1921 bytes --]

Re: New Git repository is up.

[Katsumi Yamaoka]

On Thu, 13 Nov 2014 00:01:53 -0500, Eric S. Raymond wrote:
> Paul Eggert <eggert@cs.ucla.edu>:
>> Thanks a lot for doing the conversion.
>>
>> A problem I noticed: the last two commits in the trunk bzr (118359
>> and 118360) are not in the git master branch.  Similarly, the last
>> commit in the emacs-24 bzr (117703, a backport) is not in the git
>> emacs-24 branch.  Perhaps one last pass to apply these last-second
>> bzr changes to the git version?  Or should we ask the authors of
>> those patches to reapply them?

> That "last pass" would cost a minimum of temn hours of repo downtime.
> I'm willing to do that if we find problems with the converted history
> that have to be surgically corrected, but fotr this it would be less
> work to just grab the patches from bzr and apply them.

> Sorry.  I suspect I dropped those two commits while I was trying to
> bring the transition-day patch up to date.

No problem.  I've repushed those two changed to the git repos.
I also have performed diff with the old bzr and the new git repos
for the trunk and the emacs-24 branch, and confirmed there are
no significant difference in the source codes.

Thanks for your great work.
Regards,

Re: New Git repository is up.

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

Eric,

Thank you very much for the hard work and perseverance.

I cloned from the git repo (both anonymous and with savannah credentials,
repo size ~175 MB) and it built just fine.

Christoph

On Wed, Nov 12, 2014 at 8:12 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> I repacked, push-mirrored it, then recloned.  It looks correct as far as
> I can tell in the limited time I've had to inspect it.
>
> If we later find conversion flaws, they should be fixable with much less
> effort than the initial conversion.
>
> Commits are open. Have at it.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
>

[-- Attachment #2: Type: text/html, Size: 1177 bytes --]

Re: New Git repository is up.

[Jan D.]

Eric S. Raymond skrev den 2014-11-13 04:12:
> I repacked, push-mirrored it, then recloned.  It looks correct as far as
> I can tell in the limited time I've had to inspect it.
>
> If we later find conversion flaws, they should be fixable with much less
> effort than the initial conversion.
>
> Commits are open. Have at it.
>

Nice work, thanks!

	Jan D.

Re: New Git repository is up.

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

Awesome!

— 
Cheers,
Bozhidar

On November 13, 2014 at 05:13:31, Eric S. Raymond (esr@thyrsus.com) wrote:

I repacked, push-mirrored it, then recloned. It looks correct as far as  
I can tell in the limited time I've had to inspect it.  

If we later find conversion flaws, they should be fixable with much less  
effort than the initial conversion.  

Commits are open. Have at it.  
--  
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>  


[-- Attachment #2: Type: text/html, Size: 1354 bytes --]

Re: New Git repository is up.

[Dani Moncayo]

Hi Eric,

Thank you very much for doing this.

> I repacked, push-mirrored it, then recloned.  It looks correct as far as
> I can tell in the limited time I've had to inspect it.
>
> If we later find conversion flaws, they should be fixable with much less
> effort than the initial conversion.

I've taken a quick glance at the new repo and I still see some bzr
revnos in commit messages:

------------
Merge from emacs-24; up to 117669
Merge from emacs-24; up to 117687
Merge from emacs-24; up to 117689
Revert 118323.
Merge from emacs-24; up to 117691
Merge from emacs-24; up to 117698
Merge from emacs-24; up to 117702
---------------

HTH

-- 
Dani Moncayo

Re: New Git repository is up.

[Aurélien Aptel]

On Thu, Nov 13, 2014 at 9:57 AM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> I've taken a quick glance at the new repo and I still see some bzr
> revnos in commit messages:
>
> ------------
> Merge from emacs-24; up to 117669
> Merge from emacs-24; up to 117687
> Merge from emacs-24; up to 117689
> Revert 118323.
> Merge from emacs-24; up to 117691
> Merge from emacs-24; up to 117698
> Merge from emacs-24; up to 117702
> ---------------

Thanks for the find but it's probably too late. Eric set up a test
repo online before the migration specifically for this kind of things.

Re: New Git repository is up.

[Dani Moncayo]

> Thanks for the find but it's probably too late.

That is not what I understand from what Eric have said:

> If we later find conversion flaws, they should be fixable with much less
> effort than the initial conversion.

> Eric set up a test
> repo online before the migration specifically for this kind of things.

Those commits seem to be newer than the latest test repo.

-- 
Dani Moncayo

Fixing repository conversion errors.

[Eric S. Raymond]

Dani Moncayo <dmoncayo@gmail.com>:
> Merge from emacs-24; up to 117669
> Merge from emacs-24; up to 117687
> Merge from emacs-24; up to 117689
> Revert 118323.
> Merge from emacs-24; up to 117691
> Merge from emacs-24; up to 117698
> Merge from emacs-24; up to 117702

Well, crap.  I don't know how those got by me. It probably has
someting to do with them all being bare numbers rather than prefixed
with "r" or "rev.".  There were an awful lot of false matches for 
[0-9][0-9][0-9][0-9][0-9] that I has to wade through by hand. There
were anout 700 changes of this kind, all told.

The cost if fixing this is:

(a) when I do it, everyone will have to reclone afterwards.

(b) Probably about four hours of repo downtime. It won't be ten this time
because I don't have to do another full conversion, just edit a pulled copy, 
repack it, and upload it.

It won't be any worse if we wait a week than if I do it tomorrow.  I'm
inclined to wait for a bit and see if any other minor problems turn up.
Ideally we only want to have to do this once.

We need a procedure for this - I don't want us to lose another day and
a half.  Copying Bob Proulx.  Here's how I think it should go:

(1) We test a blocking repo hook that says "Closed for all pushes."

(2) We schedule a maintainance day.

(3) On that day, the blocking hook goes in place.  Repo is still
available read-only.

(3) I fix a downloaded copy, repack it, and upload it to Savannah 
as a tarball via ftp or scp.

(4) Bob unpacks it on the same filesystem as the live repo, them moves
the directory into place (an atomic operation).

Bob, are you willing to do this?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Fixing repository conversion errors.

[Dani Moncayo]

On Thu, Nov 13, 2014 at 12:43 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Dani Moncayo <dmoncayo@gmail.com>:
>> Merge from emacs-24; up to 117669
>> Merge from emacs-24; up to 117687
>> Merge from emacs-24; up to 117689
>> Revert 118323.
>> Merge from emacs-24; up to 117691
>> Merge from emacs-24; up to 117698
>> Merge from emacs-24; up to 117702

There seem to be more cases.  For example:

  Merge from emacs-24; up to 117656
  Merge from emacs-24; up to 117634

All match a simple regex pattern (except for "Revert 118323."), so
they seem to be easily identifiable.

-- 
Dani Moncayo

Re: Fixing repository conversion errors.

[Dani Moncayo]

>>> Merge from emacs-24; up to 117669
>>> Merge from emacs-24; up to 117687
>>> Merge from emacs-24; up to 117689
>>> Revert 118323.
>>> Merge from emacs-24; up to 117691
>>> Merge from emacs-24; up to 117698
>>> Merge from emacs-24; up to 117702
>
> There seem to be more cases.  For example:
>
>   Merge from emacs-24; up to 117656
>   Merge from emacs-24; up to 117634
>
> All match a simple regex pattern (except for "Revert 118323."), so
> they seem to be easily identifiable.

Also, one caveat (it is probably unnecessary but just in case):

The revnos in "Merge from emacs-24; up to NNNNNN" are relative to the
emacs-24 branch, not the trunk.

-- 
Dani Moncayo

Re: Fixing repository conversion errors.

[Eric S. Raymond]

Dani Moncayo <dmoncayo@gmail.com>:
> The revnos in "Merge from emacs-24; up to NNNNNN" are relative to the
> emacs-24 branch, not the trunk.

I believe the way I made the revision map avoids that problem, but I'll check.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Fixing repository conversion errors.

[Harald Hanche-Olsen]

["Eric S. Raymond" <esr@thyrsus.com> (2014-11-13 11:43:08 UTC)]

> (b) Probably about four hours of repo downtime. It won't be ten this time
> because I don't have to do another full conversion, just edit a pulled copy, 
> repack it, and upload it.

Is that really necessary? I would have thought you could create a new
branch with the fixed commit messages. It should sprout off the master
branch not too far in the past. Push the new branch to the server.
Then just rename branches on the server, so the new branch will be
master. Then all the developers will have to rewind the master branch
(and origin/master) in their own clones to the latest good commit, and
do a pull. No need for a full reclone, I think.

If the problem affects more branches than just master, this might not
be much of a simplification, however.

– Harald

Re: Fixing repository conversion errors.

[Óscar Fuentes]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Dani Moncayo <dmoncayo@gmail.com>:
>> Merge from emacs-24; up to 117669
>> Merge from emacs-24; up to 117687
>> Merge from emacs-24; up to 117689
>> Revert 118323.
>> Merge from emacs-24; up to 117691
>> Merge from emacs-24; up to 117698
>> Merge from emacs-24; up to 117702

[snip]

> The cost if fixing this is:

If those "Merge from..." are proper merges, it makes no sense to fix the
commit text. We know which commits are the parents of a merge without
mentioning them on the commit msg.

[snip]

Re: Fixing repository conversion errors.

[Lars Magne Ingebrigtsen]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> The cost if fixing this is:
>
> (a) when I do it, everyone will have to reclone afterwards.
>
> (b) Probably about four hours of repo downtime. It won't be ten this time
> because I don't have to do another full conversion, just edit a pulled copy, 
> repack it, and upload it.

My vote is to just leave it as is.  It's fine.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Fixing repository conversion errors.

[Bob Proulx]

Eric S. Raymond wrote:
> We need a procedure for this - I don't want us to lose another day and
> a half.  Copying Bob Proulx.  Here's how I think it should go:
> 
> (1) We test a blocking repo hook that says "Closed for all pushes."
> 
> (2) We schedule a maintainance day.
> 
> (3) On that day, the blocking hook goes in place.  Repo is still
> available read-only.
> 
> (3) I fix a downloaded copy, repack it, and upload it to Savannah 
> as a tarball via ftp or scp.
> 
> (4) Bob unpacks it on the same filesystem as the live repo, them moves
> the directory into place (an atomic operation).
> 
> Bob, are you willing to do this?

Sure.  Happy to help.

Note that directory moves can't be atomic.  But things can be switched
pretty quickly.  Considering everything I think that is good enough.

A tar file or other is fine.  But I can easily set up a uniquely named
repository that only you know about and then you can simply upload to
it and inspect the result afterward.  That would create a git
repository as you wish it to be.  You can craft it in place.  Then
that can be swapped into place when you are happy with it.  That would
be my preference.  But either way is fine.

Bob

Re: Fixing repository conversion errors.

[Eric S. Raymond]

Bob Proulx <bob@proulx.com>:
> A tar file or other is fine.  But I can easily set up a uniquely named
> repository that only you know about and then you can simply upload to
> it and inspect the result afterward.  That would create a git
> repository as you wish it to be.  You can craft it in place.  Then
> that can be swapped into place when you are happy with it.  That would
> be my preference.  But either way is fine.

That's a good idea.  Let's set up the capability.  We're not quite at the
threshold for "must be fixed", but if we get there I want to be able to do
this quickly and with a minumum of fuss.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Fixing repository conversion errors.

[Stefan Monnier]

> Eric S. Raymond wrote:
>> We need a procedure for this - I don't want us to lose another day and
>> a half.  Copying Bob Proulx.  Here's how I think it should go:

Please don't.  This revision number is redundant data (e.g. I never
include it in my commit message when I do those merges) and the
corresponding revid is trivially available already.
I prefer to live with it than having to rebase my branches yet again.

> Sure.  Happy to help.

More importantly:
http://git.savannah.gnu.org/r/emacs.git/config shows that the email
notifications have been "deconfigured" somehow.  Could you re-enable
them (and maybe keep an eye to see if/how they get re-deconfigured)?


        Stefan

Re: Fixing repository conversion errors.

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > Eric S. Raymond wrote:
> >> We need a procedure for this - I don't want us to lose another day and
> >> a half.  Copying Bob Proulx.  Here's how I think it should go:
> 
> Please don't.  This revision number is redundant data (e.g. I never
> include it in my commit message when I do those merges) and the
> corresponding revid is trivially available already.
> I prefer to live with it than having to rebase my branches yet again.

OK, maintainer directive that the present glitches are not worth fixing 
accepted.  But I would still like to have the procedure in place in case
in case anything more serious comes up.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Fixing repository conversion errors.

[Bob Proulx]

Stefan Monnier wrote:
> More importantly:
> http://git.savannah.gnu.org/r/emacs.git/config shows that the email
> notifications have been "deconfigured" somehow. 

Commit notifications have never been configured there.  Are you
thinking about the previous bzr repository?  The bzr repository had
them.  The interim git one this past year has not had them and this
new one doesn't either.

Some background just for general communication...

This is a new git repository.  By default when new repositories are
created there are no notification messages.  Most projects by majority
don't want commit messages.  Many projects do.  The default is none.
Currently if a project wants commit messages they must ask for it.

The normal thing is to submit a support ticket.  Then someone from the
team would service the queue of tickets and act upon it.  At the
moment this would come right back around to me as the active git
person.  So I have been shortcutting the process by having you guys
email me directly if you want me to do something because otherwise it
would sit in the ticket queue until I polled it to notice things and I
have been quite busy lately and haven't been polling with any
reasonable frequency.  I didn't want a request to languish there.

> Could you re-enable them (and maybe keep an eye to see if/how they
> get re-deconfigured)?

Since it seems that the large uploads have finished I have set up
commit notification emails.  You will start seeing them upon the next
commit.  Until this time I was waiting for someone to tell me that big
uploads were done and ask for notifications to be turned on.  I am not
tracking the emacs project and if you don't tell me anything then I
don't know anything.  And maybe even if you tell me something I might
still not know anything.

Bob

Re: Fixing repository conversion errors.

[Stefan Monnier]

> Commit notifications have never been configured there.  Are you

Right, I was confused, sorry.

> Since it seems that the large uploads have finished I have set up
> commit notification emails.

Perfect, thanks Bob.  And sorry for the trouble,


        Stefan

Re: Fixing repository conversion errors.

[Bob Proulx]

Stefan Monnier wrote:
> Perfect, thanks Bob.  And sorry for the trouble,

No trouble!  You are most welcome.  And thanks to you and everyone for
maintaining emacs.  I am still a happy emacs user since way back and
hope to be using it for many years to come.

Bob

Re: New Git repository is up.

[David Engster]

Dani Moncayo writes:
> I've taken a quick glance at the new repo and I still see some bzr
> revnos in commit messages:
>
> ------------
> Merge from emacs-24; up to 117669
> Merge from emacs-24; up to 117687
> Merge from emacs-24; up to 117689
> Revert 118323.
> Merge from emacs-24; up to 117691
> Merge from emacs-24; up to 117698
> Merge from emacs-24; up to 117702
> ---------------

At least for the merge commits, the corresponding SHA1 is *right there*
as a parent, and 118323 can be trivially deduced, so please: let's just
leave it as it is, unless something actually serious comes up.

-David

Re: New Git repository is up.

[Stefan Monnier]

> Merge from emacs-24; up to 117669

Those revision numbers are not important anyway, since the commit itself
contains the necessary metadata.


        Stefan

Re: New Git repository is up.

[Lars Magne Ingebrigtsen]

Hm...  are there bits missing from the .gitignore file?  I cloned the
repo, said "make", and then vc-dir said this:

VC backend : Git
Working dir: ~/src/emacs/
Branch     : master
Remote     : larsi@git.sv.gnu.org:/srv/git/emacs.git
Stash      : Nothing stashed

                         ./
     unregistered        Makefile
     unregistered        config.log
     unregistered        config.status
                         admin/grammars/
     unregistered        admin/grammars/Makefile
                         admin/unidata/
     unregistered        admin/unidata/Makefile
                         doc/emacs/
     unregistered        doc/emacs/emacsver.texi
                         doc/man/
     unregistered        doc/man/emacs.1
                         etc/refcards/
     unregistered        etc/refcards/emacsver.tex
                         leim/
     unregistered        leim/Makefile
                         lib-src/
     unregistered        lib-src/Makefile
     unregistered        lib-src/ctags
     unregistered        lib-src/ebrowse
     unregistered        lib-src/emacsclient
     unregistered        lib-src/etags
[etc etc etc]

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: New Git repository is up.

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  are there bits missing from the .gitignore file?  I cloned the
> repo, said "make", and then vc-dir said this:

A lot of these things are absent when building outside the source
directory.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: New Git repository is up.

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@suse.de> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Hm...  are there bits missing from the .gitignore file?  I cloned the
>> repo, said "make", and then vc-dir said this:
>
> A lot of these things are absent when building outside the source
> directory.

I am building in the source directory.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: New Git repository is up.

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

There is at least one typo in the .gitignore (makefile instead of Makefile)
and a rule for .o files seems to be missing also, as well as ignoring any
of the binaries created in the src directories when building the source
tree. Shouldn't be too hard to fix.

On Thu, Nov 13, 2014 at 6:28 AM, Lars Magne Ingebrigtsen <larsi@gnus.org>
wrote:

> Andreas Schwab <schwab@suse.de> writes:
>
> > Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> >
> >> Hm...  are there bits missing from the .gitignore file?  I cloned the
> >> repo, said "make", and then vc-dir said this:
> >
> > A lot of these things are absent when building outside the source
> > directory.
>
> I am building in the source directory.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

[-- Attachment #2: Type: text/html, Size: 1397 bytes --]

Re: New Git repository is up.

[Lars Magne Ingebrigtsen]

Christoph <cschol2112@gmail.com> writes:

> There is at least one typo in the .gitignore (makefile instead of
> Makefile) and a rule for .o files seems to be missing also, as well as
> ignoring any of the binaries created in the src directories when
> building the source tree. Shouldn't be too hard to fix.

Yeah.  The old .bzrignore was really long, and the .gitignore file is
quite short.  I'm wondering whether the contents weren't copied over on
purpose, or whether somebody forgot...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: New Git repository is up.

[Eric S. Raymond]

Lars Magne Ingebrigtsen <larsi@gnus.org>:
> Christoph <cschol2112@gmail.com> writes:
> 
> > There is at least one typo in the .gitignore (makefile instead of
> > Makefile) and a rule for .o files seems to be missing also, as well as
> > ignoring any of the binaries created in the src directories when
> > building the source tree. Shouldn't be too hard to fix.
> 
> Yeah.  The old .bzrignore was really long, and the .gitignore file is
> quite short.  I'm wondering whether the contents weren't copied over on
> purpose, or whether somebody forgot...

That's complicated.  Here is how the relevant section of my lift script reads:

# IGNORE FILES
#
# Remove every .cvsignore not older than when .gitignores were first
# added.  Then rename all remaining (older) .cvsignores to
# corresponding .gitignore paths after copying in CVS defaults; the
# syntax is upward-compatible.  The date marks the introduction of
# .gitignore files.
#
# (The first .cvsignore commit was 1999-09-30T14:07:54Z!fx@gnu.org>.
# The last CVS commit was <2009-12-27T08:11:12Z!cyd@stupidchicken.com>)
#
<2009-02-03T23:32:38Z>..$ expunge /\.cvsignore$/
=B & [/^.cvsignore$/] filter --regex /^/# CVS default ignores begin\ntags\nTAGS\n.make.state\n.nse_depinfo\n*~\n#*\n.#*\n,*\n_$*\n*$\n*.old\n*.bak\n*.BAK\n*.orig\n*.rej\n.del-*\n*.a\n*.olb\n*.o\n*.obj\n*.so\n*.exe\n*.Z\n*.elc\n*.ln\ncore\n# CVS default ignores end\n/
path ^.cvsignore$ rename .gitignore
path (.*)/\.cvsignore$ rename \1/.gitignore
#
# Remove .bzrignore files, treating .gitignores as authoritative.
#
<2009-12-27T21:38:14Z>..$ expunge /\.bzrignore$/

My thinking here was that the .gitignores were tuned for git by people
actually using git, so they'd be better value than an attempted 
translation of the .bzrignore files that might trip over edge cases
in the syntax.

This sot of thing is why I went to considerable effort to put up seven
trial conversions at Gitorious.  Other people were supposed to be 
reviewing these issues *before* conversion day...

Please post a fixed version, as well as committing it.  I'll add it
to my list of things to retrofix if we do a correction day.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: New Git repository is up.

[Lars Magne Ingebrigtsen]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> This sot of thing is why I went to considerable effort to put up seven
> trial conversions at Gitorious.  Other people were supposed to be 
> reviewing these issues *before* conversion day...

Yeah, that never happens.  >"?

> Please post a fixed version, as well as committing it.  I'll add it
> to my list of things to retrofix if we do a correction day.

Ok; I'll add stuff to the .gitignore file and push.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: New Git repository is up.

[Karl Fogel]

"Eric S. Raymond" <esr@thyrsus.com> writes:
>I repacked, push-mirrored it, then recloned.  It looks correct as far as
>I can tell in the limited time I've had to inspect it.
>
>If we later find conversion flaws, they should be fixable with much less
>effort than the initial conversion.
>
>Commits are open. Have at it.

Thank you, Eric!  That entire effort qualifies as heroic IMHO.

By the way, does anyone know who has the access rights to update

  https://savannah.gnu.org/projects/emacs

with the proper new links and instructions?  (Whatever those may be -- I
actually am not quite sure, there having been appx a bajillion mails in
the relevant threads lately :-) .)

Re: New Git repository is up.

[Jay Belanger]

>>Commits are open. Have at it.
>
> Thank you, Eric!

From me, too.

Re: New Git repository is up.

[Kelvin White]

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

"Jay Belanger" <jay.p.belanger@gmail.com> wrote:
>
>
> >>Commits are open. Have at it.
> >
> > Thank you, Eric!
>
> From me, too.

ditto ;)

[-- Attachment #2: Type: text/html, Size: 306 bytes --]

Re: New Git repository is up.

[Kelvin White]

Karl Fogel <kfogel@red-bean.com> wrote:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
>>I repacked, push-mirrored it, then recloned.  It looks correct as far as
>>I can tell in the limited time I've had to inspect it.
>>
>>If we later find conversion flaws, they should be fixable with much less
>>effort than the initial conversion.
>>
>>Commits are open. Have at it.
>
> Thank you, Eric!  That entire effort qualifies as heroic IMHO.
>
> By the way, does anyone know who has the access rights to update
>
>   https://savannah.gnu.org/projects/emacs
>
> with the proper new links and instructions?  (Whatever those may be -- I
> actually am not quite sure, there having been appx a bajillion mails in
> the relevant threads lately :-) .)

This should definitely be included:
http://www.emacswiki.org/emacs/GitForEmacsDevs

Myself and several others have been contributing to this
and we should be adding anything relevant to a centralized place imho