On Sat, Jan 21, 2017 at 2:17 AM, Jeff King wrote:
> On Thu, Jan 19, 2017 at 11:30:23AM -0800, Stefan Beller wrote:
>
>> Now let's ask the same question for "git -C sub status ." (which is a
>> command that is only reading and not writing to the repository)
>>
>> 1) If the submodule
On Fri, Jan 20, 2017 at 1:58 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jeff King writes:
>>
And in my current understanding of submodules the check in
.gitmodules ought to be enough, too.
>>>
>>> Yeah, that probably
On Fri, Jan 20, 2017 at 01:58:02PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >>> And in my current understanding of submodules the check in
> >>> .gitmodules ought to be enough, too.
> >>
> >> Yeah, that probably makes
Junio C Hamano writes:
> Jeff King writes:
>
>>> And in my current understanding of submodules the check in
>>> .gitmodules ought to be enough, too.
>>
>> Yeah, that probably makes sense. You can have a gitlink without a
>> .gitmodules file, but I don't quite
On Fri, Jan 20, 2017 at 01:41:54PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> >> And in my current understanding of submodules the check in
> >> .gitmodules ought to be enough, too.
> >
> > Yeah, that probably makes sense. You can have a gitlink without a
> >
Jeff King writes:
>> And in my current understanding of submodules the check in
>> .gitmodules ought to be enough, too.
>
> Yeah, that probably makes sense. You can have a gitlink without a
> .gitmodules file, but I don't quite know what that would mean in terms
> of submodules (I
On Fri, Jan 20, 2017 at 12:00 PM, Jeff King wrote:
> On Fri, Jan 20, 2017 at 11:53:01AM -0800, Stefan Beller wrote:
>
>> > One alternative would be to make the check cheaper. Could we reliably
>> > tell from the submodule.foo.* block in the config that path "foo" is a
>> >
On Fri, Jan 20, 2017 at 11:53:01AM -0800, Stefan Beller wrote:
> > One alternative would be to make the check cheaper. Could we reliably
> > tell from the submodule.foo.* block in the config that path "foo" is a
> > submodule? I think that would work after "submodule init" but not right
> > after
On Fri, Jan 20, 2017 at 11:42 AM, Jeff King wrote:
> On Fri, Jan 20, 2017 at 11:33:45AM -0800, Stefan Beller wrote:
>
>> > I'd rather see it in the commands themselves. Especially given the
>> > "ideal" in your status example, which requires command-specific
>> > knowledge.
>>
>>
On Fri, Jan 20, 2017 at 11:33:45AM -0800, Stefan Beller wrote:
> > I'd rather see it in the commands themselves. Especially given the
> > "ideal" in your status example, which requires command-specific
> > knowledge.
>
> So you rather want to go bottom up, i.e. add it to each command
On Fri, Jan 20, 2017 at 11:17 AM, Jeff King wrote:
> On Thu, Jan 19, 2017 at 11:30:23AM -0800, Stefan Beller wrote:
>
>> Now let's ask the same question for "git -C sub status ." (which is a
>> command that is only reading and not writing to the repository)
>>
>> 1) If the
On Thu, Jan 19, 2017 at 11:30:23AM -0800, Stefan Beller wrote:
> Now let's ask the same question for "git -C sub status ." (which is a
> command that is only reading and not writing to the repository)
>
> 1) If the submodule is populated, the user clearly intended to know
>more about the
Consider you have a submodule at path "sub". What should happen in case
you run a command such as "git -C sub add ." ?
Here is what currently happens:
1) The submodule is populated, i.e. there is a .git (file/dir) inside
"sub". This is equivalent of running "git add ." in the submodule and
13 matches
Mail list logo