Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bzr is dying; Emacs needs to move

lists.gnu.org

Post reply on HN
Print view View original

211–220 of 317 posts

Re: Bzr is dying; Emacs needs to move

#211

Post by gizmogwai »

andrewem wrote: post #199
unethical_ban wrote: post #121

Earlier quoted context omitted.

Except bzr is conceptually easier to learn and has a more consistent command syntax than git.

What are some of the conceptual differences that make bzr easier to learn? (I agree that git's command syntax is inconsistent.)

Command names are closer to SVN/CVS ones, which lower the learning curve for similar concepts. The documentation really is at another level of didactic compare to git, and no, pro-git is not enough neither. Changes are tracked automatically, no need to explicitly add the files you changed to a particular commit (Whether or not it is a good idea is another discussion). Empty directories can be versioned, no need to create a .gitignore in it to fool the system (Same remark as above).

Re: Bzr is dying; Emacs needs to move

#212

Post by kzrdude »

rlpb wrote: post #112
dded wrote: post #103

Earlier quoted context omitted.

I'm entirely ignorant of bzr, but I've got to say that this surprises me. We use svn, which certainly works well with patch.

To the extent that svn works with patch, so does bzr, and so does git. What I'm talking about is lossless integration with entire patch sets in the form that git does it with format-patch, send-email and am.

git patch support is more feature complete. Atomic application by default and using parent information for three-way merge to apply patches if requested.

Re: Bzr is dying; Emacs needs to move

#213

Post by agumonkey »

aaronem wrote: post #114
dded wrote: post #108

Earlier quoted context omitted.

One of the reasons I chose GNU Emacs over XEmacs was a feeling that GNU Emacs will be maintained, even advanced, for as long as RMS has the strength to type. It's his baby. (There were other reasons, the big one being momentum. XEmacs didn't run on the platform I was on for a long time, so it would have been a switch.)

An excellent point; for example, although I don't have any reason to think RMS himself did this, Emacs 24.4 will have file change notification support across all platforms where it compiles and where such notifications are available. I grant that's a somewhat overdue feature for Emacs to have (e.g., I've wanted it ever since I set up Dropbox to synchronize my org-mode files across all my boxes), but it's definitely e…

Lisp systems legacy I suppose, the core is ~tiny, everything else is a library.

Re: Bzr is dying; Emacs needs to move

#214

Post by Demiurge »

comex wrote: post #210
Demiurge wrote: post #191

Earlier quoted context omitted.

Why would they do that? Mach allows for some cool stuff, like kernel extensions being isolated.

xnu kexts are not isolated and probably never will be, although IOKit exposes some things to userspace.

They're isolated enough that drivers can crash and just be reloaded, without a kernel panic.

Re: Bzr is dying; Emacs needs to move

#215

Post by lmm »

Crito wrote: post #184
chx wrote: post #161

Earlier quoted context omitted.

> the desire to support arbitrary workflows. Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch. git , I believe , is the textbook case of what the opposite of a user friendly UI is. command…

> "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.

I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine, the remote-tracking copies of those three on my machine, and the same again on his machine. All of which could be different.

How do I reduce that complexity? I always pull and never fetch, which helps slightly, but only slightly; pull seems to fetch other branches, so it's still possible to have my copy of a branch end up behind my remote-tracking copy of that branch. There's no command analogous to pull for "add and commit and push", so that's always a second step to possibly forget (I don't want to rely on an alias as I work on a number of different machines). Most problematic at the moment is that there's no way to tell the difference between an up-to-date branch and a non-remote-tracking branch, so I sometimes delete branches that I haven't fully pushed, because I forgot to make them remote-tracking, so they didn't show up as behind when I "git status"ed.

Re: Bzr is dying; Emacs needs to move

#216

Post by Demiurge »

justincormack wrote: post #205
Demiurge wrote: post #191

Earlier quoted context omitted.

Why would they do that? Mach allows for some cool stuff, like kernel extensions being isolated.

Because building and maintaining a competitive OS is a huge effort, and FreeBSD has lots of cool stuff which they can't use...

It's a huge effort worth that seems to be paying off quite handily. XNU seems like a competitive edge over the monolith FreeBSD, as far as desktop and mobile OS is concerned. FreeBSD has plenty of cool stuff, but in a completely different domain.

Re: Bzr is dying; Emacs needs to move

#217

Post by comex »

Demiurge wrote: post #214
comex wrote: post #210

Earlier quoted context omitted.

xnu kexts are not isolated and probably never will be, although IOKit exposes some things to userspace.

They're isolated enough that drivers can crash and just be reloaded, without a kernel panic.

No, they are not. A crash in a kext causes a kernel panic.

Re: Bzr is dying; Emacs needs to move

#218

Post by hamburglar »

lmm wrote: post #209
hamburglar wrote: post #190

Earlier quoted context omitted.

I tried to read that conversation in a neutral light, because I think RMS and JWZ are both kind of ... polarizing personalities, but RMS really came off as a stubborn, ineffective whiner in that whole thread. In particular "you hired away my maintainer" is a pathetic excuse for not releasing something for so long. Anybody could have hired away your maintainer, and you'd have to soldier on; it has no relevance that yo…

Funny, I had the opposite view. I guess your opinion of the personalities really does change everything.

There is one (and only one) other possibility, which is that you and I both read the conversation with flawless objectivity, and that you are wrong. :D

Re: Bzr is dying; Emacs needs to move

#219

Post by petertodd »

binarycrusader wrote: post #152
mikro2nd wrote: post #41

>git won the mindshare war. I regret this - I would have preferred Mercurial, but it too is not looking real healthy these days I confess that my perception of Mercurial is the diametric opposite of the author's. Recently I believe I have seen a modest resurgence of interest in Hg and increased uptake. Am I just seeing this through some peculiar VCS-warped glasses? I believe that much of the popularity of git stems f…

Yep, I don't understand the author's assertions about Mercurial either. Mercurial remains a better choice for a few use cases where git simply falls flat. Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. And realistically, perforce or other solutions appear to be even more popular among…

Git now has the git-annex extension for large files; I use it myself for all my data.

http://git-annex.branchable.com/

Re: Bzr is dying; Emacs needs to move

#220

Post by Crito »

sparkie wrote: post #138
joelthelion wrote: post #104

Earlier quoted context omitted.

>Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on? Do you really want those guys on your project?

I wonder if any of those guys would ever contribute to emacs anyway, unless we rewrite it in javascript.

If the Emacs/Guile thing ever gets off the ground properly, ECMAScript/Emacs may become a possibility.
Post reply on HN