{"thread":{"id":"1556","subject":"First stab at glossary","startedAt":"2005-08-17T14:56:48Z","lastAt":"2005-09-04T17:23:23Z","messageCount":17,"participants":["Johannes Schindelin","Daniel Barkalow","Junio C Hamano","Tim Ottinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7445","messageId":"Pine.LNX.4.63.0508171655250.13502@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1556","inReplyTo":null,"subject":"First stab at glossary","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-17T14:56:48Z","receivedAt":"2005-08-17T14:56:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nlong, long time. Here´s my first stab at the glossary, attached the \nalphabetically sorted, asciidoc marked up txt file (Comments? \nSuggestions? Pizzas?):\n\nobject::\n\tThe unit of storage in GIT. It is uniquely identified by\n\tthe SHA1 of its contents. Consequently, an object can not\n\tbe changed.\n\nSHA1::\n\tA 20-byte sequence (or 41-byte file containing the hex\n\trepresentation and a newline). It is calculated from the\n\tcontents of an object by the Secure Hash Algorithm 1.\n\nobject database::\n\tStores a set of \"objects\", and an individial object is identified\n\tby its SHA1 (its ref). The objects are either stored as single\n\tfiles, or live inside of packs.\n\nobject name::\n\tSynonym for SHA1.\n\nblob object::\n\tUntyped object, i.e. the contents of a file.\n\ntree object::\n\tAn object containing a list of blob and/or tree objects.\n\t(A tree usually corresponds to a directory without\n\tsubdirectories).\n\ntree::\n\tEither a working tree, or a tree object together with the\n\tdependent blob and tree objects (i.e. a stored representation\n\tof a working tree).\n\ncache::\n\tA collection of files whose contents are stored as objects.\n\tThe cache is a stored version of your working tree. Well, can\n\talso contain a second, and even a third version of a working\n\ttree, which are used when merging.\n\ncache entry::\n\tThe information regarding a particular file, stored in the index.\n\tA cache entry can be unmerged, if a merge was started, but not\n\tyet finished (i.e. if the cache contains multiple versions of\n\tthat file).\n\nindex::\n\tContains information about the cache contents, in particular\n\ttimestamps and mode flags (\"stat information\") for the files\n\tstored in the cache. An unmerged index is an index which contains\n\tunmerged cache entries.\n\nworking tree::\n\tThe set of files and directories currently being worked on.\n\tThink \"ls -laR\"\n\ndirectory::\n\tThe list you get with \"ls\" :-)\n\ncheckout::\n\tThe action of updating the working tree to a revision which was\n\tstored in the object database.\n\nrevision::\n\tA particular state of files and directories which was stored in\n\tthe object database. It is referenced by a commit object.\n\ncommit::\n\tThe action of storing the current state of the cache in the\n\tobject database. The result is a revision.\n\ncommit object::\n\tAn object which contains the information about a particular\n\trevision, such as parents, committer, author, date and the\n\ttree object which corresponds to the top directory of the\n\tstored revision.\n\nchangeset::\n\tBitKeeper/cvsps speak for \"commit\". Since git does not store\n\tchanges, but states, it really does not make sense to use\n\tthe term \"changesets\" with git.\n\nent::\n\tFavorite synonym to \"tree-ish\" by some total geeks.\n\nclean::\n\tA working tree is clean, if it corresponds to the revision\n\treferenced by the current head.\n\ndirty::\n\tA working tree is said to be dirty if it contains modifications\n\twhich have not been committed to the current branch.\n\nhead::\n\tThe top of a branch. It contains a ref to the corresponding\n\tcommit object.\n\nbranch::\n\tA non-cyclical graph of revisions, i.e. the complete history of\n\ta particular revision, which does not (yet) have children, which\n\tis called the branch head. The branch heads are stored in\n\t$GIT_DIR/refs/heads/.\n\nref::\n\tA 40-byte hex representation of a SHA1 pointing to a particular\n\tobject. These are stored in $GIT_DIR/refs/.\n\nhead 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\ntree-ish::\n\tA ref pointing to either a commit object, a tree object, or a\n\ttag object pointing to a commit or tree object.\n\ntag object::\n\tAn object containing a ref pointing to another object. It can\n\tcontain a (PGP) signature, in which case it is called \"signed\n\ttag object\".\n\ntag::\n\tA ref pointing to a tag or commit object. In contrast to a head,\n\ta tag is not changed by a commit. Tags (not tag objects) are\n\tstored in $GIT_DIR/refs/tags/. A git tag has nothing to do with\n\ta Lisp tag (which is called object type in git's context).\n\nmerge::\n\tTo merge branches means to try to accumulate the changes since a\n\tcommon ancestor and apply them to the first branch. An automatic\n\tmerge uses heuristics to accomplish that. Evidently, an automatic\n\tmerge can fail.\n\nresolve::\n\tThe action of fixing up manually what a failed automatic merge\n\tleft behind.\n\nrepository::\n\tA collection of refs together with an object database containing\n\tall objects, which are reachable from the refs. A repository can\n\tshare an object database with other repositories.\n\nalternate object database::\n\tVia the alternates mechanism, a repository can inherit part of its\n\tobject database from another object database, which is called\n\t\"alternate\".\n\nreachable::\n\tAn object is reachable from a ref/commit/tree/tag, if there is a\n\tchain leading from the latter to the former.\n\nchain::\n\tA list of objects, where each object in the list contains a\n\treference to its successor (for example, the successor of a commit\n\tcould be one of its parents).\n\nparent::\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\nfetch::\n\tFetching a branch means to get the branch's head ref from a\n\tremote repository, to find out which objects are missing from\n\tthe local object database, and to get them, too.\n\npull::\n\tPulling a branch means to fetch it and merge it.\n\npush::\n\tPushing a branch means to get the branch's head ref from a remote\n\trepository, find out if it is an ancestor to the branch's local\n\thead ref is a direct, and in that case, putting all objects, which\n\tare reachable from the local head ref, and which are missing from\n\tthe remote repository, into the remote object database, and updating\n\tthe remote head ref. If the remote head is not an ancestor to the\n\tlocal head, the push fails.\n\npack::\n\tA set of objects which have been compressed into one file (to save\n\tspace or to transmit them efficiently).\n\npack index::\n\tContains offsets into a pack, so the pack can be used instead of\n\tthe unpacked objects.\n\nplumbing::\n\tCute name for core git.\n\nporcelain::\n\tCute name for programs and program suites depending on core git,\n\tpresenting a high level access to core git. Porcelains expose\n\tmore of a SCM interface than the plumbing.\n\nobject type:\n\tOne of the identifiers \"commit\",\"tree\",\"tag\" and \"blob\" describing\n\tthe type of an object.\n\nSCM::\n\tSource code management (tool).\n\ndircache::\n\tYou are *waaaaay* behind.\n\n\nGIT Glossary\n============\nAug 2005\n\n[[ref_SCM]]SCM::\n\tSource code management (tool). \n\n[[ref_SHA1]]SHA1::\n\tA 20-byte sequence (or 41-byte file containing the hex representation\n\tand a newline). It is calculated from the contents of an\n\t<<ref_object,object>> by the Secure Hash Algorithm 1. \n\n[[ref_alternate_object_database]]alternate object database::\n\tVia the alternates mechanism, a <<ref_repository,repository>> can\n\tinherit part of its <<ref_object_database,object database>> from another\n\t<<ref_object_database,object database>>, which is called \"alternate\". \n\n[[ref_blob_object]]blob object::\n\tUntyped <<ref_object,object>>, i.e. the contents of a file. \n\n[[ref_branch]]branch::\n\tA non-cyclical graph of revisions, i.e. the complete history of a\n\tparticular <<ref_revision,revision>>, which does not (yet) have\n\tchildren, which is called the <<ref_branch,branch>> <<ref_head,head>>.\n\tThe <<ref_branch,branch>> heads are stored in $GIT_DIR/refs/heads/. \n\n[[ref_cache]]cache::\n\tA collection of files whose contents are stored as objects. The\n\t<<ref_cache,cache>> is a stored version of your\n\t<<ref_working_tree,working tree>>. Well, can also contain a second, and\n\teven a third version of a working <<ref_tree,tree>>, which are used when\n\tmerging. \n\n[[ref_cache_entry]]cache entry::\n\tThe information regarding a particular file, stored in the\n\t<<ref_index,index>>. A <<ref_cache_entry,cache entry>> can be unmerged,\n\tif a <<ref_merge,merge>> was started, but not yet finished (i.e. if the\n\t<<ref_cache,cache>> contains multiple versions of that file). \n\n[[ref_chain]]chain::\n\tA list of objects, where each <<ref_object,object>> in the list contains\n\ta reference to its successor (for example, the successor of a\n\t<<ref_commit,commit>> could be one of its parents). \n\n[[ref_changeset]]changeset::\n\tBitKeeper/cvsps speak for \"<<ref_commit,commit>>\". Since git does not\n\tstore changes, but states, it really does not make sense to use the term\n\t\"changesets\" with git. \n\n[[ref_checkout]]checkout::\n\tThe action of updating the <<ref_working_tree,working tree>> to a\n\t<<ref_revision,revision>> which was stored in the\n\t<<ref_object_database,object database>>. \n\n[[ref_clean]]clean::\n\tA <<ref_working_tree,working tree>> is <<ref_clean,clean>>, if it\n\tcorresponds to the <<ref_revision,revision>> referenced by the current\n\t<<ref_head,head>>. \n\n[[ref_commit]]commit::\n\tThe action of storing the current state of the <<ref_cache,cache>> in\n\tthe <<ref_object_database,object database>>. The result is a\n\t<<ref_revision,revision>>. \n\n[[ref_commit_object]]commit object::\n\tAn <<ref_object,object>> which contains the information about a\n\tparticular <<ref_revision,revision>>, such as parents, committer,\n\tauthor, date and the <<ref_tree_object,tree object>> which corresponds\n\tto the top <<ref_directory,directory>> of the stored\n\t<<ref_revision,revision>>. \n\n[[ref_dircache]]dircache::\n\tYou are *waaaaay* behind. \n\n[[ref_directory]]directory::\n\tThe list you get with \"ls\" :-) \n\n[[ref_dirty]]dirty::\n\tA <<ref_working_tree,working tree>> is said to be <<ref_dirty,dirty>> if\n\tit contains modifications which have not been committed to the current\n\t<<ref_branch,branch>>. \n\n[[ref_ent]]ent::\n\tFavorite synonym to \"<<ref_tree-ish,tree-ish>>\" by some total geeks. \n\n[[ref_fetch]]fetch::\n\tFetching a <<ref_branch,branch>> means to get the\n\t<<ref_branch,branch>>'s <<ref_head_ref,head ref>> from a remote\n\t<<ref_repository,repository>>, to find out which objects are missing\n\tfrom the local <<ref_object_database,object database>>, and to get them,\n\ttoo. \n\n[[ref_head]]head::\n\tThe top of a <<ref_branch,branch>>. It contains a <<ref_ref,ref>> to the\n\tcorresponding <<ref_commit_object,commit object>>. \n\n[[ref_head_ref]]head ref::\n\tA <<ref_ref,ref>> pointing to a <<ref_head,head>>. Often, this is\n\tabbreviated to \"<<ref_head,head>>\". Head refs are stored in\n\t$GIT_DIR/refs/heads/. \n\n[[ref_index]]index::\n\tContains information about the <<ref_cache,cache>> contents, in\n\tparticular timestamps and mode flags (\"stat information\") for the files\n\tstored in the <<ref_cache,cache>>. An unmerged <<ref_index,index>> is an\n\t<<ref_index,index>> which contains unmerged <<ref_cache,cache>> entries.\n\n[[ref_merge]]merge::\n\tTo <<ref_merge,merge>> branches means to try to accumulate the changes\n\tsince a common ancestor and apply them to the first\n\t<<ref_branch,branch>>. An automatic <<ref_merge,merge>> uses heuristics\n\tto accomplish that. Evidently, an automatic <<ref_merge,merge>> can\n\tfail. \n\n[[ref_object]]object::\n\tThe unit of storage in GIT. It is uniquely identified by the\n\t<<ref_SHA1,SHA1>> of its contents. Consequently, an\n\t<<ref_object,object>> can not be changed. \n\n[[ref_object_database]]object database::\n\tStores a set of \"objects\", and an individial <<ref_object,object>> is\n\tidentified by its <<ref_SHA1,SHA1>> (its <<ref_ref,ref>>). The objects\n\tare either stored as single files, or live inside of packs. \n\n[[ref_object_name]]object name::\n\tSynonym for <<ref_SHA1,SHA1>>. \n\n[[ref_pack]]pack::\n\tA set of objects which have been compressed into one file (to save space\n\tor to transmit them efficiently). \n\n[[ref_pack_index]]pack index::\n\tContains offsets into a <<ref_pack,pack>>, so the <<ref_pack,pack>> can\n\tbe used instead of the unpacked objects. \n\n[[ref_parent]]parent::\n\tA <<ref_commit_object,commit object>> contains a (possibly empty) list\n\tof the logical predecessor(s) in the line of development, i.e. its\n\tparents. \n\n[[ref_plumbing]]plumbing::\n\tCute name for core git. \n\n[[ref_porcelain]]porcelain::\n\tCute name for programs and program suites depending on core git,\n\tpresenting a high level access to core git. Porcelains expose more of a\n\t<<ref_SCM,SCM>> interface than the <<ref_plumbing,plumbing>>. \n\n[[ref_pull]]pull::\n\tPulling a <<ref_branch,branch>> means to <<ref_fetch,fetch>> it and\n\t<<ref_merge,merge>> it. \n\n[[ref_push]]push::\n\tPushing a <<ref_branch,branch>> means to get the <<ref_branch,branch>>'s\n\t<<ref_head_ref,head ref>> from a remote <<ref_repository,repository>>,\n\tfind out if it is an ancestor to the <<ref_branch,branch>>'s local\n\t<<ref_head_ref,head ref>> is a direct, and in that case, putting all\n\tobjects, which are <<ref_reachable,reachable>> from the local\n\t<<ref_head_ref,head ref>>, and which are missing from the remote\n\t<<ref_repository,repository>>, into the remote\n\t<<ref_object_database,object database>>, and updating the remote\n\t<<ref_head_ref,head ref>>. If the remote <<ref_head,head>> is not an\n\tancestor to the local <<ref_head,head>>, the <<ref_push,push>> fails. \n\n[[ref_reachable]]reachable::\n\tAn <<ref_object,object>> is <<ref_reachable,reachable>> from a\n\t<<ref_ref,ref>>/<<ref_commit,commit>>/<<ref_tree,tree>>/<<ref_tag,tag>>,\n\tif there is a <<ref_chain,chain>> leading from the latter to the former.\n\n[[ref_ref]]ref::\n\tA 40-byte hex representation of a <<ref_SHA1,SHA1>> pointing to a\n\tparticular <<ref_object,object>>. These are stored in $GIT_DIR/refs/. \n\n[[ref_repository]]repository::\n\tA collection of refs together with an <<ref_object_database,object\n\tdatabase>> containing all objects, which are <<ref_reachable,reachable>>\n\tfrom the refs. A <<ref_repository,repository>> can share an\n\t<<ref_object_database,object database>> with other repositories. \n\n[[ref_resolve]]resolve::\n\tThe action of fixing up manually what a failed automatic\n\t<<ref_merge,merge>> left behind. \n\n[[ref_revision]]revision::\n\tA particular state of files and directories which was stored in the\n\t<<ref_object_database,object database>>. It is referenced by a\n\t<<ref_commit_object,commit object>>. \n\n[[ref_tag]]tag::\n\tA <<ref_ref,ref>> pointing to a <<ref_tag,tag>> or\n\t<<ref_commit_object,commit object>>. In contrast to a <<ref_head,head>>,\n\ta <<ref_tag,tag>> is not changed by a <<ref_commit,commit>>. Tags (not\n\t<<ref_tag,tag>> objects) are stored in $GIT_DIR/refs/tags/. A git\n\t<<ref_tag,tag>> has nothing to do with a Lisp <<ref_tag,tag>> (which is\n\tcalled <<ref_object,object>> type in git's context). \n\n[[ref_tag_object]]tag object::\n\tAn <<ref_object,object>> containing a <<ref_ref,ref>> pointing to\n\tanother <<ref_object,object>>. It can contain a (PGP) signature, in\n\twhich case it is called \"signed <<ref_tag_object,tag object>>\". \n\n[[ref_tree]]tree::\n\tEither a <<ref_working_tree,working tree>>, or a <<ref_tree_object,tree\n\tobject>> together with the dependent blob and <<ref_tree,tree>> objects\n\t(i.e. a stored representation of a <<ref_working_tree,working tree>>). \n\n[[ref_tree_object]]tree object::\n\tAn <<ref_object,object>> containing a list of blob and/or\n\t<<ref_tree,tree>> objects. (A <<ref_tree,tree>> usually corresponds to a\n\t<<ref_directory,directory>> without subdirectories). \n\n[[ref_tree-ish]]tree-ish::\n\tA <<ref_ref,ref>> pointing to either a <<ref_commit_object,commit\n\tobject>>, a <<ref_tree_object,tree object>>, or a <<ref_tag_object,tag\n\tobject>> pointing to a <<ref_commit,commit>> or <<ref_tree_object,tree\n\tobject>>. \n\n[[ref_working_tree]]working tree::\n\tThe set of files and directories currently being worked on. Think \"ls\n\t-laR\" \n\n"},{"id":"7457","messageId":"Pine.LNX.4.63.0508171341380.23242@iabervon.org","threadId":"1556","inReplyTo":"Pine.LNX.4.63.0508171655250.13502@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: First stab at glossary","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-17T19:13:00Z","receivedAt":"2005-08-17T19:13:00Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 17 Aug 2005, Johannes Schindelin wrote:\n\n> Hi,\n>\n> long, long time. Here�s my first stab at the glossary, attached the\n> alphabetically sorted, asciidoc marked up txt file (Comments?\n> Suggestions? Pizzas?):\n>\n> object::\n> \tThe unit of storage in GIT. It is uniquely identified by\n> \tthe SHA1 of its contents. Consequently, an object can not\n> \tbe changed.\n>\n> SHA1::\n> \tA 20-byte sequence (or 41-byte file containing the hex\n> \trepresentation and a newline). It is calculated from the\n> \tcontents of an object by the Secure Hash Algorithm 1.\n\nIt's also often 40-character string (with whatever termination) in places\nlike commit objects, tag objects, command-line arguments, listings, and so\nforth.\n\n> object database::\n> \tStores a set of \"objects\", and an individial object is identified\n> \tby its SHA1 (its ref). The objects are either stored as single\n> \tfiles, or live inside of packs.\n>\n> object name::\n> \tSynonym for SHA1.\n\nHave we killed the use of the third term \"hash\" for this? I'd say that\n\"object name\" is the standard term, and \"SHA1\" is a nickname, if only\nbecause \"object name\" is more descriptive of the particular use of the\nterm.\n\n> blob object::\n> \tUntyped object, i.e. the contents of a file.\n\nThis \"i.e.\" should be \"e.g.\", since symlink targets are also stored as\nblobs, and any other bulk data stored by itself would be. (IIRC, Junio has\na tagged blob to hold his public key, for example)\n\n> tree object::\n> \tAn object containing a list of blob and/or tree objects.\n> \t(A tree usually corresponds to a directory without\n> \tsubdirectories).\n>\n> tree::\n> \tEither a working tree, or a tree object together with the\n> \tdependent blob and tree objects (i.e. a stored representation\n> \tof a working tree).\n>\n> cache::\n> \tA collection of files whose contents are stored as objects.\n> \tThe cache is a stored version of your working tree. Well, can\n> \talso contain a second, and even a third version of a working\n> \ttree, which are used when merging.\n>\n> cache entry::\n> \tThe information regarding a particular file, stored in the index.\n> \tA cache entry can be unmerged, if a merge was started, but not\n> \tyet finished (i.e. if the cache contains multiple versions of\n> \tthat file).\n>\n> index::\n> \tContains information about the cache contents, in particular\n> \ttimestamps and mode flags (\"stat information\") for the files\n> \tstored in the cache. An unmerged index is an index which contains\n> \tunmerged cache entries.\n\nI think we might want to entirely kill the \"cache\" term, and talk only\nabout the \"index\" and \"index entries\". Of course, a bunch of the code will\nhave to be renamed to make this completely successful, but we could change\nthe glossary and documentation, and mention \"cache\" and \"cache entry\" as\nold names for \"index\" and \"index entry\" respectively.\n\n> working tree::\n> \tThe set of files and directories currently being worked on.\n> \tThink \"ls -laR\"\n\nThis is where the data is actually in the filesystem, and you can edit and\ncompile it (as opposed to a tree object or the index, which semantically\nhave the same contents, but aren't presented in the filesystem that way).\n\n> directory::\n> \tThe list you get with \"ls\" :-)\n>\n> checkout::\n> \tThe action of updating the working tree to a revision which was\n> \tstored in the object database.\n\nMove after \"revision\"?\n\n> revision::\n> \tA particular state of files and directories which was stored in\n> \tthe object database. It is referenced by a commit object.\n>\n> commit::\n> \tThe action of storing the current state of the cache in the\n> \tobject database. The result is a revision.\n>\n> commit object::\n> \tAn object which contains the information about a particular\n> \trevision, such as parents, committer, author, date and the\n> \ttree object which corresponds to the top directory of the\n> \tstored revision.\n\nMove \"parent\" around here.\n\n> changeset::\n> \tBitKeeper/cvsps speak for \"commit\". Since git does not store\n> \tchanges, but states, it really does not make sense to use\n> \tthe term \"changesets\" with git.\n>\n> ent::\n> \tFavorite synonym to \"tree-ish\" by some total geeks.\n\nMove after \"tree-ish\".\n\n> head::\n> \tThe top of a branch. It contains a ref to the corresponding\n> \tcommit object.\n>\n> branch::\n> \tA non-cyclical graph of revisions, i.e. the complete history of\n> \ta particular revision, which does not (yet) have children, which\n> \tis called the branch head. The branch heads are stored in\n> \t$GIT_DIR/refs/heads/.\n\nA branch head might have children, if they're in another branch. (E.g., I\npull mainline, make a new branch based on it, and commit a change; the\nhead of mainline is still a branch head, even though it's the parent of my\nnew commit, because my new commit isn't in mainline.)\n\n> ref::\n> \tA 40-byte hex representation of a SHA1 pointing to a particular\n> \tobject. These are stored in $GIT_DIR/refs/.\n>\n> 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> tree-ish::\n> \tA ref pointing to either a commit object, a tree object, or a\n> \ttag object pointing to a commit or tree object.\n>\n> tag object::\n> \tAn object containing a ref pointing to another object. It can\n> \tcontain a (PGP) signature, in which case it is called \"signed\n> \ttag object\".\n>\n> tag::\n> \tA ref pointing to a tag or commit object. In contrast to a head,\n> \ta tag is not changed by a commit. Tags (not tag objects) are\n> \tstored in $GIT_DIR/refs/tags/. A git tag has nothing to do with\n> \ta Lisp tag (which is called object type in git's context).\n\nAs above, only the head for the branch being committed to is changed by a\ncommit. A tag, not being the head of a branch, is therefore never changed\nby a commit.\n\n> merge::\n> \tTo merge branches means to try to accumulate the changes since a\n> \tcommon ancestor and apply them to the first branch. An automatic\n> \tmerge uses heuristics to accomplish that. Evidently, an automatic\n> \tmerge can fail.\n>\n> resolve::\n> \tThe action of fixing up manually what a failed automatic merge\n> \tleft behind.\n\n\"Resolve\" is also used for the automatic case (e.g., in\n\"git-resolve-script\", which goes from having two commits and a message to\nhaving a new commit). I'm not sure what the distinction is supposed to be.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"7466","messageId":"Pine.LNX.4.63.0508172156090.17234@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1556","inReplyTo":"Pine.LNX.4.63.0508171341380.23242@iabervon.org","subject":"Re: First stab at glossary","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-17T20:05:27Z","receivedAt":"2005-08-17T20:05:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Aug 2005, Daniel Barkalow wrote:\n\n> On Wed, 17 Aug 2005, Johannes Schindelin wrote:\n> \n> > SHA1::\n> > \tA 20-byte sequence (or 41-byte file containing the hex\n> > \trepresentation and a newline). It is calculated from the\n> > \tcontents of an object by the Secure Hash Algorithm 1.\n> \n> It's also often 40-character string (with whatever termination) in places\n> like commit objects, tag objects, command-line arguments, listings, and so\n> forth.\n\nOkay.\n\n> > object name::\n> > \tSynonym for SHA1.\n> \n> Have we killed the use of the third term \"hash\" for this? I'd say that\n> \"object name\" is the standard term, and \"SHA1\" is a nickname, if only\n> because \"object name\" is more descriptive of the particular use of the\n> term.\n\nOkay for \"hash\". What is the consensus on \"object name\" being more \nstandard than \"SHA1\"?\n\n> > blob object::\n> > \tUntyped object, i.e. the contents of a file.\n> \n> This \"i.e.\" should be \"e.g.\", since symlink targets are also stored as\n> blobs, and any other bulk data stored by itself would be. (IIRC, Junio has\n> a tagged blob to hold his public key, for example)\n\nAgree.\n\n> I think we might want to entirely kill the \"cache\" term, and talk only\n> about the \"index\" and \"index entries\". Of course, a bunch of the code will\n> have to be renamed to make this completely successful, but we could change\n> the glossary and documentation, and mention \"cache\" and \"cache entry\" as\n> old names for \"index\" and \"index entry\" respectively.\n\nFor me, \"index\" is just the file named \"index\" (holding stat data and a \nref for each cache entry). That is why I say an \"index\" contains \"cache \nentries\", not \"index entries\" (wee, that sounds wrong :-).\n\n> > working tree::\n> > \tThe set of files and directories currently being worked on.\n> > \tThink \"ls -laR\"\n> \n> This is where the data is actually in the filesystem, and you can edit and\n> compile it (as opposed to a tree object or the index, which semantically\n> have the same contents, but aren't presented in the filesystem that way).\n\nMaybe I was too cautious. Linus very new idea was to think of the lowest \nlevel of an SCM as a file system. But I did not want to mention that. \nThinking of it again, maybe I should.\n\n> > checkout::\n>\n> Move after \"revision\"?\n\nUltimately, the glossary terms will be sorted alphabetically. If you look \nat the file attached to my original mail, this is already sorted and \nmarked up using asciidoc. However, I wanted you and the list to understand \nhow I grouped terms. The asciidoc'ed file is generated by a perl script.\n\n> Move \"parent\" around here.\n\nSee above.\n\n> Move after \"tree-ish\".\n\nDitto.\n\n> > branch::\n> > \tA non-cyclical graph of revisions, i.e. the complete history of\n> > \ta particular revision, which does not (yet) have children, which\n> > \tis called the branch head. The branch heads are stored in\n> > \t$GIT_DIR/refs/heads/.\n> \n> A branch head might have children, if they're in another branch. (E.g., I\n> pull mainline, make a new branch based on it, and commit a change; the\n> head of mainline is still a branch head, even though it's the parent of my\n> new commit, because my new commit isn't in mainline.)\n\nWell noted! I'll just delete that part.\n\n> > tag::\n> > \tA ref pointing to a tag or commit object. In contrast to a head,\n> > \ta tag is not changed by a commit. Tags (not tag objects) are\n> > \tstored in $GIT_DIR/refs/tags/. A git tag has nothing to do with\n> > \ta Lisp tag (which is called object type in git's context).\n> \n> As above, only the head for the branch being committed to is changed by a\n> commit. A tag, not being the head of a branch, is therefore never changed\n> by a commit.\n\nI tried to say that.\n\n> > resolve::\n> > \tThe action of fixing up manually what a failed automatic merge\n> > \tleft behind.\n> \n> \"Resolve\" is also used for the automatic case (e.g., in\n> \"git-resolve-script\", which goes from having two commits and a message to\n> having a new commit). I'm not sure what the distinction is supposed to be.\n\nI did not like that naming anyway. In reality, git-resolve-script does not \nresolve anything, but it merges two revisions, possibly leaving something \nto resolve.\n\nCiao,\nDscho\n"},{"id":"7473","messageId":"7vwtmks2m1.fsf@assigned-by-dhcp.cox.net","threadId":"1556","inReplyTo":"Pine.LNX.4.63.0508172156090.17234@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-17T20:57:42Z","receivedAt":"2005-08-17T20:57:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Okay for \"hash\". What is the consensus on \"object name\" being more \n> standard than \"SHA1\"?\n\nThe tutorial uses the term \"object name\", so does README\n(implicitly, by saying \"All objects are named by their content,\nwhich is approximated by the SHA1 hash of the object itself\").\nI think it is pretty safe to assume the list agrees with this\nterm.\n\n> For me, \"index\" is just the file named \"index\" (holding stat data and a \n> ref for each cache entry). That is why I say an \"index\" contains \"cache \n> entries\", not \"index entries\" (wee, that sounds wrong :-).\n\nI think Linus already commented on using \"index file\" and \"index\nentries\" as the canonical terms.  It would be a good idea to\nmention \"cache\" as a historical synonym in the documentation, so\nthat we do not have to rename the symbols in the code.\n\n> Ultimately, the glossary terms will be sorted alphabetically. If you look \n> at the file attached to my original mail, this is already sorted and \n> marked up using asciidoc. However, I wanted you and the list to understand \n> how I grouped terms. The asciidoc'ed file is generated by a perl script.\n\nThen we should put the text version under Documentation, along\nwith that script and a Makefile entry to do asciidoc and another\nto go to html.  No rush for the script and Makefile entries, but\nit would make things easier to manage if we put the text version\nin the tree soonish.  I've pushed out the one from your original\n\"First stab\" message.\n\n>> > branch::\n>> > \tA non-cyclical graph of revisions, i.e. the complete history of\n>> > \ta particular revision, which does not (yet) have children, which\n>> > \tis called the branch head. The branch heads are stored in\n>> > \t$GIT_DIR/refs/heads/.\n\nI wonder if there is a math term for a non-cyclical graph that\nhas a single \"greater than anything else in the graph\" node (but\nnot necessarily a single but possibly more \"lesser than anything\nelse in the graph\" nodes)?\n\n>> > tag::\n>> > \tA ref pointing to a tag or commit object. In contrast to a head,\n>> > \ta tag is not changed by a commit. Tags (not tag objects) are\n>> > \tstored in $GIT_DIR/refs/tags/. A git tag has nothing to do with\n>> > \ta Lisp tag (which is called object type in git's context).\n\nI think this is good already, but maybe mention why you would\nuse a tag in a sentence?  \"Most typically used to mark a\nparticular point in the commit ancestry chain,\" or something.\n\n>> > resolve::\n>> > \tThe action of fixing up manually what a failed automatic merge\n>> > \tleft behind.\n>> \n>> \"Resolve\" is also used for the automatic case (e.g., in\n>> \"git-resolve-script\", which goes from having two commits and a message to\n>> having a new commit). I'm not sure what the distinction is supposed to be.\n>\n> I did not like that naming anyway. In reality, git-resolve-script does not \n> resolve anything, but it merges two revisions, possibly leaving something \n> to resolve.\n\nI am sure this would break people's script, but I am not against\nrenaming git-resolve-script to say git-merge-script.\n\nAnyway, thanks for doing this less-fun and not-so-glorious job.\n"},{"id":"7474","messageId":"Pine.LNX.4.63.0508172314130.17584@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1556","inReplyTo":"7vwtmks2m1.fsf@assigned-by-dhcp.cox.net","subject":"Re: First stab at glossary","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-17T21:24:25Z","receivedAt":"2005-08-17T21:24:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Aug 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > Okay for \"hash\". What is the consensus on \"object name\" being more \n> > standard than \"SHA1\"?\n> \n> The tutorial uses the term \"object name\", so does README\n> (implicitly, by saying \"All objects are named by their content,\n> which is approximated by the SHA1 hash of the object itself\").\n> I think it is pretty safe to assume the list agrees with this\n> term.\n\nOkay, I'll give in, then.\n\n> \n> > For me, \"index\" is just the file named \"index\" (holding stat data and a \n> > ref for each cache entry). That is why I say an \"index\" contains \"cache \n> > entries\", not \"index entries\" (wee, that sounds wrong :-).\n> \n> I think Linus already commented on using \"index file\" and \"index\n> entries\" as the canonical terms.  It would be a good idea to\n> mention \"cache\" as a historical synonym in the documentation, so\n> that we do not have to rename the symbols in the code.\n> \n\nIf the king penguin speaketh, the little blue penguin followeth.\n\n> > Ultimately, the glossary terms will be sorted alphabetically. If you look \n> > at the file attached to my original mail, this is already sorted and \n> > marked up using asciidoc. However, I wanted you and the list to understand \n> > how I grouped terms. The asciidoc'ed file is generated by a perl script.\n> \n> Then we should put the text version under Documentation, along\n> with that script and a Makefile entry to do asciidoc and another\n> to go to html.  No rush for the script and Makefile entries, but\n> it would make things easier to manage if we put the text version\n> in the tree soonish.  I've pushed out the one from your original\n> \"First stab\" message.\n\nOkay. Then I follow the advice of the large and angry Saucer Crunching \nMonster, and shuffle the entries into a more logical order.\n\n> >> > branch::\n> >> > \tA non-cyclical graph of revisions, i.e. the complete history of\n> >> > \ta particular revision, which does not (yet) have children, which\n> >> > \tis called the branch head. The branch heads are stored in\n> >> > \t$GIT_DIR/refs/heads/.\n> \n> I wonder if there is a math term for a non-cyclical graph that\n> has a single \"greater than anything else in the graph\" node (but\n> not necessarily a single but possibly more \"lesser than anything\n> else in the graph\" nodes)?\n\nYes, there is. Although git itself is an example that there are two \n\"greater than almost anything else in the graph\" nodes.\n\nAlso, let's not be overzealous with our math degrees, okay? :-)\n\n> >> > tag::\n> >> > \tA ref pointing to a tag or commit object. In contrast to a head,\n> >> > \ta tag is not changed by a commit. Tags (not tag objects) are\n> >> > \tstored in $GIT_DIR/refs/tags/. A git tag has nothing to do with\n> >> > \ta Lisp tag (which is called object type in git's context).\n> \n> I think this is good already, but maybe mention why you would\n> use a tag in a sentence?  \"Most typically used to mark a\n> particular point in the commit ancestry chain,\" or something.\n\nDone.\n\n> >> > resolve::\n> >> > \tThe action of fixing up manually what a failed automatic merge\n> >> > \tleft behind.\n> >> \n> >> \"Resolve\" is also used for the automatic case (e.g., in\n> >> \"git-resolve-script\", which goes from having two commits and a message to\n> >> having a new commit). I'm not sure what the distinction is supposed to be.\n> >\n> > I did not like that naming anyway. In reality, git-resolve-script does not \n> > resolve anything, but it merges two revisions, possibly leaving something \n> > to resolve.\n> \n> I am sure this would break people's script, but I am not against\n> renaming git-resolve-script to say git-merge-script.\n\nI do not mind changing the description if the consensus is to keep \ngit-resolve-script.\n\n> Anyway, thanks for doing this less-fun and not-so-glorious job.\n\nThe little blue penguin says: Thanks for all the fish!\n"},{"id":"7478","messageId":"Pine.LNX.4.63.0508171630140.23242@iabervon.org","threadId":"1556","inReplyTo":"Pine.LNX.4.63.0508172156090.17234@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: First stab at glossary","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-17T22:09:41Z","receivedAt":"2005-08-17T22:09:41Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 17 Aug 2005, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Wed, 17 Aug 2005, Daniel Barkalow wrote:\n>\n> > On Wed, 17 Aug 2005, Johannes Schindelin wrote:\n> >\n> > > object name::\n> > > \tSynonym for SHA1.\n> >\n> > Have we killed the use of the third term \"hash\" for this? I'd say that\n> > \"object name\" is the standard term, and \"SHA1\" is a nickname, if only\n> > because \"object name\" is more descriptive of the particular use of the\n> > term.\n>\n> Okay for \"hash\".\n\nI think we only need at most two names for this, so this is more a matter\nof fixing old usage than documenting it.\n\n> > I think we might want to entirely kill the \"cache\" term, and talk only\n> > about the \"index\" and \"index entries\". Of course, a bunch of the code will\n> > have to be renamed to make this completely successful, but we could change\n> > the glossary and documentation, and mention \"cache\" and \"cache entry\" as\n> > old names for \"index\" and \"index entry\" respectively.\n>\n> For me, \"index\" is just the file named \"index\" (holding stat data and a\n> ref for each cache entry). That is why I say an \"index\" contains \"cache\n> entries\", not \"index entries\" (wee, that sounds wrong :-).\n\nWell, it often contains information not present anywhere else (the status\nof a merge; the set of files being committed, added, or removed), so it\nisn't really a cache at all.\n\n> > > working tree::\n> > > \tThe set of files and directories currently being worked on.\n> > > \tThink \"ls -laR\"\n> >\n> > This is where the data is actually in the filesystem, and you can edit and\n> > compile it (as opposed to a tree object or the index, which semantically\n> > have the same contents, but aren't presented in the filesystem that way).\n>\n> Maybe I was too cautious. Linus very new idea was to think of the lowest\n> level of an SCM as a file system. But I did not want to mention that.\n> Thinking of it again, maybe I should.\n\nYou probably don't need to mention that tree objects and index files can\nbe thought of as filesystems, but you should specify that the working tree\nreally is in the Unix filesystem, in case people have heard of the idea.\n\nIt should be clear to say 'You can \"cd\" there and \"ls\" to list your\nfiles.', rather than 'Think \"ls -laR\"' which makes my think of the output,\nwhich is like the output from git-ls-files.\n\n> > > checkout::\n> >\n> > Move after \"revision\"?\n>\n> Ultimately, the glossary terms will be sorted alphabetically. If you look\n> at the file attached to my original mail, this is already sorted and\n> marked up using asciidoc. However, I wanted you and the list to understand\n> how I grouped terms. The asciidoc'ed file is generated by a perl script.\n\nAh, okay.\n\n> > > resolve::\n> > > \tThe action of fixing up manually what a failed automatic merge\n> > > \tleft behind.\n> >\n> > \"Resolve\" is also used for the automatic case (e.g., in\n> > \"git-resolve-script\", which goes from having two commits and a message to\n> > having a new commit). I'm not sure what the distinction is supposed to be.\n>\n> I did not like that naming anyway. In reality, git-resolve-script does not\n> resolve anything, but it merges two revisions, possibly leaving something\n> to resolve.\n\nRight; I think we should change the name of the script.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7479","messageId":"Pine.LNX.4.63.0508180009180.18104@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1556","inReplyTo":"Pine.LNX.4.63.0508171630140.23242@iabervon.org","subject":"Re: First stab at glossary","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-17T22:19:02Z","receivedAt":"2005-08-17T22:19:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Aug 2005, Daniel Barkalow wrote:\n\n> On Wed, 17 Aug 2005, Johannes Schindelin wrote:\n> \n> > On Wed, 17 Aug 2005, Daniel Barkalow wrote:\n> > > [...]\n> > Okay for \"hash\".\n> \n> I think we only need at most two names for this, so this is more a matter\n> of fixing old usage than documenting it.\n\nIt's short enough to keep it in the glossary _and_ fix the old \ndocumentation.\n\n> > [blabla] index [blable] cache [bliblo]\n>\n> Well, it often contains information not present anywhere else (the status\n> of a merge; the set of files being committed, added, or removed), so it\n> isn't really a cache at all.\n\nOkay, okay. I stand corrected.\n\n> > Maybe I was too cautious. Linus very new idea was to think of the lowest\n> > level of an SCM as a file system. But I did not want to mention that.\n> > Thinking of it again, maybe I should.\n> \n> You probably don't need to mention that tree objects and index files can\n> be thought of as filesystems, but you should specify that the working tree\n> really is in the Unix filesystem, in case people have heard of the idea.\n> \n> It should be clear to say 'You can \"cd\" there and \"ls\" to list your\n> files.', rather than 'Think \"ls -laR\"' which makes my think of the output,\n> which is like the output from git-ls-files.\n\nHow about this:\n\nworking tree::\n        The set of files and directories currently being worked on,\n        i.e. you can work in your working tree without using git at all.\n\n\n> > > > checkout::\n> > >\n> > > Move after \"revision\"?\n> >\n> > Ultimately, the glossary terms will be sorted alphabetically. If you look\n> > at the file attached to my original mail, this is already sorted and\n> > marked up using asciidoc. However, I wanted you and the list to understand\n> > how I grouped terms. The asciidoc'ed file is generated by a perl script.\n> \n> Ah, okay.\n\nSorry, I attributed these \"moving suggestions\" to the large and angry SCM, \nwhile those were your comments. Since Junio decided to keep the \"topic \nordered\" form in his repository, I moved them around according to your \nmail.\n\n> > > > resolve::\n> > > > \tThe action of fixing up manually what a failed automatic merge\n> > > > \tleft behind.\n> > >\n> > > \"Resolve\" is also used for the automatic case (e.g., in\n> > > \"git-resolve-script\", which goes from having two commits and a message to\n> > > having a new commit). I'm not sure what the distinction is supposed to be.\n> >\n> > I did not like that naming anyway. In reality, git-resolve-script does not\n> > resolve anything, but it merges two revisions, possibly leaving something\n> > to resolve.\n> \n> Right; I think we should change the name of the script.\n\nHow many users are there? Probably many call git-pull-script anyway, \nright?\n\nCiao,\nDscho\n"},{"id":"7705","messageId":"430C8C31.1070902@progeny.com","threadId":"1556","inReplyTo":"Pine.LNX.4.63.0508180009180.18104@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Tool renames? was Re: First stab at glossary","fromName":"Tim Ottinger","fromEmail":"tottinge@progeny.com","sentAt":"2005-08-24T15:03:13Z","receivedAt":"2005-08-24T15:03:13Z","isPatch":false,"sender":{"key":"tottinge@progeny.com","avatar":null},"body":"So when this gets all settled, will we see a lot of tool renaming? \n\nWhile it would cause me and my team some personal effort (we have\na special-purpose porcelain), it would be welcome to have a lexicon\nthat is sane and consistent, and in tune with all the documentation.\n\nOthers may feel differently, I understand.\n\n-- \n                             ><>\n... either 'way ahead of the game, or 'way out in left field.\n"},{"id":"7732","messageId":"7v4q9eak9k.fsf@assigned-by-dhcp.cox.net","threadId":"1556","inReplyTo":"430C8C31.1070902@progeny.com","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-25T01:16:23Z","receivedAt":"2005-08-25T01:16:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tim Ottinger <tottinge@progeny.com> writes:\n\n> So when this gets all settled, will we see a lot of tool renaming? \n\nI personally do not see it coming.  Any particular one you have\nin mind?\n"},{"id":"7994","messageId":"43174090.5070503@progeny.com","threadId":"1556","inReplyTo":"7v4q9eak9k.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Tim Ottinger","fromEmail":"tottinge@progeny.com","sentAt":"2005-09-01T17:55:28Z","receivedAt":"2005-09-01T17:55:28Z","isPatch":false,"sender":{"key":"tottinge@progeny.com","avatar":null},"body":"Junio C Hamano wrote:\n\n>Tim Ottinger <tottinge@progeny.com> writes:\n>\n>  \n>\n>>So when this gets all settled, will we see a lot of tool renaming? \n>>    \n>>\n>\n>I personally do not see it coming.  Any particular one you have\n>in mind?\n>\n>  \n>\ngit-update-cache for instance?\nI am not sure which 'cache' commands need to be 'index' now.\n\n\n-- \n                             ><>\n... either 'way ahead of the game, or 'way out in left field.\n"},{"id":"8000","messageId":"7vek88tib4.fsf@assigned-by-dhcp.cox.net","threadId":"1556","inReplyTo":"43174090.5070503@progeny.com","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-02T00:38:39Z","receivedAt":"2005-09-02T00:38:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tim Ottinger <tottinge@progeny.com> writes:\n\n> git-update-cache for instance?\n> I am not sure which 'cache' commands need to be 'index' now.\n\nLogically you are right, but I suspect that may not fly well in\npractice.  Too many of us have already got our fingers wired to\ntype cache, and the glossary is there to describe both cache and\nindex.\n\n \n"},{"id":"8020","messageId":"Pine.LNX.4.63.0509021358000.23242@iabervon.org","threadId":"1556","inReplyTo":"7vek88tib4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-02T18:09:13Z","receivedAt":"2005-09-02T18:09:13Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 1 Sep 2005, Junio C Hamano wrote:\n\n> Tim Ottinger <tottinge@progeny.com> writes:\n> \n> > git-update-cache for instance?\n> > I am not sure which 'cache' commands need to be 'index' now.\n> \n> Logically you are right, but I suspect that may not fly well in\n> practice.  Too many of us have already got our fingers wired to\n> type cache, and the glossary is there to describe both cache and\n> index.\n\nMy vote's for changing the official names, but keeping symlinks for the \nold names. As far as I know, there aren't any actual conflicts, and we \nmight as well have new users pick up the logical names. I particularly \nthink \"git merge\" would be really good to have.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"8022","messageId":"7voe7bfhfz.fsf@assigned-by-dhcp.cox.net","threadId":"1556","inReplyTo":"Pine.LNX.4.63.0509021358000.23242@iabervon.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-02T18:33:20Z","receivedAt":"2005-09-02T18:33:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Thu, 1 Sep 2005, Junio C Hamano wrote:\n>\n>> Tim Ottinger <tottinge@progeny.com> writes:\n>> \n>> > git-update-cache for instance?\n>> \n>> Logically you are right, but I suspect that may not fly well in\n>> practice.  Too many of us have already got our fingers wired to\n>> type cache, and the glossary is there to describe both cache and\n>> index.\n>\n> My vote's for changing the official names, but keeping symlinks for the \n> old names. As far as I know, there aren't any actual conflicts, and we \n> might as well have new users pick up the logical names. I particularly \n> think \"git merge\" would be really good to have.\n\nOK.  As Horst also says, we should do this before 1.0.\n\n0.99.6::\n\tThis hopefully will be done on Sep 7th.  Tool renames\n\twill not happen in this release, but the set of cleaned\n\tup names will be discussed on the list during this\n\ttimeperiod.  I'll draw up a strawman tonight unless\n\tsomebody else does it first.\n\n0.99.7::\n\tWe install symbolic links for the old names.  For the\n\tdocumentation, we do not bother --- just install under\n\tnew names.  Also remove support for ancient environment\n\tvariable names from gitenv().  Aim for Sep 17th.\n\n0.99.8::\n\tAim for Oct 1st; we do not install symbolic links\n\tanymore and supply \"clean-old-install\" target in the\n\tMakefile that removes symlinks installed by 0.99.7 from\n\tDESTDIR.  This target is not run automatically from other\n\tusual make targets; it is just there for your\n\tconvenience.\n"},{"id":"8029","messageId":"7v8xyebs9v.fsf@assigned-by-dhcp.cox.net","threadId":"1556","inReplyTo":"7voe7bfhfz.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-03T06:05:16Z","receivedAt":"2005-09-03T06:05:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I said:\n\n> \tI'll draw up a strawman tonight unless somebody else\n> \tdoes it first.\n\n1. Say 'index' when you are tempted to say 'cache'.\n\n        git-checkout-cache      git-checkout-index\n        git-convert-cache       git-convert-index\n        git-diff-cache          git-diff-index\n        git-fsck-cache          git-fsck-index\n        git-merge-cache         git-merge-index\n        git-update-cache        git-update-index\n\n2. The act of combining two or more heads is called 'merging';\n   fetching immediately followed by merging is called 'pulling'.\n\n        git-resolve-script      git-merge-script\n\n   The commit walkers are called *-pull, but this is probably\n   confusing.  They are not pulling.\n\n        git-http-pull           git-http-walk\n        git-local-pull          git-local-walk\n        git-ssh-pull            git-ssh-walk\n\n3. Non-binaries are called '*-scripts'.\n\n   In earlier discussions some people seem to like the\n   distinction between *-script and others; I did not\n   particularly like it, but I am throwing this in for\n   discussion.\n\n        git-applymbox           git-applymbox-script\n        git-applypatch          git-applypatch-script\n        git-cherry              git-cherry-script\n        git-shortlog            git-shortlog-script\n        git-whatchanged         git-whatchanged-script\n\n4. To be removed shortly.\n\n        git-clone-dumb-http     should be folded into git-clone-script\n"},{"id":"8031","messageId":"Pine.LNX.4.63.0509030233350.23242@iabervon.org","threadId":"1556","inReplyTo":"7v8xyebs9v.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-03T06:54:58Z","receivedAt":"2005-09-03T06:54:58Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 2 Sep 2005, Junio C Hamano wrote:\n\n> I said:\n> \n> > \tI'll draw up a strawman tonight unless somebody else\n> > \tdoes it first.\n> \n> 1. Say 'index' when you are tempted to say 'cache'.\n> \n>         git-checkout-cache      git-checkout-index\n>         git-convert-cache       git-convert-index\n>         git-diff-cache          git-diff-index\n>         git-fsck-cache          git-fsck-index\n>         git-merge-cache         git-merge-index\n>         git-update-cache        git-update-index\n\nAgreed, except that git-convert-cache and git-fsck-cache actually have \nnothing to do this the index by any name, and should probably be \ngit-convert-objects and git-fsck-objects.\n\n> 2. The act of combining two or more heads is called 'merging';\n>    fetching immediately followed by merging is called 'pulling'.\n> \n>         git-resolve-script      git-merge-script\n> \n>    The commit walkers are called *-pull, but this is probably\n>    confusing.  They are not pulling.\n> \n>         git-http-pull           git-http-walk\n>         git-local-pull          git-local-walk\n>         git-ssh-pull            git-ssh-walk\n\nI think \"fetch\" is more applicable to what they do.\n\n> 3. Non-binaries are called '*-scripts'.\n> \n>    In earlier discussions some people seem to like the\n>    distinction between *-script and others; I did not\n>    particularly like it, but I am throwing this in for\n>    discussion.\n> \n>         git-applymbox           git-applymbox-script\n>         git-applypatch          git-applypatch-script\n>         git-cherry              git-cherry-script\n>         git-shortlog            git-shortlog-script\n>         git-whatchanged         git-whatchanged-script\n\nI don't think it matters very much whether something is a script or not; \non the other hand, it would be good to have \"git\" list a reasonable set of \ncommands to use through the interface, which would exclude, for example, \ngit-merge-one-file-script, and include the above commands.\n\n> 4. To be removed shortly.\n> \n>         git-clone-dumb-http     should be folded into git-clone-script\n\nAgreed.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"8035","messageId":"7vy86e5zbf.fsf@assigned-by-dhcp.cox.net","threadId":"1556","inReplyTo":"Pine.LNX.4.63.0509030233350.23242@iabervon.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-03T08:29:40Z","receivedAt":"2005-09-03T08:29:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> Agreed, except that git-convert-cache and git-fsck-cache actually have \n> nothing to do this the index by any name, and should probably be \n> git-convert-objects and git-fsck-objects.\n\nYou are right.\n\n> I think \"fetch\" is more applicable to what they do.\n\nOK.  then they are git-http-fetch and friends.  How about\ngit-ssh-push?  The counterpart of fetch-pack/clone-pack is\ncalled upload-pack, so would git-ssh-upload make things more\nconsistent?  I dunno.\n\n> I don't think it matters very much whether something is a script or not; \n> on the other hand, it would be good to have \"git\" list a reasonable set of \n> commands to use through the interface, which would exclude, for example, \n> git-merge-one-file-script, and include the above commands.\n\nAre you suggesting to drop -script from git-merge-one-file?\nThen git-cherry should perhaps keep its current name.\n"},{"id":"8056","messageId":"Pine.LNX.4.63.0509041318390.23242@iabervon.org","threadId":"1556","inReplyTo":"7vy86e5zbf.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-04T17:23:23Z","receivedAt":"2005-09-04T17:23:23Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 3 Sep 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > I think \"fetch\" is more applicable to what they do.\n> \n> OK.  then they are git-http-fetch and friends.  How about\n> git-ssh-push?  The counterpart of fetch-pack/clone-pack is\n> called upload-pack, so would git-ssh-upload make things more\n> consistent?  I dunno.\n\nI like that idea.\n\n> > I don't think it matters very much whether something is a script or not; \n> > on the other hand, it would be good to have \"git\" list a reasonable set of \n> > commands to use through the interface, which would exclude, for example, \n> > git-merge-one-file-script, and include the above commands.\n> \n> Are you suggesting to drop -script from git-merge-one-file?\n> Then git-cherry should perhaps keep its current name.\n\nI'd suggest it get a different ending, like .sh or -helper. That way, it's \ndistinct both from binaries and from scripts that people run directly.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}