git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* is there a truly compelling rationale for .git/info/exclude?
@ 2017-10-06 10:14 rpjday
  2017-10-06 12:13 ` Junio C Hamano
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: rpjday @ 2017-10-06 10:14 UTC (permalink / raw)
  To: git

   currently having a discussion with ben straub of "pro git" notoriety,
and he and i seem to agree that there's not much value in registering
ignore patterns in a repo-specific .git/info/exclude file.

   on the one hand, the .gitignore files that come with a repo would
represent (in ben's terminology, which i really like) the "intrinsic"
patterns to be ignored that are related to the basic content of the repo.

   at the other end, users are certainly welcome to add extra patterns
to be ignored, based purely on the way they work -- perhaps based on
their choice of editor, they might want to exclude *.swp files, or
if working on a Mac, ignore .DS_Store, and so on, using a
core.excludesFile setting.

   and in this funny grey area in between, we have .git/info/exclude,
to be used for ... what, exactly? the one argument i've come up with
is the situation where you discover that a repo you've cloned has an
incomplete set of .gitignore patterns, and while you submit a patch
for that to the maintainer, you can temporarily add that pattern
to .git/info/exclude, and as soon as the patch is accepted, you can
toss it.

   but even that isn't a really compelling reason. so what's it for?

rday



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-06 10:14 is there a truly compelling rationale for .git/info/exclude? rpjday
@ 2017-10-06 12:13 ` Junio C Hamano
  2017-10-06 17:39   ` Robert P. J. Day
  2017-10-06 14:18 ` Kaartic Sivaraam
  2017-10-08  8:41 ` Steinar Bang
  2 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2017-10-06 12:13 UTC (permalink / raw)
  To: rpjday; +Cc: git

rpjday@crashcourse.ca writes:

>   at the other end, users are certainly welcome to add extra patterns
> to be ignored, based purely on the way they work -- perhaps based on
> their choice of editor, they might want to exclude *.swp files, or
> if working on a Mac, ignore .DS_Store, and so on, using a
> core.excludesFile setting.

This is primarily why .git/info/exclude exists.  A user who does not
use the same set of tools to work on different projects may not be
able to use ~/.gitconfig with core.excludesFile pointing at a single
place that applies to _all_ repositories the user touches.

Also, core.excludesFile came a lot later than in-project and
in-repository exclude list, IIRC.

Don't waste time by seeking a "compelling" reason.  A mere "this is
the most expedite way to gain convenience" back when something was
introduced could be an answer, and it is way too late to complain
about such a choice anyway.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-06 10:14 is there a truly compelling rationale for .git/info/exclude? rpjday
  2017-10-06 12:13 ` Junio C Hamano
@ 2017-10-06 14:18 ` Kaartic Sivaraam
  2017-10-08  8:41 ` Steinar Bang
  2 siblings, 0 replies; 10+ messages in thread
From: Kaartic Sivaraam @ 2017-10-06 14:18 UTC (permalink / raw)
  To: rpjday, git

On Fri, 2017-10-06 at 06:14 -0400, rpjday@crashcourse.ca wrote:
>    and in this funny grey area in between, we have .git/info/exclude,
> to be used for ... what, exactly? the one argument i've come up with
> is the situation where you discover that a repo you've cloned has an
> incomplete set of .gitignore patterns, and while you submit a patch
> for that to the maintainer, you can temporarily add that pattern
> to .git/info/exclude, and as soon as the patch is accepted, you can
> toss it.
> 
>    but even that isn't a really compelling reason. so what's it for?
> 

Thanks for asking this question. I have long been in the scenario you
just described above except that I didn't know of .git/info/exclude all
these days. I was longing to find if there was a way to ignore files in
 a repo without touching the .gitignore of that repo . Now I have found
one, the ".git/info/exclude".

Thanks, again.

-- 
Kaartic

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-06 12:13 ` Junio C Hamano
@ 2017-10-06 17:39   ` Robert P. J. Day
  2017-10-06 19:23     ` Jonathan Nieder
                       ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Robert P. J. Day @ 2017-10-06 17:39 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Fri, 6 Oct 2017, Junio C Hamano wrote:

> rpjday@crashcourse.ca writes:
>
> >   at the other end, users are certainly welcome to add extra
> > patterns to be ignored, based purely on the way they work --
> > perhaps based on their choice of editor, they might want to
> > exclude *.swp files, or if working on a Mac, ignore .DS_Store, and
> > so on, using a core.excludesFile setting.
>
> This is primarily why .git/info/exclude exists.  A user who does not
> use the same set of tools to work on different projects may not be
> able to use ~/.gitconfig with core.excludesFile pointing at a single
> place that applies to _all_ repositories the user touches.
>
> Also, core.excludesFile came a lot later than in-project and
> in-repository exclude list, IIRC.
>
> Don't waste time by seeking a "compelling" reason.  A mere "this is
> the most expedite way to gain convenience" back when something was
> introduced could be an answer, and it is way too late to complain
> about such a choice anyway.

  perfectly respectable answer ... it tells me that, between
.gitignore files and core.excludesFile, there's not much left for
.git/info/exclude to do, except in weird circumstances.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-06 17:39   ` Robert P. J. Day
@ 2017-10-06 19:23     ` Jonathan Nieder
  2017-10-07 21:20     ` brian m. carlson
  2017-10-12 23:18     ` Johannes Schindelin
  2 siblings, 0 replies; 10+ messages in thread
From: Jonathan Nieder @ 2017-10-06 19:23 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Junio C Hamano, git

Hi,

Robert P. J. Day wrote:
> On Fri, 6 Oct 2017, Junio C Hamano wrote:

>> Don't waste time by seeking a "compelling" reason.  A mere "this is
>> the most expedite way to gain convenience" back when something was
>> introduced could be an answer, and it is way too late to complain
>> about such a choice anyway.
>
>   perfectly respectable answer ... it tells me that, between
> .gitignore files and core.excludesFile, there's not much left for
> .git/info/exclude to do, except in weird circumstances.

I use .git/info/exclude in what I don't consider to be weird
circumstances.

But I am not motivated to say more than that without knowing what my
answer is going to be used for.  E.g. is there a part of the
gitignore(5) man page where such an explanation would make it less
confusing and more useful?

Thanks,
Jonathan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-06 17:39   ` Robert P. J. Day
  2017-10-06 19:23     ` Jonathan Nieder
@ 2017-10-07 21:20     ` brian m. carlson
  2017-10-12 23:18     ` Johannes Schindelin
  2 siblings, 0 replies; 10+ messages in thread
From: brian m. carlson @ 2017-10-07 21:20 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Junio C Hamano, git

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

On Fri, Oct 06, 2017 at 01:39:16PM -0400, Robert P. J. Day wrote:
> On Fri, 6 Oct 2017, Junio C Hamano wrote:
> > This is primarily why .git/info/exclude exists.  A user who does not
> > use the same set of tools to work on different projects may not be
> > able to use ~/.gitconfig with core.excludesFile pointing at a single
> > place that applies to _all_ repositories the user touches.
> >
> > Also, core.excludesFile came a lot later than in-project and
> > in-repository exclude list, IIRC.
> >
> > Don't waste time by seeking a "compelling" reason.  A mere "this is
> > the most expedite way to gain convenience" back when something was
> > introduced could be an answer, and it is way too late to complain
> > about such a choice anyway.
> 
>   perfectly respectable answer ... it tells me that, between
> .gitignore files and core.excludesFile, there's not much left for
> .git/info/exclude to do, except in weird circumstances.

A place where I use it is in some Vim package repositories that I have
as submodules of my home directory.  The author of those repositories,
Tim Pope, explicitly does not exclude the helptags output.  I simply
ignore those files using .git/info/exclude.

Another case is when I install a plugin that lives below a our main
product repository at work.  I can simply exclude that plugin locally on
my system without the need to submit a change for merge.  I can later
remove those patterns if I like and run git clean -df to clean up.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-06 10:14 is there a truly compelling rationale for .git/info/exclude? rpjday
  2017-10-06 12:13 ` Junio C Hamano
  2017-10-06 14:18 ` Kaartic Sivaraam
@ 2017-10-08  8:41 ` Steinar Bang
  2 siblings, 0 replies; 10+ messages in thread
From: Steinar Bang @ 2017-10-08  8:41 UTC (permalink / raw)
  To: git

>>>>> rpjday@crashcourse.ca:

>   but even that isn't a really compelling reason. so what's it for?

I use it to ignore stuff in my git-versioned home directory.

Every time I use a new program and it creates a config file or a config
directory, it shows up as clutter in magit in my git versioned home
directory.

I started with putting the stuff to be ignored in .gitignore, but since
I run different stuff on different machines and on different OSes,
.gitignore started to contain irrelevant stuff (ignoring a stuff from a
program that was run once and then never again, ignoring stuff on one
machine that maybe should not be ignored on a different machine), and
then I figured it was much simpler to just ignore stuff repo-locally in
.git/info/exclude




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-06 17:39   ` Robert P. J. Day
  2017-10-06 19:23     ` Jonathan Nieder
  2017-10-07 21:20     ` brian m. carlson
@ 2017-10-12 23:18     ` Johannes Schindelin
  2017-10-12 23:56       ` Jeff King
  2 siblings, 1 reply; 10+ messages in thread
From: Johannes Schindelin @ 2017-10-12 23:18 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

Hi Robert,

[who I had to cull from the To:/Cc: headers, as my mailer consistently
told me that there is no valid DNS record to route mail to
rpjday@crashcourse.ca, which *is* weird.]

On Fri, 6 Oct 2017, Robert P. J. Day wrote:

> On Fri, 6 Oct 2017, Junio C Hamano wrote:
> 
> > Don't waste time by seeking a "compelling" reason.  A mere "this is
> > the most expedite way to gain convenience" back when something was
> > introduced could be an answer, and it is way too late to complain
> > about such a choice anyway.
> 
>   perfectly respectable answer ... it tells me that, between .gitignore
>   files and core.excludesFile, there's not much left for
>   .git/info/exclude to do, except in weird circumstances.

I use .git/info/exclude to keep worktrees in subdirectories of the "main"
worktree.

That's not really weird. It's just something few people do, but that's not
the same as "weird".

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-12 23:18     ` Johannes Schindelin
@ 2017-10-12 23:56       ` Jeff King
  2017-10-13  7:05         ` Robert P. J. Day
  0 siblings, 1 reply; 10+ messages in thread
From: Jeff King @ 2017-10-12 23:56 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: rpjday, git, Junio C Hamano

On Fri, Oct 13, 2017 at 01:18:00AM +0200, Johannes Schindelin wrote:

> [who I had to cull from the To:/Cc: headers, as my mailer consistently
> told me that there is no valid DNS record to route mail to
> rpjday@crashcourse.ca, which *is* weird.]

You are not the only one to mention this, so I did 60 seconds of
digging. Turns out that the MX of crashcourse.ca points to a CNAME
(mail.crashcourse.ca), which is explicitly forbidden by RFC 2181
(section 10.3). Some MTAs are picky about this and others are not (mine
isn't, so I've added Robert back to the cc so he sees this).

-Peff

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: is there a truly compelling rationale for .git/info/exclude?
  2017-10-12 23:56       ` Jeff King
@ 2017-10-13  7:05         ` Robert P. J. Day
  0 siblings, 0 replies; 10+ messages in thread
From: Robert P. J. Day @ 2017-10-13  7:05 UTC (permalink / raw)
  To: Jeff King; +Cc: Johannes Schindelin, git, Junio C Hamano

On Thu, 12 Oct 2017, Jeff King wrote:

> On Fri, Oct 13, 2017 at 01:18:00AM +0200, Johannes Schindelin wrote:
>
> > [who I had to cull from the To:/Cc: headers, as my mailer consistently
> > told me that there is no valid DNS record to route mail to
> > rpjday@crashcourse.ca, which *is* weird.]
>
> You are not the only one to mention this, so I did 60 seconds of
> digging. Turns out that the MX of crashcourse.ca points to a CNAME
> (mail.crashcourse.ca), which is explicitly forbidden by RFC 2181
> (section 10.3). Some MTAs are picky about this and others are not
> (mine isn't, so I've added Robert back to the cc so he sees this).

  ok, i'll tell my admin about this, thanks.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-06 10:14 is there a truly compelling rationale for .git/info/exclude? rpjday
2017-10-06 12:13 ` Junio C Hamano
2017-10-06 17:39   ` Robert P. J. Day
2017-10-06 19:23     ` Jonathan Nieder
2017-10-07 21:20     ` brian m. carlson
2017-10-12 23:18     ` Johannes Schindelin
2017-10-12 23:56       ` Jeff King
2017-10-13  7:05         ` Robert P. J. Day
2017-10-06 14:18 ` Kaartic Sivaraam
2017-10-08  8:41 ` Steinar Bang

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox