{"thread":{"id":"7289","subject":"any info getting a birdview of Git and its test suite?","startedAt":"2007-03-18T07:43:30Z","lastAt":"2007-03-19T17:34:04Z","messageCount":11,"participants":["F","Brian Gernhardt","Jakub Narebski","Johannes Schindelin","Robin Rosenberg","Andy Parkins","Nicolas Pitre","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"37358","messageId":"3b051c1a0703180043n1dec45by90e5cee3393d2b4d@mail.gmail.com","threadId":"7289","inReplyTo":null,"subject":"any info getting a birdview of Git and its test suite?","fromName":"F","fromEmail":"ff.pptux@gmail.com","sentAt":"2007-03-18T07:43:30Z","receivedAt":"2007-03-18T07:43:30Z","isPatch":false,"sender":{"key":"ff.pptux@gmail.com","avatar":null},"body":"Hi,\n I'm interested in the \"More Complete Tests\" project in SoC2007.\nI've used Linux for about more than one year and know basic bash\nskills. I've downloaded the source of Git and read some test scripts\nin the t directory. But I get confused.\n\n As said in the gitwiki page, I'm new to Git and Open Source\nDevelopment. I just know the basic usage and cannot figure out how one\ncomponent interacts with each other in a few days. It's hard for me to\nwrite a decent plan on how to impove existing test scripts and on\nwriting a new one. So is there any infomation getting a birdview of\narchitecture of Git and its test suite? Or the only way is to read the\ncode?\n\n By the way, are there many experienced guys applying for this project?\n Thanks very much!\n-- \npptux\n"},{"id":"37380","messageId":"CCA1B104-B1AB-45C0-8EFD-B0408E2C5CED@silverinsanity.com","threadId":"7289","inReplyTo":"3b051c1a0703180043n1dec45by90e5cee3393d2b4d@mail.gmail.com","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-03-18T15:57:51Z","receivedAt":"2007-03-18T15:57:51Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Mar 18, 2007, at 3:43 AM, F wrote:\n\n> So is there any infomation getting a birdview of architecture of \n> Git and\n> its test suite? Or the only way is to read the code?\n\nThe code is a great place to find out details, but I find it a little \nconfusing if you don't have some understanding. Thankfully, the \ndocumentation is actually pretty thorough. And the existing tests \nuse the git commands is ways similar to a user, so it's a good way to \nget a grasp. Any questions about a specific section of git can be \ndirected to the list or IRC. We're a pretty educational bunch (in a \nvariety of ways).\n\n~~ Brian\n"},{"id":"37423","messageId":"etkj4l$li$1@sea.gmane.org","threadId":"7289","inReplyTo":"3b051c1a0703180043n1dec45by90e5cee3393d2b4d@mail.gmail.com","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-03-18T23:48:37Z","receivedAt":"2007-03-18T23:48:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\n\nF wrote:\n\n> I'm interested in the \"More Complete Tests\" project in SoC2007.\n> I've used Linux for about more than one year and know basic bash\n> skills. I've downloaded the source of Git and read some test scripts\n> in the t directory. But I get confused.\n> \n> As said in the gitwiki page, I'm new to Git and Open Source\n> Development. I just know the basic usage and cannot figure out how one\n> component interacts with each other in a few days. It's hard for me to\n> write a decent plan on how to impove existing test scripts and on\n> writing a new one. So is there any infomation getting a birdview of\n> architecture of Git and its test suite? Or the only way is to read the\n> code?\n\nFirst, it would be hard to work on Git in my opinion if you have no\nexperience with version control (SCM) software.\n\nSecond, Git comes with two tutorials (and third in the works, check\nout mailing list archives; stalled), user's manual, and introduction\nand tutorial to core git. It has its own homepage, and its own wiki.\n\nThird, t/README and comments in t/test-lib.sh should help with setting\nup tests for git commands behavior.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"37427","messageId":"Pine.LNX.4.63.0703190119140.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7289","inReplyTo":"etkj4l$li$1@sea.gmane.org","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-19T00:20:15Z","receivedAt":"2007-03-19T00:20:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Mar 2007, Jakub Narebski wrote:\n\n> First, it would be hard to work on Git in my opinion if you have no \n> experience with version control (SCM) software.\n\nI have to disagree. Git is substantially more sane than CVS, so that it is \nactually _simpler_ to learn Git than to unlearn CVS and _then_ learn Git.\n\nCiao,\nDscho\n"},{"id":"37429","messageId":"200703190126.02948.jnareb@gmail.com","threadId":"7289","inReplyTo":"Pine.LNX.4.63.0703190119140.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-03-19T00:26:02Z","receivedAt":"2007-03-19T00:26:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Mon, 19 Mar 2007, Jakub Narebski wrote:\n> \n>> First, it would be hard to work on Git in my opinion if you have no \n>> experience with version control (SCM) software.\n> \n> I have to disagree. Git is substantially more sane than CVS, so that it is \n> actually _simpler_ to learn Git than to unlearn CVS and _then_ learn Git.\n\nWell, experience may consist of few days playing with Git. But it is not\nwhat I wanted to say. I wanted to say that before doing any work on Git\ntests one should get to know what SCM is about.\n\nBy the way, in \"more extensive tests\" did you want also tests of Git _API_,\nand not only git commands (porcelain and plumbing)? IIRC the \"more tests\"\nproposal for SoC2007 was by you...\n\n(And yes, I think that Git has most sane ideas about SCM).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"37430","messageId":"200703190128.42212.robin.rosenberg.lists@dewire.com","threadId":"7289","inReplyTo":"Pine.LNX.4.63.0703190119140.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-03-19T00:28:41Z","receivedAt":"2007-03-19T00:28:41Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndag 19 mars 2007 01:20 skrev Johannes Schindelin:\n> Hi,\n> \n> On Mon, 19 Mar 2007, Jakub Narebski wrote:\n> \n> > First, it would be hard to work on Git in my opinion if you have no \n> > experience with version control (SCM) software.\n> \n> I have to disagree. Git is substantially more sane than CVS, so that it is \n> actually _simpler_ to learn Git than to unlearn CVS and _then_ learn Git.\n\nI have to agree (with Johannes). Even if you have no or little experience with SCM\ntools, that *can* be learnt. It not magic, after all and not having the baggage of\nother tools means there's nothing to confuse you.\n\n-- robin\n"},{"id":"37435","messageId":"Pine.LNX.4.63.0703190120270.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7289","inReplyTo":"3b051c1a0703180043n1dec45by90e5cee3393d2b4d@mail.gmail.com","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-19T01:31:47Z","receivedAt":"2007-03-19T01:31:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 18 Mar 2007, F wrote:\n\n> As said in the gitwiki page, I'm new to Git and Open Source \n> Development. I just know the basic usage and cannot figure out how one \n> component interacts with each other in a few days. It's hard for me to \n> write a decent plan on how to impove existing test scripts and on \n> writing a new one. So is there any infomation getting a birdview of \n> architecture of Git and its test suite? Or the only way is to read the \n> code?\n\nOkay, I'll have a try at a short HOWTO find out how things are organized \nin Git's source code.\n\nI think a good idea is to look at the contents of the initial commit:\ne83c5163316f89bfbde7d9ab23ca2e25604af290\n\nTip: you can see what files are in there with\n\n$ git show e83c5163316f89bfbde7d9ab23ca2e25604af290:\n\nand look at those files with something like\n\n$ git show e83c5163316f89bfbde7d9ab23ca2e25604af290:cache.h\n\nBe sure to read the README in that revision _after_ you are familiar with \nthe terminology (Documentation/glossary.txt should help), since the \nterminology has changed a little since then. For example, we call the \nthings \"commits\" now, which are described in that README as \"changesets\".\n\nActually a lot of the structure as it is now can be explained by that \ninitial commit.\n\nFor example, we do not call it \"cache\" any more, but \"index\", however, the \nfile is still called \"cache.h\". (Not much reason to change it now, \nespecially since there is no good single name for it anyway, because it is \nbasically _the_ header file which is included by _all_ Git C sources).\n\nIf you grasp the ideas in that initial commit (and I keep harping on it, \nsince it is really _small_ and you can get into it really fast, and it \nwill help you recognize things in the much larger code base we have now), \nyou should go on skimming cache.h, object.h and commit.h.\n\nBy now, you know what the index is (and find the corresponding data \nstructures in cache.h), and that there are just a couple of objects \n(blobs, trees, commits and tags) which inherit their common structure from \n\"struct object\", which is their first member (and thus, you can case e.g. \n(struct object *)commit to achieve the _same_ as &commit->object, i.e. get \nat the object name and flags).\n\nOkay. End of first lesson.\n\nNext step: get familiar with the object naming. Read \"SPECIFYING \nREVISIONS\" in Documentation/rev-parse.txt. There are quite a few ways to \nname an object (and not only revisions!). All of these are handled in \nsha1_name.c.\n\nThis is just to get you into the groove for the most libified part of Git: \nthe revision walker.\n\nBasically, the initial version of \"git log\" was a shell script:\n\n$ git-rev-list --pretty $(git-rev-parse --default HEAD \"$@\") | \\\n\tLESS=-S ${PAGER:-less}\n\nWhat does this mean?\n\ngit-rev-list is the original version of the revision walker, which \n_always_ printed a list of revisions to stdout. It is still functional, \nand needs to, since most new programs start out as scripts using rev-list.\n\ngit-rev-parse is not as important any more; it was only used to filter out \noptions that were relevant for the different plumbing commands that were \ncalled by the script.\n\nMost of what rev-list did is contained in revision.[ch]. It wraps the \noptions in a struct named rev_info, which controls how and what revisions \nare walked, and more.\n\nNowadays, git-log is a builtin, which means that it is _contained_ in the \ncommand `git`. The source side of a builtin is\n\n- a function called cmd_, typically defined in builtin-.c, and \n declared in builtin.h,\n\n- an entry in the commands[] array in git.c, and\n\n- an entry in BUILTIN_OBJECTS in the Makefile.\n\nSometimes, more than one builtins are contained in one source file. For \nexample, cmd_whatchanged() and cmd_log() both reside in builtin-log.c, \nsince they share quite a bit of code. In that case, the commands which are \n_not_ named like the .c file they are defined in have to be listed in \nBUILT_INS in the Makefile.\n\ngit-log looks more complicated in C than it does in script, but that \nallows for a much greater flexibility and performance.\n\nEnd of lesson two.\n\nLesson three is: study the code. Really, it is the best way to learn about \nthe organization of Git (after you know the basic concepts).\n\nSo, think about something which you are interested in, say, \"how can I \naccess a blob just knowing the object name of it?\". The first step is to \nfind a Git command with which you can do it. In this example, it is either \n\"git show\" or \"git cat-file\".\n\nFor the sake of clarity, I will stay with cat-file, because it\n\n- is plumbing, and\n\n- was around even in the initial commit (it literally went only through \n some 20 revisions as cat-file.c, was renamed to builtin-cat-file.c when \n made a builtin, and then saw less than 10 versions).\n\nSo, look into builtin-cat-file.c, search for cmd_cat_file() and look what \nit does.\n\n git_config(git_default_config);\n if (argc != 3)\n usage(\"git-cat-file [-t|-s|-e|-p|] \");\n if (get_sha1(argv[2], sha1))\n die(\"Not a valid object name %s\", argv[2]);\n\nI'll not bore you with obvious details; the only really interesting part \nhere is the call to get_sha1(). It tries to interpret argv[2] as an object \nname, and if it refers to an object which is present in the current \nrepository, it writes the resulting SHA-1 into the variable \"sha1\".\n\nTwo things are interesting here:\n\n- get_sha1() returns 0 on _success_. This might surprise some new \n Git hackers, but there is a long tradition in UNIX to return different \n negative numbers in case of different errors -- and 0 on success.\n\n- the variable \"sha1\" in the function signature of get_sha1() is \"unsigned \n char *\", but is actually expected to be a pointer to \"unsigned \n char[20]\". This variable will contain the big endian version of the \n 40-character hex string representation of the SHA-1.\n\nYou will see both of these things throughout the code.\n\nNow, for the meat:\n\n case 0:\n buf = read_object_with_reference(sha1, argv[1], &size, NULL);\n\nThis is how you read a blob (actually, not only a blob, but any type of \nobject). To know how the function read_object_with_reference() actually \nworks, find the source code for it (I usually just something like \"git \ngrep read_object_with | grep \":[a-z]\"\" in the git repository), and read \nthe source.\n\nTo find out how the result can be used, just read on in cmd_cat_file():\n\n write_or_die(1, buf, size);\n\nSometimes, you do not know where to look for a feature. I like to search \nthrough the output of git-log, and then git-show the corresponding commit.\n\nExample: I know that there was some test case for git-bundle, but I do not \nremember where it was (yes, I could \"git grep bundle t/\", but that does \nnot illustrate my point!):\n\n$ git log --no-merges t/\n\nIn the pager (\"less\"), I just search for \"bundle\", go a few lines back, \nand see that it is in commit 18449ab0... I just copy this object name, and \npaste it into the command line\n\n$ git show 18449ab0\n\nVoila.\n\nAnother example: Find out what to do in order to make some script a \nbuiltin:\n\n$ git log --no-merges --diff-filter=A builtin-*.c\n\nYou see, Git is actually the best tool to find out about the source of Git \nitself!\n\nI hope that this gives you a fast track into the organization of Git's \nsource code. If not, please feel free to ask questions...\n\nCiao,\nDscho\n"},{"id":"37485","messageId":"200703191152.07686.andyparkins@gmail.com","threadId":"7289","inReplyTo":"Pine.LNX.4.63.0703190120270.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-19T11:52:05Z","receivedAt":"2007-03-19T11:52:05Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 March 19 01:31, Johannes Schindelin wrote:\n\n> Okay, I'll have a try at a short HOWTO find out how things are organized\n> in Git's source code.\n\nThat was fabulous. I learnt some very interesting things.\n\nCan I suggest that this should be a wiki page or even \nDocumentation/developer-tutorial.txt?\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"37501","messageId":"Pine.LNX.4.63.0703191517320.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7289","inReplyTo":"200703191152.07686.andyparkins@gmail.com","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-19T14:18:21Z","receivedAt":"2007-03-19T14:18:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Mar 2007, Andy Parkins wrote:\n\n> On Monday 2007 March 19 01:31, Johannes Schindelin wrote:\n> \n> > Okay, I'll have a try at a short HOWTO find out how things are organized\n> > in Git's source code.\n> \n> That was fabulous. I learnt some very interesting things.\n\nThanks! I'm glad that my work was useful to you.\n\n> Can I suggest that this should be a wiki page or even \n> Documentation/developer-tutorial.txt?\n\nList?\n\nI'll make the patch, or the copy & paste...\n\nCiao,\nDscho\n"},{"id":"37515","messageId":"alpine.LFD.0.83.0703191210550.18328@xanadu.home","threadId":"7289","inReplyTo":"Pine.LNX.4.63.0703191517320.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-03-19T16:12:51Z","receivedAt":"2007-03-19T16:12:51Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 19 Mar 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 19 Mar 2007, Andy Parkins wrote:\n> \n> > On Monday 2007 March 19 01:31, Johannes Schindelin wrote:\n> > \n> > > Okay, I'll have a try at a short HOWTO find out how things are organized\n> > > in Git's source code.\n> > \n> > That was fabulous. I learnt some very interesting things.\n> \n> Thanks! I'm glad that my work was useful to you.\n> \n> > Can I suggest that this should be a wiki page or even \n> > Documentation/developer-tutorial.txt?\n> \n> List?\n\nI think it certainly should appear in Documentation/howto/ at least.\n\n\nNicolas\n"},{"id":"37527","messageId":"20070319173404.GB29272@fieldses.org","threadId":"7289","inReplyTo":"Pine.LNX.4.63.0703191517320.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: any info getting a birdview of Git and its test suite?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-03-19T17:34:04Z","receivedAt":"2007-03-19T17:34:04Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Mar 19, 2007 at 03:18:21PM +0100, Johannes Schindelin wrote:\n> \n> On Mon, 19 Mar 2007, Andy Parkins wrote:\n> > Can I suggest that this should be a wiki page or even \n> > Documentation/developer-tutorial.txt?\n> \n> List?\n> \n> I'll make the patch, or the copy & paste...\n\nI've had this vague plan to suck more of the documentation into the user\nmanual: the advantage is you get an automatic table of contents that\nway, and eventually maybe an index, so hopefully stuff is more findable.\n\nSo maybe consider adding this as a chapter 9, called something like\n\"Understanding Git's Source Code\", with the \"lessons\" as subsections?\n\nIt stretches the definition of the \"user\" in \"user manual\" a bit, but I\nkinda like that.\n\n--b.\n"}]}