Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-g or --gitignore doesn't seem to work #506

Open
micisse opened this issue Sep 11, 2023 · 3 comments
Open

-g or --gitignore doesn't seem to work #506

micisse opened this issue Sep 11, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@micisse
Copy link

micisse commented Sep 11, 2023

Version

ouch 0.4.2

Description

-g or --gitignore doesn't seem to work (see attached video). Or am I doing it wrong? The use of --gitignore or -g is not mentioned anywhere in the documentation. I found it with --help then #170 to #245

The contents of the .gitignore file are as follows :

*.zip
*.tar.gz

ouch.mp4

Current Behavior

No response

Expected Behavior

It should normally ignore files/folders mentioned in .gitignore

Additional Information

No response

@micisse micisse added the bug Something isn't working label Sep 11, 2023
@marcospb19
Copy link
Member

marcospb19 commented Sep 11, 2023

This can be a bit confusing, here's how -g/--gitignore works:

When recursing through directory entries, do not include the ones in .gitignore.

(This can be useful if you want to compress a repository without including the build artifacts.)

However, you can bypass -g/--gitignore by providing the explicit name of the files you want.

That's what you're doing, your shell (bash, zsh or fish) expands * to the two arguments "PNG.zip" and "SVG.zip", so you're bypassing the -g flag.


The current workaround would be to pass the folder itself to Ouch.

cd ..
ouch compress folder testo.tar.gz --gitignore

But we can also discuss wether we want to remove the capability to bypass --gitignore.


  -g, --gitignore
          Ignores files matched by git's ignore files

Also, we need to update the --help to make this clear, and maybe document it in README.md.

@micisse
Copy link
Author

micisse commented Sep 11, 2023

@marcospb19 Thanks for your response

However, you can bypass -g/--gitignore by providing the explicit name of the files you want.

The files contained in folders are too numerous to be defined by hand. That's why I took PNG.zip and SVG.zip to create this issue. 🔥.

The current workaround would be to pass the folder itself to Ouch.

It wasn't the folder I wanted to compress, but the contents only, and above all to be able to access the files directly when opening the archive (to avoid --strip-components=1 with tar for example).

That's what you're doing, your shell (bash, zsh or fish) expands * to the two arguments "PNG.zip" and "SVG.zip", so you're bypassing the -g flag.

The idea is to take everything (*) in the folder but exclude the files mentioned in .gitignore and/or .gitignore file itself. To use git with .gitignore file, you have to be in the folder itself at the root of the .git folder and the git command takes .gitignore into account in the same place, no need to pass the parent folder.


Ouch could perhaps be inspired by the "tar" command with --exclude arg. Passing several exclusion arguments in the same way (--exclude "<regex/*.ext/string...etc>") otherwise the .gitignore or .ouchignore file idea is also good to avoid multiple --exclude arguments.

tar -czvf testo.tar.gz --exclude "*.zip" --exclude "*.tar.gz" -C <path> .(dot) --overwrite
tar -czvf testo.tar.gz --exclude "*.zip" --exclude "*.tar.gz" .(dot) --overwrite

Capture d’écran_2023-09-11_20-49-46

The output of "ouch --help" gives "Usage: ouch [OPTIONS] <COMMAND>" the options before the command. Is it necessary to respect the order?

@marcospb19
Copy link
Member

marcospb19 commented Sep 12, 2023

The output of "ouch --help" gives "Usage: ouch [OPTIONS] " the options before the command. Is it necessary to respect the order?

No, --gitignore is currently a global flag because it applies to all 3 subcommands.

Thanks for your input, having a --exclude flag sounds like a great path to solve this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants