Re: PUSH_HEAD, was Re: FETCH_HEAD question
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 18, 2009, 00:30 UTC
- Message-ID
- <alpine.DEB.1.00.0902180122440.10279@pacific.mpi-cbg.de>
- In-Reply-To
- <7vab8k39ze.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 17 Feb 2009, Junio C Hamano wrote:
Show 8 quoted lines
> FETCH_HEAD is something the user who is sitting in front of the > repository controls with "git fetch" into it. The objects referenced > from it is not part of the "reachable" set, and expectation is that > anything that requires the objects will happen before that user decides > to actively go prune unreachable objects. > > PUSH_HEAD is quite different, and it needs to be handled a lot more > carefully.
Well, when I talked about the push equivalent of FETCH_HEAD I really meant that it be exactly that. No additional taking care, that's the user's responsibility.
I got carried away with the "2nd push will not need to push the objects again", and in the meantime I think that should not be the case.
The main use for it I had in mind was to have some obviously temporary "ref" that you could push to.
However, I think that would not bode well, as receive.denyCurrentBranch will error out early, and rightfully so.
The way out I _could_ think of right now is to have a REFUSED_PUSH_HEAD _just_ for the denyCurrentBranch case, but it's bedtime for lil' Dscho, so I cannot think clearly about that today.
Ciao, Dscho "who will be dreaming of detached, split and pushed heads all night long"