on Linux seems to be fine.
The list of input of r_d_r() is in the big comment block in dir.h. In
short, the output of a directory (not counting subdirs) mainly depends
on stat info of the directory in question, all .gitignore leading to
it and the check_only flag when r_d_r() is called recursively
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Torsten Bögershausen tbo...@web.de
Signed-off
From: Junio C Hamano gits...@pobox.com
These files are used to observe the behaviour of the 'status'
command and if there weren't any such observer, the expected
output from 'status' wouldn't even mention them.
Place them in .gitignore to unclutter the output expected by the
tests. An added
From: Junio C Hamano gits...@pobox.com
These files are used to observe the behaviour of the 'status'
command and if there weren't any such observer, the expected
output from 'status' wouldn't even mention them.
Place them in .gitignore to unclutter the output expected by the
tests. An added
Duy Nguyen pclo...@gmail.com writes:
On Thu, Feb 12, 2015 at 4:23 AM, Junio C Hamano gits...@pobox.com wrote:
...
If you want to detect the content changes across working tree, index
and the tree objects by reusing hash_sha1_file(), however, you must
not feed the checked out (aka smudged)
matters to exclude machinery is the checkout version. I think for
now we fall back to hashing .gitignore content. Perhaps later we could
make an exception for cr/lf conversion (and just that, not generic
filters, doing content conversion here sounds like a bad idea).
--
Duy
--
To unsubscribe from
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
-int add_excludes_from_file_to_list(const char *fname,
-const char *base,
-int baselen,
-struct exclude_list *el,
-
+git@vger.kernel.org, plain text
I would say just use zsh globbing, it has the double star, but it'd
likely too late for that. You'd add a single rule: ignore any files
that are in a directory higher up than the .gitignore where the rule
is found.
Then if you have a git repo in your fs at /git
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 26 +-
1 file changed, 25 insertions
on Linux seems to be fine.
The list of input of r_d_r() is in the big comment block in dir.h. In
short, the output of a directory (not counting subdirs) mainly depends
on stat info of the directory in question, all .gitignore leading to
it and the check_only flag when r_d_r() is called recursively
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Torsten Bögershausen tbo...@web.de
Signed-off
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added
Stefan Beller stefanbel...@gmail.com writes:
2015-02-02 11:15 GMT-08:00 Junio C Hamano gits...@pobox.com:
Isn't gitignore(5) documentation reasonably clear?
...
- A leading slash matches the beginning of the pathname. For
example, /*.c matches cat-file.c but not mozilla-sha1/sha1.c
2015-02-02 11:15 GMT-08:00 Junio C Hamano gits...@pobox.com:
Stefan Beller stefanbel...@gmail.com writes:
On 01.02.2015 14:51, /#!/JoePea wrote:
I have this in my .gitignore:
./*.js
I would expect that to cause git to ignore .js files in the same
folder as .gitignore, but it doesn't do
Stefan Beller stefanbel...@gmail.com writes:
On 01.02.2015 14:51, /#!/JoePea wrote:
I have this in my .gitignore:
./*.js
I would expect that to cause git to ignore .js files in the same
folder as .gitignore, but it doesn't do anything. However, this works:
/*.js
I'm not sure
I have this in my .gitignore:
./*.js
I would expect that to cause git to ignore .js files in the same
folder as .gitignore, but it doesn't do anything. However, this works:
/*.js
I'm not sure what this actually means because a leading slash is the
root of some filesystem, and we're
On 01.02.2015 14:51, /#!/JoePea wrote:
I have this in my .gitignore:
./*.js
I would expect that to cause git to ignore .js files in the same
folder as .gitignore, but it doesn't do anything. However, this works:
/*.js
I'm not sure what this actually means because a leading slash
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 26 +-
1 file changed, 25 insertions
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Torsten Bögershausen tbo...@web.de
Signed-off
on Linux seems to be fine.
The list of input of r_d_r() is in the big comment block in dir.h. In
short, the output of a directory (not counting subdirs) mainly depends
on stat info of the directory in question, all .gitignore leading to
it and the check_only flag when r_d_r() is called recursively
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Torsten Bögershausen tbo...@web.de
Signed-off
on Linux seems to be fine.
The list of input of r_d_r() is in the big comment block in dir.h. In
short, the output of a directory (not counting subdirs) mainly depends
on stat info of the directory in question, all .gitignore leading to
it and the check_only flag when r_d_r() is called recursively
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added
On Wed, Nov 19, 2014 at 10:40 AM, Phil Pennock
phil-gi...@phil.spodhuis.org wrote:
Expected to work as .gitignore in top-level of repo:
*
!**/*.asc
!.gitignore
gitignore man page has this It is not possible to re-include a file
if a parent directory of that file is excluded
On 2014-11-19 at 16:48 +0700, Duy Nguyen wrote:
On Wed, Nov 19, 2014 at 10:40 AM, Phil Pennock
phil-gi...@phil.spodhuis.org wrote:
Expected to work as .gitignore in top-level of repo:
*
!**/*.asc
!.gitignore
gitignore man page has this It is not possible to re-include
On Thu, Nov 20, 2014 at 6:41 AM, Phil Pennock
phil-gi...@phil.spodhuis.org wrote:
On 2014-11-19 at 16:48 +0700, Duy Nguyen wrote:
On Wed, Nov 19, 2014 at 10:40 AM, Phil Pennock
phil-gi...@phil.spodhuis.org wrote:
Expected to work as .gitignore in top-level of repo:
*
!**/*.asc
$EDITOR .gitignore
Expected to work as .gitignore in top-level of repo:
*
!**/*.asc
!.gitignore
With that, `git status` ignores the contents of foo/ thusly:
$ git check-ignore -v foo/incl.asc
.gitignore:1:* foo/incl.asc
Commenting out the '*' line and removing
On Sat, 2014-11-08 at 16:39 +0700, Nguyễn Thái Ngọc Duy wrote:
+ * If ss is not NULL, compute SHA-1 of the exclude file and fill
+ * stat data from disk (only valid if add_excludes returns zero). If
+ * ss_valid is non-zero, ss must contain good value as input.
ss and ss_valid should be
, dirs_nr, dirs_alloc;
+ unsigned int untracked_nr;
+ unsigned int check_only : 1;
+ /* null SHA-1 means this directory does not have .gitignore */
+ unsigned char exclude_sha1[20];
+ char name[1];
For consistency, should this be char name[FLEX_ARRAY]? (this will entail
some
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Torsten Bögershausen tbo...@web.de
Signed-off
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index
On Sat, Nov 08, 2014 at 04:39:35PM +0700, Nguyễn Thái Ngọc Duy wrote:
The requirement for this to work is stat info of a directory MUST
change if an entry is added to or removed from that directory (and
should not change often otherwise). If your OS and filesytem do not
Should be filesystem
On Wed, Oct 29, 2014 at 12:37 AM, Torsten Bögershausen tbo...@web.de wrote:
On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote:
[]
Nice serious, I can imagine to test benchmark it (so I assume there is a
branch
on github or so ?)
It's on 'pu' now. There's a branch on my github repo, but it
On 2014-10-27 13.10, Nguyễn Thái Ngọc Duy wrote:
[]
Nice serious, I can imagine to test benchmark it (so I assume there is a
branch
on github or so ?)
Another thing:
Can we switch the feature off?
It could be nice to benchmark with and without the cache on the command line,
and besides that
untracked_cache_dir **dirs;
+ char **untracked;
+ /* null SHA-1 means this directory does not have .gitignore */
+ unsigned char exclude_sha1[20];
+ struct stat_data stat_data;
+ unsigned int check_only : 1;
+ unsigned int untracked_nr : 29;
+ unsigned int untracked_alloc, dirs_nr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm having an issue in that 'git ls-files -o' seems to ignore
[parts of] .gitignore whereas other commands, such as 'git status'
seem fine.
Here is an example:
richard@omnis:/home/richard/src/pkgsrc$ export LANG=C
richard@omnis:/home/richard/src
On Mon, Oct 27, 2014 at 07:16:49AM +0100, Richard PALO wrote:
Hash: SHA1
I'm having an issue in that 'git ls-files -o' seems to ignore
[parts of] .gitignore whereas other commands, such as 'git status'
seem fine.
This is, as far as I am aware, by design. If you want to apply the
standard
Charles Bailey char...@hashpling.org writes:
On Mon, Oct 27, 2014 at 07:16:49AM +0100, Richard PALO wrote:
Hash: SHA1
I'm having an issue in that 'git ls-files -o' seems to ignore
[parts of] .gitignore whereas other commands, such as 'git status'
seem fine.
This is, as far as I am aware
...@netbsd.org, git@vger.kernel.org
Envoyé: Lundi 27 Octobre 2014 09:31:56
Objet: Re: git ls-files -o seems to ignore .gitignore
Charles Bailey char...@hashpling.org writes:
On Mon, Oct 27, 2014 at 07:16:49AM +0100, Richard PALO wrote:
Hash: SHA1
I'm having an issue in that 'git ls-files
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 50
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added
on Linux seems to be fine.
The list of input of r_d_r() is in the big comment block in dir.h. In
short, the output of a directory (not counting subdirs) mainly depends
on stat info of the directory in question, all .gitignore leading to
it and the check_only flag when r_d_r() is called recursively
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo
On Tue, Oct 28, 2014 at 5:46 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index
/configurable-gitignore-filename
commit 27449825ff4d7bb3eecb5a3e32692aaf1ab1a026
Author: Bostjan Skufca bost...@a2o.si
Date: Thu Sep 4 20:20:30 2014 +
.gitignore: make '.gitignore' filename configurable
When using git with detached work tree and .git directory,
it is currently impossible
in .gitignore, which is directly related to the
problems we're having (please note, we're using git on Windows, in
case that makes a syntax difference):
*/**/*
![Ss][Rr][Cc]/**/*
So what that does is ignores every file and subdirectory at the top
level, and then un-ignores Src/ and all files/dirs under
Jeffry Johnston j...@kidsquid.com writes:
We had been experiencing random deletions of files and directories,
and we finally figured out what they were: git stash -u. A coworker
happened upon a webpage (after losing a weeks worth of experimental
work, back to his last backup), which
builtin/verify-commit.c was added in commit d07b00b (verify-commit:
scriptable commit signature verification, 2014-06-23), update
.gitignore to ignore the generated file.
Signed-off-by: Øyvind A. Holm su...@sunbase.org
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore
Signed-off-by: Jacob Keller jacob.e.kel...@intel.com
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index e0710ad5b294..098dcdfe1ea7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,6 @@
/*.d
/*.o
+/.version
/hwstamp_ctl
/phc2sys
/pmc
Hi,
Jacob Keller wrote:
Subject: gitignore: add .version as this is generated during a make
What program generates that file? When I build on a Debian machine, I
get
$ make
[...]
SUBDIR templates
$ ls -la .version
ls: cannot access .version
Jonathan Nieder jrnie...@gmail.com writes:
Jacob Keller wrote:
Subject: gitignore: add .version as this is generated during a make
What program generates that file? When I build on a Debian machine, I
get
$ make
[...]
SUBDIR templates
$ ls -la .version
On Thu, 2014-07-10 at 16:13 -0700, Jonathan Nieder wrote:
Hi,
Jacob Keller wrote:
Subject: gitignore: add .version as this is generated during a make
What program generates that file? When I build on a Debian machine, I
get
$ make
[...]
SUBDIR templates
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when one has SHA-1 of the old .gitignore.
---
dir.c | 51 ---
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/dir.c b/dir.c
index
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index 63fa960..b5bfda8 100644
--- a/dir.c
+++ b/dir.c
small cache overhead, while the number of
ignored files could go really high (e.g. *.o files mixing with source
code).
This patch captures .gitignore information, check_only bit and the
list of directories that read_directory_recursive() examines.
Two hash_sha1_file() are required for $GIT_DIR
On Fri, Apr 25, 2014 at 04:09:47PM -0700, a...@bellandwhistle.net wrote:
Andrew Ardill andrew.ard...@gmail.com writes:
As a data point, I have seen people add .gitignore to their
.gitignore file, as they don't want to share the file.
Right, I've seen that too.
That something I am actually
On 04/22/2014 06:54 PM, Junio C Hamano wrote:
Interesting. It will break immediately when the project starts
wanting to distribute its canonical ignore list
If that happens, that's a problem caused by the project wanting to
misuse .gitignore.
There are good practices and bad practices
Andrew Ardill andrew.ard...@gmail.com writes:
As a data point, I have seen people add .gitignore to their
.gitignore file, as they don't want to share the file.
Right, I've seen that too. It confused the heck out of me. It only lends
credence to my point about the docs. Those users want
Andrew Ardill andrew.ard...@gmail.com writes:
As a data point, I have seen people add .gitignore to their
.gitignore file, as they don't want to share the file.
Interesting. It will break immediately when the project starts
wanting to distribute its canonical ignore list, but until that
time
On 18 April 2014 10:36, a...@bellandwhistle.net wrote:
Like the $GIT_DIR/info/exclude file, gitignore files specify intentionally
untracked files that Git should ignore. The difference is that files matched
by a pattern in a gitignore file will be untracked for all users of the
repository
On 2014-04-16 16:45, Jonathan Nieder wrote:
Hi,
a...@bellandwhistle.net wrote:
In particular, 'exclude' is spottily documented.
Where did you expect to read about it? I see some mention of
.git/info/exclude in the gitignore(5) page, but I wouldn't be
surprised if there's room
a...@bellandwhistle.net writes:
Any clarification on the differences much appreciated:
http://stackoverflow.com/questions/23097368/git-ignore-vs-exclude-vs-assume-unchanged/23097509
Please don't force people to refer to external site.
The .gitignore and .git/info/exclude are the two UIs
Any clarification on the differences much appreciated:
http://stackoverflow.com/questions/23097368/git-ignore-vs-exclude-vs-assume-unchanged/23097509
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
.
The .gitignore and .git/info/exclude are the two UIs to invoke the
same mechanism. In-tree .gitignore are to be shared among project
members (i.e. everybody working on the project should consider the
paths that match the ignore pattern in there as cruft). On the
other hand, .git/info/exclude is meant
Hi,
a...@bellandwhistle.net wrote:
In particular, 'exclude' is spottily documented.
Where did you expect to read about it? I see some mention of
.git/info/exclude in the gitignore(5) page, but I wouldn't be
surprised if there's room for improvement there (improvements
welcome
From: Johannes Sixt j...@kdbg.org
The Windows API does not preserve file names with trailing spaces (and
dots), but rather strips them. Our tools (MSYS bash, git) base the POSIX
emulation on the Windows API. As a consequence, it is impossible for bash
on Windows to allocate a file whose name has
On Sun, Feb 09, 2014 at 06:48:18AM +0700, Duy Nguyen wrote:
I guess by quoting you meant:
echo 'trailing ' .gitignore
This makes special. If we follow shell convention then things
between .. should be literal (e.g. * is no longer a wildcard). We
don't support it yet. So I rather go
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source of
frustration when writing .gitignore.
So
On Mon, Feb 10, 2014 at 11:07 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files
Junio C Hamano gits...@pobox.com writes:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source of
frustration when writing .gitignore.
So let's ignore them. Nobody sane would put a trailing space
On Sat, Feb 08, 2014 at 03:10:02PM +0700, Nguyễn Thái Ngọc Duy wrote:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source of
frustration when
On Sat, Feb 8, 2014 at 11:45 PM, Jeff King p...@peff.net wrote:
On Sat, Feb 08, 2014 at 03:10:02PM +0700, Nguyễn Thái Ngọc Duy wrote:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore
This reroll now respects backslash quoting. Thanks Jeff and Torsten
for the comments.
Nguyễn Thái Ngọc Duy (2):
dir: warn about trailing spaces in exclude patterns
dir: ignore trailing spaces in exclude patterns
Documentation/gitignore.txt | 3 +++
dir.c | 20
Signed-off-by: Alexander Berntsen alexan...@plaimi.net
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index b5f9def..2905c21 100644
--- a/.gitignore
+++ b/.gitignore
@@ -240,3 +240,5 @@
*.pdb
/Debug/
/Release/
+*~
+.*.swp
--
1.8.3.2
Alexander Berntsen alexan...@plaimi.net writes:
Signed-off-by: Alexander Berntsen alexan...@plaimi.net
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index b5f9def..2905c21 100644
--- a/.gitignore
+++ b/.gitignore
@@ -240,3 +240,5 @@
*.pdb
is useless for those who never use vim, for example).
I don't see any downside to having this in .gitignore. However, not
including it doesn't significantly impede my workflow either. I will
not argue ferociously for this patch's inclusion. :-)
- --
Alexander
alexan...@plaimi.net
http://plaimi.net
: gitignore doc: add global gitignore to synopsis
The gitignore(5) manpage already documents $XDG_CONFIG_HOME/git/ignore
but it is easy to forget that it exists. Add a reminder to the
synopsis.
Noticed while looking for a place to put a list of scratch filenames
in the cwd used by one's editor of choice
On 16/01/14 22:06, Junio C Hamano wrote:
Alexander Berntsen alexan...@plaimi.net writes:
Signed-off-by: Alexander Berntsen alexan...@plaimi.net
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index b5f9def..2905c21 100644
--- a/.gitignore
Junio C Hamano gits...@pobox.com writes:
Alexander Berntsen alexan...@plaimi.net writes:
Signed-off-by: Alexander Berntsen alexan...@plaimi.net
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index b5f9def..2905c21 100644
--- a/.gitignore
On Fri, Jan 17, 2014 at 5:43 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Subject: gitignore doc: add global gitignore to synopsis
The gitignore(5) manpage already documents $XDG_CONFIG_HOME/git/ignore
but it is easy to forget that it exists. Add a reminder to the
synopsis.
Yes! I knew
Prevent the test-hashmap program from being accidentally tracked
with git add or cluttering git status output.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index b5f9def..dc600f9 100644
)
#
# modules/boring/
# modules/interesting/other.c
$ echo '/modules/' .gitignore
$ echo '!/modules/interesting/' .gitignore
On this git status, I would expect to see modules/interesting/other.c
listed as untracked, however:
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed
files:
# (use git add file... to include in what will be committed)
#
# modules/boring/
# modules/interesting/other.c
$ echo '/modules/' .gitignore
$ echo '!/modules/interesting/' .gitignore
I happened to write a software Gistore to backup arbitrary files and
directories using Git
On Sat, Dec 7, 2013 at 12:26 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
# Untracked files:
# (use git add file... to include in what will be committed)
#
# modules/boring/
# modules/interesting/other.c
$ echo '/modules/' .gitignore
$ echo '!/modules/interesting/' .gitignore
Also here:
https://github.com/kblees/git/commits/kb/gitignore-doc
These two patches were the result of a discussion mid-october [1] that I almost
forgot about...now including an example as suggested by Jeff.
[1] http://thread.gmane.org/gmane.comp.version-control.git/235753/focus=235856
Karsten
On Mon, Oct 07, 2013 at 07:24:11AM -0400, Jeff King wrote:
However, one thing I expected to work but didn't is:
echo '*' .gitignore
echo '!*' my_dir/.gitignore
That _does_ work for attributes, like:
echo '* foo=one' .gitattributes
echo '* foo=two' my_dir/.gitattributes
just one specific directory:
/*
!/wp-content
/wp-content/*
!/wp-content/themes
Note the /*, instead of * which matches everything everywhere.
Checkout gitignore man page for more information.
The compiled version reads like this:
A trailing / matches everything inside. For example
On Thu, Oct 10, 2013 at 09:59:38AM +0200, Karsten Blees wrote:
On Mon, Oct 07, 2013 at 07:24:11AM -0400, Jeff King wrote:
However, one thing I expected to work but didn't is:
echo '*' .gitignore
echo '!*' my_dir/.gitignore
That _does_ work for attributes, like:
echo
On Mon, Oct 07, 2013 at 07:24:11AM -0400, Jeff King wrote:
However, one thing I expected to work but didn't is:
echo '*' .gitignore
echo '!*' my_dir/.gitignore
That _does_ work for attributes, like:
echo '* foo=one' .gitattributes
echo '* foo=two' my_dir/.gitattributes
where
creative with your .gitignore if your .git directory is in the web root
directory.
Here is an example:
https://gist.github.com/AJ-Acevedo/6859779
Thanks for taking the time to consider this feature
AJ
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
by upload.
Two possibilities that come to mind are the git ls-files (read the
doc and find the option to have it read .gitignore file) command,
and the git check-ignore command.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
On Sun, Jun 2, 2013 at 9:40 PM, Peng Yu pengyu...@gmail.com wrote:
Hi,
.gitignore is a flexible way to customize what dir/file to search or
not to search. So it is of general use and is more flexible than what
is offered by find. I'm wondering if there is an API than I can use
besides using
Hi,
.gitignore is a flexible way to customize what dir/file to search or
not to search. So it is of general use and is more flexible than what
is offered by find. I'm wondering if there is an API than I can use
besides using it within git. Thanks.
--
Regards,
Peng
--
To unsubscribe from
201 - 300 of 401 matches
Mail list logo
