{"thread":{"id":"4050","subject":"[PATCH 3/3] Add a few more words to the glossary.","startedAt":"2006-05-04T04:19:54Z","lastAt":"2006-05-04T13:44:33Z","messageCount":3,"participants":["Jon Loeliger","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"19496","messageId":"E1FbVJi-0004UJ-59@jdl.com","threadId":"4050","inReplyTo":null,"subject":"[PATCH 3/3] Add a few more words to the glossary.","fromName":"Jon Loeliger","fromEmail":"jdl@jdl.com","sentAt":"2006-05-04T04:19:54Z","receivedAt":"2006-05-04T04:19:54Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"\nClean up a few entries and fix typos.\n\n    bare repository\n    cherry-picking\n    hook\n    symbolic ref\n    topic branch\n\nSigned-off-by: Jon Loeliger <jdl@jdl.com>\n\n\n---\n\n Documentation/glossary.txt |   68 ++++++++++++++++++++++++++++++++++++--------\n 1 files changed, 55 insertions(+), 13 deletions(-)\n\nb7524dc93e17807a3657f017adcbe129e16c4b94\ndiff --git a/Documentation/glossary.txt b/Documentation/glossary.txt\nindex 86196c4..f166d4f 100644\n--- a/Documentation/glossary.txt\n+++ b/Documentation/glossary.txt\n@@ -3,6 +3,17 @@ alternate object database::\n \tobject database from another object database, which is called\n \t\"alternate\".\n \n+bare repository::\n+\tA bare repository is normally an appropriately named\n+\tdirectory with a `.git` suffix that does not have a\n+\tlocally checked-out copy of any of the files under revision\n+\tcontrol.  That is, all of the `git` administrative and\n+\tcontrol files that would normally be present in the\n+\thidden `.git` sub-directory are directly present in\n+\tthe `repository.git` directory instead, and no other files\n+\tare present and checked out.  Usually publishers of public\n+\trepositories make bare repositories available.\n+\n blob object::\n \tUntyped object, e.g. the contents of a file.\n \n@@ -28,6 +39,15 @@ checkout::\n \tThe action of updating the working tree to a revision which was\n \tstored in the object database.\n \n+cherry-picking::\n+\tIn SCM jargon, \"cherry pick\" means to choose a subset of\n+\tchanges out of a series of changes (typically commits)\n+\tand record them as a new series of changes on top of\n+\tdifferent codebase.  In GIT, this is performed by\n+\t\"git cherry-pick\" command to extract the change\n+\tintroduced by an existing commit and to record it based\n+\ton the tip of the current branch as a new commit.\n+\n clean::\n \tA working tree is clean, if it corresponds to the revision\n \treferenced by the current head.  Also see \"dirty\".\n@@ -100,6 +120,16 @@ head ref::\n \tA ref pointing to a head. Often, this is abbreviated to \"head\".\n \tHead refs are stored in `$GIT_DIR/refs/heads/`.\n \n+hook::\n+\tDuring the normal execution of several git commands,\n+\tcall-outs are made to optional scripts that allow\n+\ta developer to add functionality or checking.\n+\tTypically, the hooks allow for a command to be pre-verified\n+\tand potentially aborted, and allow for a post-notification\n+\tafter the operation is done.\n+\tThe hook scripts are found in the `$GIT_DIR/hooks/` directory,\n+\tand are enabled by simply making them executable.\n+\n index::\n \tA collection of files with stat information, whose contents are\n \tstored as objects. The index is a stored version of your working\n@@ -113,10 +143,10 @@ index entry::\n \tthat file).\n \n master::\n-\tThe default branch. Whenever you create a git repository, a branch\n-\tnamed \"master\" is created, and becomes the active branch. In most\n-\tcases, this contains the local development.\n-\n+\tThe default development branch. Whenever you create a git\n+\trepository, a branch named \"master\" is created, and becomes\n+\tthe active branch. In most cases, this contains the local\n+\tdevelopment, though that is purely conventional and not required.\n \n merge::\n \tTo merge branches means to try to accumulate the changes since a\n@@ -151,10 +181,11 @@ octopus::\n \tpredator.\n \n origin::\n-\tThe default upstream branch. Most projects have one upstream\n-\tproject which they track, and by default 'origin' is used for\n-\tthat purpose.  New updates from upstream will be fetched into\n-\tthis branch; you should never commit to it yourself.\n+\tThe default upstream tracking branch. Most projects have at\n+\tleast one upstream project which they track. By default\n+\t'origin' is used for that purpose.  New upstream updates\n+\twill be fetched into this branch; you should never commit\n+\tto it yourself.\n \n pack::\n \tA set of objects which have been compressed into one file (to save\n@@ -168,7 +199,8 @@ parent::\n \tA commit object contains a (possibly empty) list of the logical\n \tpredecessor(s) in the line of development, i.e. its parents.\n \n-pickaxe:: The term pickaxe refers to an option to the diffcore routines\n+pickaxe::\n+\tThe term pickaxe refers to an option to the diffcore routines\n \tthat help select changes that add or delete a given text string.\n \tWith the --pickaxe-all option, it can be used to view the\n \tfull changeset that introduced or removed, say, a particular\n@@ -204,8 +236,8 @@ rebase::\n \tchanges from that branch.\n \n ref::\n-\tA 40-byte hex representation of a SHA1 pointing to a particular\n-\tobject. These may be stored in `$GIT_DIR/refs/`.\n+\tA 40-byte hex representation of a SHA1 or a name that denotes\n+\ta particular object. These may be stored in `$GIT_DIR/refs/`.\n \n refspec::\n \tA refspec is used by fetch and push to describe the mapping\n@@ -243,10 +275,20 @@ SCM::\n SHA1::\n \tSynonym for object name.\n \n+symbolic ref::\n+\tSee \"ref\".\n+\n+topic branch::\n+\tA regular git branch that is used by a developer to\n+\tidentify a conceptual line of development.  Since branches\n+\tare very easy and inexpensive, it is often desirable to\n+\thave several small branches that each contain very well\n+\tdefined concepts or small incremental yet related changes.\n+\n tracking branch::\n-\tA regular git branch that is used to follow changes from\n+\tA regular git branch that is used to follow changes frompointing\n \tanother repository.  A tracking branch should not contain\n-\tdirect modifications or made commits made locally.\n+\tdirect modifications or have local commits made to it.\n \tA tracking branch can usually be identified as the\n \tright-hand-side ref in a Pull: refspec.\n \n-- \n1.3.1.g3d990\n"},{"id":"19500","messageId":"7vu0868h7a.fsf@assigned-by-dhcp.cox.net","threadId":"4050","inReplyTo":"E1FbVJi-0004UJ-59@jdl.com","subject":"Re: [PATCH 3/3] Add a few more words to the glossary.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-04T05:58:01Z","receivedAt":"2006-05-04T05:58:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@jdl.com> writes:\n\n>  ref::\n> -\tA 40-byte hex representation of a SHA1 pointing to a particular\n> -\tobject. These may be stored in `$GIT_DIR/refs/`.\n> +\tA 40-byte hex representation of a SHA1 or a name that denotes\n> +\ta particular object. These may be stored in `$GIT_DIR/refs/`.\n>  \n> +symbolic ref::\n> +\tSee \"ref\".\n\nUum.  Not very clear.  Do we use that word that often?\n\nI think I used that term to differenciate between HEAD symlink\npointing at refs/heads/master and HEAD being a regular file that\nstores a line \"ref: refs/heads/master\\n\"; the latter is the\nmodern style \"textual symref\", so in that context it is not\nabout 40-byte hex at all.  And at that level it is really a\njargon to talk about one small implementation detail of HEAD, so\nI am not sure it deserves to be in the glossary.\n\n>  tracking branch::\n> -\tA regular git branch that is used to follow changes from\n> +\tA regular git branch that is used to follow changes frompointing\n>  \tanother repository.  A tracking branch should not contain\n\nI think this is a typo?\n"},{"id":"19516","messageId":"E1Fbe89-0006W5-JT@jdl.com","threadId":"4050","inReplyTo":"7vu0868h7a.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Add a few more words to the glossary.","fromName":"Jon Loeliger","fromEmail":"jdl@jdl.com","sentAt":"2006-05-04T13:44:33Z","receivedAt":"2006-05-04T13:44:33Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"So, like, the other day Junio C Hamano mumbled:\n> Jon Loeliger <jdl@jdl.com> writes:\n> \n> >  ref::\n> > -\tA 40-byte hex representation of a SHA1 pointing to a particular\n> > -\tobject. These may be stored in `$GIT_DIR/refs/`.\n> > +\tA 40-byte hex representation of a SHA1 or a name that denotes\n> > +\ta particular object. These may be stored in `$GIT_DIR/refs/`.\n> >  \n \n> Uum.  Not very clear.  Do we use that word that often?\n\nWell, I was mystified a bit too, and I tried to clean it up some...\n\"ref\" gets used as half a <refspec>, from pull-fetch-param.txt:\n\n\tA parameter <ref> without a colon is equivalent to <ref>: when\n\tpulling/fetching, so it merges <ref> into the current branch\n\twithout storing the remote branch anywhere locally\n\nSo maybe I was confused here.\n\n> > +symbolic ref::\n> > +\tSee \"ref\".\n>\n> I think I used that term to differenciate between HEAD symlink\n> pointing at refs/heads/master and HEAD being a regular file that\n> stores a line \"ref: refs/heads/master\\n\"; the latter is the\n> modern style \"textual symref\", so in that context it is not\n> about 40-byte hex at all.  And at that level it is really a\n> jargon to talk about one small implementation detail of HEAD, so\n> I am not sure it deserves to be in the glossary.\n\nGiven \"git-symbolic-ref <name> [<ref>]\", clearly I just botched it.\nYou were right to drop my confused \"symbolic ref\" entry. :-(\n\n> >  tracking branch::\n> > -\tA regular git branch that is used to follow changes from\n> > +\tA regular git branch that is used to follow changes frompointing\n> >  \tanother repository.  A tracking branch should not contain\n> \n> I think this is a typo?\n\nYes.  Thanks for noticing and cleaning.\n\njdl\n"}]}