git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Submodule's .git file contains absolute path when created using 'git clone --recursive'
@ 2016-05-05 12:51 Loet Avramson
  2016-05-05 17:19 ` Junio C Hamano
  2016-05-05 17:22 ` Stefan Beller
  0 siblings, 2 replies; 7+ messages in thread
From: Loet Avramson @ 2016-05-05 12:51 UTC (permalink / raw)
  To: git

Hi,

According to git-clone man page - running 'git clone --recursive' "...is 
equivalent to running 'git submodule update --init --recursive' immediately 
after the clone is finished...", though I found a little difference between 
the two regarding the submodule's .git file:

1. Running 'git clone' and 'git submodule update --init --recursive' 
separately will create the .git file in each submodule containing a relative 
path to the superproject's .git directory as expected.

2. Running 'git clone --recursive' will create the .git file containing an 
*absolute* path to the superproject's .git directory. (as it was expected 
using git versions 1.7.8 - 1.7.10 as far as I understand)

Not sure if that's a bug but it got stuff behaving really weird in a specific 
usecase on one of our environments. It would be highly appreciated to update 
the docs at least.

Thanks.

 -Loet

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Submodule's .git file contains absolute path when created using 'git clone --recursive'
  2016-05-05 12:51 Submodule's .git file contains absolute path when created using 'git clone --recursive' Loet Avramson
@ 2016-05-05 17:19 ` Junio C Hamano
  2016-05-05 17:22 ` Stefan Beller
  1 sibling, 0 replies; 7+ messages in thread
From: Junio C Hamano @ 2016-05-05 17:19 UTC (permalink / raw)
  To: Loet Avramson; +Cc: git

Loet Avramson <loet@forter.com> writes:

> According to git-clone man page - running 'git clone --recursive' "...is 
> equivalent to running 'git submodule update --init --recursive' immediately 
> after the clone is finished...", though I found a little difference between 
> the two regarding the submodule's .git file:
>
> 1. Running 'git clone' and 'git submodule update --init --recursive' 
> separately will create the .git file in each submodule containing a relative 
> path to the superproject's .git directory as expected.
>
> 2. Running 'git clone --recursive' will create the .git file containing an 
> *absolute* path to the superproject's .git directory. (as it was expected 
> using git versions 1.7.8 - 1.7.10 as far as I understand)
>
> Not sure if that's a bug but it got stuff behaving really weird in a specific 
> usecase on one of our environments. It would be highly appreciated to update 
> the docs at least.

If the documentation already says "equivalent" and does not say
"identical", I am not sure if there is anything to update.

In any case, I thought some people are already working to make the
result consistently use relative paths (or was it absolute?), so
this may soon become a non-issue.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Submodule's .git file contains absolute path when created using 'git clone --recursive'
  2016-05-05 12:51 Submodule's .git file contains absolute path when created using 'git clone --recursive' Loet Avramson
  2016-05-05 17:19 ` Junio C Hamano
@ 2016-05-05 17:22 ` Stefan Beller
  2016-05-05 19:20   ` Loet Avramson
  1 sibling, 1 reply; 7+ messages in thread
From: Stefan Beller @ 2016-05-05 17:22 UTC (permalink / raw)
  To: Loet Avramson; +Cc: git@vger.kernel.org

On Thu, May 5, 2016 at 5:51 AM, Loet Avramson <loet@forter.com> wrote:
> Hi,
>
> According to git-clone man page - running 'git clone --recursive' "...is
> equivalent to running 'git submodule update --init --recursive' immediately
> after the clone is finished...", though I found a little difference between
> the two regarding the submodule's .git file:
>
> 1. Running 'git clone' and 'git submodule update --init --recursive'
> separately will create the .git file in each submodule containing a relative
> path to the superproject's .git directory as expected.
>
> 2. Running 'git clone --recursive' will create the .git file containing an
> *absolute* path to the superproject's .git directory. (as it was expected
> using git versions 1.7.8 - 1.7.10 as far as I understand)
>
> Not sure if that's a bug but it got stuff behaving really weird in a specific
> usecase on one of our environments. It would be highly appreciated to update
> the docs at least.

Which version of Git are you using?

See[1] for how clone handles submodules. (It's a call to submodule
update --init --recursive)

There was a bug with recursive submodules in the 2.7 time frame and
that got fixed in [2].

So could you make sure your version of Git contains these fixes?



[1] https://kernel.googlesource.com/pub/scm/git/git/+/master/builtin/clone.c#734
[2] https://kernel.googlesource.com/pub/scm/git/git/+/7307dd898988c79fc687051e783b3cac8488a559
specially https://kernel.googlesource.com/pub/scm/git/git/+/f8eaa0ba98b3bd9cb9035eba184a2d9806d30b27



>
> Thanks.
>
>  -Loet
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Submodule's .git file contains absolute path when created using 'git clone --recursive'
  2016-05-05 17:22 ` Stefan Beller
@ 2016-05-05 19:20   ` Loet Avramson
  2016-05-05 19:32     ` Stefan Beller
  0 siblings, 1 reply; 7+ messages in thread
From: Loet Avramson @ 2016-05-05 19:20 UTC (permalink / raw)
  To: Stefan Beller; +Cc: git@vger.kernel.org

It happened on 2.8.1, also reproducible on 2.8.2.
Haven't had the time to dive deeper into the code but my guess is that
relative_path() returns different results in those 2 cases or maybe
the way git-submodule.sh handles it.

On Thu, May 5, 2016 at 8:22 PM, Stefan Beller <sbeller@google.com> wrote:
> On Thu, May 5, 2016 at 5:51 AM, Loet Avramson <loet@forter.com> wrote:
>> Hi,
>>
>> According to git-clone man page - running 'git clone --recursive' "...is
>> equivalent to running 'git submodule update --init --recursive' immediately
>> after the clone is finished...", though I found a little difference between
>> the two regarding the submodule's .git file:
>>
>> 1. Running 'git clone' and 'git submodule update --init --recursive'
>> separately will create the .git file in each submodule containing a relative
>> path to the superproject's .git directory as expected.
>>
>> 2. Running 'git clone --recursive' will create the .git file containing an
>> *absolute* path to the superproject's .git directory. (as it was expected
>> using git versions 1.7.8 - 1.7.10 as far as I understand)
>>
>> Not sure if that's a bug but it got stuff behaving really weird in a specific
>> usecase on one of our environments. It would be highly appreciated to update
>> the docs at least.
>
> Which version of Git are you using?
>
> See[1] for how clone handles submodules. (It's a call to submodule
> update --init --recursive)
>
> There was a bug with recursive submodules in the 2.7 time frame and
> that got fixed in [2].
>
> So could you make sure your version of Git contains these fixes?
>
>
>
> [1] https://kernel.googlesource.com/pub/scm/git/git/+/master/builtin/clone.c#734
> [2] https://kernel.googlesource.com/pub/scm/git/git/+/7307dd898988c79fc687051e783b3cac8488a559
> specially https://kernel.googlesource.com/pub/scm/git/git/+/f8eaa0ba98b3bd9cb9035eba184a2d9806d30b27
>
>
>
>>
>> Thanks.
>>
>>  -Loet
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Submodule's .git file contains absolute path when created using 'git clone --recursive'
  2016-05-05 19:20   ` Loet Avramson
@ 2016-05-05 19:32     ` Stefan Beller
  2016-07-12 11:22       ` Ricardo Sánchez-Sáez
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Beller @ 2016-05-05 19:32 UTC (permalink / raw)
  To: Loet Avramson; +Cc: git@vger.kernel.org

On Thu, May 5, 2016 at 12:20 PM, Loet Avramson <loet@forter.com> wrote:
> It happened on 2.8.1, also reproducible on 2.8.2.
> Haven't had the time to dive deeper into the code but my guess is that
> relative_path() returns different results in those 2 cases or maybe
> the way git-submodule.sh handles it.
>

Then you found a new bug, congratulations. ;)
Thanks for reporting.

The shell script uses relative_path() only for displaying paths,
not for writing them to the .git file.

it really boils down to different environments
"git submodule update --init --recursive" is called from
(either manually or from `git clone`).

Apart from that there are no immediate bells ringing,
are you doing any weird stuff with the file system (soft/hard
links) ?

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Submodule's .git file contains absolute path when created using 'git clone --recursive'
  2016-05-05 19:32     ` Stefan Beller
@ 2016-07-12 11:22       ` Ricardo Sánchez-Sáez
  2016-07-12 16:46         ` Stefan Beller
  0 siblings, 1 reply; 7+ messages in thread
From: Ricardo Sánchez-Sáez @ 2016-07-12 11:22 UTC (permalink / raw)
  To: git

Stefan Beller <sbeller <at> google.com> writes:

> 
> On Thu, May 5, 2016 at 12:20 PM, Loet Avramson <loet <at> forter.com> wrote:
> > It happened on 2.8.1, also reproducible on 2.8.2.
> > Haven't had the time to dive deeper into the code but my guess is that
> > relative_path() returns different results in those 2 cases or maybe
> > the way git-submodule.sh handles it.
> >
> 
> Then you found a new bug, congratulations. ;)
> Thanks for reporting.
> 
> The shell script uses relative_path() only for displaying paths,
> not for writing them to the .git file.
> 
> it really boils down to different environments
> "git submodule update --init --recursive" is called from
> (either manually or from `git clone`).
> 
> Apart from that there are no immediate bells ringing,
> are you doing any weird stuff with the file system (soft/hard
> links) ?
> 
> Thanks,
> Stefan
> 

Hi,

sorry to awake an old thread. Has this been fixed? In which git version?
It's hitting me on git version  2.7.4 (Apple Git-66) (default git client on
 OS X 10.11.5 (15F34)).

I think all submodule .git files should contain relative paths. Otherwise,
 duplicating or moving the cloned  repository folder breaks the submodules.

Best,
Ricardo


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Submodule's .git file contains absolute path when created using 'git clone --recursive'
  2016-07-12 11:22       ` Ricardo Sánchez-Sáez
@ 2016-07-12 16:46         ` Stefan Beller
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Beller @ 2016-07-12 16:46 UTC (permalink / raw)
  To: Ricardo Sánchez-Sáez; +Cc: git@vger.kernel.org

On Tue, Jul 12, 2016 at 4:22 AM, Ricardo Sánchez-Sáez
<rsanchez.saez@gmail.com> wrote:
> Stefan Beller <sbeller <at> google.com> writes:
>
> Hi,
>
> sorry to awake an old thread. Has this been fixed? In which git version?
> It's hitting me on git version  2.7.4 (Apple Git-66) (default git client on
>  OS X 10.11.5 (15F34)).
>
> I think all submodule .git files should contain relative paths. Otherwise,
>  duplicating or moving the cloned  repository folder breaks the submodules.
>
> Best,
> Ricardo
>

The commit I referenced earlier:

$ git tag --contains f8eaa0ba98b3bd9cb9035eba184a2d9806d30b27
v2.8.3
v2.8.4
v2.9.0
v2.9.0-rc0
v2.9.0-rc1
v2.9.0-rc2
v2.9.1

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-07-12 16:46 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-05 12:51 Submodule's .git file contains absolute path when created using 'git clone --recursive' Loet Avramson
2016-05-05 17:19 ` Junio C Hamano
2016-05-05 17:22 ` Stefan Beller
2016-05-05 19:20   ` Loet Avramson
2016-05-05 19:32     ` Stefan Beller
2016-07-12 11:22       ` Ricardo Sánchez-Sáez
2016-07-12 16:46         ` Stefan Beller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).