Using Git to manage your Emacs changes

Using Git to manage your Emacs changes

[John Wiegley]

If anyone here is like me and can't stand Bzr's interface/lack-of-speed due to comfort with Git, there is a *somewhat* more palatable solution:

 1. Install git-bzr (http://github.com/pieter/git-bzr).  Make sure it works by
    testing on some very small project from someplace.

 2. Do a bzr checkout of Emacs.  DO NOT use git-bzr to directly checkout the
    Emacs tree.  It will take days and days and download over 20G of data.

 3. Using git-bzr, point it at your local bzr checkout so it can do a fully local
    translation of the Bzr commits to Git commits.  This will take several hours,
    but not hog network bandwidth.

 4. When done, you can fetch Bzr changes into your tree with:

      git bzr fetch upstream

 5. Now here's the tricky part.  Move your .git directory from your git-bzr checkout
    over into your Bzr working tree.  Yes, we want Bzr and Git to manage the same
    tree.  You should be wearing your Depends; this is not for the faint of heart.

 6. Create a 'master' branch to queue your Git commits.  You can make topics branches
    off the branch, just never modify the upstream branch directly.

       git checkout -b master upstream

 7. Sadly, git-bzr is sufficiently broken that you will not be able to push your
    changes with "git bzr push upstream", as the docs indicate.  Instead, we have
    to use "git format-patch" and then turn each patch into a Bzr commit manually,
    which get pushed with "bzr push".  Once pushed, "git bzr pull upstream" reflects
    that new commit back in Git:

      ./apply.sh upstream     # apply commits using script below; stash if needed
      bzr push
      git bzr fetch upstream
      git rebase upstream     # git stash pop afterwards if needed

 8. I expect a blank line after my initial commit description.  If you don't do this,
    remove the "| tail +2" from the apply script.  It would seems that using a blank
    line is standard in the Git community, but not using it in standard for the Emacs
    tree.

I know, it's quite ugly, but using Bazaar has proven even less desirable.

John

#!/bin/bash

git checkout ${1:-upstream}
git format-patch ..master

for i in [0-9]*.patch; do
        echo Applying $i

        patch -p1 < $i

        grep ^Subject: $i | sed 's/^Subject: \[PATCH\] //' > /tmp/msg.$$

        perl -ne 'print if /^$/ .. /^---/;' $i | \
          perl -ne 'print unless /^---/ .. eof()' | \
          tail +2 >> /tmp/msg.$$

        bzr commit -F /tmp/msg.$$

        rm -f /tmp/msg.$$
done

git reset --hard HEAD
git checkout master
rm -f [0-9]*.patch

Re: Using Git to manage your Emacs changes

[David Reitter]

On Apr 7, 2010, at 3:23 PM, John Wiegley wrote:

> If anyone here is like me and can't stand Bzr's interface/lack-of-speed due to comfort with Git, there is a *somewhat* more palatable solution:
> 
> 1. Install git-bzr (http://github.com/pieter/git-bzr).

What about the reliable, simple, wonderful git mirror at http://repo.or.cz/w/emacs.git ?

The last commit to git-bzr says "Add a note saying I'm really not interested in this anymore ".   ;-)

One could use something like your script to transplant (push) changes to a separate, clean bzr checkout.  The downside I see is that changes will, in very rare circumstances, fail if the git mirror is out of date.

Re: Using Git to manage your Emacs changes

[John Wiegley]

On Apr 7, 2010, at 3:32 PM, David Reitter wrote:

> What about the reliable, simple, wonderful git mirror at http://repo.or.cz/w/emacs.git ?

You can't push to it.

John

Re: Using Git to manage your Emacs changes

[David Reitter]

On Apr 7, 2010, at 4:25 PM, John Wiegley wrote:

> On Apr 7, 2010, at 3:32 PM, David Reitter wrote:
> 
>> What about the reliable, simple, wonderful git mirror at http://repo.or.cz/w/emacs.git ?
> 
> You can't push to it.

You're not pushing from git to bzr either... 

Why not create a setup that merges all changes on the git into bzr automatically?
It's been discussed on this list.

Re: Using Git to manage your Emacs changes

[Ted Zlatanov]

On Wed, 7 Apr 2010 15:32:04 -0400 David Reitter <david.reitter@gmail.com> wrote: 

DR> On Apr 7, 2010, at 3:23 PM, John Wiegley wrote:

>> If anyone here is like me and can't stand Bzr's interface/lack-of-speed due to comfort with Git, there is a *somewhat* more palatable solution:
>> 
>> 1. Install git-bzr (http://github.com/pieter/git-bzr).

DR> What about the reliable, simple, wonderful git mirror at http://repo.or.cz/w/emacs.git ?

How reliable is it WRT recent commits?  Do they show up quickly or is
there a manual process?  We're just discussing something similar
concerning Gnus <-> Emacs synchronization so this could help us.

Thanks
Ted

Re: Using Git to manage your Emacs changes

[David Reitter]

On Apr 21, 2010, at 1:30 PM, Ted Zlatanov wrote:
> 
> DR> What about the reliable, simple, wonderful git mirror at http://repo.or.cz/w/emacs.git ?
> 
> How reliable is it WRT recent commits?  Do they show up quickly or is
> there a manual process?  We're just discussing something similar
> concerning Gnus <-> Emacs synchronization so this could help us.

I find it very reliable.  As far as I know, it is updated manually and at least daily, so it is usually very current.  You should ask Andreas if there have been any problems with the conversion requiring manual intervention; if not, it could probably be automated and done hourly or so.  A big, big thank you from me for maintaining it.

The bigger issue with this is that the mirror isn't perfectly "official", which means that it could go away, or, worse, be rebased.  Essentially this happened when Emacs switched from CVS to Bzr, and the git mirror that we used to have on Savannah went away.  The new mirror wasn't compatible.

Re-basing is not an easy option for Aquamacs, due to multiple past merges.  Right now we're carrying around both histories (the old Git mirror and the new one).  So it's maybe 200.000 revisions.  Ultimately I might be able to rewrite it, but I'm waiting for the Git mirror to be automated.

Overall, working on my downstream project has been great with git.  Merges are fast and very reliable.  A git-pull from the Cz only takes a few seconds; same for the merge.  I set up to three branches for my project (Emacs 22 based, Emacs 23 based, and Emacs 24/trunk based).  The 23 one merges directly into the 24 one, and the 22 one cherry-picks bug-fixes (but not features) from the 23 one.  Where conflicts arise, I use "git mergetool" which fires up FileMerge (a wonderful graphical tool).  I use GitX occasionally to visualize some piece of history or search for a change.  GitX is slow with those 200k revisions.  I usually I use the command line or Emacs VC, especially for showing diffs, logs, and "git blame" (C-x v g).  I use the "git new-workdir" extension to keep multiple branches in parallel without having to have separate copies of the repository.

I have a "speed" complaint: when Emacs opens a file it does some status check with Git before actually displaying it (rather than in the background).  The first time, this takes a while.  Also,  on my old laptop, git-blame takes maybe 20 seconds on the large source files, which is unnecessary given that one usually just wants "blame" for a few lines of code.

Generally though, it's blazingly fast; I've had no strange error message from git so far, and I've had no incompatibilities with git versions or repositories either.  Where I make mistakes of my own with git, I can often "git reset --hard" to rewind my changes unless I've already pushed them to our server (github). 

I hope this helps you in some way; if you have questions, do get in touch privately.  I reckon most people here aren't too interested in this.

Re: Using Git to manage your Emacs changes

[John Wiegley]

On Apr 21, 2010, at 2:12 PM, David Reitter wrote:

> Generally though, it's blazingly fast; I've had no strange error message from git so far, and I've had no incompatibilities with git versions or repositories either.  Where I make mistakes of my own with git, I can often "git reset --hard" to rewind my changes unless I've already pushed them to our server (github). 

I'll have to try using this, since I just found out today that git-bzr no longer works due to a recent commit (haven't tracked down which yet):

  11:49:57 107000/108016 commits exported at 348/minute
  11:56:34 108000/108016 commits exported at 344/minute
  fatal: Expected committer but didn't get one
  fast-import: dumping crash report to .git/fast_import_crash_98213
  bzr: broken pipe

When git-bzr dies, it dies hard and fast without much chance of recovery.  So, guess I'll have to live with a mirror that lags slightly behind my bzr tree...

Can someone point me to the e-mail thread where we chose Bazaar?  Emacs is the only project I work on that uses it, and it's been a pretty unpleasant experience thus far.

Thanks, John

Re: Using Git to manage your Emacs changes

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Wed, 21 Apr 2010 15:29:35 -0400
> Cc: Ted Zlatanov <tzz@lifelogs.com>, Andreas Schwab <schwab@linux-m68k.org>,
> 	"emacs-devel@gnu.org devel" <emacs-devel@gnu.org>
> 
> Can someone point me to the e-mail thread where we chose Bazaar?  Emacs is the only project I work on that uses it, and it's been a pretty unpleasant experience thus far.

  http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00309.html

And it really doesn't help to continue complaining about Bazaar here.
It is much better to complain on the Bazaar mailing list, where the
Bazaar maintainers will hear you and maybe do something about it.

Re: Using Git to manage your Emacs changes

[John Wiegley]

On Apr 21, 2010, at 4:42 PM, Eli Zaretskii wrote:

> And it really doesn't help to continue complaining about Bazaar here.
> It is much better to complain on the Bazaar mailing list, where the
> Bazaar maintainers will hear you and maybe do something about it.

Will they fulfill my wish of going away and causing Emacs use Git instead? :)

John

Re: Using Git to manage your Emacs changes

[Lennart Borgman]

On Thu, Apr 22, 2010 at 9:17 AM, John Wiegley <jwiegley@gmail.com> wrote:
> On Apr 21, 2010, at 4:42 PM, Eli Zaretskii wrote:
>
>> And it really doesn't help to continue complaining about Bazaar here.
>> It is much better to complain on the Bazaar mailing list, where the
>> Bazaar maintainers will hear you and maybe do something about it.
>
> Will they fulfill my wish of going away and causing Emacs use Git instead? :)


Sure. If you can get all Git developers to sign papers for FSF.

Re: Using Git to manage your Emacs changes

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Apr 22, 2010 at 9:17 AM, John Wiegley <jwiegley@gmail.com> wrote:
>> On Apr 21, 2010, at 4:42 PM, Eli Zaretskii wrote:
>>
>>> And it really doesn't help to continue complaining about Bazaar here.
>>> It is much better to complain on the Bazaar mailing list, where the
>>> Bazaar maintainers will hear you and maybe do something about it.
>>
>> Will they fulfill my wish of going away and causing Emacs use Git instead? :)
>
>
> Sure. If you can get all Git developers to sign papers for FSF.

There is no need for anyone to sign papers.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Using Git to manage your Emacs changes

[Lennart Borgman]

On Thu, Apr 22, 2010 at 12:28 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Thu, Apr 22, 2010 at 9:17 AM, John Wiegley <jwiegley@gmail.com> wrote:
>>> On Apr 21, 2010, at 4:42 PM, Eli Zaretskii wrote:
>>>
>>>> And it really doesn't help to continue complaining about Bazaar here.
>>>> It is much better to complain on the Bazaar mailing list, where the
>>>> Bazaar maintainers will hear you and maybe do something about it.
>>>
>>> Will they fulfill my wish of going away and causing Emacs use Git instead? :)
>>
>>
>> Sure. If you can get all Git developers to sign papers for FSF.
>
> There is no need for anyone to sign papers.


I must have missed something. Was not copyright issues behind the
choice of Bazaar?

Re: Using Git to manage your Emacs changes

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Apr 22, 2010 at 12:28 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Thu, Apr 22, 2010 at 9:17 AM, John Wiegley <jwiegley@gmail.com> wrote:
>>>> On Apr 21, 2010, at 4:42 PM, Eli Zaretskii wrote:
>>>>
>>>>> And it really doesn't help to continue complaining about Bazaar here.
>>>>> It is much better to complain on the Bazaar mailing list, where the
>>>>> Bazaar maintainers will hear you and maybe do something about it.
>>>>
>>>> Will they fulfill my wish of going away and causing Emacs use Git instead? :)
>>>
>>>
>>> Sure. If you can get all Git developers to sign papers for FSF.
>>
>> There is no need for anyone to sign papers.
>
>
> I must have missed something. Was not copyright issues behind the
> choice of Bazaar?

Git is already used by a lot of GNU projects.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

endless version control debates [was Re: Using Git to manage your Emacs changes]

[Glenn Morris]

Andreas Schwab wrote:

> Git is already used by a lot of GNU projects.

Could we please, please, stop having endlessly repeated version
control debates on the Emacs development mailing list. It is not going
to achieve anything.

Re: endless version control debates

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

> Could we please, please, stop having endlessly repeated version
> control debates on the Emacs development mailing list. It is not going
> to achieve anything.

Seconded.

My interventions on those threads are not aimed at switching VCS nor at
defending the status quo. I just try to help others clearing
misunderstandings, but the discussions may turn very technical, hot and
long, so maybe we could agree on relegating discussions about Bazaar's
virtues, defects and usage to its ml, and mention bzr here only for
administratrivia.

Re: endless version control debates [was Re: Using Git to manage your Emacs changes]

[Leo]

On 2010-04-22 17:20 +0100, Glenn Morris wrote:
> Andreas Schwab wrote:
>
>> Git is already used by a lot of GNU projects.
>
> Could we please, please, stop having endlessly repeated version
> control debates on the Emacs development mailing list. It is not going
> to achieve anything.

It might not be completely useless. Nothing stops emacs from using
multiple version control tools if a good synchronisation scheme can be
found.

Leo

Re: endless version control debates [was Re: Using Git to manage your Emacs changes]

[Chad Brown]

On Apr 22, 2010, at 10:07 AM, Leo wrote:

> It might not be completely useless. Nothing stops emacs from using
> multiple version control tools if a good synchronisation scheme can be
> found.

The point of choosing Bazaar was to give the support of `Emacs uses it' 
and `Emacs developers use it' to the official GNU VCS system.   Anything
that encourages Emacs [developers] to use not-Bazaar hampers that goal.

It follows simply and directly from this that the PtB are not especially interested
in supporting non-Bazaar VCS *use* for Emacs development, regardless of 
how you get there.  Nobody's going to come to your house and take away your
Emacs Developer badge, but that doesn't mean that they want to see the debates,
either.  

It can be very hard for the sort of people who typically make good developers 
(be they programmers, debuggers, testers, power-users, etc) to accept 
out-of-stream arguments, especially when they seem contrary to simple 
technical-merit-based metrics, but the current status is:  Bazaar was chosen for 
reasons other than pure technical merit, so technical merit arguments are simply
an irritation to almost everyone involved.  As a practical matter, you can probably 
bring it up again after Emacs development, Bazaar, and all potential alternatives 
have matured for a while (I'd guess a year is probably a good fencepost), but until
then, the debates, discussions, data points, etc -- NO MATTER HOW TRUE -- are
simply irritants.   Hold on to them, develop alternatives, jump into Bazaar and
shape it from the inside -- any of these are great.  For now, for this, debate is not a
viable answer.

I apologize if I've stepped on anyone's toes in saying this; it is not my intention to 
offend anyone.  I'm speaking up because I have hope that a voice from outside the
debate will have a greater chance of being actually heard above the din.

Thanks, everyone, for emacs; the last 20 years would certainly have sucked without it.
*Chad

Re: endless version control debates [was Re: Using Git to manage your Emacs changes]

[Andreas Schwab]

Chad Brown <yandros@MIT.EDU> writes:

> The point of choosing Bazaar was to give the support of `Emacs uses it' 
> and `Emacs developers use it' to the official GNU VCS system.   Anything
> that encourages Emacs [developers] to use not-Bazaar hampers that goal.

GNU is about freedom.  Everybody should be free to use the (free) tool
he thinks is the best for his needs.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: endless version control debates [was Re: Using Git to manage your Emacs changes]

[Chad Brown]

On Apr 22, 2010, at 12:16 PM, Andreas Schwab wrote:

> Chad Brown <yandros@MIT.EDU> writes:
> 
>> The point of choosing Bazaar was to give the support of `Emacs uses it' 
>> and `Emacs developers use it' to the official GNU VCS system.   Anything
>> that encourages Emacs [developers] to use not-Bazaar hampers that goal.
> 
> GNU is about freedom.  Everybody should be free to use the (free) tool
> he thinks is the best for his needs.

And everyone is.  Everyone should not feel free to debate it on the emacs-devel 
mailing list, however.   That's not any sort of law, nor freedom, but rather simple 
politeness.

*Chad

Re: endless version control debates

[Miles Bader]

Chad Brown <yandros@MIT.EDU> writes:
> And everyone is.  Everyone should not feel free to debate it on the emacs-devel 
> mailing list, however.   That's not any sort of law, nor freedom, but rather simple 
> politeness.

It has nothing to do with politeness.  There's absolutely nothing
impolite about civilly discussing emacs-development-related technical
matters on this list.

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: endless version control debates [was Re: Using Git to manage your Emacs changes]

[Leo]

On 2010-04-22 18:52 +0100, Chad Brown wrote:
>> It might not be completely useless. Nothing stops emacs from using
>> multiple version control tools if a good synchronisation scheme can
>> be found.
>
> The point of choosing Bazaar was to give the support of `Emacs uses
> it' and `Emacs developers use it' to the official GNU VCS system.
> Anything that encourages Emacs [developers] to use not-Bazaar hampers
> that goal.

That sounded like doctrine.

What makes other free version systems less free than bzr and why should
it be a problem to provide a mirror to the bzr repo that allow people to
use the tool of their choice?

Leo

Re: endless version control debates [was Re: Using Git to manage your Emacs changes]

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Thu, 22 Apr 2010 21:16:11 +0100
> 
> > The point of choosing Bazaar was to give the support of `Emacs uses
> > it' and `Emacs developers use it' to the official GNU VCS system.
> > Anything that encourages Emacs [developers] to use not-Bazaar hampers
> > that goal.
> 
> That sounded like doctrine.

It is.

> What makes other free version systems less free than bzr and why should
> it be a problem to provide a mirror to the bzr repo that allow people to
> use the tool of their choice?

I provided the URL of the discussion about this for a reason.  Please
read it, for crying out loud!  There's enough arguments there to fill
many more weeks of this "discussion".  No need to discover it all in
realtime and on-line.

Re: endless version control debates [was Re: Using Git to manage your Emacs changes]

[Jeff Clough]

Leo <sdl.web@gmail.com> writes:

> On 2010-04-22 18:52 +0100, Chad Brown wrote:
>> The point of choosing Bazaar was to give the support of `Emacs uses
>> it' and `Emacs developers use it' to the official GNU VCS system.
>> Anything that encourages Emacs [developers] to use not-Bazaar hampers
>> that goal.
>
> That sounded like doctrine.
>
> What makes other free version systems less free than bzr and why should
> it be a problem to provide a mirror to the bzr repo that allow people to
> use the tool of their choice?

Speaking from the sidelines, today I have the following version control
systems on my machine (that I can remember off the top of my head):

bazaar
cvs
mercurial
darcs
subversion
git

Each of these is necessary for one or more pieces of software I like to
stay current with.  Choice is nice and all, but the fact that there are
six different VCSs I have to care about in 2010 is pretty insane.
Anything that brings that number closer to one would be a good thing in
my book.

Jeff

Re: Using Git to manage your Emacs changes

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> Will they fulfill my wish of going away and causing Emacs use Git instead? :)
>
> Sure. If you can get all Git developers to sign papers for FSF.

Why?  The Bazaar source copyrights are held by Canonical, so clearly
it's not necessary...

-Miles

-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if
a man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: Using Git to manage your Emacs changes

[Juri Linkov]

>>> Will they fulfill my wish of going away and causing Emacs use Git instead? :)
>>
>> Sure. If you can get all Git developers to sign papers for FSF.
>
> Why?  The Bazaar source copyrights are held by Canonical, so clearly
> it's not necessary...

Then what is necessary to do to make Git a GNU package?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Using Git to manage your Emacs changes

[Ævar Arnfjörð Bjarmason]

On Fri, Apr 23, 2010 at 08:38, Juri Linkov <juri@jurta.org> wrote:
> Then what is necessary to do to make Git a GNU package?

Give Linus Torvalds a truckload of drugs.

Re: Using Git to manage your Emacs changes

[Richard Stallman]

    Then what is necessary to do to make Git a GNU package?

Agreeing to follow our practices on a lot of issues.
It is most unlikely that Torvalds would agree.

Re: Using Git to manage your Emacs changes

[Jason Earl]

Richard Stallman <rms@gnu.org> writes:

>     Then what is necessary to do to make Git a GNU package?
>
> Agreeing to follow our practices on a lot of issues.  It is most
> unlikely that Torvalds would agree.

Does it really matter that much?  I am certain that their are other
parts of the GNU system (like, perhaps, TeX), where the hackers in
question don't follow GNU policies.  In fact, Bazaar doesn't completely
follow GNU policies (no texinfo documentation, and no real plans to
generate it either).

It is likely that I am taking this too personally, but if this is an
example of how the greater GNU community supports a fellow GNU project
then I am somewhat at a loss as to why anyone would want their program
to be taken under the GNU aegis.  It is fairly clear that GNU support
for Bazaar is skin deep at best.

Apparently is it completely on-topic on this GNU-hosted mailing list to
disparage Bazaar, and worse, to actively discuss how to work around
using the official Bazaar repository.  Savannah has excellent support
for git, but very poor support for Bazaar, and, like the lack of Bazaar
documentation in texinfo, that is also apparently unlikely to change in
the near future.  Instead of actively encouraging other GNU and
Emacs-related projects to use Bazaar the Emacs project is discouraging
Bazaar use.  The Gnus switch to git is a prime example of this effect.

It is pretty clear that the Emacs development community would rather use
git, and it is also pretty clear that the folks at Savannah would rather
have GNU projects use git.  So why not simply adopt git?  Sure, it
doesn't follow all of the GNU policies, but then, neither does Bazaar.

If git were to become an official GNU project then the machinery is in
place today to switch Emacs to git.  Andreas already has a high quality
git archive (which is already being used by several Emacs-related
projects like Aquamacs, Gnus, Org-mode, and others), and Savannah has
excellent git support.

If Bazaar is going to remain the official GNU version control system
then perhaps those hackers that wish to discuss ways to work around
using Bazaar should be persuaded to take their discussion off of the
gnu.org lists (at the very least).

Jason

Re: Using Git to manage your Emacs changes

[Ævar Arnfjörð Bjarmason]

On Sat, Apr 24, 2010 at 15:27, Jason Earl <jearl@notengoamigos.org> wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>>     Then what is necessary to do to make Git a GNU package?
>>
>> Agreeing to follow our practices on a lot of issues.  It is most
>> unlikely that Torvalds would agree.
>
> Does it really matter that much?  I am certain that their are other
> parts of the GNU system (like, perhaps, TeX), where the hackers in
> question don't follow GNU policies.  In fact, Bazaar doesn't completely
> follow GNU policies (no texinfo documentation, and no real plans to
> generate it either).

Git would never agree to be under the GNU umbrella.

> It is likely that I am taking this too personally, but if this is an
> example of how the greater GNU community supports a fellow GNU project
> then I am somewhat at a loss as to why anyone would want their program
> to be taken under the GNU aegis.  It is fairly clear that GNU support
> for Bazaar is skin deep at best.
>
> Apparently is it completely on-topic on this GNU-hosted mailing list to
> disparage Bazaar, and worse, to actively discuss how to work around
> using the official Bazaar repository.  Savannah has excellent support
> for git, but very poor support for Bazaar, and, like the lack of Bazaar
> documentation in texinfo, that is also apparently unlikely to change in
> the near future.  Instead of actively encouraging other GNU and
> Emacs-related projects to use Bazaar the Emacs project is discouraging
> Bazaar use.  The Gnus switch to git is a prime example of this effect.

Some developers actively worked around CVS when the Emacs was in that
system. People are interested in hacking Emacs using the tools they're
familiar with.

I don't think you need to take it personally, people just like to work
with their regular tools. DVCS systems make it easy to use the system
you want.

Re: Using Git to manage your Emacs changes

[Alfred M. Szmidt]

   >     Then what is necessary to do to make Git a GNU package?
   >
   > Agreeing to follow our practices on a lot of issues.  It is most
   > unlikely that Torvalds would agree.

   Does it really matter that much?  I am certain that their are other
   parts of the GNU system (like, perhaps, TeX), where the hackers in
   question don't follow GNU policies.  In fact, Bazaar doesn't
   completely follow GNU policies (no texinfo documentation, and no
   real plans to generate it either).

While TeX is part of the GNU system, it is not part of the GNU
project.  I hope that bazaar will adpot texinfo manuals soon, I think
someone was working on that.

Re: Using Git to manage your Emacs changes

[Jason Earl]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    >     Then what is necessary to do to make Git a GNU package?
>    >
>    > Agreeing to follow our practices on a lot of issues.  It is most
>    > unlikely that Torvalds would agree.
>
>    Does it really matter that much?  I am certain that their are other
>    parts of the GNU system (like, perhaps, TeX), where the hackers in
>    question don't follow GNU policies.  In fact, Bazaar doesn't
>    completely follow GNU policies (no texinfo documentation, and no
>    real plans to generate it either).
>
> While TeX is part of the GNU system, it is not part of the GNU
> project.  I hope that bazaar will adpot texinfo manuals soon, I think
> someone was working on that.

Bazaar has this marked as a bug (wishlist), but they are essentially
waiting for someone to come up with a way to make texinfo documentation
from their existing rst documentation.  In fact, it could easily be
argued that they are moving farther away from texinfo as they have moved
from simply requiring docutils to requiring the more complicated sphinx
documentation build system.

On the bright side, if someone could modify Sphinx to generate texinfo
then I would get my Python documentation back in texinfo format as well.

Besides, that would only solve the documentation part of the problem.
texinfo documentation is not likely to make the existing Emacs (or GNU)
developers like Bazaar.  Nor is it likely to make Savannah support
Bazaar at least as well as it supports git.  The documentation problem
is actually relatively minor, and it is a problem shared by both bzr and
git.

My question, and I ask this as a person whose one small contribution to
GNU is that I helped (a bit) with the conversion of the Emacs repo from
CVS to bzr, is why pretend that Bazaar is part of the GNU project when
the GNU developers (and systems administrators) seem to overwhelmingly
prefer git?  Worse, they are actively trying to undermine Bazaar,
including long discussions on how to circumvent Bazaar on this very
list.

Dump bzr and make git part of the GNU "system," if that is what it
takes, but do not pretend that Bazaar is part of the GNU project when
clearly it is not.

I love Emacs, and I have come to really like Bazaar, but I can not help
but feel that by helping the Emacs development team move to Bazaar I
have actually done both of these communities a disservice.  Bazaar has
received nothing but bad publicity from the switch, and the Emacs
development group appears to have been hampered more than
helped--despite the fact that Emacs was switching from crufty CVS.
Moving from CVS should have been a no-brainer, and yet that has not been
the case.  In my defense I assumed that Savannah would be using a smart
bzr server, which really would help a great deal.

Jason

Re: Using Git to manage your Emacs changes

[Alfred M. Szmidt]

   Bazaar has this marked as a bug (wishlist), but they are
   essentially waiting for someone to come up with a way to make
   texinfo documentation from their existing rst documentation.  In
   fact, it could easily be argued that they are moving farther away
   from texinfo as they have moved from simply requiring docutils to
   requiring the more complicated sphinx documentation build system.

That is a pitty.

   My question, and I ask this as a person whose one small
   contribution to GNU is that I helped (a bit) with the conversion of
   the Emacs repo from CVS to bzr, is why pretend that Bazaar is part
   of the GNU project when the GNU developers (and systems
   administrators) seem to overwhelmingly prefer git?  Worse, they are
   actively trying to undermine Bazaar, including long discussions on
   how to circumvent Bazaar on this very list.

There is nothing to pretend, bazaar is part of the GNU project,
whether people like it or not.  Alot of freedom is left up to the
maintainers as to how they maintain their projects; and as such the
emacs maintainers decided to on bazaar.  Take Guile as a counter
example, GDB uses Python instead of Guile, does this make GDB any less
part of the GNU project? Ofcourse not.

Complaining about the topic is not going to solve anything.  If
savannah doesn't support the prefered method for bazaar someone should
step up and fix the issue, Sylvain Beucler is just about the only
person working on Savannah, and he needs help.

Re: Using Git to manage your Emacs changes

[Eli Zaretskii]

> From: Jason Earl <jearl@notengoamigos.org>
> Cc: rms@gnu.org,  jwiegley@gmail.com,  tzz@lifelogs.com,  lennart.borgman@gmail.com,  emacs-devel@gnu.org,  juri@jurta.org,  schwab@linux-m68k.org,  david.reitter@gmail.com,  eliz@gnu.org,  miles@gnu.org
> Date: Sat, 24 Apr 2010 13:33:49 -0600
> 
> Bazaar has this marked as a bug (wishlist), but they are essentially
> waiting for someone to come up with a way to make texinfo documentation
> from their existing rst documentation.  In fact, it could easily be
> argued that they are moving farther away from texinfo as they have moved
> from simply requiring docutils to requiring the more complicated sphinx
> documentation build system.

If Bazaar developers want help in automatic conversion of their docs
system to Texinfo, they should talk to Texinfo maintainers.  With the
upcoming switch from makeinfo written in C to texi2html written in
Perl, it may be easier to add additional translators; at least that
was the theory and the justification for the switch.

> My question, and I ask this as a person whose one small contribution to
> GNU is that I helped (a bit) with the conversion of the Emacs repo from
> CVS to bzr, is why pretend that Bazaar is part of the GNU project when
> the GNU developers (and systems administrators) seem to overwhelmingly
> prefer git?  Worse, they are actively trying to undermine Bazaar,
> including long discussions on how to circumvent Bazaar on this very
> list.
> 
> Dump bzr and make git part of the GNU "system," if that is what it
> takes, but do not pretend that Bazaar is part of the GNU project when
> clearly it is not.

Please do not exaggerate, and please do not generalize too much from
what you've heard here.  There are definitely several people who were
discussing git, but I would not recommend concluding that they
represent the ``overwhelming'' part of Emacs developers.  They
certainly do not represent me.  I'm using Bazaar, and I do not intend
to switch to git any time soon.

> Bazaar has received nothing but bad publicity from the switch, and
> the Emacs development group appears to have been hampered more than
> helped

I think both of these assertions are false.  I definitely feel that
Bazaar helps me more than CVS did.  I do hope that Savannah will
switch to the smart server some time this century, and I definitely
would love to see Bazaar need less bandwidth than it asks for now.
Then the quality of my life as an Emacs developer will be better yet.
But it has definitely improved already, since we switched.  So I would
like to thank you and others who've helped make that happen.

Re: Using Git to manage your Emacs changes

[Jason Earl]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jason Earl <jearl@notengoamigos.org>
>> Cc: rms@gnu.org,  jwiegley@gmail.com,  tzz@lifelogs.com,  lennart.borgman@gmail.com,  emacs-devel@gnu.org,  juri@jurta.org,  schwab@linux-m68k.org,  david.reitter@gmail.com,  eliz@gnu.org,  miles@gnu.org
>> Date: Sat, 24 Apr 2010 13:33:49 -0600
>> 
>> Bazaar has this marked as a bug (wishlist), but they are essentially
>> waiting for someone to come up with a way to make texinfo documentation
>> from their existing rst documentation.  In fact, it could easily be
>> argued that they are moving farther away from texinfo as they have moved
>> from simply requiring docutils to requiring the more complicated sphinx
>> documentation build system.
>
> If Bazaar developers want help in automatic conversion of their docs
> system to Texinfo, they should talk to Texinfo maintainers.  With the
> upcoming switch from makeinfo written in C to texi2html written in
> Perl, it may be easier to add additional translators; at least that
> was the theory and the justification for the switch.

I am glad to hear this.  I like Texinfo.

>> My question, and I ask this as a person whose one small contribution
>> to GNU is that I helped (a bit) with the conversion of the Emacs repo
>> from CVS to bzr, is why pretend that Bazaar is part of the GNU
>> project when the GNU developers (and systems administrators) seem to
>> overwhelmingly prefer git?  Worse, they are actively trying to
>> undermine Bazaar, including long discussions on how to circumvent
>> Bazaar on this very list.
>> 
>> Dump bzr and make git part of the GNU "system," if that is what it
>> takes, but do not pretend that Bazaar is part of the GNU project when
>> clearly it is not.
>
> Please do not exaggerate, and please do not generalize too much from
> what you've heard here.  There are definitely several people who were
> discussing git, but I would not recommend concluding that they
> represent the ``overwhelming'' part of Emacs developers.  They
> certainly do not represent me.  I'm using Bazaar, and I do not intend
> to switch to git any time soon.

That's good to hear.

>> Bazaar has received nothing but bad publicity from the switch, and
>> the Emacs development group appears to have been hampered more than
>> helped
>
> I think both of these assertions are false.  I definitely feel that
> Bazaar helps me more than CVS did.  I do hope that Savannah will
> switch to the smart server some time this century, and I definitely
> would love to see Bazaar need less bandwidth than it asks for now.
> Then the quality of my life as an Emacs developer will be better yet.
> But it has definitely improved already, since we switched.  So I would
> like to thank you and others who've helped make that happen.

I apologize for over-reacting.  Like I said before, apparently I am too
close to the issue.  I will keep similar opinions to myself in the
future.

Jason

Re: Using Git to manage your Emacs changes

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > If Bazaar developers want help in automatic conversion of their docs
 > system to Texinfo, they should talk to Texinfo maintainers.  With the
 > upcoming switch from makeinfo written in C to texi2html written in
 > Perl, it may be easier to add additional translators; at least that
 > was the theory and the justification for the switch.

Warning: you probably will get zero interest from docutils and Bazaar
hackers in working on code written in Perl.  The sources will remain
in reST, or a derivative, I would imagine.

 > But it has definitely improved already, since we switched.  So I would
 > like to thank you and others who've helped make that happen.

I'm glad to hear that, as a git person who nevertheless put a lot of
effort into trying to help smooth the Bazaar switch for Emacs.  Thank
you for speaking up.

Re: Using Git to manage your Emacs changes

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>I think both of these assertions are false.  I definitely feel that
>Bazaar helps me more than CVS did.  

Same here, for what it's worth.

>I do hope that Savannah will switch to the smart server some time this
>century

Working on it.  I am not the most qualified person to do it, but
apparently I'm the one doing it anyway :-).

Re: Using Git to manage your Emacs changes

[Georg Brandl]

Am 24.04.2010 21:33, schrieb Jason Earl:

>>    Does it really matter that much?  I am certain that their are other
>>    parts of the GNU system (like, perhaps, TeX), where the hackers in
>>    question don't follow GNU policies.  In fact, Bazaar doesn't
>>    completely follow GNU policies (no texinfo documentation, and no
>>    real plans to generate it either).
>>
>> While TeX is part of the GNU system, it is not part of the GNU
>> project.  I hope that bazaar will adpot texinfo manuals soon, I think
>> someone was working on that.
> 
> Bazaar has this marked as a bug (wishlist), but they are essentially
> waiting for someone to come up with a way to make texinfo documentation
> from their existing rst documentation.  In fact, it could easily be
> argued that they are moving farther away from texinfo as they have moved
> from simply requiring docutils to requiring the more complicated sphinx
> documentation build system.

As the Sphinx maintainer and at the same time avid Emacs user, I feel I have
to chime in here.

I wouldn't say that using Sphinx is moving farther away from texinfo.  As
far as I know, there is no docutils writer for texinfo right now.
Most of the work of supporting Texinfo as a Sphinx output format would be
required for docutils as well, i.e. the conversion from a node tree to
Texinfo markup.

Additional overhead is only necessary for Sphinx' custom nodes, and for
determining how to interpret cross-references and how to map the multi-file
structure of a Sphinx project to the output.  This is simply stuff that
isn't supported by "plain" docutils but has to be supported by Texinfo,
so the mapping shouldn't be hard.

> On the bright side, if someone could modify Sphinx to generate texinfo
> then I would get my Python documentation back in texinfo format as well.

I'm absolutely not opposed to supporting Texinfo.  Anyone who wants to take
this on will have my support, but as with many feature requests, I do not
have the time to do it myself.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

Re: Using Git to manage your Emacs changes

[Richard Stallman]

I will urge and help the Bzr developers to provide Texinfo documentation
and also urge other GNU package maintainers to use Bzr.

Re: Using Git to manage your Emacs changes

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: juri@jurta.org, jwiegley@gmail.com, tzz@lifelogs.com,
> 	lennart.borgman@gmail.com, emacs-devel@gnu.org,
> 	schwab@linux-m68k.org, david.reitter@gmail.com, eliz@gnu.org,
> 	miles@gnu.org
> Date: Mon, 26 Apr 2010 10:33:59 -0400
> 
> I will urge and help the Bzr developers to provide Texinfo documentation

If needed, you can count on my help regarding this.

Re: Using Git to manage your Emacs changes

[Andreas Schwab]

John Wiegley <jwiegley@gmail.com> writes:

> I'll have to try using this, since I just found out today that git-bzr no longer works due to a recent commit (haven't tracked down which yet):
>
>   11:49:57 107000/108016 commits exported at 348/minute
>   11:56:34 108000/108016 commits exported at 344/minute
>   fatal: Expected committer but didn't get one
>   fast-import: dumping crash report to .git/fast_import_crash_98213
>   bzr: broken pipe

<http://bazaar.launchpad.net/~schwab-linux-m68k/bzr-fastimport/fastimport.dev/revision/262>

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Using Git to manage your Emacs changes

[Giuseppe Scrivano]

I have some notes on your script:

John Wiegley <jwiegley@gmail.com> writes:

> git checkout ${1:-upstream}
> git format-patch ..master
>
> for i in [0-9]*.patch; do
>         echo Applying $i
>
>         patch -p1 < $i

I am not sure the script handles added and removed files, probably you
must explicitly call bzr add|rm.



>         grep ^Subject: $i | sed 's/^Subject: \[PATCH\] //' > /tmp/msg.$$
>
>         perl -ne 'print if /^$/ .. /^---/;' $i | \
>           perl -ne 'print unless /^---/ .. eof()' | \
>           tail +2 >> /tmp/msg.$$

tail -n +2



>         bzr commit -F /tmp/msg.$$

I think it is desiderable to keep the original author and commit time as
well.


Cheers,
Giuseppe

Re: Using Git to manage your Emacs changes

[Thierry Volpiatto]

Why not using a stack of patchs like stgit or mercurial qpatchs.
You can then apply these patchs to bzr repo.

Giuseppe Scrivano <gscrivano@gnu.org> writes:

> I have some notes on your script:
>
> John Wiegley <jwiegley@gmail.com> writes:
>
>> git checkout ${1:-upstream}
>> git format-patch ..master
>>
>> for i in [0-9]*.patch; do
>>         echo Applying $i
>>
>>         patch -p1 < $i
>
> I am not sure the script handles added and removed files, probably you
> must explicitly call bzr add|rm.
>
>
>
>>         grep ^Subject: $i | sed 's/^Subject: \[PATCH\] //' > /tmp/msg.$$
>>
>>         perl -ne 'print if /^$/ .. /^---/;' $i | \
>>           perl -ne 'print unless /^---/ .. eof()' | \
>>           tail +2 >> /tmp/msg.$$
>
> tail -n +2
>
>
>
>>         bzr commit -F /tmp/msg.$$
>
> I think it is desiderable to keep the original author and commit time as
> well.
>
>
> Cheers,
> Giuseppe
>
>
>
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: Using Git to manage your Emacs changes

[John Wiegley]

On Apr 7, 2010, at 4:37 PM, Thierry Volpiatto wrote:

> Why not using a stack of patchs like stgit or mercurial qpatchs.
> You can then apply these patchs to bzr repo.

I don't see how stgit improves anything.  Also, I'm using git-bzr because I need to fetch the mirrored commits back into Git immediately after pushing, and I'm not sure how often the GitHub emacs mirror updates itself.

John

Re: Using Git to manage your Emacs changes

[Jonas Bernoulli]

On Fri, Apr 9, 2010 at 00:27, John Wiegley
> I'm not sure how often the GitHub emacs mirror updates itself.

If you are talking about http://github.com/emacsmirror/emacs:
Less often than http://repo.or.cz/w/emacs.git.

I simply pull the changes from or.cz and push to github.com.
Usually I do that daily or more often but sometimes I miss a day.

-- Jonas

Re: Using Git to manage your Emacs changes

[Thierry Volpiatto]

John Wiegley <jwiegley@gmail.com> writes:

> On Apr 7, 2010, at 4:37 PM, Thierry Volpiatto wrote:
>
>> Why not using a stack of patchs like stgit or mercurial qpatchs.
>> You can then apply these patchs to bzr repo.
>
> I don't see how stgit improves anything.  Also, I'm using git-bzr
> because I need to fetch the mirrored commits back into Git immediately
> after pushing, and I'm not sure how often the GitHub emacs mirror
> updates itself.

I use http://repo.or.cz/w/emacs.git

This repo is converted to a hg repo locally.
I have cloned this hg repo to another hg repo that handle qpatchs.
So i have three repos:

git, hg, hg qpatch.

1) on git repo: git pull

2) on hg repo: hg convert <last git revision>
   (when the repo exists, hg convert is as fast as a pull)

3) on hg qpatch repo: hg pull

4) make some new patchs on hg qpatch repo (i use DVC and
anything-mercurial.el)

5) Then you can send patchs to Emacs or apply these patchs to bzr repo
directly.(your patchs have to be in git format)

The same can be done with stg.(with only 2 repo)






-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/

Re: Using Git to manage your Emacs changes

[Ken Raeburn]

On Apr 7, 2010, at 15:23, John Wiegley wrote:
> If anyone here is like me and can't stand Bzr's interface/lack-of-speed due to comfort with Git, there is a *somewhat* more palatable solution:

Thanks!

> 1. Install git-bzr (http://github.com/pieter/git-bzr).  Make sure it works by
>    testing on some very small project from someplace.

Is this currently the best version to use?  There are other versions at github, perhaps some are better maintained.

> 2. Do a bzr checkout of Emacs.  DO NOT use git-bzr to directly checkout the
>    Emacs tree.  It will take days and days and download over 20G of data.
> 
> 3. Using git-bzr, point it at your local bzr checkout so it can do a fully local
>    translation of the Bzr commits to Git commits.  This will take several hours,
>    but not hog network bandwidth.

> 5. Now here's the tricky part.  Move your .git directory from your git-bzr checkout
>    over into your Bzr working tree.  Yes, we want Bzr and Git to manage the same
>    tree.  You should be wearing your Depends; this is not for the faint of heart.

These (#2,#3,#5) sound like things that git-bzr could simply be updated to do this way.  Well, maybe not the last step, exactly, but can you move the bzr info into a git checkout instead?  Or, to keep it looking more like a clean git tree, at the cost of more disk space, bury the bzr info under .git/ and apply the patches in a separate copy there.  (That would also avoid the need for a clean tree at the start, since you wouldn't clobber your git working copy.)

> 7. Sadly, git-bzr is sufficiently broken that you will not be able to push your
>    changes with "git bzr push upstream", as the docs indicate.  Instead, we have
>    to use "git format-patch" and then turn each patch into a Bzr commit manually,
>    which get pushed with "bzr push".  Once pushed, "git bzr pull upstream" reflects
>    that new commit back in Git:

Again, it looks like a straightforward enough, programmatic change that git-bzr could be fixed to just do it.  Kind of a shame about the rebasing requirement, if someone's got local branches; why is it needed?  Is this process unable to push content or commit info into bzr in a way that matches the git version?

What happens at this point if there's a conflict with newer upstream changes?  (I.e., which command fails?  Will your script recover or blindly charge ahead?  Do you need any special commands to keep things in sync in that case?)

Ken