{"thread":{"id":"56004","subject":"Definition of \"the Git repository\"","startedAt":"2021-06-25T01:46:09Z","lastAt":"2021-06-29T06:59:27Z","messageCount":15,"participants":["Kevin Buckley","Ævar Arnfjörð Bjarmason","Igor Djordjevic","Felipe Contreras","Philip Oakley","Chris Torek","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"428453","messageId":"7dd55e85-38eb-7346-ff10-7124102cd22b@pawsey.org.au","threadId":"56004","inReplyTo":null,"subject":"Definition of \"the Git repository\"","fromName":"Kevin Buckley","fromEmail":"kevin.buckley@pawsey.org.au","sentAt":"2021-06-25T01:44:49Z","receivedAt":"2021-06-25T01:46:09Z","isPatch":false,"sender":{"key":"kevin.buckley@pawsey.org.au","avatar":null},"body":"Hi there,\n\nraising this on the back of a discussion over at the Software\nCarpentry lesson about Git,\n\n    https://github.com/swcarpentry/git-novice/issues/810\n\nI used the book to justify my claim that it is the .git directory\nthat is the repository, but I do have to concede that the way that\nthe text in section 2.1 of the book reads, does suggest that one\ncan refer to the working directory PLUS the .git directory as a\n\"repository\" as well as being able to refer to the .git directory\nalone as the \"repository\".\n\nIn the way I think of it\n\ngit init\n\ninitialises a Git repository, however, the only thing that changes\nas a result is that a .git directory has been created, ergo, the\n.git directory is the repository.\n\nFurthermore, the fact that one can take the .git directory, move it\nto a new directory and start using it there (very much a nice feature)\nalso suggests to me that it is the .git directory that is the repository,\nas distict from a working directory, under Git control because of the\nexistence of a repository within it.\n\nInterested to hear any thoughts around the semantics here,\nKevin Buckley\n\n-- \nSupercomputing Systems Administrator\nPawsey Supercomputing Centre\n"},{"id":"428454","messageId":"87tulmxyss.fsf@evledraar.gmail.com","threadId":"56004","inReplyTo":"7dd55e85-38eb-7346-ff10-7124102cd22b@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-25T05:56:49Z","receivedAt":"2021-06-25T06:07:20Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jun 25 2021, Kevin Buckley wrote:\n\n> Hi there,\n>\n> raising this on the back of a discussion over at the Software\n> Carpentry lesson about Git,\n>\n>    https://github.com/swcarpentry/git-novice/issues/810\n>\n> I used the book to justify my claim that it is the .git directory\n> that is the repository, but I do have to concede that the way that\n> the text in section 2.1 of the book reads, does suggest that one\n> can refer to the working directory PLUS the .git directory as a\n> \"repository\" as well as being able to refer to the .git directory\n> alone as the \"repository\".\n>\n> In the way I think of it\n>\n> git init\n>\n> initialises a Git repository, however, the only thing that changes\n> as a result is that a .git directory has been created, ergo, the\n> .git directory is the repository.\n>\n> Furthermore, the fact that one can take the .git directory, move it\n> to a new directory and start using it there (very much a nice feature)\n> also suggests to me that it is the .git directory that is the repository,\n> as distict from a working directory, under Git control because of the\n> existence of a repository within it.\n>\n> Interested to hear any thoughts around the semantics here,\n> Kevin Buckley\n\nI think the right answer to this is that there is no right answer, if\nyou read gitglossary(7) you'll find it mostly backs your argument, but\nyou'll also find mentions in git's own documentation that say things\nlike \"a subdirectory of your repository\" when referring to the\nrepository's working tree.\n\nMore importantly it seems like this is documentation for novices, I\nthink it's generally more important to get important notions like their\nhistorical data being stored in that .git thingy than it is to nail down\nevery concept involved in that with 100% accuracy.\n"},{"id":"428456","messageId":"9099ab09-f6d0-f1e2-1b8e-a55d22a903c5@gmail.com","threadId":"56004","inReplyTo":"7dd55e85-38eb-7346-ff10-7124102cd22b@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-06-25T08:56:28Z","receivedAt":"2021-06-25T08:56:46Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"\n\nOn 25/06/2021 03:44, Kevin Buckley wrote:\n> \n> raising this on the back of a discussion over at the Software\n> Carpentry lesson about Git,\n> \n>    https://github.com/swcarpentry/git-novice/issues/810\n> \n> I used the book to justify my claim that it is the .git directory\n> that is the repository, but I do have to concede that the way that\n> the text in section 2.1 of the book reads, does suggest that one\n> can refer to the working directory PLUS the .git directory as a\n> \"repository\" as well as being able to refer to the .git directory\n> alone as the \"repository\".\n> \n> In the way I think of it\n> \n> git init\n> \n> initialises a Git repository, however, the only thing that changes\n> as a result is that a .git directory has been created, ergo, the\n> .git directory is the repository.\n> \n> Furthermore, the fact that one can take the .git directory, move it\n> to a new directory and start using it there (very much a nice feature)\n> also suggests to me that it is the .git directory that is the repository,\n> as distict from a working directory, under Git control because of the\n> existence of a repository within it.\n> \n> Interested to hear any thoughts around the semantics here,\n\nThinking out loud, and without discussing various places where \"Git \nrepository\" might be described one way or the other, a \"repository\" \nis a place where *something* is *stored*.\n\n\"Source code repository\" would thus be a place where source code is \nstored, possibly with some metadata (current version, last change, \netc.), but not necessarily the whole (versioned) history. For storage \npurpose alone, Git's own working tree could be then considered a \nrepository in its own right (source code repository, if it contains \nsource code, but it could contain other stuff as well, in addition or \nstandalone). But as soon as you start working in it it's not really \n(only) a storage anymore (so not a repository), but a working area. \nIt's more of a conceptual thing.\n\nSo if we strictly speak of \"Git repository\", I think it should be a \nplace where Git keeps (stores) your (committed) work, alongside its \nown (meta)data - and that is the \".git\" directory, indeed. Seems \nsimple enough :)\n\nOne place where the confusion might be extended is the notion of \n\"bare repository\" for \".git\" directory alone (without the working \ntree), which should then imply \".git\" + working tree is in fact \n\"a repository\"... which it is, but bare with me - pun intended :)\n\nAs Git is mainly used to version artifacts being more or less actively \nworked on (changing, that is), one needs a working area in order to \ndo the actual work, thus we have a working tree happily and conveniently \nprovided by Git by default, as part of *working with* a Git repository.\n\nAs you said, having \".git\" directory alone is enough to recreate the \ncontents of the working tree, where if you would have the working tree \nalone, even if that could be considered to be \"a repository\" (for \nstorage, not work), you would definitely not have \"a Git repository\" \n(no \".git\" directory).\n\nAlso, when you work with a remote Git repository, it's only the \ncommitted stuff you can work with - what's inside \".git\". You have no \nidea of contents of a working tree (and ideally not knowing if one \neven exists, though that's not always the case, like if you try to \npush to a checked out branch).\n\nFor some additional understanding, I guess we can compare \"repository\" \nwith \"archive\", possibly being a more familiar concept - you can \nstore source code somewhere, and that's your archive. You don't work \non it in there, as then it would not be an archive anymore, but you \nkeep it as a backup which you can always retrieve if needed.\n\nIf you use ZIP to compress your archive, it's then a \"ZIP archive\". \nAnd for the most of the time these two would in fact be interchangeable \n- you can have one or the other, being able to recreate one from the \nother (unlike with \".git\" and working tree).\n\nBUT, if you add some additional (meta)data to your ZIP archive - like \npassword, description, etc. - then the two are not interchangeable \nanymore, \"ZIP archive\" not being the same as \"archive\", not being able \nto be recreated from it.\n\nTo conclude - Git's concept of a \"working tree\" alone could be \"a \nrepository\" (used for storage, not working), but it's not \"a Git \nrepository\" without the \".git\" directory in it. On the other hand, \nwhile \"Git repository\" must have a \".git\" directory, it can have a \n\"working tree\", too - but it doesn't need to (called \"bare [Git] \nrepository\" in such a case), as it can be completely recreated from \n\".git\" directory alone, being a mere convenience in order to be able \nto do the actual (development) work (and not required for \"Git \nrepository\" to be a \"repository\").\n\nFinally, as \"Git repository\" could be referred to as only a \n\"repository\" for brevity (which it is, in general), it's important to \nnotice the latter might be ambiguous (as it does not imply \"Git \nrepository\" in particular), thus using \"Git repository\" when being in \nthe clear is paramount, indicating that you're interested in \".git\" \ndirectory precisely (and possibly, but not necessarily the working \ntree as well). If interested in \".git\" directory alone, \"bare Git \nrepository\" is the most precise term.\n\nRegards, Buga\n"},{"id":"428460","messageId":"d4429a6e-9681-6a79-1e91-19c129fa02b4@gmail.com","threadId":"56004","inReplyTo":"7dd55e85-38eb-7346-ff10-7124102cd22b@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-06-25T09:14:54Z","receivedAt":"2021-06-25T09:15:12Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 25/06/2021 03:44, Kevin Buckley wrote:\n> \n> In the way I think of it\n> \n> git init\n> \n> initialises a Git repository, however, the only thing that changes\n> as a result is that a .git directory has been created, ergo, the\n> .git directory is the repository.\n\nAnother way to look at it could be that you possibly have a repository \nalready, and `git init` only makes it a Git repository... ;)\n\nJoking aside, for a looong train of thoughts, see that other reply[1].\n\nRegards, Buga\n\n[1]: https://lore.kernel.org/git/9099ab09-f6d0-f1e2-1b8e-a55d22a903c5@gmail.com/\n"},{"id":"428500","messageId":"60d6310134678_cc8d208c4@natae.notmuch","threadId":"56004","inReplyTo":"7dd55e85-38eb-7346-ff10-7124102cd22b@pawsey.org.au","subject":"RE: Definition of \"the Git repository\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-25T19:39:45Z","receivedAt":"2021-06-25T19:39:49Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Kevin Buckley wrote:\n> In the way I think of it\n> \n> git init\n> \n> initialises a Git repository, however, the only thing that changes\n> as a result is that a .git directory has been created, ergo, the\n> .git directory is the repository.\n\nThat's not necessarily true. Another way to look at it is that the Git\nrepository lives inside the .git directory, but not everything inside\nthat directory is necessarily part of the repository.\n\nI do have plenty of stuff that isn't part of the repository inside the\n.git directory.\n\nThe easiest way to disprove that hypothesis is finding something inside\n.git that isn't part of the repository, and that's easily done:\n\n  .git/index\n\n-- \nFelipe Contreras\n"},{"id":"428503","messageId":"435b0150-cd9f-32ce-7a07-3057ef20662a@iee.email","threadId":"56004","inReplyTo":"7dd55e85-38eb-7346-ff10-7124102cd22b@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-06-25T20:48:28Z","receivedAt":"2021-06-25T20:48:39Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Kevin,\n\nOn 25/06/2021 02:44, Kevin Buckley wrote:\n> Hi there,\n>\n> raising this on the back of a discussion over at the Software\n> Carpentry lesson about Git,\n>\n>    https://github.com/swcarpentry/git-novice/issues/810\n>\n> I used the book to justify my claim that it is the .git directory\n> that is the repository, but I do have to concede that the way that\n> the text in section 2.1 of the book reads, does suggest that one\n> can refer to the working directory PLUS the .git directory as a\n> \"repository\" as well as being able to refer to the .git directory\n> alone as the \"repository\".\n>\n> In the way I think of it\n>\n> git init\n>\n> initialises a Git repository, however, the only thing that changes\n> as a result is that a .git directory has been created, ergo, the\n> .git directory is the repository.\n>\n> Furthermore, the fact that one can take the .git directory, move it\n> to a new directory and start using it there (very much a nice feature)\n> also suggests to me that it is the .git directory that is the repository,\n> as distict from a working directory, under Git control because of the\n> existence of a repository within it.\n>\n> Interested to hear any thoughts around the semantics here,\n\nIn general, the Git semantics are confusing.\n\nThere is the generic, the conceptual and the implementation, all of the\nsame term which has to be understood in context (which again uses terms\nwith the same multi-way context..). This leapfrogging from concept to\nimplementation and back again causes lots of learner confusion.\n\nYou have already seen that a source directory can become a repository by\nbeing initialised, and that the primary artefacts are in the .git\nsub-directory. One can also include in the generic 'repository' the\nvarious special .git* files that are [user] added to the main source\ndirectory.\n\nBut it gets worse. In the .git directory there is the 'objects'\ndirectory which actually holds all the _content_ of the 'repository',\neach object named by its hash value. This object store is a superset of\nthose objects that form the versioned repository structure (the 'DAG'),\nand other parts of Git, such as the staging area (Index) contents, and\nother temporary copies of 'stuff'.\n\nMeanwhile, to make the repository structure work, there are 'branch'\npointers (see 'ref/heads' [0]) to the specific object hashes that\nprovide the _starting point_ for each branch's linked list of commits\nand their content.\n\nThe use of the write-once unique object hash names [1] is part of that\nimplementation 'trickery' that allows Git to work so well, but helps\nconfuse those who think the object store is synonymous with the\nrepository (e.g. all the new learners..).\n\nIn summary, everyone is right, as long as they are clear about the\ncontext. Which they rarely are.\n\nPhilip\n\n[0] the 'ref name's are just strings that conveniently look just like\nposix paths ...\n[1] the current hash is the 160 bit sha1, so roughly 1 : 10^24  chance\nof a collision - unique enough;-)\n"},{"id":"428579","messageId":"12dd4f05-456f-c763-441e-5bb16634306a@pawsey.org.au","threadId":"56004","inReplyTo":"435b0150-cd9f-32ce-7a07-3057ef20662a@iee.email","subject":"Re: Definition of \"the Git repository\"","fromName":"Kevin Buckley","fromEmail":"kevin.buckley@pawsey.org.au","sentAt":"2021-06-28T02:24:44Z","receivedAt":"2021-06-28T02:24:57Z","isPatch":false,"sender":{"key":"kevin.buckley@pawsey.org.au","avatar":null},"body":"On 2021/06/26 04:48, Philip Oakley wrote:\n>\n> ... One can also include in the generic 'repository' the\n> various special .git* files that are [user] added to the main source\n> directory.\n> \n> But it gets worse. In the .git directory there is the 'objects' ...\n\nI don't believe it does get worse, indeed, I am not convinced that it\nis as bad as your observation on the semantics might suggest.\n\nEverything within the .git directory \"belongs\", in my way of thinking,\nto the \"repository\", that is, the directory that gets created when git\nis (init)ialised.\n\nFor me, the 'objects\", the 'ref/heads', the \"staging area' and the like,\nalso lie within the repository.\n\nAs for any anciliary files, that control how the git commands actually\nprocess any data in the \"working directory\" beyond the defaults, some\nof them, eg the global commands, will typically exist outside of the\nworking directory: below one's home directory, and, of course, there\nare the system-wide files, typically below /etc.\n\nGiven then, that we can have Git-related files, for any given working\ndirectory, below /etc, below the user's home directory, and within the\nworking directory itself, perhaps it is the whole \"computer\" which\nshould be referred to as \"the repository\"?\n\nFurthermore, even in the case of anciliary files typically found within\nthe working directory, and I'm thinking of .gitignore as the obvious\nexample, even the directives in that can be overriden on the command\nline, as well as complemented by files outside of the working directory.\n\n\nI am tempted to say that even if the definition of a \"repository\" can't\nbe agreed on, or rather, easily determined by inspection, then at least\nthe corresponding working directory can be, however, the fact that one\nhas  access to EnvVars and corresponding command line arguments such as\n--git-dir=<path>, --work-tree=<path>, would suggest that it could be\nharder for the novice to get their head around things, however, as it is\ntypicaly clear what the working directory is (the top level directory\ncontaining the files you are working on, under the control of Git),\ncalling that same directory the \"repository\" seems, to me anyway, to add\nto any confusion, that a Git novice may have.\n\nGiven the can of worms that this question has opened up, although I'm\ngetting the feeling that it has long since been opened, I still maintain\nthat it would be less confusing, at least for a novice, for the working\ndirectory to be identified and for a previously non-existent directory,\nthat gets created by the 'git init', to be referred to as the repository,\nso as to make a distinction.\n\nKevin\n"},{"id":"428581","messageId":"60d9410bb07a1_aac5d20888@natae.notmuch","threadId":"56004","inReplyTo":"12dd4f05-456f-c763-441e-5bb16634306a@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-28T03:24:59Z","receivedAt":"2021-06-28T03:25:04Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Kevin Buckley wrote:\n\n> Everything within the .git directory \"belongs\", in my way of thinking,\n> to the \"repository\", that is, the directory that gets created when git\n> is (init)ialised.\n> \n> For me, the 'objects\", the 'ref/heads', the \"staging area' and the like,\n> also lie within the repository.\n\nDoes it?\n\nSuppose you have three directories, each with exactly the same contents\nin their corresponding .git directory, the only difference is the\n.git/index file:\n\n a) No .git/index file at all\n b) The .git/index file doesn't have anything staged\n c) The .git/index file contains some staged changes\n\nDo you really consider them three different repositories?\n\nIn my mind the staging area is where you put stuff in preparation for\nthe commit. The commit is part of the repository, the staging area\nisn't.\n\n-- \nFelipe Contreras\n"},{"id":"428583","messageId":"ec31434f-0c99-ffb7-6eb0-6ecb1f6e761c@pawsey.org.au","threadId":"56004","inReplyTo":"60d9410bb07a1_aac5d20888@natae.notmuch","subject":"Re: Definition of \"the Git repository\"","fromName":"Kevin Buckley","fromEmail":"kevin.buckley@pawsey.org.au","sentAt":"2021-06-28T04:00:15Z","receivedAt":"2021-06-28T04:03:32Z","isPatch":false,"sender":{"key":"kevin.buckley@pawsey.org.au","avatar":null},"body":"On 2021/06/28 11:24, Felipe Contreras wrote:\n> Kevin Buckley wrote:\n> \n>> Everything within the .git directory \"belongs\", in my way of thinking,\n>> to the \"repository\", that is, the directory that gets created when git\n>> is (init)ialised.\n>> \n>> For me, the 'objects\", the 'ref/heads', the \"staging area' and the like,\n>> also lie within the repository.\n> \n> Does it?\n> \n> Suppose you have three directories, each with exactly the same contents\n> in their corresponding .git directory, the only difference is the\n> .git/index file:\n> \n>   a) No .git/index file at all\n>   b) The .git/index file doesn't have anything staged\n>   c) The .git/index file contains some staged changes\n> \n> Do you really consider them three different repositories?\n> \n> In my mind the staging area is where you put stuff in preparation for\n> the commit. The commit is part of the repository, the staging area\n> isn't.\n> \n\nI think I do consider them as different, yes, but in the sense that,\nbecause the contents of any working directory can change in isolation\nto the others, they have become different instances (perhaps clones?)\nof the same repository.\n\nLet's say I make two commits, that resulted in the same state of the\nfiles in the working directory, but I make them in different order\nin two of the working directories.\n\nClearly I need to sync the two different repositories in order to gain\na consistency across them, and that suggets, to me, that they should\nbe thought of as different.\n\nLet's say I'd rsync-d one working directory, in which I'd made changes\non its branch, with an unchanged one on a different branch (not that\nI'd recommend doing this without the utmost caution), then although the\nsync will not have affected the original branch in the unchanged directory,\nthe git internals, stored in the .git repository, would have changed to\nreflect the new state.\n\nAs to the staging area,\n\nagain, for me, Git has an understanding of a \"staging area\" based on its\ninspection of the state of the working directory and a comparison of that\nstate with what it knows has been committed.\n\nGiven that one can stash uncommited changes fron the \"staging area\", I\nthink of both the \"staging area\" and various stashes as parts of the\nrepository, in that you can't have a \"staging area\", unless there's a\n.git repository there to help instantiate the staging area\".\n\n\nVery much my perception of it all though: as others have pointed out,\nthere does seem to be some wriggle room in how it is percieved.\n\nKevin\n"},{"id":"428585","messageId":"60d95c6024f3d_aaf7e208a4@natae.notmuch","threadId":"56004","inReplyTo":"ec31434f-0c99-ffb7-6eb0-6ecb1f6e761c@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-28T05:21:36Z","receivedAt":"2021-06-28T05:21:41Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Kevin Buckley wrote:\n> On 2021/06/28 11:24, Felipe Contreras wrote:\n> > Kevin Buckley wrote:\n> > \n> >> Everything within the .git directory \"belongs\", in my way of thinking,\n> >> to the \"repository\", that is, the directory that gets created when git\n> >> is (init)ialised.\n> >> \n> >> For me, the 'objects\", the 'ref/heads', the \"staging area' and the like,\n> >> also lie within the repository.\n> > \n> > Does it?\n> > \n> > Suppose you have three directories, each with exactly the same contents\n> > in their corresponding .git directory, the only difference is the\n> > .git/index file:\n> > \n> >   a) No .git/index file at all\n> >   b) The .git/index file doesn't have anything staged\n> >   c) The .git/index file contains some staged changes\n> > \n> > Do you really consider them three different repositories?\n> > \n> > In my mind the staging area is where you put stuff in preparation for\n> > the commit. The commit is part of the repository, the staging area\n> > isn't.\n> > \n> \n> I think I do consider them as different, yes, but in the sense that,\n> because the contents of any working directory can change in isolation\n> to the others, they have become different instances (perhaps clones?)\n> of the same repository.\n> \n> Let's say I make two commits, that resulted in the same state of the\n> files in the working directory, but I make them in different order\n> in two of the working directories.\n> \n> Clearly I need to sync the two different repositories in order to gain\n> a consistency across them, and that suggets, to me, that they should\n> be thought of as different.\n\nYes, but this has nothing to do with .git/index. You are talking about\nbranches and commits. Clearly these are parts of a repository, and\nnobody objects to that.\n\n> As to the staging area,\n> \n> again, for me, Git has an understanding of a \"staging area\" based on its\n> inspection of the state of the working directory and a comparison of that\n> state with what it knows has been committed.\n\nWouldn't it be much easier to say that git is comparing the working\ndirectory with HEAD?\n\nClearly HEAD is part of the repository, and so is the commit that it's\npointing to (indirectly or directly).\n\nBut that doesn't say anything about the staging area, which is between\nthe two (in my mind): the working directory and the repository.\n\n\nTo try to make it more orthogonal, let's suppose the index file was\noutside the .git directory. Would you consider then the staging area\nseparate from the repository?\n\nIn fact, we don't have to suppose:\n\n  GIT_INDEX_FILE=/tmp/index git checkout @~ -- .\n\nDoes that command change the repository in any way?\n\n-- \nFelipe Contreras\n"},{"id":"428610","messageId":"070e36dc-f126-661a-3af7-b44d47ef7861@iee.email","threadId":"56004","inReplyTo":"12dd4f05-456f-c763-441e-5bb16634306a@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-06-28T15:18:04Z","receivedAt":"2021-06-28T15:20:26Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 28/06/2021 03:24, Kevin Buckley wrote:\n> On 2021/06/26 04:48, Philip Oakley wrote:\n>>\n>> ... One can also include in the generic 'repository' the\n>> various special .git* files that are [user] added to the main source\n>> directory.\n>>\n>> But it gets worse. In the .git directory there is the 'objects' ...\n>\n> I don't believe it does get worse, indeed, I am not convinced that it\n> is as bad as your observation on the semantics might suggest.\n>\n> Everything within the .git directory \"belongs\", in my way of thinking,\n> to the \"repository\", that is, the directory that gets created when git\n> is (init)ialised.\n\nPart of my view (of the multiplicity of descriptives within Git)\nregarding what is in a repository is from comparing the git created\ncontent from a clone, that of a `git init`, and a users overall project\nand .git trees after multiple interactions. Each has different features.\n\n>\n> For me, the 'objects\", the 'ref/heads', the \"staging area' and the like,\n> also lie within the repository.\n>\n> As for any anciliary files, that control how the git commands actually\n> process any data in the \"working directory\" beyond the defaults, some\n> of them, eg the global commands, will typically exist outside of the\n> working directory: below one's home directory, and, of course, there\n> are the system-wide files, typically below /etc.\n>\n> Given then, that we can have Git-related files, for any given working\n> directory, below /etc, below the user's home directory, and within the\n> working directory itself, perhaps it is the whole \"computer\" which\n> should be referred to as \"the repository\"?\n>\n> Furthermore, even in the case of anciliary files typically found within\n> the working directory, and I'm thinking of .gitignore as the obvious\n> example, even the directives in that can be overriden on the command\n> line, as well as complemented by files outside of the working directory.\n>\n>\n> I am tempted to say that even if the definition of a \"repository\" can't\n> be agreed on, or rather, easily determined by inspection, then at least\n> the corresponding working directory can be, however, the fact that one\n> has  access to EnvVars and corresponding command line arguments such as\n> --git-dir=<path>, --work-tree=<path>, would suggest that it could be\n> harder for the novice to get their head around things, however, as it is\n> typicaly clear what the working directory is (the top level directory\n> containing the files you are working on, under the control of Git),\n> calling that same directory the \"repository\" seems, to me anyway, to add\n> to any confusion, that a Git novice may have.\n>\n> Given the can of worms that this question has opened up, although I'm\n> getting the feeling that it has long since been opened, I still maintain\n> that it would be less confusing, at least for a novice, for the working\n> directory to be identified and for a previously non-existent directory,\n> that gets created by the 'git init', to be referred to as the repository,\n> so as to make a distinction.\n\nMy main point was that there is this creative tension between the\ndifferent contexts and that beginners should be aware that it's not all\ncut and dried in the same way that language definitions tend to be.\n\n--\n\nPhilip\n\n"},{"id":"428611","messageId":"CAPx1Gvcu9XzZF_LbV8YFsiGhL1DPwki-BNp5-5ZeB9BeiRj1AQ@mail.gmail.com","threadId":"56004","inReplyTo":"070e36dc-f126-661a-3af7-b44d47ef7861@iee.email","subject":"Re: Definition of \"the Git repository\"","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2021-06-28T15:34:58Z","receivedAt":"2021-06-28T15:51:33Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Jun 28, 2021 at 8:24 AM Philip Oakley <philipoakley@iee.email> wrote:\n> My main point was that there is this creative tension between the\n> different contexts and that beginners should be aware that it's not all\n> cut and dried in the same way that language definitions tend to be.\n\nUsers should be aware that users are humans, and humans are\nnot consistent.  Nothing is as cut-and-dried as it might appear, ever.  Or,\nas Kant put it: \"Out of the crooked timber of humanity, no straight thing\nwas ever made.\" https://en.wikipedia.org/wiki/Crooked_Timber\n\n(If you want to put fine distinctions on things, some parts of a repository\nare repository-wide, and some parts are work-tree-specific.  The git\nworktree command, when it adds a new work-tree, adds a new index\nand HEAD and *_HEAD and other work-tree-specific refs, for instance.\nThat said, I still teach that .git mainly contains the repository proper,\nwith the rest being your working tree -- or, once we introduce git worktree,\nyour *main* working tree.)\n\nChris\n"},{"id":"428680","messageId":"a5579940-237b-2e4d-bf18-bc0a8f2f1ee3@pawsey.org.au","threadId":"56004","inReplyTo":"60d95c6024f3d_aaf7e208a4@natae.notmuch","subject":"Re: Definition of \"the Git repository\"","fromName":"Kevin Buckley","fromEmail":"kevin.buckley@pawsey.org.au","sentAt":"2021-06-29T01:57:31Z","receivedAt":"2021-06-29T01:57:41Z","isPatch":false,"sender":{"key":"kevin.buckley@pawsey.org.au","avatar":null},"body":"On 2021/06/28 13:21, Felipe Contreras wrote:\n> \n> To try to make it more orthogonal, let's suppose the index file was\n> outside the .git directory. Would you consider then the staging area\n> separate from the repository?\n> \n> In fact, we don't have to suppose:\n> \n>    GIT_INDEX_FILE=/tmp/index git checkout @~ -- .\n> \n> Does that command change the repository in any way?\n  \nI have to admit that I don't know, and that I can't immediately\nsee where the \"repository\" would be, in that example. This is\nobviously a gap in my understanding: happy to defer to yours.\n\nI do however feel that the fact that we have moved to using examples\nthat override the Git Index file on the command line, in order to\ndefine what a \"repository\" is, just so that we might be able to give\na \"more correct\" definition of the term, to someone completely new to\nGit, suggests that, as others have already noted in the discussion,\nit's not easy to be \"correct\"?\n\nKevin\n"},{"id":"428700","messageId":"60da80a7d0abb_20757208c5@natae.notmuch","threadId":"56004","inReplyTo":"a5579940-237b-2e4d-bf18-bc0a8f2f1ee3@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-29T02:08:39Z","receivedAt":"2021-06-29T02:08:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Kevin Buckley wrote:\n> On 2021/06/28 13:21, Felipe Contreras wrote:\n> > \n> > To try to make it more orthogonal, let's suppose the index file was\n> > outside the .git directory. Would you consider then the staging area\n> > separate from the repository?\n> > \n> > In fact, we don't have to suppose:\n> > \n> >    GIT_INDEX_FILE=/tmp/index git checkout @~ -- .\n> > \n> > Does that command change the repository in any way?\n>   \n> I have to admit that I don't know, and that I can't immediately\n> see where the \"repository\" would be, in that example. This is\n> obviously a gap in my understanding: happy to defer to yours.\n\nWell, think about it.\n\n> I do however feel that the fact that we have moved to using examples\n> that override the Git Index file on the command line, in order to\n> define what a \"repository\" is, just so that we might be able to give\n> a \"more correct\" definition of the term, to someone completely new to\n> Git, suggests that, as others have already noted in the discussion,\n> it's not easy to be \"correct\"?\n\nNo. The repository is what the repository is. The command is merely an\naid for *you* to think about it.\n\nIf you are trying to define what a swan is, and you think a swan is a\nwhite bird, but then I show you a black swan, what do you think you\nshould do with your definition?\n\nWhat's complicated about this definition?\n\n  A git repository is contained in the .git directory, but it's not the\n  same thing. The staging area is usually inside the .git directory too,\n  but it's not part of the repository.\n\nWhy do you want to make it more complicated than that?\n\n-- \nFelipe Contreras\n"},{"id":"428722","messageId":"xmqq4kdhyx4m.fsf@gitster.g","threadId":"56004","inReplyTo":"7dd55e85-38eb-7346-ff10-7124102cd22b@pawsey.org.au","subject":"Re: Definition of \"the Git repository\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-29T06:59:21Z","receivedAt":"2021-06-29T06:59:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Buckley <Kevin.Buckley@pawsey.org.au> writes:\n\n> git init\n>\n> initialises a Git repository, however, the only thing that changes\n> as a result is that a .git directory has been created, ergo, the\n> .git directory is the repository.\n\nWell, there is a distinction between \"non-bare\" and \"bare\"\nrepository, so it is not exactly _wrong_ per-se to include the\nworking tree portion of a non-bare repository as part of the\nrepository created when you run \"git clone\", i.e. it is not a crime\nto say \"please run 'git clone' to get a new repository to work in\".\n\nOften we do need to single out the things under .git/ in a non-bare\nrepository when explaining certain features of Git, and need to\nclarify if it is not clear in the context (e.g. \"the .git repository\nproper in the result of such a non-bare 'git clone'\").  \n\nIt is nothing new in inter-human communication.\n\nIf there is a use of word \"repository\" in our documentation where it\nis not clear if the repository proper or the combination of both\nworking tree and the repository prper is meant, you may want to\npropose a clarification patch.\n\nThanks.\n"}]}