[PATCH 0/2] fix problems with recursive submodule fetching

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 18.09.2010 02:29, schrieb Kevin Ballard:
> Yep, this patch fixes the output issue. Now all submodules are reported.

Thanks again for testing this, the first patch of this series fixes
that and adds the necessary tests to not let that happen again.

The second patch lets "git fetch" use the index instead of .gitmodules
to get the list of submodules to fetch. I think this makes sense, even
if fetch didn't need to read the index until now, but the gitlink
entries are not susceptible to configuration errors like those from
.gitmodules (And "git submodule update" uses the index via "git
ls-files" too, so we'll also avoid regressions that way).

Any objections to the second patch?


> However, they're still not prefixed with the previous layers, so it appears like all submodules are rooted in the current directory, which is obviously not true.

Yes, as promised I will address this in a patch soon to come. And I
will also post a patch to add a configuration option to control the
recursive fetching.

Junio: IMO these future patches are needed before this feature can be
merged into master.


> And of course the performance issue is still relevant.

Hmm, I think it still the right thing to do to a full fetch of all
submodule changes, as you can't possibly know at fetch time what you'll
need later. But I have to admit that "git submodule update" does some
kind of optimization, as it only fetches submodules where the commit
recorded in the superproject has changed. But IMO this aims a bit too
short, as it still can lead to commits missing in submodules (which are
on branches you didn't check out and ran "git submodule update" on).

The aim of these changes is to make you able to do a fetch before you go
onto a plane and then check out every branch of the superproject without
having a commit missing from a submodule. And even more, you should be
able to use all new submodule commits not yet committed inside the
superproject without being able to forget to fetch them before you leave.

But maybe we can reduce this performance impact by running the submodule
fetches in threads. Dunno yet, I'll look into that as soon as I have the
other two patches ready.


These patches apply to current next or jl/fetch-submodule-recursive.


Jens Lehmann (2):
  fetch: Fix a bug swallowing the output of recursive submodule
    fetching
  fetch: Get submodule paths from index and not from .gitmodules

 submodule.c                 |   26 +++++++++++++++++++-------
 t/t5526-fetch-submodules.sh |   30 +++++++++++++++++++++++++-----
 2 files changed, 44 insertions(+), 12 deletions(-)

-- 
1.7.3.rc2.234.g00c0

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]