On Tue, Mar 26, 2013 at 10:04 PM, Jeff King wrote:
>> specifies a path to use instead of the default `.git`
>> for the base of the repository.
>> The '--git-dir' command-line option also sets this value.
>> + If neither GIT_WORK_TREE nor '--work-tree' is set, the
>> + cur
From: "Duy Nguyen"
Sent: Tuesday, March 26, 2013 9:48 AM
On Tue, Mar 26, 2013 at 08:02:30AM -, Philip Oakley wrote:
>> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
>> GIT_DIR is explicitly set.
>
> And it *WILL* be that way til the end of time. Unless you are at
> the
On Tue, Mar 26, 2013 at 11:20:58AM -0700, Junio C Hamano wrote:
> When you are in ~/mail/subdir, because GIT_DIR alone does not give
> you to specify where the root-level of the working tree is, you had
> to "cd .." before running "GIT_DIR=~/git/mail.git git ...". By
> setting GIT_WORK_TREE to po
On 26 March 2013 18:48, Jeff King wrote:
> On Tue, Mar 26, 2013 at 06:20:09PM +0100, demerphq wrote:
>
>> Seconded. At $work lots of people started asking anxious questions
>> about this. It was suggested it is a potential security hole, although
>> I am not sure I agree, but the general idea bein
Jeff King writes:
> Yes, setting GIT_DIR but not GIT_WORK_TREE has always been a valid way
> to work on a repository where you do not want the working tree polluted
> with your .git file. It's not a common setup, but people do use it.
> E.g., you might keep ~/mail as a git repo, but do not want t
On Tue, Mar 26, 2013 at 06:20:09PM +0100, demerphq wrote:
> Seconded. At $work lots of people started asking anxious questions
> about this. It was suggested it is a potential security hole, although
> I am not sure I agree, but the general idea being that if you could
> manage to set this var in
On Tue, Mar 26, 2013 at 06:06:17PM +0100, Richard Weinberger wrote:
> >We could, but that would break the existing behavior for other people
> >(and I assume you mean "when GIT_WORK_TREE is not set at all", as I
> >would think GIT_WORK_TREE=. is explicit enough).
>
> Is there a valid use case to
On 26 March 2013 18:06, Richard Weinberger wrote:
> P.s: I've told this story to some friends and co-workers which use git like
> me very day.
> All of them were shocked about the behavior of git-clean and GIT_DIR.
Seconded. At $work lots of people started asking anxious questions
about this. It
Am 26.03.2013 15:56, schrieb Jeff King:
On Tue, Mar 26, 2013 at 02:07:44PM +0100, Richard Weinberger wrote:
Should this important warning be part of the git(1) documentation on
the environment variables (and possibly other places) given the
consequences of this case? It wasn't something
I'd app
Jeff King writes:
> On Tue, Mar 26, 2013 at 04:48:44PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> Something like this, maybe?
>>
>> -- 8< --
>> Subject: [PATCH] git.txt: document the implicit working tree setting with
>> GIT_DIR
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> Documentation/
On Tue, Mar 26, 2013 at 04:48:44PM +0700, Nguyen Thai Ngoc Duy wrote:
> Something like this, maybe?
>
> -- 8< --
> Subject: [PATCH] git.txt: document the implicit working tree setting with
> GIT_DIR
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/git.txt | 2 ++
> 1 file changed
On Tue, Mar 26, 2013 at 02:07:44PM +0100, Richard Weinberger wrote:
> >Should this important warning be part of the git(1) documentation on
> >the environment variables (and possibly other places) given the
> >consequences of this case? It wasn't something
> >I'd appreciated from a simple reading.
Am 26.03.2013 09:02, schrieb Philip Oakley:
From: "Junio C Hamano"
Sent: Monday, March 25, 2013 10:06 PM
Jonathan Nieder writes:
Richard Weinberger wrote:
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
changing the
current working directory all the time.
Yeah,
On Tue, Mar 26, 2013 at 08:02:30AM -, Philip Oakley wrote:
> >> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
> >> GIT_DIR is explicitly set.
> >
> > And it *WILL* be that way til the end of time. Unless you are at
> > the top level of your working tree, you are supposed t
From: "Junio C Hamano"
Sent: Monday, March 25, 2013 10:06 PM
Jonathan Nieder writes:
Richard Weinberger wrote:
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset
without changing the
current working directory all the time.
Yeah, for historical reasons GIT_WORK_TREE defaults
Am 25.03.2013 23:20, schrieb Junio C Hamano:
Richard Weinberger writes:
Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?
I've always set only GIT_DIR because it just worked (till today...).
That means you never run your script inside a subdirectory ;-)
If your
On Mon, Mar 25, 2013 at 3:13 PM, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
>>I do not
>> know how things will break when the end user sets and exports it to
>> the environment, and I do not think we would want to make any
>> promis
Richard Weinberger writes:
> Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?
> I've always set only GIT_DIR because it just worked (till today...).
That means you never run your script inside a subdirectory ;-)
If your $GIT_DIR is tied to a single working tree, a
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> In git versions including the patch 2cd83d10bb6b (setup: suppress
>>> implicit "." work-tree for bare repos, 2013-03-08, currently in "next"
>>> but not "master"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this
Richard Weinberger wrote:
> Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?
> I've always set only GIT_DIR because it just worked (till today...).
chdir-ing into the git repo without setting any GIT_* vars is probably
the simplest way to go.
--
To unsubscribe from t
Junio C Hamano wrote:
>I do not
> know how things will break when the end user sets and exports it to
> the environment, and I do not think we would want to make any
> promise on how it works.
That's a reasonable desire, and it means it'
Am 25.03.2013 23:06, schrieb Junio C Hamano:
Jonathan Nieder writes:
Richard Weinberger wrote:
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
changing the
current working directory all the time.
Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
G
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> In git versions including the patch 2cd83d10bb6b (setup: suppress
>> implicit "." work-tree for bare repos, 2013-03-08, currently in "next"
>> but not "master"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this
>> behavior.
>
> WAT?
Is that fa
Jonathan Nieder writes:
> Richard Weinberger wrote:
>
>> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
>> changing the
>> current working directory all the time.
>
> Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
> GIT_DIR is explicitly set.
And it
Jonathan Nieder writes:
> In git versions including the patch 2cd83d10bb6b (setup: suppress
> implicit "." work-tree for bare repos, 2013-03-08, currently in "next"
> but not "master"), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this
> behavior.
WAT?
--
To unsubscribe from this list: send the
Hi,
Richard Weinberger wrote:
> In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
> changing the
> current working directory all the time.
Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
GIT_DIR is explicitly set.
In git versions including the patch 2c
Hi!
Today I've discovered that on the build server my home directory was empty.
A post-mortem analysis showed that the git-clean command I've added to my
kernel build script
is the evil doer.
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
changing the
current working d
27 matches
Mail list logo
