GNU Emacs conversion to Git
lists.gnu.org
lists.gnu.org
To some extent, it's good he's doing this. To another, very few VCSs other than SCSS can really be called "obsolete", just primitive. Most of the time, people who go on about VCS migrations seem to be just bikeshedding and can't seem to give out specific justifications other than listing features that the upstream project likely doesn't need. It's not trivial either, changing a VCS often means changing the entire way a project is structured, for often uncertain gains.
(I'd also say that atomic commits are an excellent reason to leave CVS behind, but that can be argued.)
you should never use a vcs that has no ability to ask "is this repo in a valid state", or you may try to checkout the point version released to a large customer and be unable to do so. Data corruption can happen, even on raid drives (we're pretty sure it was a bug in the controller, but that doesn't change the effect.)
It's a smidge ironic that ESR himself is migrating a project away from it. :)
Eventually Mercurial ate Bazaar's pie and now Git is slowly eroding projects away from Mercurial. All hail Linus, who managed to create two open source systems that became de-facto industry standards.
With Linux it was the ability to use unix without having to stomp over to the university computer lab during the Finnish winter.
With git it was creating something that could handle merging patches from a disparate set of developers.
The only stand-alone software project ESR has truly driven himself is fetchmail. Fetchmail. Enough said.
I doubt ESR is posting from Windows anyway.
(setq-default ispell-program-name "c:/Aspell/bin/aspell.exe")
(add-hook 'org-mode-hook (lambda() (flyspell-mode 1)) )
(add-hook 'text-mode-hook (lambda() (flyspell-mode 1)) )
Just today I was just looking into why I wasn't getting automatic flyspell-mode activated on my Git commits. Now it seems I wont even need to research it further :)
http://savannah.gnu.org/git/?group=emacs looks valid although I didn't try cloning.
git is much saner.
Updates remote refs using local refs, while sending objects necessary to complete the given refs.
> Push changesets from the local repository to the specified destination.
:s/changesets/objects :s/local refs/local repository :s/specified destination/remote refs
Is it really that much less easy? Both require that you understand the nomenclature chosen by their respective systems ('objects'/'changesets', 'refs'/'repository').
An object is totally unspecified.
I know what a repository is when I work with version control. I've been using version control for years and I never was confused about what the repository was.
What the fuck is a ``ref''?
Git's shit.
From "man git":
"The object database contains objects of three main types: blobs, which hold file data; trees, which point to blobs and other trees to build up directory hierarchies; and commits, which each reference a single tree and some number of parent commits.
The commit, equivalent to what other systems call a "changeset" or "version", represents a
step in the project's history, and each parent represents an immediately preceding step.
Commits with more than one parent represent merges of independent lines of development.
All objects are named by the SHA-1 hash of their contents, normally written as a string of
40 hex digits. Such names are globally unique. The entire history leading up to a commit can
be vouched for by signing just that commit. A fourth object type, the tag, is provided for
this purpose.
When first created, objects are stored in individual files, but for efficiency may later be
compressed together into "pack files".
Named pointers called refs mark interesting points in history. A ref may contain the SHA-1
name of an object or the name of another ref. Refs with names beginning ref/head/ contain
the SHA-1 name of the most recent commit (or "head") of a branch under development. SHA-1
names of tags of interest are stored under ref/tags/. A special ref named HEAD contains the
name of the currently checked-out branch."It is genuinely insulting to assume me to have the time or the patience to read things like this. It's 2014. Interfaces need to be better and I refuse to use an interface that insults my time by attempting to make me learn a load of bullshit.
Interesting priorities.
"Objects" are the things that are stored in the repository, like commits and file contents.
> Updates remote refs using local refs
So, if you had a branch called "dev", and your local version pointed to a different commit than the remote version, it will update the remote "dev" to match what you've got in your local one.
> while sending objects necessary to complete the given refs.
Of course, it's likely that the whole reason that your "dev" doesn't match the remote repository's "dev" is because you've changed some stuff - why else would you be pushing? - so you've got to also upload the new commit objects that the refs refer to, plus the file-content objects that the commits specify. In other words, 'complete the given refs'.
Using some archaic VCS which nobody has heard of, and which may or may not be available on your platform of choice, certainly doesn't help herd contributors to your project.
https://lists.gnu.org/archive/html/emacs-devel/2014-11/msg00...
bazaar is the provider for code hosting.
Maybe they do offer other options but aren't really proud of it, at least not enough to put it on the first page.
Anyway, I really think being bazaar-only it's a loss for launchpad. PPA's are great, but most people I know don't want learn bazaar just for it.
But I got to thinking, early this morning, about the fact that I haven’t been able to settle on just one VCS. I use git for most things, but there’s a use case git doesn’t cover.
A fun-seeming exercise anyways, I guess it doesn't matter what tool you're using underneath.