Stefan Beller writes:
> The point I was trying to make is best demonstrated in
> t5526-fetch-submodules.sh:
>
>> ok 7 - using fetchRecurseSubmodules=true in .gitmodules recurses into
>> submodules
>> ok 8 - --no-recurse-submodules overrides .gitmodules config
>> ok 9 - using fetchRecurseSubmodul
On Thu, Jul 13, 2017 at 12:12 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote:
This triggers two reactions for me:
(a) We should totally do that.
>>>
(b) It's a rabbit hole to go down.
>>>
>>> And yes, I had both of thos
Stefan Beller writes:
> On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote:
>>> This triggers two reactions for me:
>>>
>>> (a) We should totally do that.
>>
>>> (b) It's a rabbit hole to go down.
>>
>> And yes, I had both of those reactions, too. We've had the
>> "project-level .gitconfig" discus
On 07/13, Stefan Beller wrote:
> On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote:
> >> This triggers two reactions for me:
> >>
> >> (a) We should totally do that.
> >
> >> (b) It's a rabbit hole to go down.
> >
> > And yes, I had both of those reactions, too. We've had the
> > "project-level .gi
On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote:
>> This triggers two reactions for me:
>>
>> (a) We should totally do that.
>
>> (b) It's a rabbit hole to go down.
>
> And yes, I had both of those reactions, too. We've had the
> "project-level .gitconfig" discussion many times over the years. An
On Wed, Jul 12, 2017 at 04:54:38PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I could see somebody arguing that format-patch should respect a project
> > preference, since its primary purpose is to communicate your work to the
> > rest of the project.
> >
> > But then you could make
On Wed, Jul 12, 2017 at 02:08:35PM -0700, Stefan Beller wrote:
> > I could see somebody arguing that format-patch should respect a project
> > preference, since its primary purpose is to communicate your work to the
> > rest of the project.
> >
> > But then you could make a similar argument for ot
Jeff King writes:
> I could see somebody arguing that format-patch should respect a project
> preference, since its primary purpose is to communicate your work to the
> rest of the project.
>
> But then you could make a similar argument for other diff options, too.
Yeah, and that opens a whole c
On Wed, Jul 12, 2017 at 2:37 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> 2. collaboration.
>> When I want to review a patch from the mailing list,
>> I could (a) download the patch, apply locally, see the diff
>> formatted nicely according to diff.orderFile.
>
> If you are
Stefan Beller writes:
> 2. collaboration.
> When I want to review a patch from the mailing list,
> I could (a) download the patch, apply locally, see the diff
> formatted nicely according to diff.orderFile.
If you are not doing a review of a patch with complex changes that
benefits b
On Wed, Jul 12, 2017 at 1:57 PM, Jeff King wrote:
> On Wed, Jul 12, 2017 at 01:44:46PM -0700, Junio C Hamano wrote:
>
>> Stefan Beller writes:
>>
>> > I want to force myself to think about the design before pointing out
>> > memory leaks and coding style, so the least I would wish for is:
>>
On Wed, Jul 12 2017, Junio C. Hamano jotted:
> Stefan Beller writes:
>
>> I want to force myself to think about the design before pointing out
>> memory leaks and coding style, so the least I would wish for is:
>> *.h
>> *.c
>> but as we have more to look at, I would want to have t
On Wed, Jul 12, 2017 at 1:44 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
> Just set diff.orderFile to suit your taste without bothering other
> people, I would say.
I must have explained it very badly, I'll try again:
There are 2 different use cases to use diffs.
1. my personal use ca
On Wed, Jul 12, 2017 at 01:44:46PM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > I want to force myself to think about the design before pointing out
> > memory leaks and coding style, so the least I would wish for is:
> > *.h
> > *.c
> > but as we have more to look at
Stefan Beller writes:
> I want to force myself to think about the design before pointing out
> memory leaks and coding style, so the least I would wish for is:
> *.h
> *.c
> but as we have more to look at, I would want to have the most abstract
> thing to come first. And most abst
Conceptually the file order as set with command line -O or via the config
'diff.orderFile' is interesting to both the author (when I run a quick git
diff locally) as well as reviewer (a patch floating on the mailing list),
so it is not just the author who should be responsible for getting their
co
16 matches
Mail list logo
