New sync'd branch

New sync'd branch

[Stefan Monnier]

We'd like to have a new release in the first half of next year with some
new features.  Given the short time, the new features need to be
non-intrusive, like new packages.

Until now, we've had 2 active branches: the EMACS_23_1 and the trunk,
where the first is limited to bugfixes (and mostly unused, really), and
the second is aiming to become the next release.

But two things make me think we should change this arrangement:
1- the desire and need to plan for Emacs-24: if we want to keep
   releasing regularly, we need to have 2 active branches, one for
   short-term localized improvements, and the other for longer
   term changes.
2- the fact that Emacs-23.1 seems not to suffer from any serious
   problems that would call for a quick new release from the
   EMACS_23_1 branch.

So I believe we should create a new branch EMACS_23 which will play the
role currently played by the trunk, so the trunk can now be open to more
experimental development (bidi, cpp->autoconf conversion, lexbind, ...),
targetted for Emacs-24.

There are some problem with this:
- Changes on the 23 branch need to be sync'd to the trunk.  As long as
  we haven't switched to Bzr, that means we need Miles to do the sync
  for us.  Miles, could you do that?
- People installing changes need to carefully choose whether to install
  it on the 23 branch (from where it will be sync'd to the "24 branch"
  aka "trunk"), or on the trunk.  Basically, the most important aspect
  is that any bugfix which makes sense on the 23 branch need to be
  installed on the 23 branch rather than on the trunk.
- The 23 branch will not see as much testing any more.  So we need to be
  more conservative on what can go there.  And we need to make
  a conscious effort to try and use the 23 branch on a regular basis.
  Maybe if the trunk is sufficiently unstable, this will not be
  too problematic.

What do you all think about this?


        Stefan

Re: New sync'd branch

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> What do you all think about this?

Working on what will become Emacs 24 seems very interesting and
worthwhile. Am I right to assume that those of us working with the git
mirror can continue to do so unaffected?

>
>
>         Stefan
>
-- 
Joakim Verona

Re: New sync'd branch

[Leo]

On 2009-08-23 23:35 +0100, joakim@verona.se wrote:
>> What do you all think about this?
>
> Working on what will become Emacs 24 seems very interesting and
> worthwhile. 

I am also excited about Emacs 24.

> Am I right to assume that those of us working with the git mirror can
> continue to do so unaffected?

-- 
Leo's Emacs uptime: 1 day, 19 hours, 30 minutes, 39 seconds

Re: New sync'd branch

[Dmitry Dzhus]

Stefan Monnier wrote:

> - People installing changes need to carefully choose whether to install
>   it on the 23 branch (from where it will be sync'd to the "24 branch"
>   aka "trunk"), or on the trunk.  Basically, the most important aspect
>   is that any bugfix which makes sense on the 23 branch need to be
>   installed on the 23 branch rather than on the trunk.

I don't know how things are set up, so what I don't understand is
whether the «new trunk» will be a complete superset of «23 branch»? If
some fix should go both to «pretty stable» and «unstable» branches, what
shall I do? Commit them separately? Maybe it's not a big problem really
given that probably not so many changes need to be in 23 branch instead
of just trunk, but it's unclear to me how the branches are synced.
-- 
Happy Hacking.

http://sphinx.net.ru
む

Re: New sync'd branch

[Nick Roberts]

> We'd like to have a new release in the first half of next year with some
> new features.  Given the short time, the new features need to be
> non-intrusive, like new packages.

I'm not sure how stable gdb mode will be by that time. It may require
some changes to gdb itself.  I had anticipated at least a two year
development period (21.1 -> 22.1 six years, 22.1 -> 23.1 two years).

> So I believe we should create a new branch EMACS_23 which will play the
> role currently played by the trunk, so the trunk can now be open to more
> experimental development (bidi, cpp->autoconf conversion, lexbind, ...),
> targetted for Emacs-24.

This seems contrary to earlier belief that branching well before a release
results in all energy being diverted away from the release.

I would also like to see a release from EMACS_23_1_RC where I have included
some improvements to gdb-ui.el.  I realise that this might not happen.  In
any case, I have removed this file from trunk, so I don't want to see these
changes merged back to trunk (if that were possible).


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: New sync'd branch

[joakim]

nickrob@snap.net.nz (Nick Roberts) writes:

>> So I believe we should create a new branch EMACS_23 which will play the
>> role currently played by the trunk, so the trunk can now be open to more
>> experimental development (bidi, cpp->autoconf conversion, lexbind, ...),
>> targetted for Emacs-24.
>
> This seems contrary to earlier belief that branching well before a release
> results in all energy being diverted away from the release.
>

My €0.2C: Developer energy is not a resource you can divert at will att
random tasks. My energy level depends on how interesting I find the
tasks at hand. I often wish otherwise.

Hopefully everyone can work at tasks that interests them, and we can
both have releases and a living far-future branch.

-- 
Joakim Verona

Re: New sync'd branch

[Chong Yidong]

nickrob@snap.net.nz (Nick Roberts) writes:

>> We'd like to have a new release in the first half of next year with some
>> new features.  Given the short time, the new features need to be
>> non-intrusive, like new packages.
>
> I'm not sure how stable gdb mode will be by that time. It may require
> some changes to gdb itself.  I had anticipated at least a two year
> development period (21.1 -> 22.1 six years, 22.1 -> 23.1 two years).

Then we've miscommunicated.  Stefan and I have been pretty clear that we
intended to use the trunk for 23.2.

> I would also like to see a release from EMACS_23_1_RC where I have included
> some improvements to gdb-ui.el.  I realise that this might not happen.  In
> any case, I have removed this file from trunk, so I don't want to see these
> changes merged back to trunk (if that were possible).

In that case, we'll plug gdb-ui back in for the 23.2 release (e.g., if
we decide to make a new Emacs 23 branch, we'll revert to gdb-ui on that
branch).

Re: New sync'd branch

[Stefan Monnier]

>> - People installing changes need to carefully choose whether to install
>> it on the 23 branch (from where it will be sync'd to the "24 branch"
>> aka "trunk"), or on the trunk.  Basically, the most important aspect
>> is that any bugfix which makes sense on the 23 branch need to be
>> installed on the 23 branch rather than on the trunk.

> I don't know how things are set up, so what I don't understand is
> whether the «new trunk» will be a complete superset of «23 branch»?

Yes, that's what:

   - Changes on the 23 branch need to be sync'd to the trunk.  As long as
     we haven't switched to Bzr, that means we need Miles to do the sync
     for us.  Miles, could you do that?

refers to.  Miles?  What's your verdict?


        Stefan

Re: New sync'd branch

[Nick Roberts]

 > > I'm not sure how stable gdb mode will be by that time. It may require
 > > some changes to gdb itself.  I had anticipated at least a two year
 > > development period (21.1 -> 22.1 six years, 22.1 -> 23.1 two years).
 > 
 > Then we've miscommunicated.  Stefan and I have been pretty clear that we
 > intended to use the trunk for 23.2.

I haven't followed all of the threads but I think, at times, there have been
other proposals.

 > > I would also like to see a release from EMACS_23_1_RC where I have included
 > > some improvements to gdb-ui.el.  I realise that this might not happen.  In
 > > any case, I have removed this file from trunk, so I don't want to see these
 > > changes merged back to trunk (if that were possible).
 > 
 > In that case, we'll plug gdb-ui back in for the 23.2 release (e.g., if
 > we decide to make a new Emacs 23 branch, we'll revert to gdb-ui on that
 > branch).

That's not ideal, as the mode that gets released isn't the one that gets
tested.  In the overall picture of Emacs' release, though, it's probably a
small matter, and we can probably handle any contingency when, and if, it
arises.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: New sync'd branch

[Miles Bader]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>    - Changes on the 23 branch need to be sync'd to the trunk.  As long as
>      we haven't switched to Bzr, that means we need Miles to do the sync
>      for us.  Miles, could you do that?
>
> refers to.  Miles?  What's your verdict?

Uh, I guess so... well, I'm willing to try, anyway.

-Miles

-- 
Dawn, n. When men of reason go to bed.

Re: New sync'd branch

[Stefan Monnier]

>> - Changes on the 23 branch need to be sync'd to the trunk.  As long as
>> we haven't switched to Bzr, that means we need Miles to do the sync
>> for us.  Miles, could you do that?
>> refers to.  Miles?  What's your verdict?
> Uh, I guess so... well, I'm willing to try, anyway.

You don't seem too enthusiastic.  Maybe another option would be to
make the Emacs-24 branch not in CVS but directly in Git (from where it
will be eventually turned into a Bzr branch).
- this way, syncing from the Emacs-23 branch (i.e. the CVS trunk) should
  be easy and can be done by anyone at any time: Miles is off the hook.
- the conversion to Bzr won't be affected (and the history and merging
  will be preserved).
- the Emacs-23 branch will still be the Emacs trunk, so it will
  hopefully still see a lot of testing.
- the downside of course is that people who want to work on or play with
  the Emacs-24 branch will need to learn to use Git.

How does that sound?


        Stefan

Re: New sync'd branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 26 Aug 2009 15:04:41 -0400
> Cc: emacs-devel@gnu.org, Dmitry Dzhus <dima@sphinx.net.ru>
> 
> - the downside of course is that people who want to work on or play with
>   the Emacs-24 branch will need to learn to use Git.
> 
> How does that sound?

Not good at all.  I don't want to waste my scarce time to learn Git,
in addition to Bzr.

Re: New sync'd branch

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> - the downside of course is that people who want to work on or play with
>>   the Emacs-24 branch will need to learn to use Git.
>> 
>> How does that sound?
>
> Not good at all.  I don't want to waste my scarce time to learn Git,
> in addition to Bzr.

OTOH, people like that love git -- and I get the impression there are
quite a few of us here -- would be ecstatic.

I _already_ use git for everyday read-only updates, so the rigamarole
of having to use other paths to commit things is just annoying... being
able to commit directly to git would be lovely.

[Anyway, anybody that hopes to do much free-software hacking should
learn git, since it's wildly popular in the free-software world...]

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: New sync'd branch

[Teemu Likonen]

On 2009-08-27 13:47 (+0900), Miles Bader wrote:

> [Anyway, anybody that hopes to do much free-software hacking should
> learn git, since it's wildly popular in the free-software world...]

Yes, Git is becoming / is already the standard distributed version
control tool in the free-software world. I love to play with Debian
popularity contest graphs so here's one comparing Git, Bazaar,
Mercurial, CVS and Subversion:

http://qa.debian.org/popcon-graph.php?packages=git-core%2Cbzr%2Cmercurial%2Ccvs%2Csubversion&show_vote=on&want_legend=on&from_date=2006-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

This graph is not about installations, it's about "vote" which means
that the executable files in the package has atime value updated within
certain period of time. It can be translated roughly to "how much the
tool is used" but of course there are many possible inaccuracies.

Another interesting thing is to compare the number of installations and
number of people who actually use the package. About 61% of the people
who have installed git-core package use it regularly. The same number is
only 25% for bzr package.

(n% = vote / inst * 100)
http://qa.debian.org/popcon.php?package=git-core
http://qa.debian.org/popcon.php?package=bzr

Re: New sync'd branch

[Ken Raeburn]

On Aug 27, 2009, at 00:47, Miles Bader wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>>> - the downside of course is that people who want to work on or  
>>> play with
>>>  the Emacs-24 branch will need to learn to use Git.
>>>
>>> How does that sound?
>>
>> Not good at all.  I don't want to waste my scarce time to learn Git,
>> in addition to Bzr.
>
> OTOH, people like that love git -- and I get the impression there are
> quite a few of us here -- would be ecstatic.
>
> I _already_ use git for everyday read-only updates, so the rigamarole
> of having to use other paths to commit things is just annoying...  
> being
> able to commit directly to git would be lovely.

I've been pretty happy with git so far.  But I'm not convinced that  
being able to commit with git for a little while would be all that big  
a benefit if it goes away when the switchover happens.  I would guess  
that at that point emacs-24 would become a bzr branch and the git  
mirror would be read-only?

Is there a good, working, supported git-bzr package that allows you to  
push changes to a bzr repository?  (I've read of at least a couple git- 
bzr packages, but don't know yet if they're supported or any good.)   
If so, it may just be a matter of rebasing local branches from the git  
repo to the bzr one when the time comes, and write access would still  
work.  If that's so, getting the write access sooner does sound  
enticing.

I suppose if bzr can read and write git repositories, that could also  
help; perhaps someone unfamiliar with git could make the jump from CVS  
to bzr now for emacs-24 work, and rebase local work onto "native" bzr  
when the official switchover happens?

Ken

Re: New sync'd branch

[Teemu Likonen]

On 2009-08-27 02:33 (-0400), Ken Raeburn wrote:

> Is there a good, working, supported git-bzr package that allows you to
> push changes to a bzr repository?

No.

Re: New sync'd branch

[Christian Faulhammer]

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

Hi,

Ken Raeburn <raeburn@raeburn.org>:
> Is there a good, working, supported git-bzr package that allows you
> to push changes to a bzr repository?  (I've read of at least a couple
> git- bzr packages, but don't know yet if they're supported or any
> good.) If so, it may just be a matter of rebasing local branches from
> the git repo to the bzr one when the time comes, and write access
> would still work.  If that's so, getting the write access sooner does
> sound enticing.

 http://bazaar-vcs.org/BzrForeignBranches/Git, seems to be okay.

> I suppose if bzr can read and write git repositories, that could
> also help; perhaps someone unfamiliar with git could make the jump
> from CVS to bzr now for emacs-24 work, and rebase local work onto
> "native" bzr when the official switchover happens?

 There is the bzr-rebase plugin, not as comfortable as Git's but ok.
http://bazaar-vcs.org/Rebase

People using Gentoo can pull in the Bazaar overlay and use
dev-util/bzr-git and dev-util/bzr-rebase.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: New sync'd branch

[Ken Raeburn]

On Aug 27, 2009, at 03:14, Christian Faulhammer wrote:
> Hi,
>
> Ken Raeburn <raeburn@raeburn.org>:
>> Is there a good, working, supported git-bzr package that allows you
>> to push changes to a bzr repository?  (I've read of at least a couple
>> git- bzr packages, but don't know yet if they're supported or any
>> good.) If so, it may just be a matter of rebasing local branches from
>> the git repo to the bzr one when the time comes, and write access
>> would still work.  If that's so, getting the write access sooner does
>> sound enticing.
>
> http://bazaar-vcs.org/BzrForeignBranches/Git, seems to be okay.

That's the reverse of what I, as a reasonably happy git user, would  
want.  That one plugs into bzr to let you access a git repository, and  
I want to access a bzr repository using git as my UI.  (I.e., use git  
natively now with the suggested git-only emacs-24 branch, and switch  
to accessing bzr using git when the repository change is done.)

Ken

Re: New sync'd branch

[Miles Bader]

Ken Raeburn <raeburn@raeburn.org> writes:
>> http://bazaar-vcs.org/BzrForeignBranches/Git, seems to be okay.
>
> That's the reverse of what I, as a reasonably happy git user, would
> want.  That one plugs into bzr to let you access a git repository, and
> I want to access a bzr repository using git as my UI.  (I.e., use git
> natively now with the suggested git-only emacs-24 branch, and switch  to
> accessing bzr using git when the repository change is done.)

Yes, me too.

-Miles

-- 
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra

Re: New sync'd branch

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Wed, 26 Aug 2009 15:04:41 -0400
>> Cc: emacs-devel@gnu.org, Dmitry Dzhus <dima@sphinx.net.ru>
>> 
>> - the downside of course is that people who want to work on or play with
>>   the Emacs-24 branch will need to learn to use Git.
>> 
>> How does that sound?
>
> Not good at all.  I don't want to waste my scarce time to learn Git,
> in addition to Bzr.

It would be interesting to know the needs you see that makes you make
this statement.

The way I used the Emacs CVS repos before I switched to bzr and git was
just:

- make local copy of remote repos
- hack
- fetch changes from upstream
- provide patch for emacs-devel to ridicule

which is about 3 scm commands. It seems to be a small investment even
for the interim.

I'm sure, though, that you need to do more complex things I'm missing.

Now that I use git I do more stuff like local branching, having several
remote branches to sync with, etc, but one doesn't have to do those kinds
of things.

>
-- 
Joakim Verona

Re: New sync'd branch

[Stephen J. Turnbull]

Miles Bader writes:
 > Ken Raeburn <raeburn@raeburn.org> writes:
 > >> http://bazaar-vcs.org/BzrForeignBranches/Git, seems to be okay.
 > >
 > > That's the reverse of what I, as a reasonably happy git user, would
 > > want.  That one plugs into bzr to let you access a git repository, and
 > > I want to access a bzr repository using git as my UI.  (I.e., use git
 > > natively now with the suggested git-only emacs-24 branch, and switch  to
 > > accessing bzr using git when the repository change is done.)

bzr now is able to produce "fastimport" format dumps.  They're doing
this for other reasons (for one thing, it's apparently an obvious way
to implement git-filter-branch like capability), but it should be
possible to use that to get reliable, robust synching.

Re: New sync'd branch

[Stefan Monnier]

>> - the downside of course is that people who want to work on or play with
>> the Emacs-24 branch will need to learn to use Git.
>> How does that sound?

> Not good at all.  I don't want to waste my scarce time to learn Git,
> in addition to Bzr.

Maybe we could setup the git-cvsserver for that purpose,


        Stefan

Re: New sync'd branch

[Glenn Morris]

Stefan Monnier wrote:

> So I believe we should create a new branch EMACS_23 which will play the
> role currently played by the trunk, so the trunk can now be open to more
> experimental development (bidi, cpp->autoconf conversion, lexbind, ...),
> targetted for Emacs-24.

It would be good to always have a place for such experimental things.

What's the reason to have two branches EMACS_23 and EMACS_23_1_RC?
The latter will be almost entirely unused. Are you holding it in
reserve in case 23.2 is needed at short notice, eg for a security issue?

> There are some problem with this:
> - Changes on the 23 branch need to be sync'd to the trunk.  As long as
>   we haven't switched to Bzr, that means we need Miles to do the sync
>   for us.

Or we sync manually, or someone else volunteers to do it "automatically".

> - The 23 branch will not see as much testing any more.

I think that's the biggest issue.

[milesomatic merging]
> You don't seem too enthusiastic.  Maybe another option would be to
> make the Emacs-24 branch not in CVS but directly in Git (from where it
> will be eventually turned into a Bzr branch).

Sorry, but that's an idea I have no enthusiasm for.

I'm happy to sync my own changes manually between CVS branches, or
wait for Bzr (assuming this solves all problems).

Re: New sync'd branch

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> What's the reason to have two branches EMACS_23 and EMACS_23_1_RC?
> The latter will be almost entirely unused. Are you holding it in
> reserve in case 23.2 is needed at short notice, eg for a security issue?

That too, but the main reason is that current trunk code contains code
that we want to include in 23.2.  Since the trunk is still relatively
stable, it's easier to cut a new 23.2 release branch than to backport
into EMACS_23_1_RC.

Re: New sync'd branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  dima@sphinx.net.ru,  miles@gnu.org
> Date: Thu, 27 Aug 2009 17:27:31 -0400
> 
> >> - the downside of course is that people who want to work on or play with
> >> the Emacs-24 branch will need to learn to use Git.
> >> How does that sound?
> 
> > Not good at all.  I don't want to waste my scarce time to learn Git,
> > in addition to Bzr.
> 
> Maybe we could setup the git-cvsserver for that purpose,

That'd be great, thanks.

Re: New sync'd branch

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Cc: Eli Zaretskii <eliz@gnu.org>,  dima@sphinx.net.ru,  Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Thu, 27 Aug 2009 08:38:24 +0300
> 
> On 2009-08-27 13:47 (+0900), Miles Bader wrote:
> 
> > [Anyway, anybody that hopes to do much free-software hacking should
> > learn git, since it's wildly popular in the free-software world...]
> 
> Yes, Git is becoming / is already the standard distributed version
> control tool in the free-software world.

I agree with Miles that I _should_ learn git.  But the list of things
I should do is very long, and I'm old enough to realize that some of
them will probably never happen.

In this case, investing my time in working in the bidirectional
editing in Emacs sounds like a much more valuable contribution to Free
Software than using that time on learning git (in addition to Bzr,
which I will have to learn when Emacs switches to that).

Re: New sync'd branch

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org,
>         dima@sphinx.net.ru, miles@gnu.org
> Date: Thu, 27 Aug 2009 11:47:23 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Date: Wed, 26 Aug 2009 15:04:41 -0400
> >> Cc: emacs-devel@gnu.org, Dmitry Dzhus <dima@sphinx.net.ru>
> >> 
> >> - the downside of course is that people who want to work on or play with
> >>   the Emacs-24 branch will need to learn to use Git.
> >> 
> >> How does that sound?
> >
> > Not good at all.  I don't want to waste my scarce time to learn Git,
> > in addition to Bzr.
> 
> It would be interesting to know the needs you see that makes you make
> this statement.

Actually, I don't have a good idea what I will need, because for that
I would need to study git at least to some degree, won't I?  What's
below is just the beginning.

> - make local copy of remote repos
> - hack
> - fetch changes from upstream
> - provide patch for emacs-devel to ridicule
> 
> which is about 3 scm commands. It seems to be a small investment even
> for the interim.
> 
> I'm sure, though, that you need to do more complex things I'm missing.
> 
> Now that I use git I do more stuff like local branching, having several
> remote branches to sync with, etc, but one doesn't have to do those kinds
> of things.

First, you are probably working on GNU/Linux most of the time.  By
contrast, most of my Emacs development is on MS-Windows, where
installing git is an adventure at best.  Last time I looked (I'd love
to learn things changed since then), most of git were Unixy shell
scripts, which means I will need to install Cygwin or MSYS.  Each one
of these needs its own share of learning, tweaking, and getting used
to.  If I had this kind of time, I'd probably install GNU/Linux ion
the first place.

Then I already have several local sandboxes: the trunk, the 23_1_RC
branch, a sandbox where I build and test the DOS port, and now the
bidi branch.  It's confusing as it is already; learning how to do that
with 2 new tools (Bzr and git) will take more time -- time I don't
have.  I prefer not to do that if there's a good alternative.

Re: New sync'd branch

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> I prefer not to do that if there's a good alternative.

Maybe git-cvsserver is enough...

-Miles

-- 
Rational, adj. Devoid of all delusions save those of observation, experience
and reflection.

Re: New sync'd branch

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org,
>         dima@sphinx.net.ru
> Date: Thu, 27 Aug 2009 13:47:11 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> - the downside of course is that people who want to work on or play with
> >>   the Emacs-24 branch will need to learn to use Git.
> >> 
> >> How does that sound?
> >
> > Not good at all.  I don't want to waste my scarce time to learn Git,
> > in addition to Bzr.
> 
> OTOH, people like that love git -- and I get the impression there are
> quite a few of us here -- would be ecstatic.

I don't have any problems with having a git access to Emacs 24
repository, as long as it's not the only one.

Re: New sync'd branch

[Teemu Likonen]

On 2009-08-28 12:04 (+0300), Eli Zaretskii wrote:

> First, you are probably working on GNU/Linux most of the time. By
> contrast, most of my Emacs development is on MS-Windows, where
> installing git is an adventure at best. Last time I looked (I'd love
> to learn things changed since then), most of git were Unixy shell
> scripts, which means I will need to install Cygwin or MSYS. Each one
> of these needs its own share of learning, tweaking, and getting used
> to. If I had this kind of time, I'd probably install GNU/Linux ion the
> first place.

The installation is just a click-click thing:

    http://code.google.com/p/msysgit/

This "most of Git were Unixy shell scripts" is no longer true. There are
some shell scripts but they are some rarely userd low-level utilities
which I don't even remember what they are at the moment. Git is C code
now.

Re: New sync'd branch

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Cc: joakim@verona.se,  emacs-devel@gnu.org
> Date: Fri, 28 Aug 2009 12:19:23 +0300
> 
> On 2009-08-28 12:04 (+0300), Eli Zaretskii wrote:
> 
> > First, you are probably working on GNU/Linux most of the time. By
> > contrast, most of my Emacs development is on MS-Windows, where
> > installing git is an adventure at best. Last time I looked (I'd love
> > to learn things changed since then), most of git were Unixy shell
> > scripts, which means I will need to install Cygwin or MSYS. Each one
> > of these needs its own share of learning, tweaking, and getting used
> > to. If I had this kind of time, I'd probably install GNU/Linux ion the
> > first place.
> 
> The installation is just a click-click thing:
> 
>     http://code.google.com/p/msysgit/

Did you actually try to install and set up MSYS on Windows, and then
use that in parallel to the native MinGW development environment?

I did, so please don't tell me it's ``just a click-click thing''.
Installation is just the beginning of your trouble.  You install
things in order to be able to use them; it's _using_ MSYS together
with native environment on the same machine that takes most of the
energy.

> This "most of Git were Unixy shell scripts" is no longer true. There are
> some shell scripts but they are some rarely userd low-level utilities
> which I don't even remember what they are at the moment. Git is C code
> now.

As long as it needs MSYS, the problem is still there for me.

Let's face it: Git was invented for GNU/Linux by Linux enthusiasts; it
kicks ass on GNU/Linux, but using it on non-Posix platforms is not
(and was not supposed to be) a feast.

Re: New sync'd branch

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, I don't have a good idea what I will need, because for that
> I would need to study git at least to some degree, won't I?  What's
> below is just the beginning.

Indeed.

>
>> - make local copy of remote repos
>> - hack
>> - fetch changes from upstream
>> - provide patch for emacs-devel to ridicule
>> 
>> which is about 3 scm commands. It seems to be a small investment even
>> for the interim.
>> 
>> I'm sure, though, that you need to do more complex things I'm missing.
>> 
>> Now that I use git I do more stuff like local branching, having several
>> remote branches to sync with, etc, but one doesn't have to do those kinds
>> of things.
>
> First, you are probably working on GNU/Linux most of the time.  By
> contrast, most of my Emacs development is on MS-Windows, where
> installing git is an adventure at best.  Last time I looked (I'd love
> to learn things changed since then), most of git were Unixy shell
> scripts, which means I will need to install Cygwin or MSYS.  Each one
> of these needs its own share of learning, tweaking, and getting used
> to.  If I had this kind of time, I'd probably install GNU/Linux ion
> the first place.
>
> Then I already have several local sandboxes: the trunk, the 23_1_RC
> branch, a sandbox where I build and test the DOS port, and now the
> bidi branch.  It's confusing as it is already; learning how to do that
> with 2 new tools (Bzr and git) will take more time -- time I don't
> have.  I prefer not to do that if there's a good alternative.

Yes I understand your situation better now.

If it would be any help I could send you a pre-installed Gnu/Linux
machine, but I suppose getting a machine with a pre-installed distro is
not the main time sink you're worried about.

-- 
Joakim Verona

Re: New sync'd branch

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: emacs-devel@gnu.org
> Date: Fri, 28 Aug 2009 11:38:41 +0200
> 
> If it would be any help I could send you a pre-installed Gnu/Linux
> machine, but I suppose getting a machine with a pre-installed distro is
> not the main time sink you're worried about.

Yes, the main time sink is setting it up for networking, email, etc.,
and then maintaining it.

Re: New sync'd branch

[Eli Zaretskii]

> Date: Fri, 28 Aug 2009 12:48:51 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: joakim@verona.se
> > Cc: emacs-devel@gnu.org
> > Date: Fri, 28 Aug 2009 11:38:41 +0200
> > 
> > If it would be any help I could send you a pre-installed Gnu/Linux
> > machine, but I suppose getting a machine with a pre-installed distro is
> > not the main time sink you're worried about.
> 
> Yes, the main time sink is setting it up for networking, email, etc.,
> and then maintaining it.

Sorry, I forgot to say thanks.

Thanks.

Re: New sync'd branch

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> First, you are probably working on GNU/Linux most of the time.  By
> contrast, most of my Emacs development is on MS-Windows, where
> installing git is an adventure at best.

No, at best it is easy.

> Last time I looked (I'd love to learn things changed since then), most
> of git were Unixy shell scripts, which means I will need to install
> Cygwin or MSYS.

No, it means you have to install msysgit.

<URL:http://code.google.com/p/msysgit/wiki/InstallMSysGit>

> Each one of these needs its own share of learning,
> tweaking, and getting used to.  If I had this kind of time, I'd
> probably install GNU/Linux in the first place.

That would not help developing for Windows, though.

> Then I already have several local sandboxes: the trunk, the 23_1_RC
> branch, a sandbox where I build and test the DOS port, and now the
> bidi branch.  It's confusing as it is already; learning how to do that
> with 2 new tools (Bzr and git) will take more time -- time I don't
> have.  I prefer not to do that if there's a good alternative.

Frankly, CVS is not a good alternative.  I've been using git internally
for both CVS as well as SVN based projects.  The latter works pretty
well thanks to git-svn.  The former is aggravating, but still better
bang for the buck than working directly with CVS only.

-- 
David Kastrup

Re: New sync'd branch

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Teemu Likonen <tlikonen@iki.fi>
>> 
>> The installation is just a click-click thing:
>> 
>>     http://code.google.com/p/msysgit/
>
> Did you actually try to install and set up MSYS on Windows,

You presumably mean msysgit?  AFAIK, it is not a separate install.

> and then use that in parallel to the native MinGW development
> environment?
>
> I did, so please don't tell me it's ``just a click-click thing''.
> Installation is just the beginning of your trouble.  You install
> things in order to be able to use them; it's _using_ MSYS together
> with native environment on the same machine that takes most of the
> energy.

> Let's face it: Git was invented for GNU/Linux by Linux enthusiasts; it
> kicks ass on GNU/Linux, but using it on non-Posix platforms is not
> (and was not supposed to be) a feast.

Johannes Schindelin is mostly responsible for msysgit, I believe.  And
he is what you call a "Linux enthusiast".  He has invested a lot of
tears and blood into msysgit, so the chances are that this reduces the
amount you need to invest yourself.  I think that the Windows port of
Emacs has had a few workers on it with a similar situation, and your
MSDOS port of it appears to be somewhat similarly motivated.

If you have things with msysgit, there will be people eager to hear from
you and trying to address your concerns.  Don't expect them to refrain
from namecalling concerning Windows, but that's not a high price to pay
when you think about it.

-- 
David Kastrup

Re: New sync'd branch

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> As long as it needs MSYS, the problem is still there for me.
>
> Let's face it: Git was invented for GNU/Linux by Linux enthusiasts; it
> kicks ass on GNU/Linux, but using it on non-Posix platforms is not
> (and was not supposed to be) a feast.

As someone who tried git on Windows some weeks ago, I can confirm Eli's
fears.

And would say more: git is the brainchild of Linus, and works according
to Linus views of the world. For instance, CRLF line endings cause a lot
of trouble.

git's extraordinay responsiveness disappears on Windows too.

Then there are those who think that msysgit is a "native" port to
windows, instead cygwin's "emulation". Well, they ignore what msys is: a
fork of cygwin.

BTW, cygwin's git worked much better than msysgit for me.

Finally, git's UI is horrid: complex, barroque, with plenty of
opportunities for shooting yourself on the feet. Those kernel guys are
not the right people for designing UIs. Some day people will recognize
this and will see today's massive leaning towards git as a mistake
originated on juvenile reverence towards its original author and on
simplistic metrics like raw speed, putting aside a critical and objetive
assessment of its merits compared against the alternatives.

-- 
Óscar

Re: New sync'd branch

[Juanma Barranquero]

On Fri, Aug 28, 2009 at 11:32, Eli Zaretskii<eliz@gnu.org> wrote:

> Did you actually try to install and set up MSYS on Windows, and then
> use that in parallel to the native MinGW development environment?

If you install the git executable bundle (currently, that's called
Git-1.6.4-preview20090730.exe ) instead of the msysgit development
environment (that's msysGit-*install-1.6.4-preview20090730.exe), you
can have it set up so it doesn't mess at all with your existing MinGW
or MSYS; the only thing it adds to the PATH is
C:\my_git_install_path\cmd, and that directory just contains a couple
.cmd scripts which locally tweak the PATH to be able to run things in
git\bin.

    Juanma

Re: New sync'd branch

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Aug 2009 16:01:30 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> If you install the git executable bundle (currently, that's called
> Git-1.6.4-preview20090730.exe ) instead of the msysgit development
> environment (that's msysGit-*install-1.6.4-preview20090730.exe), you
> can have it set up so it doesn't mess at all with your existing MinGW
> or MSYS; the only thing it adds to the PATH is
> C:\my_git_install_path\cmd, and that directory just contains a couple
> .cmd scripts which locally tweak the PATH to be able to run things in
> git\bin.

Thanks, I will see if I can find time for trying this out.

But if there's no MSYS with its shell, how do the git shell scripts
work?

Re: New sync'd branch

[Juanma Barranquero]

On Fri, Aug 28, 2009 at 16:08, Eli Zaretskii<eliz@gnu.org> wrote:

> But if there's no MSYS with its shell, how do the git shell scripts
> work?

There's a shell:

C:\> dir \my_git_install_path\bin\*sh.exe

 Volume in drive C is unlabeled      Serial number is 57d9:23e9
 Directory of  C:\my_git_install_path\bin\*sh.exe

30/07/2009   2:17         567.296  bash.exe
30/07/2009   2:17         567.296  sh.exe

[etc]

It's just that they are not on the PATH, so they don't mess with your
MSYS shell.

    Juanma

Re: New sync'd branch

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Aug 2009 16:13:28 +0200
> Cc: emacs-devel@gnu.org
> 
> On Fri, Aug 28, 2009 at 16:08, Eli Zaretskii<eliz@gnu.org> wrote:
> 
> > But if there's no MSYS with its shell, how do the git shell scripts
> > work?
> 
> There's a shell:
> 
> C:\> dir \my_git_install_path\bin\*sh.exe
> 
>  Volume in drive C is unlabeled      Serial number is 57d9:23e9
>  Directory of  C:\my_git_install_path\bin\*sh.exe
> 
> 30/07/2009   2:17         567.296  bash.exe
> 30/07/2009   2:17         567.296  sh.exe

So MSYS is there after all.

> It's just that they are not on the PATH, so they don't mess with your
> MSYS shell.

I don't use MSYS shells.  If I did, I wouldn't mind having another
dependency on it.

Anyway, thanks for the pointer, I hope I will have time to look into
it.

Re: New sync'd branch

[Juanma Barranquero]

On Fri, Aug 28, 2009 at 16:33, Eli Zaretskii<eliz@gnu.org> wrote:

> So MSYS is there after all.

Yes, of course, along with Perl, ssh, Tcl/Tk, GnuPG and a few other
things. Safely tucked away, though.

> I don't use MSYS shells.  If I did, I wouldn't mind having another
> dependency on it.

I fail to understand what is you're afraid msysgit will mess with,
then. You certainly don't have to install Cygwin, MSYS or MinGW to use
msysgit.

> Anyway, thanks for the pointer, I hope I will have time to look into
> it.

Glad to help.

    Juanma

Re: New sync'd branch

[Juanma Barranquero]

On Fri, Aug 28, 2009 at 15:46, Óscar Fuentes<ofv@wanadoo.es> wrote:

> As someone who tried git on Windows some weeks ago, I can confirm Eli's
> fears.

Did you install the msysgit development environment, or the git exe?

> And would say more: git is the brainchild of Linus, and works according
> to Linus views of the world. For instance, CRLF line endings cause a lot
> of trouble.

A little trouble, yes, though that's better in recent versions.

> git's extraordinay responsiveness disappears on Windows too.

??

git on Windows is surely not as fast as it is on GNU/Linux, but are
you saying that it is slower than bzr (or cvs) for you?

> Then there are those who think that msysgit is a "native" port to
> windows, instead cygwin's "emulation". Well, they ignore what msys is: a
> fork of cygwin.

And that's a problem because...? You don't have to install Cygwin
(which I hate). What does matter how msysgit works internally?

> Finally, git's UI is horrid: complex, barroque, with plenty of
> opportunities for shooting yourself on the feet. Those kernel guys are
> not the right people for designing UIs.

I agree with that, and certainly it's a bit absurd the sheer number of
options most commands have. But you can do serious work with git using
a tiny fraction of that complexity (I do, and I've just used the
simplest of git tutorials).

That said, every DVCS is an acquired taste; I don't think bzr's
command set is that elegant, either (though it is definitely simpler).

> Some day people will recognize
> this and will see today's massive leaning towards git as a mistake
> originated on juvenile reverence towards its original author and on
> simplistic metrics like raw speed, putting aside a critical and objetive
> assessment of its merits compared against the alternatives.

Come that day, perhaps will all be using darcs ;-)

    Juanma

Re: New sync'd branch

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Finally, git's UI is horrid: complex, barroque, with plenty of
> opportunities for shooting yourself on the feet.

But there is the reflog.  After shooting yourself in the foot, you
always have the option of going back to before the shot.

Yes, it is reasonably easy to blow up some operation terribly if you
don't know what you are doing.  Because git has lots of power.  But you
always can tell it: "Ok, this was a complete messup.  Give me back what
I had 20 minutes ago".

It is very hard to actually do something which can't be undone.  You
have to really try.

> Those kernel guys are not the right people for designing UIs.

Which is why there are different user interfaces on top of the raw git.
git-gui does quite a few nice things, various Emacs modes as well.

> Some day people will recognize this and will see today's massive
> leaning towards git as a mistake originated on juvenile reverence
> towards its original author and on simplistic metrics like raw speed,
> putting aside a critical and objetive assessment of its merits
> compared against the alternatives.

You underestimate git.  And you underestimate "people".  Torvalds
usually does several hundreds of merges a day.  And that's not just
because of "raw speed", but also because of high-quality merging
strategies.  Moving Emacs towards Bazaar was a real stress test for
Bazaar, and still is.  In contrast, using the git mirrors and
repositories was not a terrible strain.  Most problems were about how to
best preserve (and/or reinvent) history when converting to git.

-- 
David Kastrup

Re: New sync'd branch

[David Reitter]

On Aug 28, 2009, at 5:04 AM, Eli Zaretskii wrote:

>>> Not good at all.  I don't want to waste my scarce time to learn Git,
>>> in addition to Bzr.

I found the learning part (bzr and git) to be good fun since the basic  
concepts are quite easy.  The great time-wasting happened when I tried  
to actually do stuff with bzr and the Emacs repository, because  
everything took ages with bzr (even after their optimizations) and,  
more often than not, I got incomprehensible error messages from deep  
down in the Python code (how is that for good UI?).   Changes to the  
repo format were plenty, and usually the formats were incompatible or  
had to be converted on-the-fly, making things even slower.

Developers on the bzr mailing list were very friendly and responsive,  
but that doesn't help when basic quality assurance doesn't work and  
when the basic design is prone to useless error messages and slow  
operation that doesn't scale well with project size (commit numbers).

I don't contribute enough to Emacs proper for my opinion to be heard  
here, which is why I've quietly switched my own branch to Git, despite  
the pain I'm anticipating when the git mirror will be recreated.  It's  
well worth it.

(By the way, I use git with git-new-workdir from contrib/ in order to  
keep multiple branches in parallel without wasting disk space.  That's  
the bzr model of a local shared repo, as far as I understand it.)

> First, you are probably working on GNU/Linux most of the time.  By
> contrast, most of my Emacs development is on MS-Windows, where
> installing git is an adventure at best.  Last time I looked (I'd love
> to learn things changed since then), most of git were Unixy shell
> scripts, which means I will need to install Cygwin or MSYS.

It seems like there's a complete point-and-click installer with msys.   
Looks very Windowslike to me.  Mostly up to date (July 09) and  
comfortable.

http://nathanj.github.com/gitguide/tour.html

Re: New sync'd branch

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Aug 28, 2009 at 15:46, Óscar Fuentes<ofv@wanadoo.es> wrote:
>
>> As someone who tried git on Windows some weeks ago, I can confirm Eli's
>> fears.
>
> Did you install the msysgit development environment, or the git exe?

I used the msysgit installer. This was 2 months ago IIRC.

[snip]

>> git's extraordinay responsiveness disappears on Windows too.
>
> ??
>
> git on Windows is surely not as fast as it is on GNU/Linux, but are
> you saying that it is slower than bzr (or cvs) for you?

I say that git's speed is no longer a reason for choosing it on
Windows. Some operations (like initializing a git-svn repo) is orders of
magnitude slower on Windows than on GNU/Linux. Importing a 1000 revs svn
repo took *hours* on Windows, less than a minute on GNU/Linux. bzr
imports it on Windows almost as fast as git on GNU/Linux.

>> Then there are those who think that msysgit is a "native" port to
>> windows, instead cygwin's "emulation". Well, they ignore what msys is: a
>> fork of cygwin.
>
> And that's a problem because...? You don't have to install Cygwin
> (which I hate). What does matter how msysgit works internally?

Why do you hate cygwin and not msys, which is cygwin by other name (and
with not so good maintenance and quality, IMO).

>> Finally, git's UI is horrid: complex, barroque, with plenty of
>> opportunities for shooting yourself on the feet. Those kernel guys are
>> not the right people for designing UIs.
>
> I agree with that, and certainly it's a bit absurd the sheer number of
> options most commands have. But you can do serious work with git using
> a tiny fraction of that complexity (I do, and I've just used the
> simplest of git tutorials).

This is like C++ and other gratuitously complex systems: it is difficult
to learn what's important and what's irrelevant or even dangerous.

> That said, every DVCS is an acquired taste; I don't think bzr's
> command set is that elegant, either (though it is definitely simpler).

Learning bzr took me half an hour and I'm productively working with it
since two months ago. bzr does its job and it is out your way. git
requires quite a bit of mastership and knowing lots of things about its
inner workings. Typical mindset of a Linux kernel developer: know by
heart everything you use. A very improductive mindset, I'll say.

[snip]

-- 
Óscar Fuentes
Desarrollo de Software

Re: New sync'd branch

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Finally, git's UI is horrid: complex, barroque, with plenty of
>> opportunities for shooting yourself on the feet.
>
> But there is the reflog.  After shooting yourself in the foot, you
> always have the option of going back to before the shot.
>
> Yes, it is reasonably easy to blow up some operation terribly if you
> don't know what you are doing.  Because git has lots of power.  But you
> always can tell it: "Ok, this was a complete messup.  Give me back what
> I had 20 minutes ago".

I'll really apreciate a tool that does not make me waste those 20
minutes.

It's true that bzr is appreciably slower than git doing common
operations: diff and annotate is intantaneous in git (on GNU/Linux),
takes a few seconds on bzr. But when I screw my git setup, the time that
takes me to fix it is much longer than the time I lost waiting for bzr.

> It is very hard to actually do something which can't be undone.  You
> have to really try.

And this is different from other VCSs how?

>> Those kernel guys are not the right people for designing UIs.
>
> Which is why there are different user interfaces on top of the raw git.
> git-gui does quite a few nice things, various Emacs modes as well.

Agreed.

>> Some day people will recognize this and will see today's massive
>> leaning towards git as a mistake originated on juvenile reverence
>> towards its original author and on simplistic metrics like raw speed,
>> putting aside a critical and objetive assessment of its merits
>> compared against the alternatives.
>
> You underestimate git.  And you underestimate "people".  Torvalds
> usually does several hundreds of merges a day.

The typical Emacs developer is not like Torvads. Emacs has a development
style that is very far from Linux's. Every example about how well git
works specifically for Torvalds is moot.

> And that's not just because of "raw speed", but also because of
> high-quality merging strategies.

git's mergin strategies are possibly superior to bzr, but do we (Emacs
and most other Free projects) really need them? I think not.

> Moving Emacs towards Bazaar was a real stress test for
> Bazaar, and still is.

This will be fixed over time. git's problems (mostly UI and poor support
for non-POSIX environments) will not be solved anytime soon.

[snip]

-- 
Óscar

Re: New sync'd branch

[Juanma Barranquero]

On Fri, Aug 28, 2009 at 19:11, Óscar Fuentes<ofv@wanadoo.es> wrote:

> I say that git's speed is no longer a reason for choosing it on
> Windows. Some operations (like initializing a git-svn repo) is orders of
> magnitude slower on Windows than on GNU/Linux. Importing a 1000 revs svn
> repo took *hours* on Windows, less than a minute on GNU/Linux. bzr
> imports it on Windows almost as fast as git on GNU/Linux.

Your experience with bzr seems to have been better than mine. Cloning
a repo, and doing some normal operations has been much slower with bzr
than git. So, if not a reason to use git over bzr (on projects that
don't require it, as Emacs will be), it is certainly a factor. AFAIK,
it did take months for bzr log to be usable on an Emacs repository...

> Why do you hate cygwin and not msys, which is cygwin by other name (and
> with not so good maintenance and quality, IMO).

I don't really hate Cygwin, I hate *having to use it*; I hate it
forcing me into that fake "you're on Unix now" mindset. If some tool
uses Cygwin under the hood, at it works fine, fine.

> This is like C++ and other gratuitously complex systems: it is difficult
> to learn what's important and what's irrelevant or even dangerous.

Yes. That does not mean that C++ or other "gratuitously complex
systems" are worthless (and I say that as someone who once ago made a
living programming in C++ and who does *not* like it). So, if you're
saying that git would be better by removing complexity, I agree. But
still, some things it does quite well (frankly, switching branches in
place is much more intuitive for me that the current "shared
repository" thing in bzr, for example).

> Learning bzr took me half an hour and I'm productively working with it
> since two months ago. bzr does its job and it is out your way. git
> requires quite a bit of mastership and knowing lots of things about its
> inner workings.

I disagree. It only requires that you know about the complexity if you
intend to do some specialized things, and the same if true for bzr or
any other DVCS. I know nothing about git inner workings.

All in all, we'll have to agree to disagree. It would be silly to turn
this into a bzr vs git war; and more so because I really don't have
anything against bzr; it's just that I have nothing *for* it, either,
at the moment.

    Juanma

Re: New sync'd branch

[David Reitter]

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

On Aug 28, 2009, at 1:11 PM, Óscar Fuentes wrote:

> git
> requires quite a bit of mastership and knowing lots of things about  
> its
> inner workings.

When did you learn it?  Was that before or after their interface  
improvements in or around 2008?

I use git productively without knowing anything about their pack  
format, or when exactly it runs a garbage collection, or how the git  
transfer protocol works.  I do know that it's a graph structure, what  
they mean by HEAD, how a refid identifies a node on the graph,  why it  
changes if content or metadata of the node change, what it means to  
rebase (although the exact syntax I would look up).   All useful and  
beautiful concepts, easy to understand with some general computer  
science training.   And I think you'd have to know this stuff for Bzr  
or Hg, too.



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: New sync'd branch

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Finally, git's UI is horrid: complex, barroque, with plenty of
>>> opportunities for shooting yourself on the feet.
>>
>> But there is the reflog.  After shooting yourself in the foot, you
>> always have the option of going back to before the shot.
>>
>> Yes, it is reasonably easy to blow up some operation terribly if you
>> don't know what you are doing.  Because git has lots of power.  But
>> you always can tell it: "Ok, this was a complete messup.  Give me
>> back what I had 20 minutes ago".
>
> I'll really apreciate a tool that does not make me waste those 20
> minutes.

It saves you hours elsewhere.

>> It is very hard to actually do something which can't be undone.  You
>> have to really try.
>
> And this is different from other VCSs how?

No impact on a central repository even when you tried some complex merge
and got it wrong.  Nobody gets to see your damaged foot.  You just
messed up your personal sandbox temporarily.

>>> Some day people will recognize this and will see today's massive
>>> leaning towards git as a mistake originated on juvenile reverence
>>> towards its original author and on simplistic metrics like raw
>>> speed, putting aside a critical and objetive assessment of its
>>> merits compared against the alternatives.
>>
>> You underestimate git.  And you underestimate "people".  Torvalds
>> usually does several hundreds of merges a day.
>
> The typical Emacs developer is not like Torvads.  Emacs has a
> development style that is very far from Linux's.  Every example about
> how well git works specifically for Torvalds is moot.

That sounds like "nobody will ever need a car, because people ride
horses quite differently than they would ride a car".

>> And that's not just because of "raw speed", but also because of
>> high-quality merging strategies.
>
> git's mergin strategies are possibly superior to bzr, but do we (Emacs
> and most other Free projects) really need them? I think not.

Do we really need cars?  I think not.

I've been the designated merger for diverging feature branches at the
last company I worked with.  Because I was used to working with git.
The VCS at the company was Subversion.  Subversion is quite better with
regard to merging than CVS ever was.  Still I was able to do this stuff
quite more thoroughly and faster with git.  And with "faster" I mean the
investment of human time, not computing time.

>> Moving Emacs towards Bazaar was a real stress test for
>> Bazaar, and still is.
>
> This will be fixed over time.

That's the sort of sentence in software development environments that
sets off all my alarms.

> git's problems (mostly UI and poor support for non-POSIX environments)
> will not be solved anytime soon.

"Stay with our stuff, it is slated to get better.  The stuff that works
better is bad for you" has quite rarely made good on its promises in my
experience.

-- 
David Kastrup

Re: New sync'd branch

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

>>> Yes, it is reasonably easy to blow up some operation terribly if you
>>> don't know what you are doing.  Because git has lots of power.  But
>>> you always can tell it: "Ok, this was a complete messup.  Give me
>>> back what I had 20 minutes ago".
>>
>> I'll really apreciate a tool that does not make me waste those 20
>> minutes.
>
> It saves you hours elsewhere.

Compared against the other DVCS's? Not on my experience. git's speed
advantage is not *that* large.

>>> It is very hard to actually do something which can't be undone.  You
>>> have to really try.
>>
>> And this is different from other VCSs how?
>
> No impact on a central repository even when you tried some complex merge
> and got it wrong.  Nobody gets to see your damaged foot.  You just
> messed up your personal sandbox temporarily.

I insist: and this is different from other VCS how?

Does git block you from sending your changes upstream when you messed up
your personal repo?

If you screw up your personal branch, bzr notices it and maliciously
sends the changes upstream without you asking for it?

>> The typical Emacs developer is not like Torvads.  Emacs has a
>> development style that is very far from Linux's.  Every example about
>> how well git works specifically for Torvalds is moot.
>
> That sounds like "nobody will ever need a car, because people ride
> horses quite differently than they would ride a car".

Often, a car is the worst option as a vehicle.

>> git's mergin strategies are possibly superior to bzr, but do we (Emacs
>> and most other Free projects) really need them? I think not.
>
> Do we really need cars?  I think not.
>
> I've been the designated merger for diverging feature branches at the
> last company I worked with.  Because I was used to working with git.
> The VCS at the company was Subversion.  Subversion is quite better with
> regard to merging than CVS ever was.  Still I was able to do this stuff
> quite more thoroughly and faster with git.  And with "faster" I mean the
> investment of human time, not computing time.

I was talking about bzr vs git for merging. hg vs git fits too. Now you
talk about svn, which merging support is basic, to say it softly. If you
keep changing your counterexample for making git look infinitely better
at every point, this discussion has no value.

>>> Moving Emacs towards Bazaar was a real stress test for
>>> Bazaar, and still is.
>>
>> This will be fixed over time.
>
> That's the sort of sentence in software development environments that
> sets off all my alarms.

There is a clear concern and involvement among bzr developers about
improving performance and almost everything else. I can't see much
concern about UI and multi-platform support when I read git's mailing
list, though.

[snip]

-- 
Óscar Fuentes
Desarrollo de Software

Re: New sync'd branch

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Finally, git's UI is horrid: complex, barroque, with plenty of
> opportunities for shooting yourself on the feet.

There are bad parts of git's UI, but on average it's pretty good.

>Those kernel guys are not the right people for designing UIs. Some day
> people will recognize this and will see today's massive leaning
> towards git as a mistake originated on juvenile reverence towards its
> original author and on simplistic metrics like raw speed, putting
> aside a critical and objetive assessment of its merits compared
> against the alternatives.

Yeesh, please take the juvenile rants elsewhere.

-miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: New sync'd branch

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
>> It saves you hours elsewhere.
>
> Compared against the other DVCS's? Not on my experience. git's speed
> advantage is not *that* large.

It's very, _very_ fast.  It's also far more powerful than most, and
offers a very flexible and intuitive paradigm (when many other systems
are still lamely attempting to follow the creaky old models).

Anyway, it's pretty clear that many, many, very smart people really like
git, _despite_ the strong competition.  Why do you think that is?

[Hint:  your silly claim that it's all because of "linux worship" are
just clueless flamebait.]

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: New sync'd branch

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>>> It saves you hours elsewhere.
>>
>> Compared against the other DVCS's? Not on my experience. git's speed
>> advantage is not *that* large.
>
> It's very, _very_ fast.

Yeah, as if showing a diff or a log in 0.1 seconds instead of 1 second
were a definitive advantage.

Slowness is a reason for rejecting a tool, but being blazingly fast is
not a compelling reason for choosing it.

> It's also far more powerful than most, and
> offers a very flexible and intuitive paradigm (when many other systems
> are still lamely attempting to follow the creaky old models).

I like git's approach wrt branches, yes.

> Anyway, it's pretty clear that many, many, very smart people really like
> git, _despite_ the strong competition.  Why do you think that is?
>
> [Hint:  your silly claim that it's all because of "linux worship" are
> just clueless flamebait.]

First you say that very smart people is choosing git as an evidence of
its superiority, and then dismiss as flamebait my assertion that
Torvarlds' authorship is one of the main reasons for git's popularity.

-- 
Óscar

Re: New sync'd branch

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
>> It's very, _very_ fast.
>
> Yeah, as if showing a diff or a log in 0.1 seconds instead of 1 second
> were a definitive advantage.
>
> Slowness is a reason for rejecting a tool, but being blazingly fast is
> not a compelling reason for choosing it.

I don't think speed is the primary reason to choose git, but it most
definitely is a very appealing aspect of it.

In many cases, the competition _is_ slow, and sometimes _really_ slow.
While a 1 second delay is annoying, a 10 second delay starts to cause
real problems, and a 2 minute delay is insane.

Moreover, a _really_ fast system (where almost every operation is
near-instantaneous) actually does allow different work flows; instead of
feeling like you have to plan all your operations carefully, you feel
free to explore (git's facile interface and transparency really help
here too of course).

Combined with most operations being purely local, it really feels
_different_ (in a very good way) from past systems.

>> Anyway, it's pretty clear that many, many, very smart people really like
>> git, _despite_ the strong competition.  Why do you think that is?
>>
>> [Hint:  your silly claim that it's all because of "linux worship" are
>> just clueless flamebait.]
>
> First you say that very smart people is choosing git as an evidence of
> its superiority, and then dismiss as flamebait my assertion that
> Torvarlds' authorship is one of the main reasons for git's popularity.

Yeesh, I can't believe you're trying to defend your silly troll, but:

I'm not claiming that "many smart people choosing git" is a _reason_ for
others (e.g. us) to choose git (though, in fact it's obviously a better
reason than a single smart person!), I'm asking why you think they chose
it.  It's a reality check of your flamebait.

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: New sync'd branch

[Stefan Monnier]

Can we please stop rehyashing this dicussion and get back to the
question at hand, which is about an Emacs-24 branch and how to do it?
Anyway, it seems that if we can get git-cvsserver, the main problem will
be solved.


        Stefan


>>>>> "Óscar" == Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>> 
>>> Finally, git's UI is horrid: complex, barroque, with plenty of
>>> opportunities for shooting yourself on the feet.
>> 
>> But there is the reflog.  After shooting yourself in the foot, you
>> always have the option of going back to before the shot.
>> 
>> Yes, it is reasonably easy to blow up some operation terribly if you
>> don't know what you are doing.  Because git has lots of power.  But you
>> always can tell it: "Ok, this was a complete messup.  Give me back what
>> I had 20 minutes ago".

> I'll really apreciate a tool that does not make me waste those 20
> minutes.

> It's true that bzr is appreciably slower than git doing common
> operations: diff and annotate is intantaneous in git (on GNU/Linux),
> takes a few seconds on bzr. But when I screw my git setup, the time that
> takes me to fix it is much longer than the time I lost waiting for bzr.

>> It is very hard to actually do something which can't be undone.  You
>> have to really try.

> And this is different from other VCSs how?

>>> Those kernel guys are not the right people for designing UIs.
>> 
>> Which is why there are different user interfaces on top of the raw git.
>> git-gui does quite a few nice things, various Emacs modes as well.

> Agreed.

>>> Some day people will recognize this and will see today's massive
>>> leaning towards git as a mistake originated on juvenile reverence
>>> towards its original author and on simplistic metrics like raw speed,
>>> putting aside a critical and objetive assessment of its merits
>>> compared against the alternatives.
>> 
>> You underestimate git.  And you underestimate "people".  Torvalds
>> usually does several hundreds of merges a day.

> The typical Emacs developer is not like Torvads. Emacs has a development
> style that is very far from Linux's. Every example about how well git
> works specifically for Torvalds is moot.

>> And that's not just because of "raw speed", but also because of
>> high-quality merging strategies.

> git's mergin strategies are possibly superior to bzr, but do we (Emacs
> and most other Free projects) really need them? I think not.

>> Moving Emacs towards Bazaar was a real stress test for
>> Bazaar, and still is.

> This will be fixed over time. git's problems (mostly UI and poor support
> for non-POSIX environments) will not be solved anytime soon.

> [snip]

> -- 
> Óscar

Re: New sync'd branch

[Stephen J. Turnbull]

David Reitter writes:

 > And I think you'd have to know [a bit about the revision DAG] for
 > Bzr or Hg, too.

Not really.  hg is designed to strongly encourage "virtually linear"
development, automatically managing the DAG for "small" divergences
and using the single command "merge" to manually manage "large"
divergences or those with conflicts.  By "automatically" I mean that
hg dislikes having multiple heads (anonymous branches) in a single
workspace, so most users use either the fetch extension or pull -u to
pull and merge in a single operation.  Thus even though most of the
time your local commit will end up being parallel to somebody else's
commit in the public repository, almost all the time you're in a state
where there's only a single head in your branch.  push works to
preserve that invariant for the public repository.  This keeps merges
to a minimum, and you rarely need to be aware of the DAG or even the
branch name.

The bzr command set is a big mess, intended to support a wide variety
of variant workflows with a small number of commands each.  Most of
the commands are the same across workflows, but often they have wildly
varying semantics depending on how your branch is configured.  In
particular, "commit" can mean "record a version in the local repo" (in
a "standalone" branch), "push a version to a remote repo without
recording locally" (in a "lightweight checkout") or "record *and*
push" (in a "heavyweight checkout" or "bound branch").  bzr is
somewhat more friendly to multiple heads than is hg, especially with
the loom extension, but the basic philosophy is the same: try to
maintain a single-headed DAG as much of the time as possible, and
merge only when tactically (the case of a conflict) or strategically
(integrating a feature) necessary.  You rarely need to be aware of the
DAG or the branch name in bzr too, but you do need to be aware of the
type of branch (standalone, lightweight checkout, bound branch).

In fact, for both hg and bzr, I'd say if you become aware of the DAG
you had better be a core VCS hacker.  Anybody else is in big trouble,
because it requires deep understanding of internals to safely
manipulate the DAG directly.

git can emulate all of these various workflows to some degree
(lightweight checkouts are currently impossible to fully emulate
because of restrictions on pushing from "shallow clones"), but you do
need to understand the DAG well to do so.  Also, in git branching is
the cheapest possible operation (a pointer copy) and branch switching
is relatively cheap, so branches tend to proliferate.  For that
reason, you need to be aware of branch names, and it's hard in git to
work with anonymous branches.

Re: New sync'd branch

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>>> Yes, it is reasonably easy to blow up some operation terribly if you
>>>> don't know what you are doing.  Because git has lots of power.  But
>>>> you always can tell it: "Ok, this was a complete messup.  Give me
>>>> back what I had 20 minutes ago".
>>>
>>> I'll really apreciate a tool that does not make me waste those 20
>>> minutes.
>>
>> It saves you hours elsewhere.
>
> Compared against the other DVCS's? Not on my experience. git's speed
> advantage is not *that* large.

I did not say "hours in computing time".  Hours in manual labor.

>>>> It is very hard to actually do something which can't be undone.  You
>>>> have to really try.
>>>
>>> And this is different from other VCSs how?
>>
>> No impact on a central repository even when you tried some complex merge
>> and got it wrong.  Nobody gets to see your damaged foot.  You just
>> messed up your personal sandbox temporarily.
>
> I insist: and this is different from other VCS how?

First, it is different from all central-repository version control systems.

> Does git block you from sending your changes upstream when you messed
> up your personal repo?

Why would you want to send them upstream?

> If you screw up your personal branch, bzr notices it and maliciously
> sends the changes upstream without you asking for it?

If I screw up my personal branch, there won't be a copy upstream that I
can revert to.  That's what "personal branch" is all about.  In git, I
can revert my personal branch to its version of two hours ago without
ever bothering upstream, either read or write.  I can reconstitute _my_
branch.

>>> The typical Emacs developer is not like Torvads.  Emacs has a
>>> development style that is very far from Linux's.  Every example about
>>> how well git works specifically for Torvalds is moot.
>>
>> That sounds like "nobody will ever need a car, because people ride
>> horses quite differently than they would ride a car".
>
> Often, a car is the worst option as a vehicle.

I think we can stop here.

-- 
David Kastrup

Re: New sync'd branch

[Stefan Monnier]

> If I screw up my personal branch, there won't be a copy upstream that I
> can revert to.  That's what "personal branch" is all about.  In git, I
> can revert my personal branch to its version of two hours ago without
> ever bothering upstream, either read or write.  I can reconstitute _my_
> branch.

This property is shared by all VCSes of interest.  In any case: please
stop this thread (or move it elsewhere, /dev/null being the most
productive place for it).


        Stefan

Re: New sync'd branch

[Richard Stallman]

If people want to argue about a technical comparison between git and bzr,
please take it elsewhere.