What does HackerNews think of git?
Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documentation/SubmittingPatches procedure for any of your improvements.
But Perl still has a lot to offer (CPAN, backwards compatibility, speed). Go look for example at Git (https://github.com/git/git), not a small nor insignificant project. It says there is 5.9% Perl and 0.9% Python there. Maybe some intelligent geeks out there still appreciate Perl, and Perl still does a good job.
Just use what suits your needs and tastes.
Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your mood):
If you don't believe me, clone git itself ($ git clone https://github.com/git/git) and open up the repo in tig(1)
To be honest, I only in the past 2 years even bothered to view ($ git log --graph). Regardless of --graph getting wide now and then, I always visualize my git history as a straight line.
Also, sometimes having a non-linear history is inevitable. Especially in large open source projects where you're pulling in patches to a branch, and patches on top of that. You're not always going to be merging a branch with a single author straight onto master.
Despite posts like this (http://www.bitsnbites.eu/a-tidy-linear-git-history/) encouraging good git hygiene, I've had multiple open source projects merge in code via GitHub and never had negative consequence for it :P
Maybe there are corner cases where git bisect wouldn't work? Though I never used git bisect even once. Most I do is scroll through tig and view diffs. Also used to play with a cool git plugin in vim (https://github.com/tpope/vim-fugitive).
Also, GitHub has (since that linear git history post) introduced Rebase + Merge https://github.com/blog/2243-rebase-and-merge-pull-requests. I think that'll get you what you want.
I do keep branches ("pull requests" if you're using GH lingo) up to date with ($ git pull --rebase). That does mean a force push ($ git push --force), but it's ok if it's your personal branch. I also use interactive mode ($ git rebase -i ) to edit/blend multiple commits.
Also, when I do merge, if I go through CLI, I'll preserve the history of the branch by not doing fast forwards ($ git merge --no-ff).
I don’t think so. Look at the Git sources (https://github.com/git/git). Most of the C source files are in the top directory.
Some other people like to write unit test in the same directories as the source files, by adding a `.test` suffix to each source file name.
Some other people like to embed unit tests in source files, “à la” Rust.
There is no One True rule. Not organizing things the way you do is not necessarily bad.
To give examples:
- Git https://github.com/git/git,
- Linux https://github.com/torvalds/linux,
- LibreOffice https://github.com/LibreOffice/core,
- Firefox https://github.com/mozilla/gecko-dev
apt-get install git
pacman -Sy git
emerge --ask dev-vcs/git
yum install gitGithub's previous policy was to allow any content that did not expressly break American laws. I thought this was a good idea, and it was the justification behind keeping the GreatFire repo up, even in the face of DoS attacks by China. Very commendable, IMO. However, when they start censoring people who break no laws, I do think they are more likely to censor things in the future.
Lastly, I'd like to point out that "git" is an offensive word to some people. It was chosen by Linus Torvalds for that reason. Now that Github has demonstrated their willingness to censor words that hurt people's feelings, would they consider censoring this awful project? [1] While they're at it, could they change their name too?
Git's commit log is probably the most detailed and informative log I've ever seen. And it's a bit fun to have a glance at Linus Torvald's old initial commits from 2005 :-)
(You might want to check the 'pu' branch rather than the 'master' branch. And there're lots of 'Merge branch...' commits that aren't super interesting.)
If I recall it is like 500-ish lines of code, compiles easily, and is runnable. It makes a little .git folder. It's only the "plumbing" of git, back when it was a "content tracker".
Linus used to brag that it was self hosting in 3 days or something like that, and presumably this is what he was talking about.
It helps you understand the design of git for sure, and gave me an appreciation for Linus's coding style. I didn't really think he had a great sense of style because Linux is known to be somewhat of a smorgasbord. Git itself also has a sloppy and confusing interface IMO, but that's a different issue.
I didn't follow it any further than the first commit, but I bet you could learn a lot that way. (You would also presumably see how nobody designed the interface and it just accumulated commands and flags in a haphazard fashion)
I've never looked at .git/logs, but it looks like that is used by the `git reflog` command. It's basically a history (or log) of every commit that a particular reference has pointed to[1]. For example, I cloned the git source code:
user@host ~/src/git % cat .git/logs/HEAD\n 0000000000000000000000000000000000000000 d7aced95cd681b761468635f8d2a8b82d7ed26fd First Last 1387237920 -0500\tclone: from https://github.com/git/git.git\n\n user@host ~/src/git % git reflog\n d7aced9 HEAD@{0}: clone: from https://github.com/git/git.git\n ~/src/git $ cat .git/HEAD\n ref: refs/heads/master\n\n ~/src/git $ cat .git/refs/heads/master\n d7aced95cd681b761468635f8d2a8b82d7ed26fd\n> What are the SHA-1 sums of? Are they of the entire snapshot, or the delta? I went into objects/ and ran `sha1sum $objfile`, and the sum did not match the file name. So that remains obscure.
See: http://stackoverflow.com/questions/5290444/why-does-git-hash...
[1]: Since the local repository was created. This information does not sync between local and remote.
The fixed-size int finally got a permanent solution: #include
If you are targeting autoconf/automake as your build system, that has a lot of built-in solutions to portability issues, like defining macros. It's not easy to learn, and I don't pretend to know it well, but when I'm compiling someone else's project, I'm always happy to see a configure script.
The gtk project's libglib is a pretty comprehensive library of C data structures. The Apache Portable Runtime serves a similar purpose: http://en.wikipedia.org/wiki/Apache_Portable_Runtime
What I find annoying about libraries like glib is that they tend to impose their own style on your project by using their own typedef'ed types and such.
If you don't mind it, you can cobble together your own data structures from various open-source projects. Judy arrays are pretty fast, and you can use them in a variety of ways. Searching google for "c hash table" came up with a lot of excellent results, so try googling whatever data structure or algorithm you need, and chances are, you'll find something.
I don't really use the github file browser frequently enough to be able to tell if the async loading of the files/directories is what you're referring to. Plus, linking to the github home page was kind of confusing.