Official git repository history?

Hi,

Yesterday I cloned the official git repository and for fun I checkout out the first ever commit "e83c5163316f..."

So how did Linus get those first few commits / history into the official git repository? Was the first 8 C source code files already enough to work as a basic git repository? Or did he use another revision control system and then later imported that history into the official git repository (when git was working)?

Just curious?  :-)

Regards,
  - Graeme -

Graeme Geldenhuys <graemeg@gmail.com> writes:

He did it very well, and Yes.

You would need to check out an old revision, say v0.99, and look at the original tutorial by Linus in Documentation/tutorial.txt. It was since rewritten into Documentation/gittutorial-2.txt but the original command sequence Linus used from the initial version of git was replaced with their more modern variants (e.g. Linus used "git-update-cache --add" but the updated tutorial talks about "git add" that did not exist nor Linus needed to have back then).

Junio C Hamano wrote:

Wow, very impressive! Such a little code, yet already workable.

Last night I played further with the first ever commit. I managed to figure out the sequence in which commands had to be run. Kudos to the people that decided the make the commands easier in the later versions. :-)

Regards,
  - Graeme -

Graeme Geldenhuys wrote:

Indeed. The git concept is an extremely simple one. The complexity comes when you start optimizing it, really. Producing packfiles today requires more code than made up all of git at its inception. Simple models can easily be extended with complex algorithms, while complex models generally require the simplest possible algorithm to work reliably. This design lesson has served me well over the years.

Cheers. There's about 650 of us, so that's a lot of kudos ;-)

Andreas Ericsson wrote:

That is what amazed me the most. The concept IS truly simple.

Regards,
  - Graeme -

On Tue, 30 Jun 2009, Graeme Geldenhuys wrote:

Well, in all fairness, even _I_ didn't enjoy using it at that stage. It was all very hacky, with the manual "write-tree" + "commit-tree" stuff.

But it's interesting to look at the timing:

 - Start early April

 - First git commit April 7

 - first kernel commit April 16

 - first merge: April 17 (14:47)

The time of that first merge is interesting, because it's worth correlating the git tree with the early kernel tree there. What preceded that first merge? Yup: the git 'merge-base' program was written a couple of hours before.

But the really interesting thing (to me) is that while I had tools/scripts to apply patches and to do relatively fancy tthings like merges etc basically just a couple of weeks after starting, it's telling just how long it took for something as simple as "git commit" to happen: May 30.

Never mind that it was actually just a totally trivial shell script, literally just a few lines. So it wasn't about the technology, it's very much a sign of what mattered to me.

I mean, I had a tool to create merges with conflicts back in mid-april! But something as simple as just committing the existing tree? No tools, you had to do that whole

	git-update-index ..
	commit=$(git-commit-tree $(git-write-tree) -p HEAD)
	.. type in message ..
	echo $commit > .git/HEAD

song-and-dance by hand.

Or use cogito, which explains the success of early wrappers - other people had rather different priorities than I did.

			Linus

Linus Torvalds wrote:

Very true!  It's the workings of a technical mind. ;-)  It's all about priorities.

Regards,
  - Graeme -

On Mon, 29 Jun 2009, Graeme Geldenhuys wrote:

Take a look at http://lkml.org/lkml/2005/4/8/9 and the earliest commits in the git.git repository; the directory he mentions had a non-bare repository hosting the commits up to that point, which would have been e497ea2a9b6c378f01d092c210af20cbee762475.

	-Daniel
*This .sig left intentionally blank*