On Sun, 15 Apr 2007, Junio C Hamano wrote:
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html