Re: Get "responsible" .gitignore file / rule

2018-12-07 Thread Victor Toni
Am Fr., 7. Dez. 2018 um 13:45 Uhr schrieb Eric Sunshine
:
>
> On Fri, Dec 7, 2018 at 7:36 AM Victor Toni  wrote:
> > I'm wondering if there is any way to show which rules (ideally with
> > the .gitignore file they are coming from) are causing a specific file
> > to get ignored so I could easily fix the .gitignore file?
>
> Perhaps the "git check-ignore" command would help.

Thanks for the tip!
Works like a charm (had to use the --verbose option though, without,
it does not give much feedback)


Get "responsible" .gitignore file / rule

2018-12-07 Thread Victor Toni
In a rather complex setup with deep directory structure it happens
every now and then, that files get ignored when trying to add them.
As these files are _not_ shown in `git status` but in `git status
--ignored` so I guess the culprit is some misconfigured `.gitignore`.

Trying to ad the specific file gives a:
$ git add ignored/file/name
The following paths are ignored by one of your .gitignore files:
ignored/file/name
Use -f if you really want to add them.

Using -v doen't add any verbosity. I'm using git 2.19.1.windows.1 if
this matters

I'm wondering if there is any way to show which rules (ideally with
the .gitignore file they are coming from) are causing a specific file
to get ignored so I could easily fix the .gitignore file?


Re: Handling of paths

2017-07-20 Thread Victor Toni
2017-07-20 22:30 GMT+02:00 Junio C Hamano :
>
> I've read the function again and I think the attached patch covers
> everything that ought to be a filename.
>
Your swift reaction is very much appreciated.
With the background you gave I just started to to create a patch
myself just to see that you already finished the patch.

Thanks a lot!

Best regards,
Victor


Handling of paths

2017-07-19 Thread Victor Toni
Hello,

I have a .gitconfig in which I try to separate work and private stuff
by using includes which works great.

When using [include] the path is treated either
- relative to the including file (if the path itself relative)
- relative to the home directory if it starts with ~
- absolute if the path is absolute

This is fine and expected.

What's unexpected is that paths used for sslKey or sslCert are treated
differently insofar as they are expected to be absolute.
Relative paths (whether with or without "~") don't work.

It would't be an issue to use absoulte paths if I wouldn't use the
same config for Linux and Windows and each OS has its own semantic
where it $HOME ishould be.

To avoid double configurations I tried to use the same directory
structure within my $HOME for both OS.

This approach fails since paths other than for [include] seem to have
to be absolute which seems like a bug to me.

Do you have any suggestions how I could make this work?

Thank you,
Victor