# The shared Git repo used by git-new-workdir

4 messages from 2012-01-14 to 2012-01-16. Participants: Hilco Wijbenga, Holger Hellmuth.
Thread: https://gitlist.dev/t/29368

## Hilco Wijbenga, 2012-01-14 20:59

Subject: The shared Git repo used by git-new-workdir
Message-ID: <CAE1pOi3fBUBeNuhJqtJhxuMfz2G3iYOJy7U2HX6Nv4kqjcbnhw@mail.gmail.com>
URL: https://gitlist.dev/e/CAE1pOi3fBUBeNuhJqtJhxuMfz2G3iYOJy7U2HX6Nv4kqjcbnhw%40mail.gmail.com

```
Hi all,

First off, I use git-new-workdir a lot and it's working great. Kudos
to its developers!

I have been looking at the Git clone that is at the root of
git-new-workdir (i.e. the repository that is reused by all my
git-new-workdir created directories). This repo shows a lot of
activity when I run "git status" there.

So now I'm wondering. Should I simply ignore this completely? Or is
there some "clean up" I can do so that "git status" shows nothing? Or
would I destroy my git-new-workdir directories doing that? So far I've
only used this repo to create branches (i.e. to run git-new-workdir).

I would like to understand a bit better how I should treat this repo.
Whether it's basically a "do-not-touch" environment or whether I can
safely treat it as a normal Git repo.

Cheers,
Hilco

```

## Holger Hellmuth, 2012-01-16 18:09

Subject: Re: The shared Git repo used by git-new-workdir
Message-ID: <4F1467C1.504@ira.uka.de>
URL: https://gitlist.dev/e/4F1467C1.504%40ira.uka.de
In-Reply-To: <CAE1pOi3fBUBeNuhJqtJhxuMfz2G3iYOJy7U2HX6Nv4kqjcbnhw@mail.gmail.com>

```
On 14.01.2012 21:59, Hilco Wijbenga wrote:
> Hi all,
>
> First off, I use git-new-workdir a lot and it's working great. Kudos
> to its developers!
>
> I have been looking at the Git clone that is at the root of
> git-new-workdir (i.e. the repository that is reused by all my
> git-new-workdir created directories). This repo shows a lot of
> activity when I run "git status" there.
>
> So now I'm wondering. Should I simply ignore this completely? Or is
> there some "clean up" I can do so that "git status" shows nothing? Or
> would I destroy my git-new-workdir directories doing that? So far I've
> only used this repo to create branches (i.e. to run git-new-workdir).
>
> I would like to understand a bit better how I should treat this repo.
> Whether it's basically a "do-not-touch" environment or whether I can
> safely treat it as a normal Git repo.

Take a look at the rather simple script git-new-workdir (everything 
important happens in the last 20 lines). It just makes logical links to 
all files (mostly directories) under .git except three files that relate 
to the index (mainly the index file itself and HEAD)

That would suggest that normal git operations operating on files in 
those directories happen identical whether you are in the root repo or 
in any of the satellites. Only where the whole repo is acted upon (git 
clone, cp/rsync or deletion of the whole repo) the root repo would be 
"special".

```

## Hilco Wijbenga, 2012-01-16 18:57

Subject: Re: The shared Git repo used by git-new-workdir
Message-ID: <CAE1pOi3JocCoDGAmpCYdGdJN4E1nz8O4_i0MtLhwhP_axmH-uw@mail.gmail.com>
URL: https://gitlist.dev/e/CAE1pOi3JocCoDGAmpCYdGdJN4E1nz8O4_i0MtLhwhP_axmH-uw%40mail.gmail.com
In-Reply-To: <4F1467C1.504@ira.uka.de>

```
On 16 January 2012 10:09, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> On 14.01.2012 21:59, Hilco Wijbenga wrote:
> Take a look at the rather simple script git-new-workdir (everything
> important happens in the last 20 lines). It just makes logical links to all
> files (mostly directories) under .git except three files that relate to the
> index (mainly the index file itself and HEAD)

Yes, I did that but I cannot figure out from that why I see lots of
files and such staged for commit on master when I almost never work on
master. I only use master to pull in upstream and to merge in one of
my branches and push. So unless I'm doing that, I would expect "git
status" to not output anything.

> That would suggest that normal git operations operating on files in those
> directories happen identical whether you are in the root repo or in any of
> the satellites. Only where the whole repo is acted upon (git clone, cp/rsync
> or deletion of the whole repo) the root repo would be "special".

That all makes sense to me and is what I was expecting. So why is "git
status" on master displaying anything?

Here is what I see:

In my working directory:
hilco@centaur /mnt/lacie/workspaces/my-project-master
my-project-master (master $ u=)$ git status
# On branch master
nothing to commit (working directory clean)

In the shared repo:
hilco@centaur ~/git-clones/my-project my-project (master +$ u=)$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    .gitattributes
#       modified:   .gitignore
#       new file:   ...
... hundreds more ...

Is this related to my use of a symlink? I have a symlink
"~/workspaces" pointing to /mnt/lacie/workspaces/. Is that somehow
affecting things?

```

## Holger Hellmuth, 2012-01-16 19:15

Subject: Re: The shared Git repo used by git-new-workdir
Message-ID: <4F14774A.40100@ira.uka.de>
URL: https://gitlist.dev/e/4F14774A.40100%40ira.uka.de
In-Reply-To: <CAE1pOi3JocCoDGAmpCYdGdJN4E1nz8O4_i0MtLhwhP_axmH-uw@mail.gmail.com>

```
On 16.01.2012 19:57, Hilco Wijbenga wrote:
> In my working directory:
> hilco@centaur /mnt/lacie/workspaces/my-project-master
> my-project-master (master $ u=)$ git status
> # On branch master
> nothing to commit (working directory clean)
>
> In the shared repo:
> hilco@centaur ~/git-clones/my-project my-project (master +$ u=)$ git status
> # On branch master
> # Changes to be committed:
> #   (use "git reset HEAD<file>..." to unstage)
> #
> #       deleted:    .gitattributes
> #       modified:   .gitignore
> #       new file:   ...
> ... hundreds more ...

This is related to your using two repos with the same branch 
(irrespective of root repo or not).

There is nothing wrong with that per se, but if you add/commit/merge etc 
in one of those two, the working directory and index of the other repo 
doesn't get updated automatically. You would have to do "git reset 
--hard" in that repo to get it up-to-date

If you want to avoid this just don't check out the same branch in any 
two repos, root or not.

```
