Re: Trying to push into empty repo, get fatal: bad revision 'HEAD'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Samuel & Junio,

On 2015-04-01 03:36, Junio C Hamano wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
> 
>> Samuel Williams <space.ship.traveller@xxxxxxxxx> writes:
>>
>>> I would expect if you push to an empty repo, it would update it
>>> (because denyCurrentBranch = updateInstead).
>>
>> Good finding.
>>
>> I think the current implementation of updateInstead is set up to
>> bootstrap from an empty repository but only supports incremental
>> updates once the receiving repository and its working tree gets set
>> up.  But I do not think it was a conscious design decison to forbid
>> bootstrapping an empty repository, but was a mere gap in the
>> implementation.  At least, I do not think of a reason why we should
>> forbid it (and I am Cc'ing Dscho to confirm).
> 
> This is a tangent but I think we should unify the "do we already
> have history behind HEAD, or is the current branch still unborn"
> test done by various commands and tighten it.

Right, I did not think about that use case at all.

> As a quick and dirty hack, I just mimicked what builtin/merge.c seems to do, but this would tell a detached HEAD that points at a nonsense object name (i.e. "abcde" not a full 40-hex) as "unborn", where we would be better off stopping the operation instead of making the repository breakage worse by doing further damage.

Yeah, and we could refactor that into a global function, too. But for the moment, I think your proposed patch is good enough.

Ciao,
Dscho

--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]