git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@cam.org>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Theodore Tso <tytso@mit.edu>, Junio C Hamano <junkio@cox.net>,
	git <git@vger.kernel.org>
Subject: Re: git push to a non-bare repository
Date: Mon, 19 Mar 2007 00:08:47 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.0.83.0703182355570.18328@xanadu.home> (raw)
In-Reply-To: <20070319035351.GI20658@spearce.org>

On Sun, 18 Mar 2007, Shawn O. Pearce wrote:

> Theodore Tso <tytso@mit.edu> wrote:
> > So I dug a little more deeply, and the problem is that the reflog for
> > master was getting updated, but not the reflog for HEAD, and that's
> > what "git reflog" was showing --- hence my confusion.
> > 
> > What are the rules for when HEAD's reflog should get updated, and is
> > this documented anywhere in the man pages?
> 
> It is buried down in write_ref_sha1 (in refs.c).  The rule is if the
> name of the ref given to us for update does not match the actual
> ref we are about to change, we log to both the original ref name
> given and the actual ref name.
> 
> This handles the case of HEAD being a symref to some actual branch;
> we update the HEAD reflog and the actual branch reflog whenever
> someone updates HEAD.  Which is what we are usually doing from
> tools like git-checkout.
> 
> receive-pack isn't updating the HEAD reflog as its updating the
> actual branch, not HEAD.  If you pushed instead to HEAD you should
> see the HEAD reflog entry too.

This is indeed a corner case.  And it was never considered before as 
great care was made at the time to be sure pushes wouldn't create any 
reflogs on the remote side, which is effectively done by not 
automatically enabling reflogs on bare repos.

> Its a little ugly here as I'm not sure we should always update
> HEAD's reflog if HEAD points at a branch we are actually updating.
> Maybe we should though in receive-pack ?

If the meaning of HEAD changed (although indirectly) because HEAD 
happens to point to the branch that just got updated then logically the 
HEAD reflog should be updated too.  On the other hand the HEAD reflog 
should reflect operations performed on HEAD.  Since the push updates the 
branch directly it is not exactly performing some operation on HEAD 
since HEAD could point anywhere and that wouldn't change the push at 
all.

Meaning that for the discussion of pushing to a non-bare repository with 
a dirty working tree... If the branch being pushed into is not pointed 
to by HEAD then no consideration what so ever about the working tree 
should be made, and no update to the HEAD reflog made of course.


Nicolas

  reply	other threads:[~2007-03-19  4:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-18 17:31 git push to a non-bare repository Matthieu Moy
2007-03-18 19:47 ` Junio C Hamano
2007-03-18 21:51   ` Sam Vilain
2007-03-18 22:01     ` Jakub Narebski
2007-03-18 22:18     ` Junio C Hamano
2007-03-19  2:00 ` Theodore Tso
2007-03-19  1:55   ` Junio C Hamano
2007-03-19  2:21     ` Shawn O. Pearce
2007-03-19  2:47       ` Theodore Tso
2007-03-19  2:56         ` Shawn O. Pearce
2007-03-19  3:21           ` Theodore Tso
2007-03-19  3:53             ` Shawn O. Pearce
2007-03-19  4:08               ` Nicolas Pitre [this message]
2007-03-19  6:25                 ` Theodore Tso
2007-03-19  6:44                   ` Junio C Hamano
2007-03-19 15:20                     ` Nicolas Pitre
2007-03-19 15:16                   ` Nicolas Pitre
2007-03-19 23:58               ` Sam Vilain
2007-03-20  0:49                 ` Junio C Hamano
2007-03-20  0:54                   ` Junio C Hamano
2007-03-19  3:33           ` Theodore Tso
2007-03-19  3:47             ` Shawn O. Pearce
2007-03-19  4:14               ` Junio C Hamano
2007-03-19  9:19   ` Matthieu Moy
2007-03-19 10:01     ` Jakub Narebski
2007-03-21 17:20     ` Neil Schemenauer
2007-03-19 12:44 ` Sergio Callegari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.0.83.0703182355570.18328@xanadu.home \
    --to=nico@cam.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=spearce@spearce.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).