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

Make path to .gitignore.d and .gitattributes.d configurable #203

Closed
wants to merge 1 commit into from
Closed

Make path to .gitignore.d and .gitattributes.d configurable #203

wants to merge 1 commit into from

Conversation

miramir
Copy link

@miramir miramir commented Jun 12, 2016

Fix issue #180

@kwbr
Copy link

kwbr commented Oct 12, 2016

Any chance to release a new vcsh with this patch applied?

@RichiH RichiH closed this Mar 29, 2021
@RichiH RichiH deleted the branch RichiH:master March 29, 2021 14:44
@alerque
Copy link
Collaborator

alerque commented Apr 2, 2021

Hey @RichiH any chance I could get the short version on the reasoning behind this PR closure?

@alerque
Copy link
Collaborator

alerque commented Apr 2, 2021

I might have found it, your comment here explains what you were probably thinking. Since it's kind of off topic there maybe humor me for a minute here, but I'm not convinced the logic is correct:

Users may have $XDG_CONFIG_HOME set to different locations on different machines or several users may use one repo. vcsh could not handle this without softlinks or other hacks. Thus, $VCSH_BASE/.gitignore.d is the only place that makes sense. I could make this a config option, but I doubt this is useful and only serves for people to shoot their own feet.

Of course $XDG_CONFIG_HOME may vary from machine to machine, but if it does wouldn't using that variable in our default config by definition solve that? And if the user chooses to override that as a default location, wouldn't the fact that the config is stored in the git repo meta data solve this anyway? If vcsh finds the repo at all it would by definition find the related ignores and attributes no matter where they were configured to go, no?

@RichiH
Copy link
Owner

RichiH commented Apr 2, 2021

This seems to a side effect of the rename from master to main; and it took me some time figure out that the hint was in the mouse-over of the disabled re-open button... Weird

image

@RichiH
Copy link
Owner

RichiH commented Apr 2, 2021

OK, https://github.com/miramir/vcsh is deleted and it seems that verification was triggered by the rename. But, given how GitHub stores forks as one repo in the background, e4addc8 still exists

@RichiH
Copy link
Owner

RichiH commented Apr 2, 2021

I will report this as a bug to GitHub support.

@RichiH
Copy link
Owner

RichiH commented Apr 2, 2021

@alerque: I don't get email for my own "closing" of PRs and issues. Did you get any other close emails at around the same time? If yes, we need to review them all.

@alerque
Copy link
Collaborator

alerque commented Apr 2, 2021

Yes. There were 4 of them as I recall. Since most of them automatically reparented and just those 4 closed I thought at first they were ones you had just decided to ditch—although the lack of comments made me wonder. I didn't notice anything unique about the 4 but now that you point it out I didn't review the status of the downstream forks. I'll track down the other 3.

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

Successfully merging this pull request may close these issues.

4 participants