According to this article in Mercurial wiki, its core is being re-written in Rust. Mercurial is one of the largest open-source Python projects in existence.
This does not however mean everything will be rewritten in Rust. (Yes, this post’s heading’s not entirely accurate.)
* hg is a Rust binary that embeds and uses a Python interpreter when appropriate (hg is a Python script today)
* Python code seemlessly calls out to functionality implemented in Rust
The obvious reason for the decision is startup performance concerns, but the article also (interestingly) states:
In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial’s development velocity.
Git was also designed with a core written in C and a host of shell scripts that call the core for additional functionality. For example, rebase is actually a shell script.
However, usage of shell scripts has made porting Git to Windows a pain. See the Lessons Learned section in this AOSA article.
Git 1.8.5 is now out. The RC was available for more than a month, and now it’s gone stable. One interesting change is the new alias for HEAD. From the atlassian blog:
This had been cooking for a while and it’s finally in: HEAD has a new alias, instead of typing four capital letters you can say “@” now, e.g. “git log @“.
Which means you can now just type in @^ for HEAD^ and @~2 for HEAD~2 and so on.
Among other notable changes are that git-repack (which was a shell script previously) has been rewritten in C, cherry-pick shows the commits being cherry-picked and diff-filter has got an “all-but” option.
The Jenkins guys seem to have had a rough day.
yesterday something strange has happen to many Jenkins repositories on GitHub (more then 50 Repos)…
Luca Milanesio seems have pushed to many many repositories without really changing anything – at least I have not seen anything changed.
But the folks at github have helped by restoring the state prior to the force push into a separate branch. Good old git reflog to the rescue.
Typically recovering a force push is straightforward:
1. git reflog > look at the SHA-1 before the forced push
2. git branch -f <name> <sha-1>
As far as I know, bare repos don’t have reflog enabled by default. They might have turned on core.logAllRefUpdates for all the repos at github by default.
The gist a simple git branching model has gained much popularity lately. The author mentions some drastic changes to the normal git flow like merging changes from feature branches straight into master. This is necessary to maintain simplicity.
There are some notes to the end of the gist. Among them is one titled “Don’t fork. Push feature branches to main repo.”.
Sometimes I see people forking repositories in order to issue pull-requests. Yes, you may have to do this when contributing to open-source projects you don’t regularly contribute to. But, if you are a contributor, or working in the same org, get push rights on the repo and push all your feature branches to it. Issue pull requests from one branch to another within the same repo.
Because the whole fork and pull-request mechanism can be devastating sometimes, you don’t need to consider such sophisticated schemes for small teams. Let’s face it, only a fraction developers out there have the itch to really learn the tools they are using. You’re lucky if more than half of your team is well-versed with at least the basic git commands.
When you can afford it, it’s always a good idea to have a central repo and give everyone write permissions. You can even fine-tune the permissions to specific branches if your git server runs gitolite. AFAIK, this is not possible with github or gitlab.
Git’s being used to do many more things besides version controlling code. I once wrote about tracking laws with git in Germany.
Github has introduced government.github.com. From their blog post:
Governments at all levels have been using GitHub for some time now to build better, more accessible websites, publish laws and data, and even collaborate on policies themselves.
Today we’re proud to announced the launch of government.github.com, a website dedicated to showcasing the amazing efforts of public servants and civic hackers around the globe.
Open data projects in github isn’t new. Concepts like forking your city shows the possibilities are boundless.
4b825dc642cb6eb9a060e54bf8d69288fbee4904 is a special hash value in git which denotes an empty tree. And it does not change from repo to repo. This opens way to some neat tricks, but how the hell would one remember this value? You don’t need to.
Colin Schimmelfing:
In both of the links that mentioned the special hash, it looks like there is another way to find the magic value, a little faster:
> git hash-object -t tree –stdin < /dev/null
4b825dc642cb6eb9a060e54bf8d69288fbee4904
Thus you get the hash of the ‘null’ tree.
The author of the post mentions about changing/diff-ing the first commit using this, but remember that since git 1.7.12 or so you have this awesome –root flag for git-rebase which does wonders in this particularly intimidating situation.
So, if you want to amend the initial commit or add one after some commits (humans forget), you can just:
git rebase -i –root
Now just do whatever you want in the editor window that pops up. Anything’s possible with git-rebase.
I feel stupid for not being aware of a global git ignore earlier. It’s a good approach to globally ignore those editor-specific swap files, OS-specific crap (like .DS_Store in OS X) etc. From usevim:
A better approach is to use a global option. Run git config –global core.excludesfile ~/.gitignore. Then you can add *.sw?, and perhaps *~ as well. I like to add .DS_Store because Windows developers don’t need to worry about that nonsense, and they should probably add Thumbs.db.
The trick is to add globally-ignored files into some place like ~/.gitignore and specifying this in core.excludesfile.
Just got to know that Gitlab 6.0 has been released over an week ago.
The biggest improvement I noticed in the changelog was the new merge request feature. You can fork a repo and send merge requests to the original – github style. Good news for everyone who kept away from Gitlab coz it’d break their workflows.
Some handy new features have found their way to the UI as well.
The groups still suck. They’ve continued to confuse me from the beginning. The flat structure would be okay for a small group of people, but if the organization is large (100+ developers) this can become a mess.
Also, let us organize the repos several sub-directories deep, please?
Seen in the #git freenode channel today:
circle : How do I find projects to work on in github?
bremner : fwiw, this is not a git question.
circle : true
circle : but people here would know any way
One wouldn’t go to #linux and ask them about a good keyboard to buy because everyone there use keyboards and are techy enough to know what keyboards are the best.
From Quora:
Am I the only one who thinks the phrase “Fork me on GitHub” sounds like it has sexual implications?
This is a genuine question. I’ve asked several people what they thought about the phrase and not many feel the same way I do. I started to wonder if I was the only one.
Did I think it had sexual implications? Not until now. -_-
