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 you
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 debug by hand.
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 more natural and
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 layer
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 fine by
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
biased towards
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 processing
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=pattern and lines read from --exclude-from=file
come at the beginning of the list of patterns, in the order
given on the command line. Patterns that come
Marco Costalba [EMAIL PROTECTED] writes:
Are really necessary to have both --exclude-from=file and
--exclude-per-directory=name ?
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
Junio C Hamano [EMAIL PROTECTED] wrote:
* When --exclude-per-directory=name 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 specified
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
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=file.
If entering in a
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 have
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 that makes
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 Docs
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.
Your saying
--- 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 PROTECTED],
Catalin Marinas [EMAIL
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 want to
18 matches
Mail list logo
