Live data from Hacker News

Bzr is dying; Emacs needs to move

lists.gnu.org

301–310 of 317 posts

Re: Bzr is dying; Emacs needs to move

#301
post #288

Earlier quoted context omitted.

As he said, 'more than Emacs is at stake here.'.[1] I presume this refers to Bazaar's status as part of the GNU project, and that RMS did not want to write off part of GNU without being certain he needed to. Regardless, he has since OKd the switch from bzr: I don't insist that Emacs should stay with bzr. I chose to support bzr because it was still a contender at the time. [2] [1] https://lists.gnu.org/archive/html/em…

I think the subsequent OK'ing is unfortunate. Attracting younger hackers shouldn't be a more important goal than integrity.

What does this have to do with integrity?

Re: Bzr is dying; Emacs needs to move

#302
post #258
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 doesn't show up as a merge in the history.

You might like "git pull --rebase"

Re: Bzr is dying; Emacs needs to move

#303
post #301
post #288

Earlier quoted context omitted.

I think the subsequent OK'ing is unfortunate. Attracting younger hackers shouldn't be a more important goal than integrity.

What does this have to do with integrity?

I mean, don't not fixing what ain't broke is certainly a matter of integrity. Fixing something to the latest hippest new fad just to "attract young hackers" detracts from integrity. Making the editor an awesome badass attractive editor should be enough. Otherwise you'll only be attracting groupthink-prone douchebags, anyway.

Re: Bzr is dying; Emacs needs to move

#304
post #278

Earlier quoted context omitted.

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

I get what you're saying, but it depends on how you learn it. I tried learning both of them through their official tutorials and /their CLI commands/. With git's more confusing command set, I had a harder time learning.

Re: Bzr is dying; Emacs needs to move

#305
post #46

Earlier quoted context omitted.

I've noticed this, oddly, while my workplace is transitioning to git from Mercurial. A lot of developers using .NET tend to go for Mercurial because a while back it felt a lot nicer to use on Windows. It's why I always preferred using Mercurial. A few .NET shops that use TFP/VSO are moving towards Git for the Visual Studio support, but I've noticed a few Python and PHP developers making the switch to Mercurial. To be…

> A lot of developers using .NET tend to go for Mercurial because a while back it felt a lot nicer to use on Windows. In my opinion it is more elegant. Git only works because it installs hacked up Linux utilities on Windows. In practice it might not matter but I feel dirty when I'm using "inelegant" solutions. I guess it's a matter of taste or opinion but Mercurial is easier to use too. Though if you're just working…

"Then again I've also been looking at and using Fossil for my projects because it's a single binary with no installer which makes it pretty cool in my opinion."

It actually relies on some configuration files in user's directory. I had troubles even launching it on a heavy-modified OS. I assumed it was a pretty simple and straightforward CLI tool that could work on bare-bone operating system. I was wrong!

Re: Bzr is dying; Emacs needs to move

#306
post #297

Earlier quoted context omitted.

>the GNU tools are used in a huge number of operating systems You mean linux? That isn't a huge number. >and are installed on a staggering number of devices The staggering number of devices you refer to almost exclusively run busybox or one of the similar projects. GNU software is hugely bloated and not a good choice for embedded systems. >Second, it is debatable whether sticking to Hurd was a good or a bad idea tech…

Last I heard a lot of users of Solaris and other Unixes often also use the GNU tools, though those are generally dying out in favour of Linux anyway.

Last you heard wrong then. Occasionally we begrudgingly install some GNU bloatware because some poorly written software requires it. That's about it. Every other OS already comes with its own versions of all the unix tools.

Re: Bzr is dying; Emacs needs to move

#307

Earlier quoted context omitted.

>the GNU tools are used in a huge number of operating systems You mean linux? That isn't a huge number. >and are installed on a staggering number of devices The staggering number of devices you refer to almost exclusively run busybox or one of the similar projects. GNU software is hugely bloated and not a good choice for embedded systems. >Second, it is debatable whether sticking to Hurd was a good or a bad idea tech…

GNU tools were often used on other OSes too including Solaris and other commercial Unixes but also Windows under Cygwin. Particularly GCC, make etc. but also command line tools such as grep where the default platform versions were often not as feature rich. I didn't use those platforms so others will remember and know better but I don't think huge was an obviously wrong description.

There is a big difference between "some people optionally could install GNU stuff in addition to their existing tools" and "those OSes use GNU tools".

Re: Bzr is dying; Emacs needs to move

#308

Earlier quoted context omitted.

GNU tools were often used on other OSes too including Solaris and other commercial Unixes but also Windows under Cygwin. Particularly GCC, make etc. but also command line tools such as grep where the default platform versions were often not as feature rich. I didn't use those platforms so others will remember and know better but I don't think huge was an obviously wrong description.

There is a big difference between "some people optionally could install GNU stuff in addition to their existing tools" and "those OSes use GNU tools".

>the GNU tools are used in a huge number of operating systems

Fair enough, I read "in" as a synonym for "on" but read in a less casual way the difference could be important.

Even in the "in" case I think many BSD's used GCC as the default compiler (CLANG seems to be taking over now).

Re: Bzr is dying; Emacs needs to move

#309
post #236

Earlier quoted context omitted.

I can't tell now that the other one is dead, but I believe it's link was http: while this one's is https:. I use the "https everywhere" browser extension so when I copied the URL I probably got the upgraded one. I think that explains why the dup detector didn't catch it. I don't know why this story took off and the other died. Maybe the headline?

You're probably right, I only looked at the path. Thanks for the followup.

TLS FTW. (or sometimes TLS MITM FTW.)

Re: Bzr is dying; Emacs needs to move

#310
post #236

Earlier quoted context omitted.

I can't tell now that the other one is dead, but I believe it's link was http: while this one's is https:. I use the "https everywhere" browser extension so when I copied the URL I probably got the upgraded one. I think that explains why the dup detector didn't catch it. I don't know why this story took off and the other died. Maybe the headline?

You're probably right, I only looked at the path. Thanks for the followup.

[deleted]
Post reply on HN