On Fri, Oct 28, 2016 at 10:32:07PM +1300, Aaron Pelly wrote:
> On 28/10/16 15:54, Junio C Hamano wrote:
> > Jeff King writes:
> >
> >> However, as I said elsewhere, I'm not convinced this feature is all that
> >> helpful for in-repository .gitignore files, and I think it does
> >> introduce comp
On Fri, Oct 28, 2016 at 4:32 PM, Aaron Pelly wrote:
> Or how about a new githook that can intelligently create or return the
> details? This would be my least favourite option unless it was
> configured in an obvious place.
I wonder if smudge/clean filters can be used to recreate in-tree
.gitigno
On Fri, Oct 28, 2016 at 4:04 AM, Jeff King wrote:
> On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:
>
>> > I think the normal behavior in such "foo.d" directory is to just sort
>> > the contents lexically and read them in order, as if they were all
>> > concatenated together, and wit
On 28/10/16 15:54, Junio C Hamano wrote:
> Jeff King writes:
>
>> However, as I said elsewhere, I'm not convinced this feature is all that
>> helpful for in-repository .gitignore files, and I think it does
>> introduce compatibility complications. People with older git will not
>> respect your .g
On Fri, Oct 28, 2016 at 11:17:26AM +1300, Aaron Pelly wrote:
> On 28/10/16 10:55, Aaron Pelly wrote:
> > 2) I fetch a repo with a hostile ignore file. It includes files from
> > $GIT_DIR/test-data/ssl/private or some such. Change. Don't pay
> > attention. Commit. Push. Problems if my test data com
Jeff King writes:
> However, as I said elsewhere, I'm not convinced this feature is all that
> helpful for in-repository .gitignore files, and I think it does
> introduce compatibility complications. People with older git will not
> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely
On 28/10/16 10:07, Jeff King wrote:
> I think it does
> introduce compatibility complications.
If this is not a show stopper, I am happy to knock out a short
functional spec. I'll give it some hours before I begin.
On 28/10/16 10:07, Jeff King wrote:
> I think it does
> introduce compatibility complications. People with older git will not
> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local
> matter.
I know. I don't think it's a serious compatibility issue, but more
important people may
On 28/10/16 10:55, Aaron Pelly wrote:
> 2) I fetch a repo with a hostile ignore file. It includes files from
> $GIT_DIR/test-data/ssl/private or some such. Change. Don't pay
> attention. Commit. Push. Problems if my test data comes from production.
>
> Is this mitigated currently?
>
> Not that gi
On 28/10/16 09:55, Jeff King wrote:
> On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
>
>>> - we parse possibly-hostile .gitignore files from cloned repositories.
>>> What happens when I include ask to include /etc/passwd? Probably
>>> nothing, but there are setups where it
On Thu, Oct 27, 2016 at 2:04 PM, Jeff King wrote:
> I'm not convinced this is needed for in-repo .gitignore files. The point
> is that you are pulling together separate files that may be administered
> independently. But git repositories inherently have a whole-project
> view. I'm not sure that se
On 28/10/16 10:04, Jeff King wrote:
> On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:
>
>>> I think the normal behavior in such "foo.d" directory is to just sort
>>> the contents lexically and read them in order, as if they were all
>>> concatenated together, and with no recursion. I
On Thu, Oct 27, 2016 at 04:55:08PM -0400, Jeff King wrote:
> On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
>
> > > - we parse possibly-hostile .gitignore files from cloned repositories.
> > > What happens when I include ask to include /etc/passwd? Probably
> > > nothing,
On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:
> > I think the normal behavior in such "foo.d" directory is to just sort
> > the contents lexically and read them in order, as if they were all
> > concatenated together, and with no recursion. I.e., behave "as if" the
> > user had run
On 28/10/16 08:48, Jacob Keller wrote:
> I would strongly prefer rc.d style directories either with a "if the
> .gitignore is a directory treat it like rc.d" or even "add support for
> .gitignore.d as well as .gitignore"
I think adding .gitignore.d shouldn't break existing systems, is
intuitive, a
On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:
> > - we parse possibly-hostile .gitignore files from cloned repositories.
> > What happens when I include ask to include /etc/passwd? Probably
> > nothing, but there are setups where it might matter (e.g., something
> > li
On 27/10/16 23:50, Jeff King wrote:
> I'd shy away from an actual include directive, as it raises a lot of
> complications:
I'm leaning that way now too.
> - we parse possibly-hostile .gitignore files from cloned repositories.
> What happens when I include ask to include /etc/passwd? Probab
On Thu, Oct 27, 2016 at 3:50 AM, Jeff King wrote:
> On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote:
>
>> The use case for this is where I did not write my own rules, but I want
>> to keep them updated. https://github.com/github/gitignore is a damn good
>> resource, but I want to pull
On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote:
> The use case for this is where I did not write my own rules, but I want
> to keep them updated. https://github.com/github/gitignore is a damn good
> resource, but I want to pull it and include relevant bits project by
> project and/or
On 27/10/16 21:19, Alexei Lozovsky wrote:
>> I'm thinking something like ". path/to/include/file" in an ignore file,
>> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore
>> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent
>> mixture of these things.
>
> I
On 27/10/16 15:22, Stefan Beller wrote:
>> The use case for this is where I did not write my own rules, but I want
>> to keep them updated. https://github.com/github/gitignore is a damn good
>> resource, but I want to pull it and include relevant bits project by
>> project and/or system wide. I don
> I'm thinking something like ". path/to/include/file" in an ignore file,
> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore
> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent
> mixture of these things.
I think the rc.d-like approach with directories is
> The use case for this is where I did not write my own rules, but I want
> to keep them updated. https://github.com/github/gitignore is a damn good
> resource, but I want to pull it and include relevant bits project by
> project and/or system wide. I don't want to have to update many projects
> ma
I want a feature. It may be a bad-idea(tm). Advice appreciated.
I want git to be able to include, in its gitignore files, sub-files of
ignores or have it understand a directory of ignore files. Or both.
The use case for this is where I did not write my own rules, but I want
to keep them updated.
24 matches
Mail list logo
