[PATCH 0/8] Fix some problems with reflog expiration

2015-02-09 Thread Michael Haggerty
In addition to a few cleanups, this patch series fixes some problems
that I noticed when working on mh/reflog-expire:

* Ignore '--updateref' when expiring the reflog of a symbolic
  reference, because the alternatives are all pretty silly. See the
  log message for commit 6/8 for more information.

* Ignore '--updateref' when *all* reflog entries are expired by git
  reflog expire or git reflog delete. Currently, this sets the
  reference to 0{40}, which breaks the repository. (Another
  alternative would be to delete the reference in this situation, but
  that seemed too radical to me somehow.)

* When expiring the reflog for a symbolic reference, lock the symbolic
  reference rather than its referent.

This patch series applies on top of master merged together with
sb/atomic-push, like the refs-have-new patch series that I just
submitted. It is also available from my GitHub account [1] as branch
expire-updateref-fixes.

There is a minor conflict between this patch series and
mh/refs-have-new:

 HEAD
if (!is_null_sha1(update-new_sha1)) {
if (!update-lock-force_write 
!hashcmp(update-lock-old_sha1, update-new_sha1)) 
{
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock, 
update-new_sha1,
  update-msg)) {
||| merged common ancestors
if (!is_null_sha1(update-new_sha1)) {
if (write_ref_sha1(update-lock, update-new_sha1,
   update-msg)) {
===
if ((flags  REF_HAVE_NEW)  !is_null_sha1(update-new_sha1)) {
if (write_ref_sha1(update-lock, update-new_sha1,
   update-msg)) {
 refs-have-new

It can be resolved in the obvious way:


if ((flags  REF_HAVE_NEW)  !is_null_sha1(update-new_sha1)) {
if (!update-lock-force_write 
!hashcmp(update-lock-old_sha1, update-new_sha1)) 
{
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock, 
update-new_sha1,
  update-msg)) {


By the way, both of these patch series conflict with
sb/atomic-push-fix, which is in pu. My understanding is that Stefan
wants to rework that patch series anyway, but if not I would be happy
to show how to resolve the conflicts.

Michael

[1] https://github.com/mhagger/git

Michael Haggerty (8):
  write_ref_sha1(): remove check for lock == NULL
  write_ref_sha1(): Move write elision test to callers
  lock_ref_sha1_basic(): do not set force_write for missing references
  reflog: fix documentation
  reflog: rearrange the manpage
  reflog_expire(): ignore --updateref for symbolic references
  reflog_expire(): never update a reference to null_sha1
  reflog_expire(): lock symbolic refs themselves, not their referent

 Documentation/git-reflog.txt | 65 +++-
 builtin/reflog.c |  2 +-
 refs.c   | 55 -
 3 files changed, 65 insertions(+), 57 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/8] Fix some problems with reflog expiration

2015-02-09 Thread Stefan Beller
On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote:

 By the way, both of these patch series conflict with
 sb/atomic-push-fix, which is in pu. My understanding is that Stefan
 wants to rework that patch series anyway, but if not I would be happy
 to show how to resolve the conflicts.

Heh, I had it already reworked on Friday evening, but forgot to send it out
for review. As mentioned before, sb/atomic-push-fix is a misleading branch name
as it actually enables large transactions [ large means  $(ulimit -n) ].

I don't mind reworking that series again on top of either this or the other
patch series you sent out, as I wasn't entirely happy with it anyway.
(Naming is hard)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html