Add support for dot ignore files (like: .gitignore)
File name is .gcpignore by default, and could be changed using -i or --ignore
Note: this doesn't support the syntax starting with ! to exclude some special patterns from the old defined ones.
Add support for dot ignore files (like: .gitignore)
File name is `.gcpignore` by default, and could be changed using `-i` or `--ignore`
> Note: this doesn't support the syntax starting with `!` to exclude some special patterns from the old defined ones.
Thank you so much for your contribution, it is much appreciated!
My first remark is that -i is already a GNU cp option (--interactive);
since a long-term goal of GCP is to have CLI compatibility with GNU cp, I would
like to find something else.
Regarding your design, I like the idea of being able to exclude dotfiles, but I
think it would be even better to implement generic exclude/include option, like rsync does:
--exclude=PATTERN exclude files matching PATTERN
--exclude-from=FILE read exclude patterns from FILE
--include=PATTERN don't exclude files matching PATTERN
--include-from=FILE read include patterns from FILE
(rsync's --files-from=FILE would also be a nice feature to have at some
point.)
I'm not saying that we should implement all of these at once, but do you think
you could change your code to an implementation of --exclude-from? You
would then call gcp --exclude-from=.gcpignore or something like that.
If we then implement --exclude, we could use --exclude='.*' to ignore all
dotfiles, just like with rsync.
We don't have to handle the whole rsync pattern language right now, we can
start with a basic language that matches files in the directory being copied,
like you did in your code.
Thoughts?
Matteo
Hi Ahmed,
Thank you so much for your contribution, it is much appreciated!
My first remark is that `-i` is already a GNU cp option (`--interactive`);
since a long-term goal of GCP is to have CLI compatibility with GNU cp, I would
like to find something else.
Regarding your design, I like the idea of being able to exclude dotfiles, but I
think it would be even better to implement generic exclude/include option, like
`rsync` does:
--exclude=PATTERN exclude files matching PATTERN
--exclude-from=FILE read exclude patterns from FILE
--include=PATTERN don't exclude files matching PATTERN
--include-from=FILE read include patterns from FILE
(rsync's `--files-from=FILE` would also be a nice feature to have at some
point.)
I'm not saying that we should implement all of these at once, but do you think
you could change your code to an implementation of `--exclude-from`? You
would then call `gcp --exclude-from=.gcpignore` or something like that.
If we then implement `--exclude`, we could use `--exclude='.*'` to ignore all
dotfiles, just like with rsync.
We don't have to handle the whole rsync pattern language right now, we can
start with a basic language that matches files in the directory being copied,
like you did in your code.
Thoughts?
Matteo
Sorry for being late, and thank you for your notes.
I just have a comment about the convention, the idea is to have some feature like Git's .gitignore files, but the flag --exclude-from=FILE suggests that you should provide some specific file path, but actually it searches for that file name into each directory while walking deep, and exclude files with the specified patterns relatively to the directory which contains the file. Exactly like what we do do with .gitignore file.
Don't you think that --exclude-from=FILE will be confusing somehow.
Anyway I've updated it to --exclude-from, If we just can find more expressive name 😄
Hi Matteo,
Sorry for being late, and thank you for your notes.
I just have a comment about the convention, the idea is to have some feature like Git's `.gitignore` files, but the flag `--exclude-from=FILE` suggests that you should provide some specific file path, but actually it searches for that file name into each directory while walking deep, and exclude files with the specified patterns relatively to the directory which contains the file. Exactly like what we do do with `.gitignore` file.
Don't you think that `--exclude-from=FILE` will be confusing somehow.
Anyway I've updated it to `--exclude-from`, If we just can find more expressive name :smile:
This pull request is marked as a work in progress. Remove the WIP: prefix from the title when it's ready
Add support for dot ignore files (like: .gitignore)
File name is
.gcpignore
by default, and could be changed using-i
or--ignore
Hi Ahmed,
Thank you so much for your contribution, it is much appreciated!
My first remark is that
-i
is already a GNU cp option (--interactive
);since a long-term goal of GCP is to have CLI compatibility with GNU cp, I would
like to find something else.
Regarding your design, I like the idea of being able to exclude dotfiles, but I
think it would be even better to implement generic exclude/include option, like
rsync
does:(rsync's
--files-from=FILE
would also be a nice feature to have at somepoint.)
I'm not saying that we should implement all of these at once, but do you think
you could change your code to an implementation of
--exclude-from
? Youwould then call
gcp --exclude-from=.gcpignore
or something like that.If we then implement
--exclude
, we could use--exclude='.*'
to ignore alldotfiles, just like with rsync.
We don't have to handle the whole rsync pattern language right now, we can
start with a basic language that matches files in the directory being copied,
like you did in your code.
Thoughts?
Matteo
Hi Matteo,
Sorry for being late, and thank you for your notes.
I just have a comment about the convention, the idea is to have some feature like Git's
.gitignore
files, but the flag--exclude-from=FILE
suggests that you should provide some specific file path, but actually it searches for that file name into each directory while walking deep, and exclude files with the specified patterns relatively to the directory which contains the file. Exactly like what we do do with.gitignore
file.Don't you think that
--exclude-from=FILE
will be confusing somehow.Anyway I've updated it to
--exclude-from
, If we just can find more expressive name 😄