Re: git push to a non-bare repository

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

 



On Sun, 18 Mar 2007, Junio C Hamano wrote:

> Theodore Tso <tytso@xxxxxxx> writes:
> 
> > Right, but if the branch being pointed to is pointed to by HEAD I
> > would argue that the reflog for HEAD should be updated, since
> > operations that reference HEAD will see a new commit, and and it will
> > be confusing when "git reflog" shows no hint of the change.
> >
> > Of couse, if the branch being pushed to isn't one which is pointed by
> > HEAD, of course HEAD's reflog shouldn't be updated.
> 
> If we were to do this properly, we probably would need to
> restructure the reflog update code for the HEAD in a major way.
> "git-update-ref refs/heads/foo $newvalue" when HEAD points at
> branch 'foo' currently does not update HEAD reflog because the
> current definition of HEAD reflog is (as Nico mentioned) log of
> changes made through HEAD symref.  Instead, we would need a
> reverse lookup every time any ref is updated to see if that ref
> is pointed by any symbolics ref and update the reflogs of those
> symbolic refs.  This is expensive to do in general, though,
> because there is no backpointer to list of symbolic refs that
> point at a non-symbolic ref.

But practically speaking... is there that many cases where a branch is 
updated directly instead of the operation performed through HEAD?

We identified one case which is a push to a non bare repo.

If those cases are very few (and they _should_ be very few) then we 
might simply cheat a little and update HEAD separately in those cases.


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