Bzr is dying; Emacs needs to move • Hacker News Board

Re: Bzr is dying; Emacs needs to move

#271

Post by EdwardDiego » Fri, Jan 03, 2014, 1:01 AM UTC

lmm wrote: post #81

xradionut wrote: post #42

Earlier quoted context omitted.

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in th…

> Java did win the war... ...You could argue that Ruby has overtaken it

For what? A specific niche of web applications?

Re: Bzr is dying; Emacs needs to move

#272

Post by NickNameNick » Fri, Jan 03, 2014, 1:02 AM UTC

lmm wrote: post #258

Crito wrote: post #255

Earlier quoted context omitted.

Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit" . If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push,…

> Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". Sure, but you hit the problem twice as often in git, because you have to do twice as many things. > If you forget to check f…

In SVN, that shows up as a conflict which has to be merged by hand. 'git rebase' and/or 'git mergetool' are nicer.

Re: Bzr is dying; Emacs needs to move

#273

Post by SimHacker » Fri, Jan 03, 2014, 1:14 AM UTC

dded wrote: post #108

cpach wrote: post #95

Earlier quoted context omitted.

I thought RMS had resigned as Emacs’ maintainer? http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg021...

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.)

RMS has RSI, so he doesn't type, he dictates. Oh, shit -- that didn't come out the way I meant it to. ;(

Re: Bzr is dying; Emacs needs to move

#274

Post by BostX » Fri, Jan 03, 2014, 1:30 AM UTC

pygy_ wrote: post #241

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…

Poaching the lead dev to work on your own fork is a hostile move, and in my book, it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately. The guys at Lucid also barely communicated for long periods of time, making collaboration impossible.

> Poaching the lead dev to work on your own fork is a hostile move

That's an argument one can use when asked to spend more time with kids.

> it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately

Huh?!? Open Source model not working or what?

Re: Bzr is dying; Emacs needs to move

#275

Post by BostX » Fri, Jan 03, 2014, 1:45 AM UTC

jamesaguilar wrote: post #244

lmm wrote: post #81

Earlier quoted context omitted.

Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in th…

> Vim did win the war; there's still nothing better Least substantiated claim of 2014 so far.

Haha, but the race is long :)

Re: Bzr is dying; Emacs needs to move

#276

Post by Crito » Fri, Jan 03, 2014, 1:56 AM UTC

lmm wrote: post #258

Crito wrote: post #255

Earlier quoted context omitted.

Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit" . If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push,…

> Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit". Sure, but you hit the problem twice as often in git, because you have to do twice as many things. > If you forget to check f…

> "Sure, but you hit the problem twice as often in git, because you have to do twice as many things."

Well no, I don't...

If this really is a frequent problem for you, then you might want to consider adding a note to the end of git-commit's output to remind you to push, or even just aliasing git-commit to push by default. I would recommend that you instead learn how to use git, but failing that...

> "In SVN that doesn't show up as a merge in the history."

If you don't want to resolve those situations with a merge, then don't resolve those situations with a merge... Rebasing exists for a reason.

Re: Bzr is dying; Emacs needs to move

#277

Post by Crito » Fri, Jan 03, 2014, 1:58 AM UTC

lmm wrote: post #269

mattengi wrote: post #261

Earlier quoted context omitted.

Don't pull origin/master directly into local feature/test branch. Pull into local master then rebase local branch onto it.

This goes against all the advice I've seen elsewhere; we push our feature branches all the time, and sometimes pull from each other's if we're working in overlapping areas, so we need to not rebase them.

If that's what you want to do, that is fine, but you are no longer using a centralized process if you do it that way.

Git allows you to follow a centralized process perfectly fine. However if you choose to not follow a centralized process, it will not force you to.

Re: Bzr is dying; Emacs needs to move

#278

Post by Crito » Fri, Jan 03, 2014, 2:02 AM UTC

unethical_ban wrote: post #222

andrewem wrote: post #199

Earlier quoted context omitted.

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

The syntax is part of it being easier. Also, though it's been a while since I tried using any official git documentation, bzr's website had handy tutorials, references, and cheatsheets available. Great layout, assumed no VCS experience.

That's not conceptually simpler, that is just easier to learn. Git's concepts actually are simple. You can explain the concepts and guts of git to developers with a whiteboard in a few minutes.

The standard CLI UI is admittedly a weak-point, but it does not appear to have slowed adoption...

Re: Bzr is dying; Emacs needs to move

#279

Post by JabavuAdams » Fri, Jan 03, 2014, 3:25 AM UTC

belluchan wrote: post #230

lmm wrote: post #207

Earlier quoted context omitted.

> Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning…

No Objective-C was not dead before iOS. A thriving Apple was supporting Objective-C in every way possible, and moving from Carbon to Cocoa. Objective-C is used to build applications for Apple software. It's not a threat to Java, but that doesn't mean Objective-C is dead. Objective-C will be around for a long time to come. It's a modern language that powers all of Apple's most recent technology. They have no reasons t…

> So the code matters. There will never be powerful IDE like features as long it's this single threaded thing that only ever does anything as a response to user input.

Run VIM in a sub-process, and communicate with it through a fake terminal. Basically, quarantine the madness.

Re: Bzr is dying; Emacs needs to move

#280

Post by belorn » Fri, Jan 03, 2014, 3:38 AM UTC

BostX wrote: post #274

pygy_ wrote: post #241

Earlier quoted context omitted.

Poaching the lead dev to work on your own fork is a hostile move, and in my book, it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately. The guys at Lucid also barely communicated for long periods of time, making collaboration impossible.

> Poaching the lead dev to work on your own fork is a hostile move That's an argument one can use when asked to spend more time with kids. > it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately Huh?!? Open Source model not working or what?

>> it provides a reasonable excuse for the delays, since nobody was able to take his succession immediately

> Huh?!? Open Source model not working or what?

I guess its only illusion and crazy lawyers who like to add anti-poaching clauses in employee contracts. If a company can't handle loosing their top engineers, clearly its the the proprietary model that is not working.