GNU Emacs Switches From CVS To Bazaar 198
kfogel writes "GNU Emacs, one of the oldest continuously developed free software projects around, has switched from CVS to Bazaar. Emacs's first recorded version-control commits date from August, 1985. Eight years later, in 1993, it moved to CVS. Sixteen years later, it is switching to Bazaar, its first time in a decentralized version control system. If this pattern holds, GNU Emacs will be in Bazaar for at least thirty-two years ..."
Why 32? (Score:5, Insightful)
Re:Why 32? (Score:5, Funny)
I reckon after two years they'll get bored and switch to keeping commits in directories named gnuemacs.20120415, gnuemacs.working, gnuemacs.old-dontdelete, etc.
Re:Why 32? (Score:4, Funny)
Is there a 'scary' mod? I don't see it in my list unfortunately.
Re: (Score:2)
> Is there a 'scary'
scary mod would be ambiguous with regards to ranking, some horror/apocalyptic movie fans might view as + while some others might view it as - ;-)
Re: (Score:3, Funny)
Re:Why 32? (Score:4, Insightful)
Re:Why 32? (Score:5, Funny)
Future emacs development will be hosted inside emacs, with a version control extension written in emacs lisp.
Re:Why 32? (Score:5, Funny)
THIS! IS! EMACS!
Re: (Score:2)
Best. EMACS. Comment. Ever.
Re: (Score:2, Informative)
Ok, that's fair -- it could go either way. That's what I get for trying to be too clever!
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
24 is plausible, too; an arithmetic not geometric progression.
I'm so sorry, but you are utterly wrong.
24 would perhaps be plausible in carpentry or equestrian, or if the numbers were 7 and 14, but in this case, i.e. with software, powers of two and slashdot, there are simply two and only two possible successions to that and those are indeed the 0x20 and some-funky-number-with-cowboyneal-embedded. And that's final. Move along, move along.
Re: (Score:2)
But what if the powers themselves go along a geometric progression? 2^3, 2^4, 2^5.33...
first first? (Score:5, Funny)
You'd think there'd be an emacs keystroke combo to check for duplicate words in a block of text.
Re:first first? (Score:5, Insightful)
"Search for word dupes"
(interactive)
(search-forward-regexp "[^a-z]\\([a-z]+\\) \\1[^a-z]"))
(global-set-key (kbd "<f7>") 'search-dupe-words)
Re:first first? (Score:4, Insightful)
For OP: The key sequence you are looking for is:
<C-M\>s\<\(\w+\) \1\>
Re: (Score:3, Insightful)
The key sequence you are looking for is:
<C-M\>s\<\(\w+\) \1\>
And they say Unix isn't user-friendly!
ObSimpsons (Score:5, Funny)
Disco Stu: Did you know that disco record sales were up 400% for the year ending 1976? If these trends continue... A-y-y-y!
Re:ObSimpsons (Score:4, Funny)
Re: (Score:3, Informative)
Re: (Score:2)
Right, xkcd deliberately and maliciously aped the great and wonderful Simpsons just to annoy you to the point where you'd share that gemlike nugget of profound wisdom with us. Because anybody making a similar joke to one that happened to appear on the Simpsons must be doing so only in order to desecrate our precious bodily fluids as epitomized by the Simpsons, the font of all right and true humour!
In short, you're a tard. Kindly get over yourself, then FOAD.
Re: (Score:2)
I'll take your xkcd and your Simpsons, and raise you a Southpark.
"Simpsons did it, Simpsons did it !"
News? (Score:3, Funny)
So some young whippersnappers decide to change things around and this is news?
Get off my lawn!
Cathedral & the Bazaar? Irony? (Score:5, Funny)
Wasn't Emacs used as an example of a "Cathedral" project in Raymond's paper?
Re:Cathedral & the Bazaar? Irony? (Score:4, Interesting)
I can't remember if it was in the paper offhand, but in any case Emacs development is not really very cathedral-y.
Re:Cathedral & the Bazaar? Irony? (Score:4, Interesting)
It used to be. It since opened up in reaction to Raymond's paper. The power of words...
Re:Cathedral & the Bazaar? Irony? (Score:5, Informative)
Re:Cathedral & the Bazaar? Irony? (Score:4, Funny)
Oy, too much more of this, and we'll be setting ourselves up for a paradox.
You've got GNU/Emacs which is the operating system of its own, but runs on the GNU/Linux operating system as well. And it runs on the free proprietary OS. And Emacs is also in bazaar, even though it's based on the cathedral model. But its owner is very, very fond of bazaar (and bizarre, but that's neither there nor certainly here) development, despite not using it, while also using it.
Basically, we're looking at Emacs as a self-contradiction as things stand. Too much more of this and it's going to just go *poof*.
Re: (Score:2)
Actually I thought the same thing myself when I heard about the "Cathedral and the Bazaar," but in reality it specifically compares two different free software development models. Emacs is held up as being "Cathedral"
From the Wikipedia article: [wikipedia.org]
* The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples.
Re: (Score:2)
I know, bad flydnkrtn, don't cite Wikipedia...
I think you misspel... Oh, I see.
Re: (Score:2)
Personally I think the tight control is why linux succeeded and hurd has not yet done so. There's probably nothing wrong with hurd that a few thousand people putting in a bit of time couldn't fix, but the people that would be interested are not made to feel welcome.
Re: (Score:2)
particularly operating systems. Not emacs.
I am not getting the distinction here.
Operating systems generally include a text editor.
Re: (Score:3, Informative)
Re: (Score:2)
The CVS access that started in 1993 was not network-based (since CVS didn't have networking then). You had to log into the server where the masters were. It was still an improvement over raw RCS, however.
Re: (Score:2)
Actually that fork was in the (late) 2.x days. EGCS became gcc 2.95, when the reconciliation occurred. Also, IIRC, EGCS was originally called PGCC (for Pentium GCC).
The other kewl thing (Score:2, Funny)
Is, the code for EMACS is written in vi.
Re: (Score:3, Funny)
Re: (Score:2)
M-x skynet [No match]
I had to check, just to be sure...
Emacs is in Bazaar (Score:5, Funny)
I'm waiting for someone to write a Bazaar server that runs inside Emacs. Will Emacs then update itself and become self-aware? That ought to put the Emacs vs. VI debate to rest once and for all.
Hah! (Score:3, Funny)
It will be too late! --vi
Re: (Score:2)
Re: (Score:2)
Well do it quickly! vi is already taking over myc9hg over mc8hc8hdy taking over :!rm -rf :!echo NO CARRIER
Re: (Score:2)
self-aware
Been there, done that. [sourceforge.net]
Re: (Score:3, Insightful)
what's new?; bazaar versus git (Score:5, Interesting)
I started using emacs about 7 years ago, at which point the jokes about its feature creep ("nice OS, just needs a good editor," etc.) were already probably 20 years old. A few years ago I switched to mg, which is an emacs clone that is much more lightweight. The advantage of mg is that it loads immediately, and it has all the features I actually need. So maybe I'm just a curmudgeon, but -- what is currently happening in emacs development? New features? Better performance? Bug fixes? Polishing the brasswork? I'm honestly curious why it can't just go into the same kind of masterpiece-maintenance mode as some of Knuth's projects like Tex.
As far as bazaar, my impression is that it has had a much lower profile than git, and that its main selling point seems to be that it's supposed to be easier to use than git. Here [canonical.com] is bazaar's explanation of why they think bazaar is good. Here [whygitisbetterthanx.com] is a similar sales job for git. Bazaar is used by ubuntu, sponsored by Canonical, and written in Python. You can get free bazaar-based hosting on Launchpad. Personally I've been happy with git.
Re:what's new?; bazaar versus git (Score:4, Informative)
Two recent features in the stable release are antialiased fonts and the daemon mode (speeds up invocation, but useless for those who never quit and use Emacs for everything). I am a big fan and I cannot stand using anything else when I am coding (C++, Common Lisp, Bash, HTML, LaTeX) or editing plain text (my favorite text format). I love the default integration with gcc and make, and the fact that my ~/.emacs has clever LaTeX bindings, but the main selling point for me is the (fully justified) feeling of total control. I like knowing that I can easily extend the functionality and/or disable any feature I don't like.
Re: (Score:3, Interesting)
So maybe I'm just a curmudgeon, but -- what is currently happening in emacs development? New features? Better performance? Bug fixes? Polishing the brasswork? I'm honestly curious why it can't just go into the same kind of masterpiece-maintenance mode as some of Knuth's projects like Tex.
Check out org-mode. It's a fantastical set of code for managing things in emacs. It takes a bit of setting up, but it's very powerful and awesome. It's now included standard in emacs.
Re: (Score:2)
Re:what's new?; bazaar versus git (Score:5, Insightful)
As Linus explained, the “easier” argument is gone, since they did put really hard work into git’s user interface. They knew that it was bad. And what was the normal interface back then, is now the low-level interface, with a whole new, nice interface on top. (But you can still use the low-level one, when you need it.)
Anyway, maybe it’s me, but I don’t see “easy” per se as a advantage. I prefer efficiency. And more often than I like it, easiness seems to mean less efficiency.
It’s like “Those who give up some efficiency for a little easiness, deserve neither”. ^^
Of course the same is true for too (pointlessly) complicated interfaces too. (Main examples: Emacs and VI.)
The problem is, that most programmers seem to see that level of complexity as static. But it has to adapt to the user, over time. Rise when in need, fall when not. Stepless, if possible.
Instead they think in absolute, black and white, one-dimensional spaces: Either Notepad with Clippy, or Emacs/VM.
It’s so stupid.
To me, git is a tool that is pretty nice in that aspect.
Simple committing and version management for yourself is very easy.
But if you want to do crazy stuff, like go back 10 versions, patch that one with eight other forks, wrap it, and the next five versions, into one version, and put that thing not only back into your repository, but into that of others too... then it doesn’t leave you in the rain, but gives you the tools to do it.
Re:what's new?; bazaar versus git (Score:5, Insightful)
"Anyway, maybe it's me, but I don't see "easy" per se as a advantage. I prefer efficiency. And more often than I like it, easiness seems to mean less efficiency."
And sometimes it means more.
The main issue with the interfaces to systems like emacs, or LaTeX or git (the old one; the current interface is not bad) is that they are only really efficient if you use the tools all the time. If you use emacs all day, every day then the interface is probably fine. I constantly use LaTeX and so it's really much more effective for me than a graphical typesetting-type application. If all your software lives in git repos and you work with them most days of the week then it soon becomes second nature.
But many people don't use their tools every day. I'd say that every single one of us have some tools that we do use and do like, but we simply don't need them every day or even every week. And when you're an occasional user, no matter how "power" you are, the kind of cryptic interfaces these tools have become a hindrance, not a help. The UI is not discoverable - it's not clear how to do things you may want - so when you don't use it all the time you forget how to do even simple, common tasks.
You end up spending your time searching the web or grep:ing your own shell history to remind yourself how you do stuff, and the efficiency goes straight out the window.
"So use it more often" isn't an answer. These are tools, not something you use just for their own sake. If you don't need to, say, write a report more than once every three months then you're certainly not going to create the occasional bogus document just so you don't forget how to do things in LaTeX.
So depending on the task, more than on the user, these interfaces can be a help or a major hindrance.
Re: (Score:2)
Yes. Absolutely. That was kinda the point I tried to make: The interface has to adapt.
Even git does not do that. In fact, command line interfaces are very unfriendly in that aspect. Because you don’t know what you want to do, until you know what you can do. Which in this case is hidden in directories with a thousand executables, and man pages that you can only read when you already know the name of the command.
A good shell would be like a really good RAD programming IDE.
And a good editor would be both
Re: (Score:2)
Emacs' UI is very discoverable. It has a menu bar by default these days. And it has online help with a decent index and decent search facilities. And about half a dozen different ways to search for the right command.
If you want to do X, where X is more complex than simply moving the cursor around and using the clipboard, then it is as easy to find out how to do X in Emacs as in any other editor, and often it is easier.
Re: (Score:3, Informative)
What Does It Need? (Score:5, Interesting)
Well not entirely perfect, but I have yet to find a better editor for editing code. I keep my resume as a big lisp data structure which Emacs can use to emit into any markup language I care to write an emitter for (Currently HTML and plain text, but I've been pondering writing a LaTeX one as well.)
What I'd like to see in Emacs:
Ultimately it would be nifty if Emacs could work as well with the GUI components on my desktop as it can with text mode UNIX applications, but I suppose that might be asking too much of it.
Re: (Score:2)
Clearly, this guy doesn't have a job yet.
For me, a paper napkin (it doesn't have to be clean), with whatever I can think of at the top of my head, usually does the job.
Re: (Score:2)
A better mail client, or better integration with a GUI mail client. Emacs together with Remembrance makes for an awesome mail combo, but every time I've tried to do Email in Emacs, it's been a huge effort to keep it going.
I find the Wanderlust email client for emacs is pretty damn good - give it a try.
Re: (Score:3, Interesting)
Have you thought of re-booting your Emacs addiction?
gVim was perfect - I used to write all of my documents in restructured text (gVim addon or rst2pdf to get PDFs) and all my emails with Mutt and Pine.
One day I switched to Freemind and Open Office for documents and Gmail for email ... so terribly un-geek like, but so much easier.
Never looked back.
You should give it a try.
Re: (Score:2)
Interesting. One of the main reasons why I stick to, in my case Emacs, mutt & similar tools is the extra options storing everything as (more or less) plain text gives me. If I need to search for something in my mail, I can use the standard unix tools for it (vastly superior to gmail's search features). I can easily version control my documents and actually get useful diffs from (as opposed to the uninformative "well, the file changed" you get as a history when putting a binary document in an RCS). In th
Re: (Score:3, Interesting)
I regret nothing ;) the speed and agility one gains from 'light' but imperfect solutions is far better than the effort required to do anything else.
Plain text is best of course, but binary formats are easier for dimwit colleagues to understand - and I get paid quicker that way too. We both have problems diff'ing between binary formats so most of the time they don't bother and neither do I - no loss really because most documents have a very limited lifetime (especially when you use LiveLink :). It's kind of
Re: (Score:2)
One day I switched to Freemind and Open Office for documents and Gmail for email ... so terribly un-geek like, but so much easier.
I don't care one iota about the "geekiness" of a solution. If Gmail and OO.org works for you and you can get stuff done faster, that's wonderful. Personally, I did look back after I realized I can get so much more done in vim.
Re: (Score:2)
Perfect? Not quite.
I've been using Emacs for more than 20 years, and while it is unbeatable as a text editor, it suffers in comparison with modern code editors. For example, it does not have a source browser like visual slickedit does. In fact, the open source world at present does not have a good code browser that can handle C++ or any of the other modern languages. Sorry, cscope does not cut it. Xrefactory comes close, but suffers from its own weirdnesses and is not open source anyway. Even though I am as
Re: (Score:2, Informative)
I want to use Emacs for my editor boxes in Firefox, notably.
I am doing that right now, via "It's All Text" -plugin to Firefox. The most important FF add-on after Adblock+, IMHO.
Re: (Score:2)
I did source code auditing at Data General back in the day and one of my co-workers got the code for vi assigned to him. This was
Re: (Score:2)
One feature missing from all of them (Score:2)
There's one feature that, as far as I've been able to tell, is not in any of the major version control systems, whether distributed or not. That's good support for directory-based files.
What I mean by "directory-based files" are documents that are treated as a file by the applications that know about them, and the GUI system, but are actually implemented as a directory. The major example would be MacOS package files. For example, an OmniOutliner document actually consists of a directory with the name of you
Re: (Score:2)
Personally I've been happy with git.
I love git. Oh, no, I don't actually use it myself. I love watching other people trying to use it. My God, what a usability train wreck git is. And since it's promoted by Linus, lots of people use it blindly. Love it!
Re: (Score:2)
"The advantage of mg is that it loads immediately"
Loads, loads... Hmmm. What's that? ... Oh, yeah, you mean what you do once every few years when you have to reboot for a kernel or hardware upgrade and then you log in and have to wait 10s or so until emacs fills your screen again? Is that this "load" time you're talking about?
Anybody who cares how long emacs takes to load isn't using it the Right Way(TM)*.
[*] Meaning, of course, how I use it.
Re: (Score:2)
I'm honestly curious why it can't just go into the same kind of masterpiece-maintenance mode as some of Knuth's projects like Tex.
Honestly, I always thought Knuth was kind of arrogant to ascribe this status to TeX, given that TeX is an absolute nightmare to use on a modern machine.
A modern TeX distribution is usually a 1.3gb download, doesn't support modern typefaces, and produces some of the most unintelligible error messages I've ever seen. To get other "modern" features (ie. embedding a .png or adding hyperlinks), you have to rely on unofficial extensions to the language.
There's a lot to like about TeX. I still use it for any lar
Why not git? (Score:2)
Why use Bazaar over Git?
Re: (Score:2, Insightful)
Why use Git over Bazaar?
Re:Why not git? (Score:4, Informative)
There are plenty of reasons. [whygitisbetterthanx.com]
Re: (Score:2)
GIT vs Mercurial vs Bazaar (Score:2)
Why GIT is Better Than X [whygitisbetterthanx.com]
Why Mercurial is Better Than X [whyhgisbetterthanx.com]
Why Bazaar is Better Than X [github.com]
non-joke versions of the last two (Score:5, Informative)
Why Mercurial? [red-bean.com]
Why Switch to Bazaar? [canonical.com]
How bazaar! (Score:3, Funny)
If this pattern holds, GNU Emacs will be in Bazaar for at least thirty-two years.
I'm pretty sure Emacs has already been bizarre for at least 32 years.
Re:Wow, what quality... (Score:5, Informative)
I don't know where you live, but in American English, the singular possessive of a noun ending in s can either have just ' or 's appended. See Wikipedia [wikipedia.org]. (In particular, that article makes it sound like the Chicago Manual of Style recognizes both forms as valid.)
Re:Wow, what quality... (Score:4, Funny)
It's a matter of long debate among grammarians, and I take other grammarians's point of view :-).
Re:32 years? (Score:4, Insightful)
I've used both and don't agree. Bazaar's quite good. Not that there's anything wrong with git, either. At this point in their development, I think the old rule is starting to apply: "the smaller the differences, the louder the arguments".
Re: (Score:3)
Re:32 years? (Score:5, Informative)
Speed in repositories with very large history (> 10000 commits) and in network operations, but the difference is not large. As for features, they're pretty much tied:
http://versioncontrolblog.com/comparison/Bazaar/Git/index.html [versioncontrolblog.com]
Re:32 years? (Score:5, Informative)
The difference is not large until you realize that just about anything you want to do is going to take under a second, including merges. The only place I've started to see slowdown with Git is Webkit, with 40,000 commits.
That's an important threshold. That's the difference between "I'll do it later" and instantly, almost unconsciously committing or merging. And that's good -- this is version control, you can always undo it, but you can't undo what you put off committing.
I know when I was working on a large svn project, some people put off committing (or pulling) for days because they didn't want to deal with the conflicts, branching and merging was a hassle (so, same problem), and if they made the effort to stay up-to-date (so conflicts would be small, infrequent, and manageable), it was too slow. And that was with only a few thousand revisions.
I think I just fell into this trap, though:
"the smaller the differences, the louder the arguments"
Victory #1: You're using version control!
Victory #2: You're using something distributed!
Beyond that, it's a matter of taste. I think Git is far and away the best, but the gap between git, bzr, hg, darcs, anything, is still far less than the difference between any of them and svn or cvs.
Re: (Score:2)
Victory #1: You're using version control!
Victory #2: You're using something distributed!
Actually, there's a level of victory between those two: a version control system that can manage addition and removal of directories. That was another key step forward of CVS over RCS. (Really. I remember using RCS and I won't ever go back there.)
Re: (Score:2)
Really. I remember using RCS and I won't ever go back there
What alternatives would you suggest for stuff I'm doing by myself?
Re: (Score:2)
Re: (Score:2)
I use SCCS to this day. I like it very much for situations where I am working on some files in SVN or CVS and I am still experimenting. So that I can easily go back when things do not work-out I use sccs edit and delget before I try something new, the way I might have copied to a foo.c.bak or foo.c.3 without SCCS. Then I just cvs or svn commit that dir when I have some good code.
That's largely because of the warts in CVS and SVN though.
Re: (Score:2)
Re: (Score:2)
I don't even care about that. I look at it two ways:
First, it's poor, but it works. I guess this answers my question of what Cygwin is good for.
Second, I'm always going to have a Unix fileserver anyway. Even if I switched to entirely a Windows desktop, I could store the files on a samba share and use Git over Putty.
Re:32 years? (Score:5, Informative)
I lost data [dlitz.net] as a result of bzr not supporting history rewriting. As far as I can tell, it's still not supported [launchpad.net].
I have never lost data that has been committed to a git repository, even though my build of git-svn occasionally segfaults on me.
Re: (Score:3, Insightful)
Somebody mod that up. That is an awesome rant of the best sort, one with experience, opinions, technical details, and examples.
Re:32 years? (Score:4, Insightful)
Git is written in C by people with experience doing complicated things very quickly(kernel programmers).
Bazaar is written in python.
Re: (Score:2)
Re: (Score:3, Interesting)
You should see how much of a fuss it's making with the ubuntu mailing lists.
At any rate, bazaar is politically entrenched because it's the only officially supported RCS and it's backed by the corporate might of canonical.
I'm not aware of any particular merits or demerits of either system.
Re:32 years? (Score:5, Informative)
crappy windows support
I'll give you that. Still, it does have Windows support, and all the cool kids are on unices these days -- even Macs.
too many commands, too many options,
Dude, you're a programmer. If you can't learn to use a meaningful subset and ignore the rest, you're in the wrong field.
Yes, there are a crapton of commands, but because the data model is so simple, once you get it, it's easy to understand what each command actually does just by reading its description.
Silly need for repository maintenance, ala git-gc;
Which bzr does automatically every few revisions whether you want to or not. I'm sure someone could hack a script around that if you're too lazy -- check the gc.auto config variable. In my experience, it's needed rarely enough that it's not hard to remember, and it's nice in case you screw up a repository to know that, in theory, every single commit is still there until you run 'git gc'.
incomplete, unclear documentation.
When did you last check? I found excellent documentation at git-scm.org. What's missing?
You can very easily shoot yourself in the foot with git, and accidentally destroy important history info (eg git-push --force),
You pretty much deserve what you get, there -- it's like 'rm -rf'. Any time you use --force isn't "easily", it's the fact that you didn't read the GIANT WARNING around the option. From the docs:
Usually, the command refuses to update a remote ref that is not an
ancestor of the local ref used to overwrite it. This flag disables the
check. This can cause the remote repository to lose commits; use it
with care.
I hate to say it, but RTFM.
Note also that this is again why 'git gc' exists. git-push may cause the remove repository to lose commits -- but not necessarily, and anything that hasn't been cleaned by 'git gc' can be recovered, likely with its entire tree intact.
And finally, assuming you're git-pushing to a remote repository that other people already have copies of, chances are someone will have that history. That's the beauty of a DVCS in the first place.
I will admit this:
Mercurial is a lot closer to CVS/SVN in terminology, much easier for developers to adapt to.
I thought so, too. I also thought that about bzr. I avoided Git for awhile, until I realized that all the projects I wanted to contribute to were on Github, so I forced myself to learn it.
I think the investment is well worth it.
VCS should be simple,
To a point. Think about it this way: As a programmer, your VCS is your most important tool. More important than your language, more important than your editor. You owe it to yourself to know it inside and out.
And as I said, the Git data model is simple -- ridiculously simple, back-of-an-envelope-from-memory simple. It's the tools that add features, and make it either harder or easier to use -- and I'd argue this is true of all good systems. Your filesystem is absurdly simple -- a hierarchy of directories (which can hold named references to other directories or files), and files (dumb streams of bytes). HTTP is incredibly simple, but use it properly (REST) and it's a powerful remote API.
Off the top of my hand, a Git feature for which I don't know a Mercurial equivalent -- git-cherry-pick. Want to rewrite history a bit? Create a new branch from sometime before the commits you want to change, then cherry-pick (point-and-click simple in gitk) the commits you want, in the order you want, ignoring the ones you don't. When you're ready, clobber master with your new branch.
I mean, quilt (hg mq) is cool and all, but how easy is it to rewrite history if you weren't in a quilt to begin with?
Re: (Score:2)
If you're serious about configuration management, you shouldn't be rewriting history at all. Git allows developers to very easily commit SCM atrocities. If you make a mistake that gets committed and pushed to your mainline tree, deal with it, submit a new patch fixing it, and leave the mistake showing what happened. This provides for a transparent development process and accountability.
Git may be programmer friendly, but it isn't enterprise friendly at all.
Re: (Score:2)
If you're serious about configuration management, you shouldn't be rewriting history at all.
For the times when you need to, it makes sense -- especially if you do so before the code is shared. Almost as often as I create a new commit, I'll instead do 'git commit --amend'.
If you make a mistake that gets committed and pushed to your mainline tree, deal with it, submit a new patch fixing it, and leave the mistake showing what happened.
Absolutely. But not if you catch the mistake before you push. And it's not about this:
it isn't enterprise friendly at all.
It's not about me being embarrassed. It's about making things cleaner and more readable for everyone involved. It makes everyone's life easier if I push cleaner changes. (And, since it makes everyone's life harder to rewrite public history after
Re: (Score:2)
Re:32 years? (Score:4, Informative)
Silly need for repository maintenance, ala git-gc
Git does this for you automatically.
and accidentally destroy important history info (eg git-push --force)
This is disabled in shared respositories by default, and you can run "git config receive.denyNonFastForwards true" in non-shared repositories if you somehow think you'll "accidentally" use --force even though you know better.
VCS should be simple
Git provides a very simple data structure (it's just a directed acyclic graph of commits), and a comprehensive and mature set of tools for manipulating this structure. Sure, there's a learning curve, but really it's easier to learn than, say, Ruby, and once that's done git stays out of your way and does a great job of helping you manage your changes.
Re: (Score:3, Insightful)
bzr has been sponsored by canonical for ages. It grew out of Tom Lord's Arch project, which was the first serious attempt at an open source distributed VCS.
Re: (Score:2)
arch's command-line interface was worse than git's. And starting filenames with + was just a tremendous annoyance to vi users, I think it was done intentionally.
Re: (Score:2)
you mean other than Bzr is almost certainly going to fade into obscurity?
People have heard of git and mercurial. it's rare to meet someone who has heard of bzr. I realize it's not fair that it boils down to a popularity contest, and that we should weigh the technical merits. But that is never how it works, especially developer tool software.