* New sync'd branch
@ 2009-08-23 22:21 Stefan Monnier
2009-08-23 22:35 ` joakim
2009-08-24 19:24 ` Dmitry Dzhus
0 siblings, 2 replies; 60+ messages in thread
From: Stefan Monnier @ 2009-08-23 22:21 UTC (permalink / raw
To: miles, emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-23 22:21 New sync'd branch Stefan Monnier
@ 2009-08-23 22:35 ` joakim
2009-08-24 13:58 ` Leo
2009-08-24 19:24 ` Dmitry Dzhus
1 sibling, 1 reply; 60+ messages in thread
From: joakim @ 2009-08-23 22:35 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel, miles
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-23 22:35 ` joakim
@ 2009-08-24 13:58 ` Leo
0 siblings, 0 replies; 60+ messages in thread
From: Leo @ 2009-08-24 13:58 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-23 22:21 New sync'd branch Stefan Monnier
2009-08-23 22:35 ` joakim
@ 2009-08-24 19:24 ` Dmitry Dzhus
2009-08-25 17:44 ` Stefan Monnier
1 sibling, 1 reply; 60+ messages in thread
From: Dmitry Dzhus @ 2009-08-24 19:24 UTC (permalink / raw
To: emacs-devel
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
む
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
@ 2009-08-24 22:25 Nick Roberts
2009-08-25 9:29 ` joakim
2009-08-25 14:06 ` Chong Yidong
0 siblings, 2 replies; 60+ messages in thread
From: Nick Roberts @ 2009-08-24 22:25 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-24 22:25 Nick Roberts
@ 2009-08-25 9:29 ` joakim
2009-08-25 14:06 ` Chong Yidong
1 sibling, 0 replies; 60+ messages in thread
From: joakim @ 2009-08-25 9:29 UTC (permalink / raw
To: Nick Roberts; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-24 22:25 Nick Roberts
2009-08-25 9:29 ` joakim
@ 2009-08-25 14:06 ` Chong Yidong
2009-08-25 21:02 ` Nick Roberts
1 sibling, 1 reply; 60+ messages in thread
From: Chong Yidong @ 2009-08-25 14:06 UTC (permalink / raw
To: Nick Roberts; +Cc: Stefan Monnier, emacs-devel
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).
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-24 19:24 ` Dmitry Dzhus
@ 2009-08-25 17:44 ` Stefan Monnier
2009-08-26 8:31 ` Miles Bader
0 siblings, 1 reply; 60+ messages in thread
From: Stefan Monnier @ 2009-08-25 17:44 UTC (permalink / raw
To: Dmitry Dzhus, miles; +Cc: emacs-devel
>> - 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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-25 14:06 ` Chong Yidong
@ 2009-08-25 21:02 ` Nick Roberts
0 siblings, 0 replies; 60+ messages in thread
From: Nick Roberts @ 2009-08-25 21:02 UTC (permalink / raw
To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel
> > 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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-25 17:44 ` Stefan Monnier
@ 2009-08-26 8:31 ` Miles Bader
2009-08-26 19:04 ` Stefan Monnier
0 siblings, 1 reply; 60+ messages in thread
From: Miles Bader @ 2009-08-26 8:31 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel, Dmitry Dzhus
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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-26 8:31 ` Miles Bader
@ 2009-08-26 19:04 ` Stefan Monnier
2009-08-27 3:09 ` Eli Zaretskii
2009-08-27 21:52 ` Glenn Morris
0 siblings, 2 replies; 60+ messages in thread
From: Stefan Monnier @ 2009-08-26 19:04 UTC (permalink / raw
To: Miles Bader; +Cc: emacs-devel, Dmitry Dzhus
>> - 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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-26 19:04 ` Stefan Monnier
@ 2009-08-27 3:09 ` Eli Zaretskii
2009-08-27 4:47 ` Miles Bader
` (2 more replies)
2009-08-27 21:52 ` Glenn Morris
1 sibling, 3 replies; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-27 3:09 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel, dima, miles
> 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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 3:09 ` Eli Zaretskii
@ 2009-08-27 4:47 ` Miles Bader
2009-08-27 5:38 ` Teemu Likonen
` (2 more replies)
2009-08-27 9:47 ` joakim
2009-08-27 21:27 ` Stefan Monnier
2 siblings, 3 replies; 60+ messages in thread
From: Miles Bader @ 2009-08-27 4:47 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dima, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 4:47 ` Miles Bader
@ 2009-08-27 5:38 ` Teemu Likonen
2009-08-28 8:34 ` Eli Zaretskii
2009-08-27 6:33 ` Ken Raeburn
2009-08-28 9:18 ` Eli Zaretskii
2 siblings, 1 reply; 60+ messages in thread
From: Teemu Likonen @ 2009-08-27 5:38 UTC (permalink / raw
To: Miles Bader; +Cc: Eli Zaretskii, emacs-devel, Stefan Monnier, dima
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 4:47 ` Miles Bader
2009-08-27 5:38 ` Teemu Likonen
@ 2009-08-27 6:33 ` Ken Raeburn
2009-08-27 7:08 ` Teemu Likonen
2009-08-27 7:14 ` Christian Faulhammer
2009-08-28 9:18 ` Eli Zaretskii
2 siblings, 2 replies; 60+ messages in thread
From: Ken Raeburn @ 2009-08-27 6:33 UTC (permalink / raw
To: Miles Bader; +Cc: Emacs development discussions
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 6:33 ` Ken Raeburn
@ 2009-08-27 7:08 ` Teemu Likonen
2009-08-27 7:14 ` Christian Faulhammer
1 sibling, 0 replies; 60+ messages in thread
From: Teemu Likonen @ 2009-08-27 7:08 UTC (permalink / raw
To: Ken Raeburn; +Cc: Emacs development discussions, Miles Bader
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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 6:33 ` Ken Raeburn
2009-08-27 7:08 ` Teemu Likonen
@ 2009-08-27 7:14 ` Christian Faulhammer
2009-08-27 8:55 ` Ken Raeburn
1 sibling, 1 reply; 60+ messages in thread
From: Christian Faulhammer @ 2009-08-27 7:14 UTC (permalink / raw
To: Ken Raeburn, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 7:14 ` Christian Faulhammer
@ 2009-08-27 8:55 ` Ken Raeburn
2009-08-27 9:07 ` Miles Bader
0 siblings, 1 reply; 60+ messages in thread
From: Ken Raeburn @ 2009-08-27 8:55 UTC (permalink / raw
To: Christian Faulhammer; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 8:55 ` Ken Raeburn
@ 2009-08-27 9:07 ` Miles Bader
2009-08-27 10:11 ` Stephen J. Turnbull
0 siblings, 1 reply; 60+ messages in thread
From: Miles Bader @ 2009-08-27 9:07 UTC (permalink / raw
To: Ken Raeburn; +Cc: emacs-devel, Christian Faulhammer
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 3:09 ` Eli Zaretskii
2009-08-27 4:47 ` Miles Bader
@ 2009-08-27 9:47 ` joakim
2009-08-28 9:04 ` Eli Zaretskii
2009-08-27 21:27 ` Stefan Monnier
2 siblings, 1 reply; 60+ messages in thread
From: joakim @ 2009-08-27 9:47 UTC (permalink / raw
To: Eli Zaretskii; +Cc: miles, dima, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 9:07 ` Miles Bader
@ 2009-08-27 10:11 ` Stephen J. Turnbull
0 siblings, 0 replies; 60+ messages in thread
From: Stephen J. Turnbull @ 2009-08-27 10:11 UTC (permalink / raw
To: Miles Bader; +Cc: Ken Raeburn, Christian Faulhammer, emacs-devel
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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 3:09 ` Eli Zaretskii
2009-08-27 4:47 ` Miles Bader
2009-08-27 9:47 ` joakim
@ 2009-08-27 21:27 ` Stefan Monnier
2009-08-28 8:28 ` Eli Zaretskii
2 siblings, 1 reply; 60+ messages in thread
From: Stefan Monnier @ 2009-08-27 21:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: miles, dima, emacs-devel
>> - 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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-26 19:04 ` Stefan Monnier
2009-08-27 3:09 ` Eli Zaretskii
@ 2009-08-27 21:52 ` Glenn Morris
2009-08-27 22:17 ` Chong Yidong
1 sibling, 1 reply; 60+ messages in thread
From: Glenn Morris @ 2009-08-27 21:52 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel, Dmitry Dzhus, Miles Bader
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).
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 21:52 ` Glenn Morris
@ 2009-08-27 22:17 ` Chong Yidong
0 siblings, 0 replies; 60+ messages in thread
From: Chong Yidong @ 2009-08-27 22:17 UTC (permalink / raw
To: Glenn Morris; +Cc: Miles Bader, Dmitry Dzhus, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 21:27 ` Stefan Monnier
@ 2009-08-28 8:28 ` Eli Zaretskii
0 siblings, 0 replies; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 8:28 UTC (permalink / raw
To: Stefan Monnier; +Cc: miles, dima, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 5:38 ` Teemu Likonen
@ 2009-08-28 8:34 ` Eli Zaretskii
0 siblings, 0 replies; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 8:34 UTC (permalink / raw
To: Teemu Likonen; +Cc: dima, emacs-devel, monnier, miles
> 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).
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 9:47 ` joakim
@ 2009-08-28 9:04 ` Eli Zaretskii
2009-08-28 9:12 ` Miles Bader
` (4 more replies)
0 siblings, 5 replies; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 9:04 UTC (permalink / raw
To: joakim; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:04 ` Eli Zaretskii
@ 2009-08-28 9:12 ` Miles Bader
2009-08-28 9:19 ` Teemu Likonen
` (3 subsequent siblings)
4 siblings, 0 replies; 60+ messages in thread
From: Miles Bader @ 2009-08-28 9:12 UTC (permalink / raw
To: Eli Zaretskii; +Cc: joakim, emacs-devel
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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-27 4:47 ` Miles Bader
2009-08-27 5:38 ` Teemu Likonen
2009-08-27 6:33 ` Ken Raeburn
@ 2009-08-28 9:18 ` Eli Zaretskii
2 siblings, 0 replies; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 9:18 UTC (permalink / raw
To: Miles Bader; +Cc: dima, monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:04 ` Eli Zaretskii
2009-08-28 9:12 ` Miles Bader
@ 2009-08-28 9:19 ` Teemu Likonen
2009-08-28 9:32 ` Eli Zaretskii
2009-08-28 9:38 ` joakim
` (2 subsequent siblings)
4 siblings, 1 reply; 60+ messages in thread
From: Teemu Likonen @ 2009-08-28 9:19 UTC (permalink / raw
To: Eli Zaretskii; +Cc: joakim, emacs-devel
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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:19 ` Teemu Likonen
@ 2009-08-28 9:32 ` Eli Zaretskii
2009-08-28 13:03 ` David Kastrup
` (2 more replies)
0 siblings, 3 replies; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 9:32 UTC (permalink / raw
To: Teemu Likonen; +Cc: joakim, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:04 ` Eli Zaretskii
2009-08-28 9:12 ` Miles Bader
2009-08-28 9:19 ` Teemu Likonen
@ 2009-08-28 9:38 ` joakim
2009-08-28 9:48 ` Eli Zaretskii
2009-08-28 11:18 ` David Kastrup
2009-08-28 15:59 ` David Reitter
4 siblings, 1 reply; 60+ messages in thread
From: joakim @ 2009-08-28 9:38 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:38 ` joakim
@ 2009-08-28 9:48 ` Eli Zaretskii
2009-08-28 10:02 ` Eli Zaretskii
0 siblings, 1 reply; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 9:48 UTC (permalink / raw
To: joakim; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:48 ` Eli Zaretskii
@ 2009-08-28 10:02 ` Eli Zaretskii
0 siblings, 0 replies; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 10:02 UTC (permalink / raw
To: joakim, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:04 ` Eli Zaretskii
` (2 preceding siblings ...)
2009-08-28 9:38 ` joakim
@ 2009-08-28 11:18 ` David Kastrup
2009-08-28 15:59 ` David Reitter
4 siblings, 0 replies; 60+ messages in thread
From: David Kastrup @ 2009-08-28 11:18 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:32 ` Eli Zaretskii
@ 2009-08-28 13:03 ` David Kastrup
2009-08-28 13:46 ` Óscar Fuentes
2009-08-28 14:01 ` Juanma Barranquero
2 siblings, 0 replies; 60+ messages in thread
From: David Kastrup @ 2009-08-28 13:03 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:32 ` Eli Zaretskii
2009-08-28 13:03 ` David Kastrup
@ 2009-08-28 13:46 ` Óscar Fuentes
2009-08-28 14:55 ` Juanma Barranquero
` (2 more replies)
2009-08-28 14:01 ` Juanma Barranquero
2 siblings, 3 replies; 60+ messages in thread
From: Óscar Fuentes @ 2009-08-28 13:46 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:32 ` Eli Zaretskii
2009-08-28 13:03 ` David Kastrup
2009-08-28 13:46 ` Óscar Fuentes
@ 2009-08-28 14:01 ` Juanma Barranquero
2009-08-28 14:08 ` Eli Zaretskii
2 siblings, 1 reply; 60+ messages in thread
From: Juanma Barranquero @ 2009-08-28 14:01 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 14:01 ` Juanma Barranquero
@ 2009-08-28 14:08 ` Eli Zaretskii
2009-08-28 14:13 ` Juanma Barranquero
0 siblings, 1 reply; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 14:08 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 14:08 ` Eli Zaretskii
@ 2009-08-28 14:13 ` Juanma Barranquero
2009-08-28 14:33 ` Eli Zaretskii
0 siblings, 1 reply; 60+ messages in thread
From: Juanma Barranquero @ 2009-08-28 14:13 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 14:13 ` Juanma Barranquero
@ 2009-08-28 14:33 ` Eli Zaretskii
2009-08-28 14:44 ` Juanma Barranquero
0 siblings, 1 reply; 60+ messages in thread
From: Eli Zaretskii @ 2009-08-28 14:33 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 14:33 ` Eli Zaretskii
@ 2009-08-28 14:44 ` Juanma Barranquero
0 siblings, 0 replies; 60+ messages in thread
From: Juanma Barranquero @ 2009-08-28 14:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 13:46 ` Óscar Fuentes
@ 2009-08-28 14:55 ` Juanma Barranquero
2009-08-28 17:11 ` Óscar Fuentes
2009-08-28 15:08 ` David Kastrup
2009-08-28 22:00 ` Miles Bader
2 siblings, 1 reply; 60+ messages in thread
From: Juanma Barranquero @ 2009-08-28 14:55 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 13:46 ` Óscar Fuentes
2009-08-28 14:55 ` Juanma Barranquero
@ 2009-08-28 15:08 ` David Kastrup
2009-08-28 17:21 ` Óscar Fuentes
2009-08-28 22:00 ` Miles Bader
2 siblings, 1 reply; 60+ messages in thread
From: David Kastrup @ 2009-08-28 15:08 UTC (permalink / raw
To: emacs-devel
Ó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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 9:04 ` Eli Zaretskii
` (3 preceding siblings ...)
2009-08-28 11:18 ` David Kastrup
@ 2009-08-28 15:59 ` David Reitter
4 siblings, 0 replies; 60+ messages in thread
From: David Reitter @ 2009-08-28 15:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: joakim, Emacs Development
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 14:55 ` Juanma Barranquero
@ 2009-08-28 17:11 ` Óscar Fuentes
2009-08-28 17:49 ` Juanma Barranquero
2009-08-28 18:00 ` David Reitter
0 siblings, 2 replies; 60+ messages in thread
From: Óscar Fuentes @ 2009-08-28 17:11 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 15:08 ` David Kastrup
@ 2009-08-28 17:21 ` Óscar Fuentes
2009-08-28 19:33 ` David Kastrup
2009-08-29 0:46 ` Stefan Monnier
0 siblings, 2 replies; 60+ messages in thread
From: Óscar Fuentes @ 2009-08-28 17:21 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 17:11 ` Óscar Fuentes
@ 2009-08-28 17:49 ` Juanma Barranquero
2009-08-28 18:00 ` David Reitter
1 sibling, 0 replies; 60+ messages in thread
From: Juanma Barranquero @ 2009-08-28 17:49 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 17:11 ` Óscar Fuentes
2009-08-28 17:49 ` Juanma Barranquero
@ 2009-08-28 18:00 ` David Reitter
2009-08-29 3:56 ` Stephen J. Turnbull
2009-08-29 20:20 ` Richard Stallman
1 sibling, 2 replies; 60+ messages in thread
From: David Reitter @ 2009-08-28 18:00 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 17:21 ` Óscar Fuentes
@ 2009-08-28 19:33 ` David Kastrup
2009-08-28 21:41 ` Óscar Fuentes
2009-08-29 0:46 ` Stefan Monnier
1 sibling, 1 reply; 60+ messages in thread
From: David Kastrup @ 2009-08-28 19:33 UTC (permalink / raw
To: emacs-devel
Ó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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 19:33 ` David Kastrup
@ 2009-08-28 21:41 ` Óscar Fuentes
2009-08-28 22:20 ` Miles Bader
2009-08-29 9:08 ` David Kastrup
0 siblings, 2 replies; 60+ messages in thread
From: Óscar Fuentes @ 2009-08-28 21:41 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 13:46 ` Óscar Fuentes
2009-08-28 14:55 ` Juanma Barranquero
2009-08-28 15:08 ` David Kastrup
@ 2009-08-28 22:00 ` Miles Bader
2 siblings, 0 replies; 60+ messages in thread
From: Miles Bader @ 2009-08-28 22:00 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Ó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]
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 21:41 ` Óscar Fuentes
@ 2009-08-28 22:20 ` Miles Bader
2009-08-28 22:55 ` Óscar Fuentes
2009-08-29 9:08 ` David Kastrup
1 sibling, 1 reply; 60+ messages in thread
From: Miles Bader @ 2009-08-28 22:20 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Ó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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 22:20 ` Miles Bader
@ 2009-08-28 22:55 ` Óscar Fuentes
2009-08-29 0:17 ` Miles Bader
0 siblings, 1 reply; 60+ messages in thread
From: Óscar Fuentes @ 2009-08-28 22:55 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 22:55 ` Óscar Fuentes
@ 2009-08-29 0:17 ` Miles Bader
0 siblings, 0 replies; 60+ messages in thread
From: Miles Bader @ 2009-08-29 0:17 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Ó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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 17:21 ` Óscar Fuentes
2009-08-28 19:33 ` David Kastrup
@ 2009-08-29 0:46 ` Stefan Monnier
1 sibling, 0 replies; 60+ messages in thread
From: Stefan Monnier @ 2009-08-29 0:46 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 18:00 ` David Reitter
@ 2009-08-29 3:56 ` Stephen J. Turnbull
2009-08-29 20:20 ` Richard Stallman
1 sibling, 0 replies; 60+ messages in thread
From: Stephen J. Turnbull @ 2009-08-29 3:56 UTC (permalink / raw
To: David Reitter; +Cc: Óscar Fuentes, emacs-devel
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.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 21:41 ` Óscar Fuentes
2009-08-28 22:20 ` Miles Bader
@ 2009-08-29 9:08 ` David Kastrup
2009-08-29 15:25 ` Stefan Monnier
1 sibling, 1 reply; 60+ messages in thread
From: David Kastrup @ 2009-08-29 9:08 UTC (permalink / raw
To: emacs-devel
Ó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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-29 9:08 ` David Kastrup
@ 2009-08-29 15:25 ` Stefan Monnier
0 siblings, 0 replies; 60+ messages in thread
From: Stefan Monnier @ 2009-08-29 15:25 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: New sync'd branch
2009-08-28 18:00 ` David Reitter
2009-08-29 3:56 ` Stephen J. Turnbull
@ 2009-08-29 20:20 ` Richard Stallman
1 sibling, 0 replies; 60+ messages in thread
From: Richard Stallman @ 2009-08-29 20:20 UTC (permalink / raw
To: David Reitter; +Cc: ofv, emacs-devel
If people want to argue about a technical comparison between git and bzr,
please take it elsewhere.
^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2009-08-29 20:20 UTC | newest]
Thread overview: 60+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-23 22:21 New sync'd branch Stefan Monnier
2009-08-23 22:35 ` joakim
2009-08-24 13:58 ` Leo
2009-08-24 19:24 ` Dmitry Dzhus
2009-08-25 17:44 ` Stefan Monnier
2009-08-26 8:31 ` Miles Bader
2009-08-26 19:04 ` Stefan Monnier
2009-08-27 3:09 ` Eli Zaretskii
2009-08-27 4:47 ` Miles Bader
2009-08-27 5:38 ` Teemu Likonen
2009-08-28 8:34 ` Eli Zaretskii
2009-08-27 6:33 ` Ken Raeburn
2009-08-27 7:08 ` Teemu Likonen
2009-08-27 7:14 ` Christian Faulhammer
2009-08-27 8:55 ` Ken Raeburn
2009-08-27 9:07 ` Miles Bader
2009-08-27 10:11 ` Stephen J. Turnbull
2009-08-28 9:18 ` Eli Zaretskii
2009-08-27 9:47 ` joakim
2009-08-28 9:04 ` Eli Zaretskii
2009-08-28 9:12 ` Miles Bader
2009-08-28 9:19 ` Teemu Likonen
2009-08-28 9:32 ` Eli Zaretskii
2009-08-28 13:03 ` David Kastrup
2009-08-28 13:46 ` Óscar Fuentes
2009-08-28 14:55 ` Juanma Barranquero
2009-08-28 17:11 ` Óscar Fuentes
2009-08-28 17:49 ` Juanma Barranquero
2009-08-28 18:00 ` David Reitter
2009-08-29 3:56 ` Stephen J. Turnbull
2009-08-29 20:20 ` Richard Stallman
2009-08-28 15:08 ` David Kastrup
2009-08-28 17:21 ` Óscar Fuentes
2009-08-28 19:33 ` David Kastrup
2009-08-28 21:41 ` Óscar Fuentes
2009-08-28 22:20 ` Miles Bader
2009-08-28 22:55 ` Óscar Fuentes
2009-08-29 0:17 ` Miles Bader
2009-08-29 9:08 ` David Kastrup
2009-08-29 15:25 ` Stefan Monnier
2009-08-29 0:46 ` Stefan Monnier
2009-08-28 22:00 ` Miles Bader
2009-08-28 14:01 ` Juanma Barranquero
2009-08-28 14:08 ` Eli Zaretskii
2009-08-28 14:13 ` Juanma Barranquero
2009-08-28 14:33 ` Eli Zaretskii
2009-08-28 14:44 ` Juanma Barranquero
2009-08-28 9:38 ` joakim
2009-08-28 9:48 ` Eli Zaretskii
2009-08-28 10:02 ` Eli Zaretskii
2009-08-28 11:18 ` David Kastrup
2009-08-28 15:59 ` David Reitter
2009-08-27 21:27 ` Stefan Monnier
2009-08-28 8:28 ` Eli Zaretskii
2009-08-27 21:52 ` Glenn Morris
2009-08-27 22:17 ` Chong Yidong
-- strict thread matches above, loose matches on Subject: below --
2009-08-24 22:25 Nick Roberts
2009-08-25 9:29 ` joakim
2009-08-25 14:06 ` Chong Yidong
2009-08-25 21:02 ` Nick Roberts
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.