git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* .gitattributes lookup doesn't respect GIT_WORK_TREE
@ 2018-04-15 19:04 Andreas Schwab
  2018-04-15 21:05 ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Andreas Schwab @ 2018-04-15 19:04 UTC (permalink / raw)
  To: git

The functions in attr.c do not look at $GIT_WORK_TREE when trying to
find the .gitattributes file.  Thus if you are not inside the work tree,
but have GIT_WORK_TREE set attribute lookup will be wrong.

Password Store <http://www.passwordstore.org/> is using this feature
when the password store is a git repository.  It sets up a diff
attribute that decrypts the contents, but that works only if the command
is issued while inside the repository.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

* Re: .gitattributes lookup doesn't respect GIT_WORK_TREE
  2018-04-15 19:04 .gitattributes lookup doesn't respect GIT_WORK_TREE Andreas Schwab
@ 2018-04-15 21:05 ` Junio C Hamano
  2018-04-15 22:40   ` Andreas Schwab
  0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2018-04-15 21:05 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: git

Andreas Schwab <schwab@linux-m68k.org> writes:

> The functions in attr.c do not look at $GIT_WORK_TREE when trying to
> find the .gitattributes file.  Thus if you are not inside the work tree,
> but have GIT_WORK_TREE set attribute lookup will be wrong.

I may be mistaken (I do not have the code in front of me right now)
but IIRC after the setup.c code runs (which happens quite early in
the sequence that starts from git.c::cmd_main()), the Git process
moves to the top level of the working tree, and at that point there
is no reason to pay attention to $GIT_WORK_TREE or other mechanisms
that places the working tree at a non-standard location, because the
attributes (or any in-tree files like .gitignore or .gitmodules)
will be found relative to the current working directory no matter
what.  Did we break that recently?


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

* Re: .gitattributes lookup doesn't respect GIT_WORK_TREE
  2018-04-15 21:05 ` Junio C Hamano
@ 2018-04-15 22:40   ` Andreas Schwab
  2018-04-16 15:37     ` Duy Nguyen
  0 siblings, 1 reply; 4+ messages in thread
From: Andreas Schwab @ 2018-04-15 22:40 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Apr 16 2018, Junio C Hamano <gitster@pobox.com> wrote:

> I may be mistaken (I do not have the code in front of me right now)
> but IIRC after the setup.c code runs (which happens quite early in
> the sequence that starts from git.c::cmd_main()), the Git process
> moves to the top level of the working tree,

git log/show don't appear to do that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

* Re: .gitattributes lookup doesn't respect GIT_WORK_TREE
  2018-04-15 22:40   ` Andreas Schwab
@ 2018-04-16 15:37     ` Duy Nguyen
  0 siblings, 0 replies; 4+ messages in thread
From: Duy Nguyen @ 2018-04-16 15:37 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Junio C Hamano, Git Mailing List

On Mon, Apr 16, 2018 at 12:40 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Apr 16 2018, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I may be mistaken (I do not have the code in front of me right now)
>> but IIRC after the setup.c code runs (which happens quite early in
>> the sequence that starts from git.c::cmd_main()), the Git process
>> moves to the top level of the working tree,
>
> git log/show don't appear to do that.

Yeah we lazily set up worktree in some cases. Elsewhere in the
chdir-notify thread, I suggested that we set up worktree
unconditionally (but do not die setup fails; only die when a command
specifically requests for worktree). That work would help make this
work in most cases. But it's not materialized yet.
-- 
Duy

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

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-15 19:04 .gitattributes lookup doesn't respect GIT_WORK_TREE Andreas Schwab
2018-04-15 21:05 ` Junio C Hamano
2018-04-15 22:40   ` Andreas Schwab
2018-04-16 15:37     ` Duy Nguyen

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