Heiko Voigt writes:
> On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote:
>> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote:
>> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:
>> >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:
>> >> > On Fri, Aug 18, 2017
On Fri, Aug 25, 2017 at 2:10 AM, Heiko Voigt wrote:
> On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote:
>> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote:
>> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:
>> >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote
On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote:
> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote:
> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:
> >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:
> >> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C
On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote:
> On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:
>> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:
>> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:
>> >> As long as we are talking about idealized future w
On Mon, Aug 21, 2017 at 09:48:51AM -0700, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > So I think it is important that there are commits in the submodule so
> > its history makes sense independently for others.
>
> I was trying to push the "just like trees" to the logical conclusion
> in or
On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:
> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:
> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:
> >> As long as we are talking about idealized future world (well, at
> >> least an idea of somebody's "ideal", n
Stefan Beller writes:
> On Fri, Aug 18, 2017 at 11:51 PM, Junio C Hamano wrote:
>
>> As long as we are talking about idealized future world (well, at
>> least an idea of somebody's "ideal", not necessarily shared by
>> everybody), I wonder if there is even any need to have commits in
>> submodul
Heiko Voigt writes:
> So I think it is important that there are commits in the submodule so
> its history makes sense independently for others.
I was trying to push the "just like trees" to the logical conclusion
in order to see see if it leads to an absurd conclusions, or some
useful scenario.
On Fri, Aug 18, 2017 at 11:51 PM, Junio C Hamano wrote:
> As long as we are talking about idealized future world (well, at
> least an idea of somebody's "ideal", not necessarily shared by
> everybody), I wonder if there is even any need to have commits in
> submodules in such a world. To realize
On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:
> On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:
>> As long as we are talking about idealized future world (well, at
>> least an idea of somebody's "ideal", not necessarily shared by
>> everybody), I wonder if there is even any n
On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:
> As long as we are talking about idealized future world (well, at
> least an idea of somebody's "ideal", not necessarily shared by
> everybody), I wonder if there is even any need to have commits in
> submodules in such a world. To r
> On 18 Aug 2017, at 19:16, Stefan Beller wrote:
>
>> In the past "submodule..update=none" was an easy way
>> to selectively disable certain Submodules.
>>
>> How would I do this with Git 2.14?
>
>submodule..active = false
That's what I thought after your first response. However,
this tes
Stefan Beller writes:
> Jonathan brought up the following very long term vision:
> Eventually the everyday git commands do not treat submodules
> any special than trees, even the submodules git directory
> may be non existent (everything is absorbed into the superproject);
> so it really feels li
Stefan Beller writes:
>> In the past "submodule..update=none" was an easy way
>> to selectively disable certain Submodules.
>>
>> How would I do this with Git 2.14?
>
> submodule..active = false
>
>> My gut feeling is that all commands should respect the
>> "submodule..update=none" setting.
>
On Fri, Aug 18, 2017 at 9:50 AM, Junio C Hamano wrote:
> I am not sure if I follow. Submodules are not trees and one of the
> reasons people may want to separate things into different modules is
> so that they can treat them differently. If submodules allow you
> a richer set of operations than
> In the past "submodule..update=none" was an easy way
> to selectively disable certain Submodules.
>
> How would I do this with Git 2.14?
submodule..active = false
> My gut feeling is that all commands should respect the
> "submodule..update=none" setting.
Well my gut feeling was that the "
Stefan Beller writes:
> On Thu, Aug 17, 2017 at 7:13 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> Are you saying this might be a design mistake and
>>> the .update ought to be respected by all the other
>>> commands? For example
>>> git reset --recurse-submodules
>>> should ign
> On 17 Aug 2017, at 23:55, Stefan Beller wrote:
>
> On Thu, Aug 17, 2017 at 2:21 PM, Lars Schneider
> wrote:
>>
>>> Oh, wait.
>>> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c
>>> c9c63ee558 Merge branch 'sb/pull-rebase-submodule'
>>> a6d7eb2c7a pull: optionally rebase submodules (re
On Thu, Aug 17, 2017 at 7:13 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Are you saying this might be a design mistake and
>> the .update ought to be respected by all the other
>> commands? For example
>> git reset --recurse-submodules
>> should ignore the .update= none?
>
> I have
Stefan Beller writes:
> Are you saying this might be a design mistake and
> the .update ought to be respected by all the other
> commands? For example
> git reset --recurse-submodules
> should ignore the .update= none?
I have been under the impression that that has been the traditional
desir
On Thu, Aug 17, 2017 at 2:21 PM, Lars Schneider
wrote:
>
>> Oh, wait.
>> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c
>> c9c63ee558 Merge branch 'sb/pull-rebase-submodule'
>> a6d7eb2c7a pull: optionally rebase submodules (remote submodule changes only)
>> could also be a culprit. Do you
> On 16 Aug 2017, at 20:51, Stefan Beller wrote:
>
> On Wed, Aug 16, 2017 at 11:35 AM, Lars Schneider
> wrote:
>> Hi,
>>
>> I think we discovered a regression in Git 2.14.1 today.
>> It looks like as if "git submodule update --init --recursive" removes
>> the "skip submodules" config.
>>
>> C
On Wed, Aug 16, 2017 at 11:51 AM, Stefan Beller wrote:
> Any chance the "did not happen with 2.13" was not
> freshly cloned but tested on an existing repo? If so a hot
> candidate for suspicion is a93dcb0a56 (Merge branch
> 'bw/submodule-is-active', 2017-03-30), IMHO, just
> gut feeling, though.
On Wed, Aug 16, 2017 at 11:35 AM, Lars Schneider
wrote:
> Hi,
>
> I think we discovered a regression in Git 2.14.1 today.
> It looks like as if "git submodule update --init --recursive" removes
> the "skip submodules" config.
>
> Consider the following steps:
>
> git clone https://server/repo.
24 matches
Mail list logo
