Linus Torvalds [off-list ref] writes:
On Sun, 15 Apr 2007, Junio C Hamano wrote:
quoted
quoted
But no, I wasn't following that series, so I probably totally
misunderstood what you were going after..
Could be.
The issue in short was about:
$ git checkout $branch
At this point you think your HEAD is at $branch head, and you
are working towards building a commit that has that commit as
one of the parents.
Then a gremlin updates the commit HEAD points at.
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.
Also, the case of multiple working trees sharing the same refs/
namespace cannot be solved by trapping receive-pack alone.
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