http://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&...
If you integrate source control with issue-tracking, you start to want source code changes to correspond to issue numbers, and changes to be pushed if an issue is in a certain state or owned by a specific developer. But you can't get this information when you are offline without access to the issue-tracker.
Either there's a case for distributed issue-tracking too, which would give you that information, or issue-tracking being centralized pushes back on source control wanting to be distributed.
I wish this was addressed in Git's assumptions.
He was definitely right about that, what I like about Linus is he really does seem to prefer to do things in as concrete and simple a way as possible instead of getting mired in abstractions.
This muddled language later turned into a muddled UI that was supposed to get cleaned up, but never did.
I'm pretty sure the only reason git took most of the mind share instead of hg was (1) github (2) Linus admiration.
- git has an 'email' centric workflow
- The index with git (git add -i) awesome for people doing patch maintenance
- the rebase workflow is great when you want to maintain against an upstream that you expect someone other than you to commit your changes to, or you have a "pre-publish" phase.
It's almost like those reasons follow the linux workflow.. almost perfectly.
My workflow for a lot of the projects I contribute to is something like:
edit -> commit (repeat as necessary) -> rebase -i -> format-patch -> send patchset by email
Which is surprising, given how rough all the email-involving commands of git are. Badly documented (git-send-email man page doesn't even come close to documenting all options properly), awful error reporting and a badly explained (although, in itself, quite sane) workflow when sending the patches.
When setting up my email setup, I consulted the underlying Perl script more than the docs :(.
That's a good observation. Git seems to assume its distributed issue-tracker is email.
- Mercurial also has an email-centric workflow, look at its mailing list: http://mercurial.markmail.org/search/?q=#query:+page:1+mid:p...
- The staging area can be achieved in hg in several ways, or it can be avoided as desired. One easy way is to just pick apart your commit with hg (c)record --amend and just keep adding to your commit as necessary.
- Rebasing has also been available in hg forever (and wasn't available in git from the beginning). We also have some really interesting changes brewing for rebasing in Mercurial: https://www.youtube.com/watch?v=4OlDm3akbqg
These ideas in hg were all for following the Linux workflow too.
Nothing against git, but it's important to not deify Linus as if he were a unique genius. He has his flaws, and so does the software that he's responsible for.
Mercurial beat git past the starting gates, but git has the advantage of being used on a very widely used, widely developed, immensely high profile project. While Hg has its own commendable set of projects, git has simply won the mindshare battle.
Could be worse: there's arch and bzr and probably some others.
Hell, even GNU/EFF are looking to ditch their own VCS in favor of git from what I understand.
GNU Emacs decided to switch from bzr to git, but GNU as a whole doesn't have a recommended VCS yet. In GNU Octave we will keep using hg. I don't think the EFF is too public about which VCS they use.
But yes, I meant "FSF", not "EFF".
Hg eventually came around but, for me, the damage had been done. It's the second biggest reason I went with git.
(The biggest, of course, is you use git if you want to interact with kernel devs. But lots of kernel devs hated git in 2005/2006. Mercurial had a reasonably big window of opportunity... all imo, fwiw)
There's a strong aversion of using tools done in Python outside of Python community. It is irrational, but it being an inherently interpreted language puts it into the same perception bucket as Perl and who'd want to use a control system written in Perl?
> So I've been thinking about this for basically months, but the way I work, I actually want to have a good mental picture of what I'm doing before I start prototyping. And while I had a high-level notion of what I wanted, I didn't have enough of a idea of the details to really start coding.
So two weeks seems reasonable to me, especially if he built a prototype first. (Did he?)
1: https://plus.google.com/102150693225130002912/posts/X2XVf9Q7...
I think that git commit, init, add, fetch, branch, checkout, merge, and push all have sane defaults and anybody can pick up very basic git usage using those commands in less than a few hours.
Things get complicated when you start looking at the details, but I don't see any way around that. And the interface doesn't change. It's just a matter of learning more flags and commands.
"I don't know how to use git"
or
"I don't know how to alias complex commands I use frequently"
Maybe you'll have better luck with the responses you get :)
It's very un-Unix.
Then again, I alias nearly all the CLI programs I use frequently. Grep's recursive search is aliased to `sr`, Python to `py`, Django's `manage.py runserver` to `run`.
That, and runit has been around for a while, though I don't know much about it.
[1] https://lkml.org/lkml/2012/12/23/75
[2] https://plus.google.com/u/0/+LinusTorvalds/posts/1vyfmNCYpi5
Edit: No need to be as explicit as Linus to be sarcastic.
Many moons ago in an organizational behavior / group decisionmaking book whose title I can never keep in mind, I read a fascinating chapter on various group structures for decisionmaking.
Of the various models, the one which works best under more circumstances is that in which there is a leadership role (so there's no indecision over what decision has been made or when it's been taken), but that role is collectively assigned based on merits.
In other words, the leaders' tenure is at the consent of the group as a whole, and can be transfered. The one decision over which the leader has no effective say (or at least: no more than any other individual) is over the question of leadership.
Strikes me as very much the model that's followed by the most successful free software projects.
I believe Linus learning some manners for himself would hardly slow down neither of Linux or Git, and nor would make him a lesser leader. Seriously, there are better ways of putting things forth, than execrating persons who contribute to Linux/Git for a living, on public mailing lists. Leaders need be responsible of their public speech. Someone who is writing curse words in all caps is not speaking responsibly by definition.
In both cases, the result doesn't seem to have hurt what matters: the project themselves and the utility they provide their users.
The goal of the projects isn't to protect tender egos. It's to get shit done and make the right decisions.
Linus answered one woman who'd criticized his behavior by noting that a key issue for him was making absolutely unambiguously clear how good or bad a given technical suggestion was. And he does that.
Here we go: https://plus.google.com/102150693225130002912
Because if you want me to "act professional," I can tell you that I'm not interested. I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm ALSO not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways.
As I commented at the time:
There's something to be said for being an equal-opportunity asshole, in a fair and balanced manner.
And in running the most effective, successful, beneficial, and largest OS development project the world has ever seen.
I see Linus's behavior as being an instance of Celine's Second Law:
Accurate communication is possible only in a non-punishing situation.
https://en.wikipedia.org/wiki/Celine's_laws\#Celine.27s\_Sec...
"Huh?" you say? But Linus is punishing communication.
No. Linus is communicating. He's expressing a clear view of what is or isn't valuable. The punishment isn't in rating the quality of contributions to the kernel, or usefulness of others' participation in the LKML. It's in criticizing the communications methods used to convey that feedback.
Yes, it may be insensitive. But fuck sensitivity
We've already got a world with multiple inits. The rationale for adopting systemd is ... troubling. Clearly, Linus has some issues with the team involved, though I don't know whether or not he's also concerned with the deep coupling.
Hauling systemd out of udev (or offering a systemd-free alternative) would also make me far happier.
Complexity is the enemy of reliability. An expression dating back, I've recently discovered, to January, 1958, and The Economist Newspaper.