jacknagel

>But then I found that that email address is shared to the whole world in git commit summary!

If you're talking about the email address in the commit itself, that's part of the commit object and not anything GitHub does behind your back. If you publish the commit anywhere, not just GitHub, the email address has become public knowledge.

You might find `git add -N` ("--intent-to-add") useful. It's an extra step, yes, but it allows you to e.g. view the content of new files with `git diff` without actually staging the content for commit, and will allow you to stage that file during `git add -p`.

Sorry, should be

    HISTIGNORE=ssh*

Like many shell variables, this one is a colon-separated list.

HISTIGNORE=ssh

It won't strip existing lines, but will prevent them from being recorded in the future.

IIRC (I read the git mailing list) there was a lot of arguing about whether generation numbers should be in the commit headers or stored in separate cache, and then a different fix went in to speed up "tag --contains" and the discussion was pretty much abandoned.

Does anyone know how to adjust the line height?

In 1.x I could do

    defaults write com.macromates.TextMate OakLineHeightDelta n

git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it yourself, you decide where line breaks should be, not the presentation machinery.

The optimal human-readable line length is something like 66 characters. It's much easier to quickly scan a log message that's 72 characters wide vs. one that is 200 characters wide.

It's hard to understate the importance of this.

GitHub's online editor has a default commit message along the lines of "Edited path/to/file", and I see a lot of pull requests with that message, and nothing else. That's about the most useless message possible, since it adds no information that isn't already implicit in the commit. It would be better to leave it blank and force users to at least write _something_.

Actually if you follow the thread(s) relating to this, a less invasive change to speed up "git tag --contains" was adopted (see git.git@ffc4b8012), so "soon" probably isn't the right word.

Awesome.

Just for kicks, here's a (terribly ugly) pipeline that will display the contents of .nls and `ls`, with duplicates removed:

ls | cat .nls - | column -t -s: | sort -r | perl -ane 'print unless $x{$F[0]}++'

and then obviously just echo "dirname: description" >> .nls to append to the file.

I would be interested in seeing a better pipeline, one that doesn't need perl/awk/ruby/what have you to remove the duplicates correctly.

So the author has reached this conclusion after _several hours_ of using Lion?

Yes, in most cases, but most packages have minimal dependencies due to Homebrew's "use what OS X provides" philosophy, i.e., the XCode toolchain (Homebrew doesn't even have a package for GCC).

FWIW, Homebrew only needs gcc 4.0 for a select few formula. The vast majority of them build with more modern compilers (gcc 4.2, llvm-gcc, and clang are supported; and I use a non-Apple gcc 4.6 to compile things occasionally).

Minor smackdown from this thread here: http://article.gmane.org/gmane.comp.version-control.git/1771...

Troll. Nothing to see here.

Edit:

> I am simply trying to develop an application, is there a good reason why I am compiling libxml2 and all of its dependencies?

I'm pretty sure that libxml2 has no dependencies other than the standard C library.

Agreed--there is way too much of this. A member of my family has Asperger's, is on medication and regularly sees a psychiatrist. It's insulting to him and everyone who has a clinical diagnosis when people throw the term around like that.

Twitterific has Twitter in the name, and it's been around for ages.

It's also possible that Xcode 4 is only on the App Store because Lion is going to be on the App Store, and people who buy a physical copy of Lion will get Xcode 4 on the disc.

I have a 2006 Core Duo MBP also. Running file on the binary produces this:

Pixelfari: Mach-O 64-bit executable x86_64

Guess I'll have to find a 64-bit Mac so that I can play with it.