On Sun, 18 Mar 2007, Shawn O. Pearce wrote: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. 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 24/37] dccp: Processing Confirm options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Alexey Dobriyan | Re: [GIT]: Networking |
| david | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
