On Sat, Mar 12, 2016 at 11:29 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> Why is it interesting for submodules but not for standard repositories?
>>
>> If I clone a repository without submodules, it is also not recorded
>> that I cloned with an explicit depth=1. If you fetch, you may end up with
>> a deeper history as git fetch doesn't do a "reshallow" to the configured
>> depth.
>
> Very simple.
>
> If you do not have submodule, you would always interact with the
> other side directly with "git fetch" or "git pull" and have total
> control over when you choose to pass or not to pass extra options to
> choose to 1. incrementally extend, 2. deepen, or 3. unshallow. The
> user will always explicitly tell you, and knowing how you got there
> would not help you, as there is no need to guess for you.
But the 1. being the default when no options are given, would fit into
the story of submodule treatment here, too?
Say you have run
$ git clone --recurse-submodules --shallow-submodules --depth 42
and later
$ git fetch --recurse-submodules
you'd fetch as usual without moving the anchor point. You could have
options like
$ git fetch --recurse-submodules[=label/pattern]
--unshallow-submodules[=label/pattern]
So first a switch for submodule behavior during fetch and that switch could
be narrowed down to specific submodules only.
>
> The user can do the same explicit "cd dir && git fetch" update in
> each submodule directory and give appropriate options to choose
> among the three, but I have an impression that your recent work is
> going in the direction of making commands that are run in the
> superproject recurse into submodules that automatically fetches and
> updates the history down there, discouraging users from working on
> individual submodules.
Glad you see the high level direction where the submodules are heading,
I was just fixing the most obvious problems (as indicated by their existence
in the "repo" tool).
For the workflow I would think you'd only operate in the supermodule for
synchronizing, e.g.
$ (cd super_project && git pull --recurse-submodules)
$ (cd super_project/submoduleA && $EDITOR && git add <...> && git
commit <...>)
$ (cd super_project/submoduleB && $EDITOR && git add <...> && git
commit <...>)
# now it becomes a Gerrit specific workflow; no need to commit
submodule changes
# to the super project, (but it may not do harm?)
$ (cd super_project && git push --recurse-submodules
--submodules-only origin HEAD:refs/for/master)
The last command pushes submodules only as Gerrit will perform the
superproject update
on your behalf. This is needed as submodules are treated as binary
files, i.e. merging
diverged submodules is hard. So to avoid diverging submodules, Gerrit
can do that for you.
Another workflow could be to improve the merge algorithm for
submodules, such that
you can specify how they should be integrated (merged when no conflict
in the submodules
occurs; or rebase the commits in the submodules, altering the commit
in the superproject.)
> You lose the flexibility to explicitly
> choose among the three for individual submodules, and you may want
> to have some smart in your "run from the superproject and recurse"
> tools.
But that smart can also come from commandline options (or configuration in
the super project). So you would suggest to configure the superproject
to a certain behavior when you clone with submodules in a certain way?
>
> A submodule that was initially cloned with depth=1, perhaps because
> the user didn't know if the module was interesting to her in the
> context of working on the superproject before she had her clone of
> the superproject hence she only wanted to see what's there, and a
> submodule that was not even fetched initially when the superproject
> was cloned and later was "submodule init"ed and fetched with
> depth=1, would have the same shallow boundary, but the intent of the
> user would clearly be different in the larger picture. I imagined
> that your "run in top-level and recurse to fetch in submodules"
> tools would benefit if it has more information to intuit what the
> end user meant.
So the first one should be shallowed after fetch, but the second would
fetch or even deepen automatically?
I am not sure if we add too much "intuitive magic" here as it would be
hard to explain why that happens?
--
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