Re: Reverting the whole index-base series

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

Linus Torvalds [off-list ref] writes:

quoted

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