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

Combining tup and user gitignore entries #476

Open
evur opened this issue Feb 5, 2023 · 2 comments
Open

Combining tup and user gitignore entries #476

evur opened this issue Feb 5, 2023 · 2 comments

Comments

@evur
Copy link

evur commented Feb 5, 2023

Tup currently only ignores the .gitignore file if there is no user content inside. This behavior was added in 627aa56.
This approach has the problem of not ignoring auto-generated .gitignore files and doesn't work correctly on windows.
So my suggestion is to merge a file called tup.gitignore (if it exists) with the generated .gitignore.

For example:

(the .gitignore which would normally be generated by Tup)

##### TUP GITIGNORE #####
##### Lines below automatically generated by Tup.
##### Do not edit.
.tup
/.gitignore

tup.gitignore (user created)

/foobar

.gitignore (created by merging the gitignore generated by Tup and tup.gitignore)

##### TUP GITIGNORE #####
##### Lines below automatically generated by Tup.
##### Do not edit.
.tup
/.gitignore
/foobar
@gittup
Copy link
Owner

gittup commented Mar 24, 2024

I like this idea, it seems like it would help not having to commit changes to .gitignore files that contain a manually entered section just because the Tupfile changes.

What part is not working correctly on Windows currently? As far as I can tell it seems to be working the same as other OSes, which is the .gitignore file is ignored if it is completely auto-generated, and it is not ignored if you put manual content in there.

Regarding the name tup.gitignore, what do you think of something like .gitignore.tup instead? Other tup-related files are either capitalized (eg: Tupfile, Tupfile.ini), or have a .tup extension. I think .gitignore.tup would be a little more consistent in this regard, and would show up in the shell / file-browser alongside the .gitignore file to make it a little more obvious to a user that the .tup version is present and could be modified instead of the base .gitignore file.

Another option is to add parser logic in the Tupfile / Tupfile.lua that allows you to specify extra gitignore entries there. Eg in lua this could be something like:

tup.gitignorefiles({'foo.txt', 'bar.dat'})

In a regular Tupfile it could be that the .gitignore command takes a list of entries to add to the generated .gitignore file.

@evur
Copy link
Author

evur commented Mar 24, 2024

What part is not working correctly on Windows currently? As far as I can tell it seems to be working the same as other OSes, which is the .gitignore file is ignored if it is completely auto-generated, and it is not ignored if you put manual content in there.

Unfortunately I no longer know what the issue was. But it worked on Linux.

Regarding the name tup.gitignore, what do you think of something like .gitignore.tup instead?

Agreed, .gitignore.tup sounds good and is better for sorting. But I've got a new idea: you could preserve the current behavior but use .git/info/exclude instead of .gitignore (see https://git-scm.com/docs/gitignore and https://stackoverflow.com/a/22906964). The user would not normally see this and doesn't need to care about tup's gitignore entries. What do you think about it?

Another option is to add parser logic in the Tupfile / Tupfile.lua that allows you to specify extra gitignore entries there.

This would be interesting when implemented in addition to this feature. It could be used for programmatically specifying gitignore entries. But I can only imagine this being useful in some edge cases.

@evur evur changed the title User .gitignore Combining tup and user gitignore entries Mar 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants