Re: Definition of "the Git repository"

From: Kevin Buckley <kevin.buckley@pawsey.org.au>
Date: Jun 28, 2021, 04:00 UTC
Message-ID: <ec31434f-0c99-ffb7-6eb0-6ecb1f6e761c@pawsey.org.au>
In-Reply-To: <60d9410bb07a1_aac5d20888@natae.notmuch>

On 2021/06/28 11:24, Felipe Contreras wrote:

Show 25 quoted lines

> Kevin Buckley wrote:
> 
>> Everything within the .git directory "belongs", in my way of thinking,
>> to the "repository", that is, the directory that gets created when git
>> is (init)ialised.
>> 
>> For me, the 'objects", the 'ref/heads', the "staging area' and the like,
>> also lie within the repository.
> 
> Does it?
> 
> Suppose you have three directories, each with exactly the same contents
> in their corresponding .git directory, the only difference is the
> .git/index file:
> 
>   a) No .git/index file at all
>   b) The .git/index file doesn't have anything staged
>   c) The .git/index file contains some staged changes
> 
> Do you really consider them three different repositories?
> 
> In my mind the staging area is where you put stuff in preparation for
> the commit. The commit is part of the repository, the staging area
> isn't.
>

I think I do consider them as different, yes, but in the sense that, because the contents of any working directory can change in isolation to the others, they have become different instances (perhaps clones?) of the same repository.

Let's say I make two commits, that resulted in the same state of the files in the working directory, but I make them in different order in two of the working directories.

Clearly I need to sync the two different repositories in order to gain a consistency across them, and that suggets, to me, that they should be thought of as different.

Let's say I'd rsync-d one working directory, in which I'd made changes on its branch, with an unchanged one on a different branch (not that I'd recommend doing this without the utmost caution), then although the sync will not have affected the original branch in the unchanged directory, the git internals, stored in the .git repository, would have changed to reflect the new state.

As to the staging area,

again, for me, Git has an understanding of a "staging area" based on its inspection of the state of the working directory and a comparison of that state with what it knows has been committed.

Given that one can stash uncommited changes fron the "staging area", I think of both the "staging area" and various stashes as parts of the repository, in that you can't have a "staging area", unless there's a .git repository there to help instantiate the staging area".

Very much my perception of it all though: as others have pointed out, there does seem to be some wriggle room in how it is percieved.

Kevin