Questions, improvements

Questions, improvements

[BARDOT Jérôme]

Hello,

It's my first email here.
Maybe questions have been already debate.

1)

Why git not embed by default some gitinore rules (and can be "disable"
after).
All the time i have to add all operating system stuff, all editor stuff.

2)

I need a domain name / uri / ip base way to choose auth information.
i find some examples in past but not as smart as what i want. (Maybe i
miss something)

3)

For auth client side can we use tools like Pass and or identity manager.



Thx.
j.

PS : Feel free to send me RTFM (with link) if needed.

Re: Questions, improvements

[Jeff King]

On Tue, Oct 19, 2021 at 07:38:16PM +0200, BARDOT Jérôme wrote:

> 1)
> 
> Why git not embed by default some gitinore rules (and can be "disable"
> after).
> All the time i have to add all operating system stuff, all editor stuff.

I think you may have a hard time getting people to agree on what should
go into those rules. ;)

But you may find core.excludesFile (documented in "git help config")
helpful. You can set up your personal set of files once, and they will
be used in every repository.

> 2)
> 
> I need a domain name / uri / ip base way to choose auth information.
> i find some examples in past but not as smart as what i want. (Maybe i
> miss something)
> 
> 3)
> 
> For auth client side can we use tools like Pass and or identity manager.

I'm not entirely sure I understand your questions here, but I think
you're looking for credential helpers? Try "git help credentials" for an
overview.

There are helpers which interact with common OS secure storage systems
(like osxkeychain, libsecret, etc). But you can also write your own
little scripts, and restrict them based on URLs.

So for instance I use this config to pull a GitHub PAT out of the "pass"
tool:

  [credential "https://github.com"]
  username = peff
  helper = "!f() { test $1 = get && echo password=`pass github/token`; }; f"

-Peff

Re: Questions, improvements

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

Hi,

On Tue, 19 Oct 2021, Jeff King wrote:

> On Tue, Oct 19, 2021 at 07:38:16PM +0200, BARDOT Jérôme wrote:
>
> > 2)
> >
> > I need a domain name / uri / ip base way to choose auth information.
> > i find some examples in past but not as smart as what i want. (Maybe i
> > miss something)
> >
> > 3)
> >
> > For auth client side can we use tools like Pass and or identity manager.
>
> I'm not entirely sure I understand your questions here, but I think
> you're looking for credential helpers? Try "git help credentials" for an
> overview.
>
> There are helpers which interact with common OS secure storage systems
> (like osxkeychain, libsecret, etc). But you can also write your own
> little scripts, and restrict them based on URLs.
>
> So for instance I use this config to pull a GitHub PAT out of the "pass"
> tool:
>
>   [credential "https://github.com"]
>   username = peff
>   helper = "!f() { test $1 = get && echo password=`pass github/token`; }; f"

A quite complete, cross-platform credential helper (included in Git for
Windows and enabled by default, but it also works on macOS and on Linux)
is Git Credential Manager:
https://github.com/microsoft/Git-Credential-Manager-Core/

It comes with backends for some major Git hosters and is pretty
hassle-free, once configured.

Ciao,
Johannes

Re: Questions, improvements

[BARDOT Jérôme]

On 19/10/2021 23:31, Jeff King wrote:
> On Tue, Oct 19, 2021 at 07:38:16PM +0200, BARDOT Jérôme wrote:
>
>> 1)
>>
>> Why git not embed by default some gitinore rules (and can be "disable"
>> after).
>> All the time i have to add all operating system stuff, all editor stuff.
> I think you may have a hard time getting people to agree on what should
> go into those rules. ;)

Yes but for certain things i think we will are most of us agree. (In
professional context)

Temp files for Operating System, file system, text editor and IDE.

It can be also a great way to improve interoperability (between tools)
and identify/improve tools without personnal and team configuration.

Keep repositories clean and easily usable with an abstraction layer of
tools used to do things (editor, OS, CI, etc) is what i want. 

> But you may find core.excludesFile (documented in "git help config")
> helpful. You can set up your personal set of files once, and they will
> be used in every repository.
>
>> 2)
>>
>> I need a domain name / uri / ip base way to choose auth information.
>> i find some examples in past but not as smart as what i want. (Maybe i
>> miss something)
>>
>> 3)
>>
>> For auth client side can we use tools like Pass and or identity manager.
> I'm not entirely sure I understand your questions here, but I think
> you're looking for credential helpers? Try "git help credentials" for an
> overview.
you understand well
> There are helpers which interact with common OS secure storage systems
> (like osxkeychain, libsecret, etc). But you can also write your own
> little scripts, and restrict them based on URLs.
>
> So for instance I use this config to pull a GitHub PAT out of the "pass"
> tool:
>
>   [credential "https://github.com"]
>   username = peff
>   helper = "!f() { test $1 = get && echo password=`pass github/token`; }; f"

Look great i will test

> -Peff

Re: Questions, improvements

[BARDOT Jérôme]

On 20/10/2021 13:42, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 19 Oct 2021, Jeff King wrote:
>
>> On Tue, Oct 19, 2021 at 07:38:16PM +0200, BARDOT Jérôme wrote:
>>
>>> 2)
>>>
>>> I need a domain name / uri / ip base way to choose auth information.
>>> i find some examples in past but not as smart as what i want. (Maybe i
>>> miss something)
>>>
>>> 3)
>>>
>>> For auth client side can we use tools like Pass and or identity manager.
>> I'm not entirely sure I understand your questions here, but I think
>> you're looking for credential helpers? Try "git help credentials" for an
>> overview.
>>
>> There are helpers which interact with common OS secure storage systems
>> (like osxkeychain, libsecret, etc). But you can also write your own
>> little scripts, and restrict them based on URLs.
>>
>> So for instance I use this config to pull a GitHub PAT out of the "pass"
>> tool:
>>
>>   [credential "https://github.com"]
>>   username = peff
>>   helper = "!f() { test $1 = get && echo password=`pass github/token`; }; f"
> A quite complete, cross-platform credential helper (included in Git for
> Windows and enabled by default, but it also works on macOS and on Linux)
> is Git Credential Manager:
> https://github.com/microsoft/Git-Credential-Manager-Core/

We only use GNU\Linux for our work, i see there is .deb, are they
integrated in official debian repositories (stable) ?

We avoid tools not Libre and not package by default in debian. (with few
exeptions) 

And for what i see it's using C# and Microsoft not really play
integration by putting stuff on their side instead of working with the
GNU community (but it's just my opinion).

> It comes with backends for some major Git hosters and is pretty
> hassle-free, once configured.
Pretty sure it is.
> Ciao,
> Johannes

Thx for the information by the way

Re: Questions, improvements

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

On 2021-10-20 at 12:40:10, BARDOT Jérôme wrote:
> On 20/10/2021 13:42, Johannes Schindelin wrote:
> > A quite complete, cross-platform credential helper (included in Git for
> > Windows and enabled by default, but it also works on macOS and on Linux)
> > is Git Credential Manager:
> > https://github.com/microsoft/Git-Credential-Manager-Core/
> 
> We only use GNU\Linux for our work, i see there is .deb, are they
> integrated in official debian repositories (stable) ?
> 
> We avoid tools not Libre and not package by default in debian. (with few
> exeptions) 

I believe this tool is open source, but it requires .NET Core, which is
not in Debian, so it's not included.  I don't know if it will work with
Mono instead, which is packaged in Debian.

I _think_ Debian prefers Mono over .NET Core because it is substantially
more portable in terms of architecture support.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Questions, improvements

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]

On 2021-10-20 at 12:25:32, BARDOT Jérôme wrote:
> 
> On 19/10/2021 23:31, Jeff King wrote:
> > I think you may have a hard time getting people to agree on what should
> > go into those rules. ;)
> 
> Yes but for certain things i think we will are most of us agree. (In
> professional context)
> 
> Temp files for Operating System, file system, text editor and IDE.

Unfortunately, there are a lot of different patterns here.  Some IDEs
use entire directories, and sometimes those patterns conflict with
common patterns used elsewhere.

For example, GitHub's recommended Visual Studio .gitignore[0] recommends
excluding directories "Bin" and "bin".  However, it is extremely common
for folks to have a "bin" directory in their dotfiles (I do, at least),
and that would cause problems.

It is generally recommended that projects try to remain reasonably
editor independent so that people can use whichever editor they prefer.
As a result, many projects don't include any editor-specific .gitignore
patterns, and rely on each individual user using their
`core.excludesfile` settings to ignore their own editor's and operating
system's files (e.g., Vim swap files).  Only editor-agnostic files, such
as .editorconfig files or files to run linting or formatting tools, are
included.

Also, when you try to pick common patterns, you end up with having to
decide what "common" means.  Should we support every editor's temporary
files, no matter how infrequently used?  Should we only support the top
N editors?  How do we decide which editors we should support?  How do we
decide which OSes we should support?  Should all patterns be case
insensitive to support the most OSes, or case sensitive to prevent false
positives?  How do we limit the rules to avoid bad performance from
giant lists of rules?  How do we resolve conflicts between these rules?

As you can see, it becomes quite sticky pretty quickly, and we're
basically bound to make somebody unhappy.  Letting each project decide
the appropriate rules for them may not please everybody, but it at least
displeases far fewer people, and it lets the people most competent to
decide those rules (the project leaders) make the decision.

[0] https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]