Git to Bzr - what works?

Git to Bzr - what works?

[Daniel Colascione]

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

I have a bunch of patches locked up in my git mirror of the Emacs trunk. I'd
like to commit some of them, and that involves pushing these patches to a bzr
branch before pushing them to the main repository. But I can't the patches out
of git. I can't find any working git-to-bzr packages that work with the Emacs
trunk. The wiki suggests git-bzr, but both git-bzr and git-bzr-ng both complain
(via git-fast-import) about missing committer records. Does anyone have a
working bidirectional git setup?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Git to Bzr - what works?

[John Wiegley]

>>>>> Daniel Colascione <dancol@dancol.org> writes:

> I have a bunch of patches locked up in my git mirror of the Emacs trunk. I'd
> like to commit some of them, and that involves pushing these patches to a
> bzr branch before pushing them to the main repository. But I can't the
> patches out of git. I can't find any working git-to-bzr packages that work
> with the Emacs trunk. The wiki suggests git-bzr, but both git-bzr and
> git-bzr-ng both complain (via git-fast-import) about missing committer
> records. Does anyone have a working bidirectional git setup?

I have never succeeded in getting anything to work, just FYI, and I've tried
several different things.  If you can figure out something, please let me
know, because it impairs my ability to contribute upstream as well.

John

Re: Git to Bzr - what works?

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Tue, 14 Aug 2012 12:54:17 -0500
> 
> >>>>> Daniel Colascione <dancol@dancol.org> writes:
> 
> > I have a bunch of patches locked up in my git mirror of the Emacs trunk. I'd
> > like to commit some of them, and that involves pushing these patches to a
> > bzr branch before pushing them to the main repository. But I can't the
> > patches out of git. I can't find any working git-to-bzr packages that work
> > with the Emacs trunk. The wiki suggests git-bzr, but both git-bzr and
> > git-bzr-ng both complain (via git-fast-import) about missing committer
> > records. Does anyone have a working bidirectional git setup?
> 
> I have never succeeded in getting anything to work, just FYI, and I've tried
> several different things.  If you can figure out something, please let me
> know, because it impairs my ability to contribute upstream as well.

I don't understand the problem.  What's wrong with generating diffs
from the git repo and then applying them to the bzr repo?

Re: Git to Bzr - what works?

[BT Templeton]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "John Wiegley" <johnw@newartisans.com>
>> Date: Tue, 14 Aug 2012 12:54:17 -0500
>> 
>> >>>>> Daniel Colascione <dancol@dancol.org> writes:
>> 
>> > I have a bunch of patches locked up in my git mirror of the Emacs trunk. I'd
>> > like to commit some of them, and that involves pushing these patches to a
>> > bzr branch before pushing them to the main repository. But I can't the
>> > patches out of git. I can't find any working git-to-bzr packages that work
>> > with the Emacs trunk. The wiki suggests git-bzr, but both git-bzr and
>> > git-bzr-ng both complain (via git-fast-import) about missing committer
>> > records. Does anyone have a working bidirectional git setup?
>> 
>> I have never succeeded in getting anything to work, just FYI, and I've tried
>> several different things.  If you can figure out something, please let me
>> know, because it impairs my ability to contribute upstream as well.
>
> I don't understand the problem.  What's wrong with generating diffs
> from the git repo and then applying them to the bzr repo?

You'd lose the commit metadata. AFAICT generating fastimport files is
currently the only reasonable way to move commits between git and bzr
without losing (much) information.

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

Re: Git to Bzr - what works?

[Eli Zaretskii]

> From: BT Templeton <bpt@hcoop.net>
> Date: Tue, 14 Aug 2012 15:56:06 -0400
> 
> > I don't understand the problem.  What's wrong with generating diffs
> > from the git repo and then applying them to the bzr repo?
> 
> You'd lose the commit metadata. AFAICT generating fastimport files is
> currently the only reasonable way to move commits between git and bzr
> without losing (much) information.

But fastimport doesn't quite work, does it?  So in practice, it isn't
a solution, either.

Did someone try to merge from git repository to bzr repository using
the bzr-git plugin?

Re: Git to Bzr - what works?

[Fabian Ezequiel Gallina]

2012/8/14 Eli Zaretskii <eliz@gnu.org>:
>
> But fastimport doesn't quite work, does it?  So in practice, it isn't
> a solution, either.
>
> Did someone try to merge from git repository to bzr repository using
> the bzr-git plugin?
>

That's exactly how I merged python.el from github to the bzr repo.

I generated the patches from git repo with git format-patch, modified
paths in patch files with sed to match Emacs file structure, and then
used bzr git-apply with no problems, except for the fact that I had to
create a commit adding a blank lisp/progmodes/python.el after deleting
the old one in order for bzr git-apply to apply patches successfully.


Regards,
Fabián

Re: Git to Bzr - what works?

[Stephen J. Turnbull]

Fabian Ezequiel Gallina writes:

 > I generated the patches from git repo with git format-patch, modified
 > paths in patch files with sed to match Emacs file structure, and then
 > used bzr git-apply with no problems, except

This sounds reasonable (it should be unnecessary, but one can script
what Bazaar didn't think necessary to do), but

 > for the fact that I had to create a commit adding a blank
 > lisp/progmodes/python.el after deleting the old one in order for
 > bzr git-apply to apply patches successfully.

IMO, this is hardly a "no problems, except" problem.  This is a
show-stopper, unacceptable even the worker doesn't mind doing it by
hand.  This makes the "blame" command useless for investigating the
provenance of any code that appears in the deleted-readded file.  You
might get by with this in other projects, but Emacs cares greatly
about such issues for legal reasons.

It also makes one wonder about Bazaar, but that's a whole other issue.

Steve

Re: Git to Bzr - what works?

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand the problem.  What's wrong with generating diffs from the
> git repo and then applying them to the bzr repo?

Try it for a while.  Then come talk to me.

John

Re: Git to Bzr - what works?

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Wed, 15 Aug 2012 12:22:37 -0500
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't understand the problem.  What's wrong with generating diffs from the
> > git repo and then applying them to the bzr repo?
> 
> Try it for a while.  Then come talk to me.

I was trying to help, actually.

Re: Git to Bzr - what works?

[Eli Zaretskii]

> Date: Wed, 15 Aug 2012 00:08:16 -0300
> From: Fabian Ezequiel Gallina <galli.87@gmail.com>
> Cc: BT Templeton <bpt@hcoop.net>, emacs-devel@gnu.org
> 
> 2012/8/14 Eli Zaretskii <eliz@gnu.org>:
> >
> > But fastimport doesn't quite work, does it?  So in practice, it isn't
> > a solution, either.
> >
> > Did someone try to merge from git repository to bzr repository using
> > the bzr-git plugin?
> >
> 
> That's exactly how I merged python.el from github to the bzr repo.
> 
> I generated the patches from git repo with git format-patch, modified
> paths in patch files with sed to match Emacs file structure, and then
> used bzr git-apply with no problems, except for the fact that I had to
> create a commit adding a blank lisp/progmodes/python.el after deleting
> the old one in order for bzr git-apply to apply patches successfully.

That's not what I had in mind.  But since yours is a real-life
experience, while my idea is a purely theoretical one, perhaps what I
say below is much less important.

What I had in mind was this:

 . Use bzr-git to make a bzr branch out of the git repo.  (This part
   does work, I'm successfully tracking several projects that use git
   this way.)

 . When you have changes in the bzr repo:

    . "bzr pull" from the git repo to the bzr branch created above

    . "bzr merge" to another bzr branch that tracks the Emacs trunk

    . "bzr ci" or "bzr push" (depending on whether the latter branch
      is or isn't bound) to the master bzr repo

Again, I never tried this, so it might not work at all.

If the above works, one could try pushing directly from the bzr branch
created from git, thus avoiding another branch and another merge.

Re: Git to Bzr - what works?

[Stefan Monnier]

>  . When you have changes in the bzr repo:
>     . "bzr pull" from the git repo to the bzr branch created above

But his Git repository is the result of a "Bzr->Git" conversion.
So we'd get here a "Bzr->Git->Bzr" conversion.  I strongly suspect that
it is not an identity and that all the revids will be different.

>     . "bzr merge" to another bzr branch that tracks the Emacs trunk

If indeed all the revids are different, this will either complain that
there's no common ancestor (best case) or find some distant ancestor and
pretty much double the size of the repository with a new copy of the
whole history.

This said, I don't understand the problem discussed here.
Isn't "git-bzr" bidirectional (i.e. you can "git push" onto the Bzr
repository)?


        Stefan

Re: Git to Bzr - what works?

[Daniel Colascione]

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

On 8/15/12 1:45 PM, Stefan Monnier wrote:
>>  . When you have changes in the bzr repo:
>>     . "bzr pull" from the git repo to the bzr branch created above
> 
> But his Git repository is the result of a "Bzr->Git" conversion.
> So we'd get here a "Bzr->Git->Bzr" conversion.  I strongly suspect that
> it is not an identity and that all the revids will be different.

I tried cloning a local git mirror (derived from the Savannah git
mirorr) using bzr-git. It's even slower than git-bzr. It's used 23
miutes of CPU time and processed 8315 of 122105 records.

>>     . "bzr merge" to another bzr branch that tracks the Emacs trunk
> 
> If indeed all the revids are different, this will either complain that
> there's no common ancestor (best case) or find some distant ancestor and
> pretty much double the size of the repository with a new copy of the
> whole history.
> 
> This said, I don't understand the problem discussed here.
> Isn't "git-bzr" bidirectional (i.e. you can "git push" onto the Bzr
> repository)?

git-bzr would be great if it worked, but it doesn't work for me. After
chugging along for about an hour, it fails and complains about a
missing committer record.

How is the Savannah git mirror being generated? Matching its revids
would be the most important part of any bidirectional mirriroing
scheme. If Savannah is using git-bzr, I'd like to know the versions of
the pieces of software involved and whether the Savannah people made
any local modifications.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Git to Bzr - what works?

[Eli Zaretskii]

> Date: Wed, 15 Aug 2012 16:49:28 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: Eli Zaretskii <eliz@gnu.org>, bpt@hcoop.net, emacs-devel@gnu.org, 
>  Fabian Ezequiel Gallina <galli.87@gmail.com>
> 
> I tried cloning a local git mirror (derived from the Savannah git
> mirorr) using bzr-git. It's even slower than git-bzr. It's used 23
> miutes of CPU time and processed 8315 of 122105 records.

This is a one-time issue.  Subsequent pulls are faster.

Re: Git to Bzr - what works?

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> > I don't understand the problem.  What's wrong with generating diffs from the
>> > git repo and then applying them to the bzr repo?
>> 
>> Try it for a while.  Then come talk to me.

> I was trying to help, actually.

Sorry, it's been one of those days.

When I've hand-patched my changes over from Git to Bzr, it has often happened
to me that I can't do it fast enough before some other Bzr change comes down
the pipe.  Then I try to do a merge, but merging in Bzr makes no sense to me
(yet), so I fail miserably and start the process over.  Once I had to do this
3 times before I could get the commit in.

The problem for me is, I have no other use for Bazaar, and my brain is too
full to try and master another VCS to the extent of being fluent enough not to
be bothered by things like this, so instead I just keep my changes local.

It's an inertia thing, really.  I could find a solution to my problem, I'm
just not motivated to.  In fact, I'm anti-motivated each time I try to touch
Bzr, and it's *just* weird enough from a Git standpoint to cause me problems.

Like when I commit, and the commit goes straight to remote (wait!  I wanted to
push that with other commits!).  Or I set the up indirection, and find later
that my push pushed to a local directory instead of remote (what?  you didn't
get my change?  I just pushed it!).  Etc.

John

Re: Git to Bzr - what works?

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> I tried cloning a local git mirror (derived from the Savannah git
>> mirorr) using bzr-git. It's even slower than git-bzr. It's used 23
>> miutes of CPU time and processed 8315 of 122105 records.

> This is a one-time issue.  Subsequent pulls are faster.

Yeah, I've had full git-bzr clones take around 10 hours.  It gets slower as it
goes, too.

But you won't be able to push with it.  Trying gets me an exception within
the export process.

John

Re: Git to Bzr - what works?

[Óscar Fuentes]

John Wiegley <johnw@newartisans.com> writes:

> When I've hand-patched my changes over from Git to Bzr, it has often
> happened to me that I can't do it fast enough before some other Bzr
> change comes down the pipe.  Then I try to do a merge, but merging in
> Bzr makes no sense to me (yet), so I fail miserably and start the
> process over.  Once I had to do this 3 times before I could get the
> commit in.

You can try `bzr rebase' instead, part of the `rewrite' plugin:

http://wiki.bazaar.canonical.com/Rewrite/

`bzr rebase' is very basic, but it should be enough for avoiding `merge'
on your case.

[snip]

> Like when I commit, and the commit goes straight to remote (wait!  I wanted to
> push that with other commits!).

Don't use a bound branch, then. Commit your changes and push. If pushing
fails because upstream's history now contains new revisions, rebase and
push again.

[snip]

Re: Git to Bzr - what works?

[Julien Danjou]

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

On Thu, Aug 16 2012, Daniel Colascione wrote:

> git-bzr would be great if it worked, but it doesn't work for me. After
> chugging along for about an hour, it fails and complains about a
> missing committer record.

git-bzr-ng¹ works well for me. Push does not work because of bzr bug
#541626² that nobody ever wanted to fix.

(Which doesn't help making me having a good opinion on bzr.)

¹  http://github.com/termie/git-bzr-ng

²  https://bugs.launchpad.net/bzr/+bug/541626

-- 
Julien Danjou
;; Free Software hacker & freelance
;; http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Git to Bzr - what works?

[Andreas Schwab]

Julien Danjou <julien@danjou.info> writes:

> git-bzr-ng¹ works well for me. Push does not work because of bzr bug
> #541626² that nobody ever wanted to fix.

You can use bzr-fastimport from
<http://bazaar.launchpad.net/~schwab-linux-m68k/bzr-fastimport/master/>
instead, which is based on a still working older version plus some
pending bug fixes.

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: Git to Bzr - what works?

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Wed, 15 Aug 2012 22:18:46 -0500
> 
> It's an inertia thing, really.  I could find a solution to my problem, I'm
> just not motivated to.  In fact, I'm anti-motivated each time I try to touch
> Bzr, and it's *just* weird enough from a Git standpoint to cause me problems.
> 
> Like when I commit, and the commit goes straight to remote (wait!  I wanted to
> push that with other commits!).  Or I set the up indirection, and find later
> that my push pushed to a local directory instead of remote (what?  you didn't
> get my change?  I just pushed it!).  Etc.

I think you will be much better off using Oscar's advice: using a
non-bound bzr branch where you can commit locally at will and push
upstream only when you decide to do so.  That should allow you a
workflow that is largely mechanic and does not require to rewire your
brain for bzr.

Re: Git to Bzr - what works?

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Wed, 15 Aug 2012 22:19:59 -0500
> 
> But you won't be able to push with [bzr-git].  Trying gets me an
> exception within the export process.

That's because push is not yet supported.  But dpush should work.

Re: Git to Bzr - what works?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 16 Aug 2012 05:42:34 +0200
> 
> You can try `bzr rebase' instead, part of the `rewrite' plugin:
> 
> http://wiki.bazaar.canonical.com/Rewrite/

In many (most? all?) current distributions of bzr, rewrite is
bundled.  So before downloading a potentially incompatible version, it
is best to make sure you don't already have it.

Re: Git to Bzr - what works?

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I think you will be much better off using Oscar's advice: using a non-bound
> bzr branch where you can commit locally at will and push upstream only when
> you decide to do so.  That should allow you a workflow that is largely
> mechanic and does not require to rewire your brain for bzr.

What commands should I run at terminal to create this probably unbound branch?

John

Re: Git to Bzr - what works?

[Daniel Colascione]

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

On 8/16/2012 5:09 AM, Andreas Schwab wrote:
> Julien Danjou <julien@danjou.info> writes:
> 
>> git-bzr-ng¹ works well for me. Push does not work because of bzr bug
>> #541626² that nobody ever wanted to fix.
> 
> You can use bzr-fastimport from
> <http://bazaar.launchpad.net/~schwab-linux-m68k/bzr-fastimport/master/>
> instead, which is based on a still working older version plus some
> pending bug fixes.

I tried using git-bzr-ng along with Adnreas's bzr-fastimport branch. After
several hours, the git bzr clone operation failed because it managed to use all
17GB of disk space available on my VM.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Git to Bzr - what works?

[Stefan Monnier]

> You can try `bzr rebase' instead, part of the `rewrite' plugin:

FWIW, I've had no end of trouble with it.  It's clearly not nearly as
robust as the rest of Bzr.


        Stefan

Re: Git to Bzr - what works?

[Daniel Colascione]

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

On 8/16/2012 8:30 PM, Stefan Monnier wrote:
>> You can try `bzr rebase' instead, part of the `rewrite' plugin:
> 
> FWIW, I've had no end of trouble with it.  It's clearly not nearly as
> robust as the rest of Bzr.

bzr rebase also doesn't support interactive rebasing. Interactive rebasing is
great for maintaining a patch set; it lets you squash patches together, change
patch descriptions, incorporate later fixes into earlier patches, and keep up to
date with changes to the underlying tree.

bzr doesn't have anything comparable. There's bzr loom, but after reading its
documentation, I think it's awkward compared to git's interactive rebasing ---
loom has special commands, while rebasing works with regular commit, merge, and
branch operations.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Git to Bzr - what works?

[Eli Zaretskii]

> Date: Thu, 16 Aug 2012 21:02:48 -0700
> From: Daniel Colascione <dancol@dancol.org>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> bzr rebase also doesn't support interactive rebasing. Interactive rebasing is
> great for maintaining a patch set; it lets you squash patches together, change
> patch descriptions, incorporate later fixes into earlier patches, and keep up to
> date with changes to the underlying tree.

Did you try to use "bzr shelve" to shelve some of the changes?  That
command is interactive.

Re: Git to Bzr - what works?

[Eli Zaretskii]

> From: John Wiegley <johnw@newartisans.com>
> Date: Thu, 16 Aug 2012 17:12:26 -0500
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think you will be much better off using Oscar's advice: using a non-bound
> > bzr branch where you can commit locally at will and push upstream only when
> > you decide to do so.  That should allow you a workflow that is largely
> > mechanic and does not require to rewire your brain for bzr.
> 
> What commands should I run at terminal to create this probably unbound branch?

If you have a Savannah user name:

  bzr branch bzr+ssh://eliz@bzr.savannah.gnu.org/emacs/trunk/

If you don't:

  bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk

If you already have a bound branch, you can either create a local
branch from it:

  cd /path/to/emacs/trunk/..
  bzr branch emacs-local

(then do most of your work in emacs-local and push from there) or
simply unbind the bound branch:

  cd /path/to/emacs/trunk
  bzr unbind

The last two are much faster than the other two, because an initial
branch pulls the entire history of the development through the wire.

I think having a local branch in addition to the bound branch is
better, as you get to benefit from both of the worlds.  So the 3rd
command above is what I'd recommend.

Re: Git to Bzr - what works?

[Daniel Colascione]

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

On 8/16/12 7:27 PM, Daniel Colascione wrote:
> On 8/16/2012 5:09 AM, Andreas Schwab wrote:
>> Julien Danjou <julien@danjou.info> writes:
>>
>>> git-bzr-ng¹ works well for me. Push does not work because of bzr bug
>>> #541626² that nobody ever wanted to fix.
>>
>> You can use bzr-fastimport from
>> <http://bazaar.launchpad.net/~schwab-linux-m68k/bzr-fastimport/master/>
>> instead, which is based on a still working older version plus some
>> pending bug fixes.
> 
> I tried using git-bzr-ng along with Adnreas's bzr-fastimport branch. After
> several hours, the git bzr clone operation failed because it managed to use all
> 17GB of disk space available on my VM.
> 

On a different machine, I let git bzr run for a while. After chewing
through about 50GB of disk space, the import process failed with this
error:

python(60661) malloc: *** mmap(size=140780772814848) failed (error
code=12)
*** error: can't allocate region

Even the most heroic of memory managers won't honor a request for 140
terabytes.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Git to Bzr - what works?

[Stephen J. Turnbull]

Daniel Colascione writes:

 > bzr doesn't have anything comparable.

True.  Sad, but Emacs is unlikely to switch again in the lifetime of
your current feature branches, right?

 > There's bzr loom, but after reading its documentation, I think it's
 > awkward compared to git's interactive rebasing --- loom has special
 > commands, while rebasing works with regular commit, merge, and
 > branch operations.

In some sense it's awkward, but this is a style difference, based in
the notion that one should never change the presentation of history.
So loom actually (AIUI, which is LSI-element-deep :) implements a
restricted rebase and/or colocated branching that allows you to know
the actual temporal history of changes (at least as long as the loom
is in effect).

loom is probably among the most solid bzr plugins.  Robert Collins is
the bzr dev who's least dogmatic about this stuff (though he is as big
a fan of the Bazaar Way as any of them).  So you may never learn to
love loom but if it serves your purpose, it may be the best way to
work in bzr.  And I doubt it will break on you.

The other possibility is to use Aaron Bentley's pipeline plugin, which
is like Mercurial queues.  Again, not comparable to git rebase, but it
might serve your purpose better than trying to bidirectionally sync a
local git repo.  Aaron can be bzr-dogmatic, but his code is solid, and
the idea of pipelines is very straightforward.  The dogma isn't going
to bite you unexpectedly, all the restrictions are printed on the
wrapper. :-)

Steve

Re: Git to Bzr - what works?

[Richard Stallman]

    FWIW, I've had no end of trouble with it.  It's clearly not nearly as
    robust as the rest of Bzr.

Have you reported the bugs?

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Git to Bzr - what works?

[Stefan Monnier]

> Even the most heroic of memory managers won't honor a request for 140
> terabytes.

Come on, just buy more ram and stop complaining,
Sheesh,


        Stefan

Re: Git to Bzr - what works?

[Ted Zlatanov]

On Wed, 15 Aug 2012 22:18:46 -0500 John Wiegley <johnw@newartisans.com> wrote: 

JW> The problem for me is, I have no other use for Bazaar, and my brain is too
JW> full to try and master another VCS to the extent of being fluent enough not to
JW> be bothered by things like this, so instead I just keep my changes local.

JW> It's an inertia thing, really.  I could find a solution to my problem, I'm
JW> just not motivated to.  In fact, I'm anti-motivated each time I try to touch
JW> Bzr, and it's *just* weird enough from a Git standpoint to cause me problems.

JW> Like when I commit, and the commit goes straight to remote (wait!  I wanted to
JW> push that with other commits!).  Or I set the up indirection, and find later
JW> that my push pushed to a local directory instead of remote (what?  you didn't
JW> get my change?  I just pushed it!).  Etc.

I have had similar experiences.  I would conservatively estimate it cost
me 40 man-hours to work with Bazaar instead of Git when I was doing the
GnuTLS integration.  I lost work several times!  Perhaps I'm an idiot
unable to grasp the subtleties of Bazaar, but I think the *cost* of
using Bazaar to casual contributors like me should be considered.

(asbestos underwear on, preparing underground bunker, etc.)

If a technical solution must be had (and I don't think that this is a
techical problem), let's do it at the origin, providing Git and Bazaar
repositories that synchronize.  Hire/find a person to do it.  Their time
will be spent developing synchronization tools and procedures so the
rest of us won't have to.  Let's not push that pain out to the
contributors in the form of plugins and walkthroughs.

Sincerely
Ted

Re: Git to Bzr - what works?

[Karl Fogel]

Ted Zlatanov <tzz@lifelogs.com> writes:
>I have had similar experiences.  I would conservatively estimate it cost
>me 40 man-hours to work with Bazaar instead of Git when I was doing the
>GnuTLS integration.  I lost work several times!  Perhaps I'm an idiot
>unable to grasp the subtleties of Bazaar, but I think the *cost* of
>using Bazaar to casual contributors like me should be considered.
>
>(asbestos underwear on, preparing underground bunker, etc.)
>
>If a technical solution must be had (and I don't think that this is a
>techical problem), let's do it at the origin, providing Git and Bazaar
>repositories that synchronize.  Hire/find a person to do it.  Their time
>will be spent developing synchronization tools and procedures so the
>rest of us won't have to.  Let's not push that pain out to the
>contributors in the form of plugins and walkthroughs.

I agree, and think there are other casual contributors and minor
maintainers here who agree.  This has not led to any change in the
Bzr-primary policy, but little reminders of it are useful from time to
time because otherwise the issue would look quiescent when it's not.

I will continue to use Bzr here as long as necessary, but it definitely
slows down the rate at which I can do Emacs work.

Re: Git to Bzr - what works?

[Xue Fuqiao]

On Fri, 21 Dec 2012 10:05:44 -0500
Ted Zlatanov <tzz@lifelogs.com> wrote:

> I would conservatively estimate it cost
> me 40 man-hours to work with Bazaar instead of Git when I was doing the
> GnuTLS integration.  I lost work several times!  Perhaps I'm an idiot
> unable to grasp the subtleties of Bazaar, but I think the *cost* of
> using Bazaar to casual contributors like me should be considered.

I also have had similar experiences, such as confused with `bzr pull', `bzr update' and `bzr merge', didn't know how to move uncommitted changes from one tree to another and so on.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: Git to Bzr - what works?

[Bastien]

Karl Fogel <kfogel@red-bean.com> writes:

> I agree, and think there are other casual contributors and minor
> maintainers here who agree.  

FWIW I do.

If FSF cannot have someone to do the work Ted describes, 
maybe this could be a nice GSoC project for 2013?

-- 
 Bastien

Re: Git to Bzr - what works?

[Juri Linkov]

> didn't know how to move uncommitted changes from one tree to another

1. Open vc-dir with `C-x v d'
2. Select files and type `='
3. Remove unnecessary changes with `M-k'
4. Move uncommitted changes to another tree with `M-x ediff-patch-file RET'
5. Commit moved changes in another tree.

Re: Git to Bzr - what works?

[Stephen J. Turnbull]

Bastien writes:

 > If FSF cannot have someone to do the work Ted describes, 
 > maybe this could be a nice GSoC project for 2013?

It's not a GSoC project.  Many man-months have been spent on the
problem (Lele Gaifax's Tailor, work by the Bazaar developers, plus
work by the various projects on making the git-import format more
generic), and there's no satisfactory solution yet.  It might be
somewhat easier with a specific pair in mind, but there's good reason
to believe that Bazaar is the most difficult because of its much
richer metadata (including tracking both directories and few
"containers").

I dunno, guys.  I like Bazaar as little as anybody (I was the git
advocate for Python's PEP 374, I was one of the strong advocates for
git when Emacs decided to move), but I really haven't had that much
difficulty working with it in the few projects I work on that require
it.  The patterns for working with Emacs seem to be rather few and
uncomplicated.  People who like to commit directly to trunk keep a
checkout, and people who like to work on branches use the more
elaborate setup that Karl set out in BzrForEmacsDevs.  If you don't
like the bzr terminology (I don't, but they do have some claim to
using many of the terms like "pull" first), it's not terribly hard to
set up a set of aliases that does the simple work.

Re: Git to Bzr - what works?

[Stephen J. Turnbull]

Stephen J. Turnbull writes:

 > there's good reason
 > to believe that Bazaar is the most difficult because of its much
 > richer metadata (including tracking both directories and few
 > "containers").

Erp, that should be "file", not "few".

Re: Git to Bzr - what works?

[Bastien]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> I dunno, guys.  I like Bazaar as little as anybody (I was the git
> advocate for Python's PEP 374, I was one of the strong advocates for
> git when Emacs decided to move), but I really haven't had that much
> difficulty working with it in the few projects I work on that require
> it.  The patterns for working with Emacs seem to be rather few and
> uncomplicated.  People who like to commit directly to trunk keep a
> checkout, and people who like to work on branches use the more
> elaborate setup that Karl set out in BzrForEmacsDevs.  If you don't
> like the bzr terminology (I don't, but they do have some claim to
> using many of the terms like "pull" first), it's not terribly hard to
> set up a set of aliases that does the simple work.

I don't really think it's a matter of terminology.

I think bzr is okay when you are working directly in Emacs,
but that's a few of us, and generally for small patches.  

In the end, I respect the choice of the maintainers, because
I don't see anyone else able to do their job.  As a maintainer
myself for Org, I respect that.  But keeping in mind that the
choice of bzr doesn't please many (potential) contributors is
good too IMHO.

-- 
 Bastien

Re: Git to Bzr - what works?

[Xue Fuqiao]

Although Bazaar makes me confused sometimes, it has a large number of add-ons and associated tools that makes Bazaar easier to use, like bzr-gtk, qbzr, explorer, loggerhead and so on.  And Bazaar identify revisions using sequential numbers per branch, not hash strings, I think it is intuitive.

Unlike Git, Bazaar and Mercurial(which XEmacs uses) won’t implicitly commit for you just because a merge appeared to work. After merging in Bazaar, you can always run your automated tests and confirm they pass before committing.

-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: Git to Bzr - what works?

[Juanma Barranquero]

> Unlike Git, Bazaar and Mercurial(which XEmacs uses) won’t implicitly commit for you just because a merge appeared to work.

Of course, you can always create an alias for "git merge --no-commit".

    Juanma

Re: Git to Bzr - what works?

[Xue Fuqiao]

Furthermore, most Bazaar command take a revision number in parameter. For example, to get back 2 versions earlier, it is enough to write:
  bzr revert -r -2 file

The git equivalent is more cryptic:
  bzr checkout HEAD~2 file
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: Git to Bzr - what works?

[Andreas Schwab]

Xue Fuqiao <xfq.free@gmail.com> writes:

> After merging in Bazaar, you can always run your automated tests and
> confirm they pass before committing.

You can always amend if the merge did something wrong.

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: Git to Bzr - what works?

[Andreas Schwab]

Xue Fuqiao <xfq.free@gmail.com> writes:

> Furthermore, most Bazaar command take a revision number in parameter. For example, to get back 2 versions earlier, it is enough to write:
>   bzr revert -r -2 file

If you don't know what -2 means it's just as cryptic.

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: Git to Bzr - what works?

[Thomas Koch]

Ted Zlatanov:
> I have had similar experiences.  I would conservatively estimate it cost
> me 40 man-hours to work with Bazaar instead of Git when I was doing the
> GnuTLS integration.  I lost work several times!  Perhaps I'm an idiot
> unable to grasp the subtleties of Bazaar, but I think the *cost* of
> using Bazaar to casual contributors like me should be considered.

Just for the record. I'm just lurking on this mailing list and learning to use 
Emacs. But I don't think I'll consider contributing to emacs for two reasons:

- I don't want to invest in learning Bzr. I haven't liked it before and this 
blogpost[1] seems to confirm that Bzr has no bright future.

[1] http://stationary-traveller.eu/pages/bzr-a-retrospective.html

- It unsettles me that the emacs team seems to continue to use an inferior 
tool for reasons of politics instead of using the best available tool.

Both reasons are of course highly subjective and controversial. I just wanted 
to give the perspective of somebody who is reserved because of bzr.

Best regards,

Thomas Koch, http://www.koch.ro

Re: Git to Bzr - what works?

[Thien-Thi Nguyen]

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

() Thomas Koch <thomas@koch.ro>
() Sat, 22 Dec 2012 18:04:56 +0100

   - It unsettles me that the emacs team seems to continue to use an
   inferior tool for reasons of politics instead of using the best
   available tool.

That's good.  So what do you do to convert this feeling into action?

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Git to Bzr - what works?

[Ted Zlatanov]

On Sat, 22 Dec 2012 18:28:38 +0100 Thien-Thi Nguyen <ttn@gnuvola.org> wrote: 

TN> () Thomas Koch <thomas@koch.ro>
TN> () Sat, 22 Dec 2012 18:04:56 +0100

TN>    - It unsettles me that the emacs team seems to continue to use an
TN>    inferior tool for reasons of politics instead of using the best
TN>    available tool.

TN> That's good.  So what do you do to convert this feeling into action?

I think you're asking the wrong person the wrong question.

Ted

Re: Git to Bzr - what works?

[Ted Zlatanov]

On Sat, 22 Dec 2012 21:24:20 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Bastien writes:
>> If FSF cannot have someone to do the work Ted describes, 
>> maybe this could be a nice GSoC project for 2013?

SJT> It's not a GSoC project.  Many man-months have been spent on the
SJT> problem (Lele Gaifax's Tailor, work by the Bazaar developers, plus
SJT> work by the various projects on making the git-import format more
SJT> generic), and there's no satisfactory solution yet.  It might be
SJT> somewhat easier with a specific pair in mind, but there's good reason
SJT> to believe that Bazaar is the most difficult because of its much
SJT> richer metadata (including tracking both directories and few
SJT> "containers").

I really think it's a job, not a technical problem to be solved.

Katsumi Yamaoka does it for Gnus.  He has good procedures in place for
synchronizing Gnus' Git repo with Emacs' Bazaar repo.

Ted

Re: Git to Bzr - what works?

[Thien-Thi Nguyen]

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

() Ted Zlatanov <tzz@lifelogs.com>
() Sat, 22 Dec 2012 14:06:45 -0500

   I think you're asking the wrong person the wrong question.

Well, it's happened before and it will undoubtedly happen again.

Why do you think that?  (<-- another instance?!)

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Git to Bzr - what works?

[Ted Zlatanov]

On Sat, 22 Dec 2012 18:28:38 +0100 Thien-Thi Nguyen <ttn@gnuvola.org> wrote: 
TN> () Thomas Koch <thomas@koch.ro>
TN> () Sat, 22 Dec 2012 18:04:56 +0100

TK> - It unsettles me that the emacs team seems to continue to use an
TK> inferior tool for reasons of politics instead of using the best
TK> available tool.

TN> That's good.  So what do you do to convert this feeling into action?

On Mon, 24 Dec 2012 06:56:31 +0100 Thien-Thi Nguyen <ttn@gnuvola.org> wrote: 

TN> () Ted Zlatanov <tzz@lifelogs.com>
TN> () Sat, 22 Dec 2012 14:06:45 -0500

TZ>    I think you're asking the wrong person the wrong question.

TN> Well, it's happened before and it will undoubtedly happen again.

(For you it's rare; for me it's a profession :)

TN> Why do you think that?  (<-- another instance?!)

I'm happy to answer:

You can't expect casual contributors to take up banners and arise.  They
have no history, experience, or significant stake in improving the
usability of Emacs' DVCS.

As far as I have those three, they lead me to keep pushing for Git, but
I must be considered a casual contributor with little influence on the
Emacs project.  Any change must come from gentle conviction at the Emacs
maintainer level and beyond (note I didn't say "above").

Ted

Re: Git to Bzr - what works?

[Thien-Thi Nguyen]

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

() Ted Zlatanov <tzz@lifelogs.com>
() Mon, 24 Dec 2012 08:31:43 -0500

   You can't expect casual contributors to take up banners and arise.

Right.  I expect nothing when i ask questions, generally.  The form and
content of any response (let me show you some of the hate mail i get
some time) is an opportunity for me to learn.  That's the selfish truth.

Another aspect of my questioning is the conceit that maybe by provoking
public discourse, the public mind will become more aware, and over time
reach some threshold where that translates to public action.

In this case, the "unsettling" feeling can be both +ve and -ve, and i
was (and am still) curious how (in what style) the OP surfs w/ it.

Personally, i predict Bazaar will wither and Someone will write a GPLv3+
Git workalike in Guile Scheme in the next year or so -- how hard can it
be?  Now, whether or not the situation w/ Emacs will change, i agree w/
you there -- only the maintainers (and beyond) can say for sure.

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Git to Bzr - what works?

[Bastien]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> Personally, i predict Bazaar will wither and Someone will write a GPLv3+
> Git workalike in Guile Scheme in the next year or so -- how hard can it
> be?

I predict this will be very hard.

First because this person will certainly be a huge fan of git 
(otherwise he would not care cloning it.)

Second because it will be hard to get the same performance in
Guile as Git gets in C.  And this guy will soon realize "Mh..
why do I do this?  Just for the sake of having a Git-like in
GPLv3+?"

In fact, I predict this guy does not exist :)

-- 
 Bastien