Re: Reverting the whole index-base series

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 15, 2007, 23:58 UTC
Message-ID: <Pine.LNX.4.64.0704151652420.5473@woody.linux-foundation.org>
In-Reply-To: <7vhcrh1a2w.fsf@assigned-by-dhcp.cox.net>

On Sun, 15 Apr 2007, Junio C Hamano wrote:

Show 9 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> > Ahh, ok. I was kind of expecting that you'd actually do something at 
> > "receive-pack" time instead, not at the next commit. That would also solve 
> > it - just have an option saying "update the working tree when receiving". 
> 
> I specifically did not want to do that, as it would break
> existing workflow of pushing into a live repository, knowing the
> branch might be checked out at the remote.

Yeah. That said, maybe we could make it an option. There's really a few different things we could do:

 (a) what we do now - the working tree and index is totally unaffected
 (b) do a "git-read-tree -m old new" and if that fails, fail the push.
     This would at least ensure the *index* matches
 (b') same as (b), but with "-u" to actually check it out
 (c) do a "git-read-tree --reset new"
 (c') same as (c), but with "-u"

and we could just keep the *default* the same, but allow the receiving side to say what it wants to happen.

> Also, the case of multiple working trees sharing the same refs/
> namespace cannot be solved by trapping receive-pack alone.

Right. I think any working-tree thing would have to be conditional on the receive being done on a non-bare git repository (obviously) and we'd only update the directory that the push was aimed at.

So if somebody does

	git push remote:my-git-tree/.git/

then we'd *always* do (a), since we pushed into the "bare" part, but if somebody did

	git push remote:my-git-tree

and the receiver ended up doing a "cd .git", it would remember what the checked-out tree was and update that one (and no other).

			Linus