From: Junio C Hamano <junkio@cox.net>
Date: Fri, 12 Jan 2007 21:33:33 GMT
Subject: Re: 1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add
Message-ID: <7vps9kq6aa.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200701122015.l0CKFB8j022355@laptop13.inf.utfsm.cl>

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

> Junio C Hamano <junkio@cox.net> wrote:
> ...
>> This _is_ a regression, as we are checking something we did not
>> check before and refusing to work in cases where we did.  But I
>> am not sure if reverting to lift the safety (for that matter,
>> introducing the third "depends" alternative) is better than the
>> latest behaviour.
>
> It grates me somewhat that there isn't a clean way of saying "My .git stuff
> is over there". No big deal, really.
>
> And it is not a "depends", AFAICS: GIT_DIR says where to stash stuff, users
> had better know what they are doing in that case... so perhaps allow
> anything if GIT_DIR is set?

One problem I have with that is that doing so would make it
harder to prevent pushing into the current branch of a
repository with working tree from happening later.

In the "sequence of tarballs" example, I wonder why you cannot
do something like:

	git init-db
	for tarball
        do
        	tar xf $tarball
                # if it extracts in a wrong directory, move them
                # up first ...
                git add .
                git commit -a
		git rm -r .
	done