On 7/29/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> While I would in principle prefer to offer more freedom to shoot
> yourselves in the foot ;-), the pragmatic side of me says too
> much flexibility is just asking for trouble with not much
> additional gain.
For an example of just how far y
Petr Baudis wrote:
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
Hi, A Large Angry SCM wrote:
So you're arguing for "last match wins" versus "first match wins". I,
personally, find the former more natural and easi
Dear diary, on Fri, Jul 29, 2005 at 10:24:54AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> In the meantime, the current one is clearly broken as you
> pointed out, so let's replace it with the updated "generic rule
> with the following exceptions" one.
That's fi
Petr Baudis <[EMAIL PROTECTED]> writes:
> Hmm. What about just excluding the files according to the order of
> parameters on the command line?
>
> Here, the question is whether the GIT Core tools should provide full
> flexibility and friendness to custom use, or rather serve as tighter
> unifying
Hi,
Petr Baudis:
> Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
> where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> > Hi, A Large Angry SCM wrote:
> >
> > > So you're arguing for "last match wins" versus "first match wins". I,
> > > personally, find the former m
Dear diary, on Fri, Jul 29, 2005 at 07:04:36AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> * When checking a file to see if it is excluded, we first look
>at "exclude-from patterns" list, then "per directory
>patterns" list, and then "command line patter
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> Hi, A Large Angry SCM wrote:
>
> > So you're arguing for "last match wins" versus "first match wins". I,
> > personally, find the former more natural and easier to debu
Petr Baudis <[EMAIL PROTECTED]> writes:
> You generally don't say "I never want this ignored, but I want
> the rest of that ignored", but "I want that ignored, except
> this".
OK.
> But more importantly,
>
> .gitignore: *.txt
> Documentation/.gitignore: !*.txt
>
> will not work, whic
Hi, A Large Angry SCM wrote:
> So you're arguing for "last match wins" versus "first match wins". I,
> personally, find the former more natural and easier to debug by hand.
You know, up until five minutes ago, I thought so too.
However ... as a human being, I liik for meaning, not for processin
Petr Baudis wrote:
I think this is wrong, and my brief experiments confirm that. I think
that the actually useful semantics of exclusion would be for
_subsequent_ exclusions, not preliminary ones. You generally don't say
"I never want this ignored, but I want the rest of that ignored", but
"I w
Dear diary, on Mon, Jul 25, 2005 at 10:27:36PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > On Mon, 25 Jul 2005, Junio C Hamano wrote:
> >>
> >> I personally do not have preference either way, but am slightly
> >>
Hello,
after skimming through it, I think I completely like what you have
shown here. I'm only concerned about this:
Dear diary, on Mon, Jul 25, 2005 at 12:49:33AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> $ cat Documentation/.gitignore
> # ignore
Marco Costalba <[EMAIL PROTECTED]> writes:
> This cumulative effect brakes local scoping of .gitignore files in
> corresponding subdirectory.
>
> As example in a directory A we can have a .gitignore file with
>
> !foo.html
> *.html
>
> because we want to special case 'that' foo.html in 'that'
> d
--- Marco Costalba <[EMAIL PROTECTED]> wrote:
> Date: Mon, 25 Jul 2005 14:34:56 -0700 (PDT)
> From: Marco Costalba <[EMAIL PROTECTED]>
> Subject: Re: [RFC] extending git-ls-files --exclude.
> To: Junio C Hamano <[EMAIL PROTECTED]>
> CC: Linus Torvalds <[EMAIL
On Mon, 2005-07-25 at 12:58 -0700, Junio C Hamano wrote:
> Catalin Marinas <[EMAIL PROTECTED]> writes:
> >> An exclude pattern is of the following format:
> > [...]
> >
> > That's fine. Actually, the Porcelain would care much about it since it
> > gets the information already filtered by git.
>
>
On Mon, 2005-07-25 at 13:27 -0700, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
> > Imagine, for example, that you have separate subdirectory structures for
> > Documentation and for source - maybe you'd put the "*.o" rule in the
> > source directory, and a "*.1" rule in the
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 25 Jul 2005, Junio C Hamano wrote:
>>
>> I personally do not have preference either way, but am slightly
>> biased towards the "cumulative" behaviour the patch attempts to
>> implement, which was what Pasky said he wanted to have.
>
> I think t
On Mon, 25 Jul 2005, Junio C Hamano wrote:
>
> I personally do not have preference either way, but am slightly
> biased towards the "cumulative" behaviour the patch attempts to
> implement, which was what Pasky said he wanted to have.
I think that makes sense.
Imagine, for example, that you ha
Marco Costalba <[EMAIL PROTECTED]> writes:
> Peraphs, if the file name of excluded list is the same for each directory,
> e.g. .gitignore or something similar, instead of --exclude-per-directory
> we can use a concept of file validity 'scope' and just use
> --exclude-from=.
> If entering in a di
Catalin Marinas <[EMAIL PROTECTED]> writes:
> I think it would make more sense for the exclude-per-directory
> patterns to be local to that directory only, without recursively
> preserving them for subdirectories.
I personally do not have preference either way, but am slightly
biased towards the
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> * When --exclude-per-directory= is specified, upon
>entering a directory that has such a file, its contents are
>appended at the end of the current "list of patterns". They
>are popped off when leaving the directory.
[...]
> A pattern specif
Marco Costalba <[EMAIL PROTECTED]> writes:
> Are really necessary to have both --exclude-from= and
> --exclude-per-directory= ?
>
> Peraphs, if the file name of excluded list is the same for each directory,
> e.g. .gitignore or something similar, instead of --exclude-per-directory
> we can use a
Junio C Hamano wrote:
>The list of patterns that is in effect at a given time is
>built and ordered in the following way:
>
> * --exclude= and lines read from --exclude-from=
> come at the beginning of the list of patterns, in the order
> given on the command line. Patterns that come from th
Petr Baudis <[EMAIL PROTECTED]> writes:
> Yes. There were several discussions about this in the past, with no
> clear outcome, IIRC. I would prefer:
>
> ~/.git/ignore per-user
> /.git/ignore per-repository
> .gitignore per-directory (cummulative with parent directories)
>
> Note that I also
24 matches
Mail list logo
