why a .git directory and not gitdir + core.worktree

[Manuel Naranjo]

Hello guys,

In the company I work for I've been assigned the challenging task of
migrating all the source repositories from svn to git. Once we had that
completed I suggested and introduced a modified version of repo so that
we can get all the dependencies together (internal and external) when
building any of the company projects. This customized repo has some new
features like allowing to do git push from repo and it evens works on
Windows with the usage of ntfslink.

Anyway thing is that some of this Windows users are using TortoiseGit
and Tortoise gets in trouble when .git has symlinks inside and thinks
the directory is not actually a git repository. So I started researching
and find out that .git can be a file with just a line that says 'gitdir:
< path to repository data >' and adding core.worktree to the config of
the repository data that points to the root of the checkout folder,
question is why this cool feature is not been used by repo?

Cheers,
Manuel

[Rich Schmitt]

I followed you up until your comment about adding core.worktree.  Perhaps you can elaborate.

The main and possibly only reason I know of for why .git has text to the gitdir rather then the actualy gitdir subdirectory is for submodules.  In the case of submodules, the submodule gitdir is actually under the super-module's gitdir.  If you look in the super-module's gitdir, you will see a subdirectory called 'modules' and under this, you will see subdirectories for each submodule registered. 

I suppose if .git only ran on linux, they could have made the .git file in the submodule working directory be a linux soft link, but since git is portable they created their own way of showing the link.

Rich

[Shawn Pearce]

IIRC the .git-as-afile link came about after repo was written. Nobody
has gone back and updated repo.

[Manuel Naranjo]

On 18/01/13 13:52, Rich Schmitt wrote:
> I followed you up until your comment about adding core.worktree.
> Perhaps you can elaborate.

Ok so let's say you have the following structure

1 - <root>/.repo/projects/projectA.git
2 - <root>/projectA

in 2 you want a .git file that says 'gitdir: <path to 1>'
and in 1 you want core.worktree to be set to <path to 2> otherwise git
from a folder inside 2 will not behave correctly only from 2.

>
> The main and possibly only reason I know of for why .git has text to the
> gitdir rather then the actualy gitdir subdirectory is for submodules.
> In the case of submodules, the submodule gitdir is actually under the
> super-module's gitdir. If you look in the super-module's gitdir, you
> will see a subdirectory called 'modules' and under this, you will see
> subdirectories for each submodule registered.

Indeed the main usage is submodules, but there are others as well, as in
this case.

As I said on my reply to Shawm, I was just double checking, wanted to
make sure it wasn't a design choice, but rather something that wasn't
available or something like that.

>
> I suppose if .git only ran on linux, they could have made the .git file
> in the submodule working directory be a linux soft link, but since git
> is portable they created their own way of showing the link.
>
> Rich
>
> On Friday, January 18, 2013 7:33:48 AM UTC-6, Manuel Naranjo wrote:
>
> Hello guys,
>
> In the company I work for I've been assigned the challenging task of
> migrating all the source repositories from svn to git. Once we had that
> completed I suggested and introduced a modified version of repo so that
> we can get all the dependencies together (internal and external) when
> building any of the company projects. This customized repo has some new
> features like allowing to do git push from repo and it evens works on
> Windows with the usage of ntfslink.
>
> Anyway thing is that some of this Windows users are using TortoiseGit
> and Tortoise gets in trouble when .git has symlinks inside and thinks
> the directory is not actually a git repository. So I started
> researching
> and find out that .git can be a file with just a line that says
> 'gitdir:
> < path to repository data >' and adding core.worktree to the config of
> the repository data that points to the root of the checkout folder,
> question is why this cool feature is not been used by repo?
>
> Cheers,
> Manuel
>

> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

[Brad Larson]

If it is helpful, I started work on this back when $DAYJOB was considering repo on Windows.  It was never finished, but was very close.

https://gerrit-review.googlesource.com/#/c/20981/ 

[Torne Wuff]

One downside of this approach is that currently it's possible to share .repo/projects between multiple checkouts. If you used the textual-link .git instead then the checkouts would be sharing their entire state, including the HEAD pointer, and thus this would break badly.

Currently repo sets up the symlink forest such that the object database and set of branches is shared, but the checkouts can have independant HEADs (the same way git-new-workdir works) and I quite like this feature..

Having it as an option (or just doing it on windows?) would be reasonable, though.

--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

[Manuel Naranjo]

On 18/01/13 16:57, Torne Wuff wrote:
> One downside of this approach is that currently it's possible to share
> .repo/projects between multiple checkouts. If you used the textual-link
> .git instead then the checkouts would be sharing their entire state,
> including the HEAD pointer, and thus this would break badly.

I see, ok that something I think we can drop in our use case. We don't
have 15G of code to transfer so it's ok for us.

> Currently repo sets up the symlink forest such that the object database
> and set of branches is shared, but the checkouts can have independant
> HEADs (the same way git-new-workdir works) and I quite like this feature..

I will check this feature, never heard of it.

> Having it as an option (or just doing it on windows?) would be
> reasonable, though.

Actually repo for Windows can work without this. What you get when you
add this is the ability to use shell features like TortoiseGit.

>
>
> On 18 January 2013 05:33, Manuel Naranjo <naranjo...@gmail.com

> <mailto:naranjo...@gmail.com>> wrote:
>
> Hello guys,
>
> In the company I work for I've been assigned the challenging task of
> migrating all the source repositories from svn to git. Once we had
> that completed I suggested and introduced a modified version of repo
> so that we can get all the dependencies together (internal and
> external) when building any of the company projects. This customized
> repo has some new features like allowing to do git push from repo
> and it evens works on Windows with the usage of ntfslink.
>
> Anyway thing is that some of this Windows users are using
> TortoiseGit and Tortoise gets in trouble when .git has symlinks
> inside and thinks the directory is not actually a git repository. So
> I started researching and find out that .git can be a file with just
> a line that says 'gitdir: < path to repository data >' and adding
> core.worktree to the config of the repository data that points to
> the root of the checkout folder, question is why this cool feature
> is not been used by repo?
>
> Cheers,
> Manuel
>
> --

> To unsubscribe, email repo-discuss+unsubscribe@__googlegroups.com
> <mailto:repo-discuss%2Bunsu...@googlegroups.com>
> More info at http://groups.google.com/__group/repo-discuss?hl=en
> <http://groups.google.com/group/repo-discuss?hl=en>
>
>

[Manuel Naranjo]

>> One downside of this approach is that currently it's possible to share
>> .repo/projects between multiple checkouts. If you used the textual-link
>> .git instead then the checkouts would be sharing their entire state,
>> including the HEAD pointer, and thus this would break badly.

Is this when you setup a repo mirror and then use repo reference on init?

Or are you talking of one manifest referencing the same project multiple
times?

If it's the first case then there's no problem with this. Because you
would have 1 git dir inside .repo/projects per repo structure, which
will have objects/info/alternates set accordingly, then been able to
share the objects which is what takes most space in HD.

[Torne Wuff]

On 24 January 2013 07:28, Manuel Naranjo <naranjo...@gmail.com> wrote:

One downside of this approach is that currently it's possible to share
.repo/projects between multiple checkouts. If you used the textual-link
.git instead then the checkouts would be sharing their entire state,
including the HEAD pointer, and thus this would break badly.

Is this when you setup a repo mirror and then use repo reference on init?

Or are you talking of one manifest referencing the same project multiple times?

No, neither of these things. I have a number of trees where the entire .repo/projects directory is literally shared with another tree via a bindmount. This means that everything only gets downloaded and stored once (without the hazards of using alternates) and it also means that local branches are visible in both trees. This only works because the actual working copies of each project have a .git/HEAD which is a real file that isn't shared. This is not something that repo "supports", it just happens to work because of how repo sets up the symlink forest in .git in each workdir, which is very reminiscent of git-new-workdir. Using a textual link for .git will stop this working.

 

If it's the first case then there's no problem with this. Because you would have 1 git dir inside .repo/projects per repo structure, which will have objects/info/alternates set accordingly, then been able to share the objects which is what takes most space in HD.

This is not entirely about saving disk space; it's about being able to work in multiple checkouts/manifest branches at once without having to pull one's own local changes back and forth between places.