can't push to binutils-gdb, git-hooks rejecting commits

can't push to binutils-gdb, git-hooks rejecting commits

[Pedro Alves]

Hi,

I'm trying to push a patch to master, but it's getting rejected by the
server-side git hooks.  Anyone else seeing the same?  See below.

Repeating that big "git rev-list" command below locally shows:

  fatal: bad revision '^refs/heads/users/hjl/pr17709'

That branch doesn't appear to exist anymore.   Sounds like the hooks
need to run "git remote prune origin" on their clone?  Does that make
sense?

Joel, any ideas?

$ git push ssh://palves@sourceware.org/git/binutils-gdb.git HEAD:master
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.19 KiB | 0 bytes/s, done.
Total 6 (delta 5), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote:   File "hooks/update.py", line 69, in <module>
remote:     check_update(args.ref_name, args.old_rev, args.new_rev)
remote:   File "hooks/update.py", line 62, in check_update
remote:     update_cls.validate()
remote:   File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 123, in validate
remote:     self.__check_max_commit_emails()
remote:   File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 653, in __check_max_commit_emails
remote:     self.__set_send_email_p_attr(self.added_commits)
remote:   File "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 713, in __set_send_email_p_attr
remote:     _split_lines=True)
remote:   File "/sourceware1/projects/src-home/git-hooks/hooks/git.py", line 132, in f
remote:     return git_run(command, *args, **kwargs)
remote:   File "/sourceware1/projects/src-home/git-hooks/hooks/git.py", line 104, in git_run
remote:     output)
remote: git.CalledProcessError: Command 'git rev-list 0d999a6ef0f98b22430d70951408869864c979e0 ^refs/heads/users/hjl/pr17709 ^refs/heads/users/hjl/compressed ^refs/heads/users/ibm/binutils-2_25 ^refs/heads/users/ibm/binutils-2_24 ^refs/heads/users/palves/cxx-eliminate-cleanups ^refs/heads/users/hjl/mpx/plt2 ^refs/heads/users/hjl/branch ^refs/heads/users/arnez/lk3 ^refs/heads/users/hjl/dynobj ^refs/heads/users/apinski/gdb-ilp32-gdbserver ^refs/heads/users/ccoutant/two-level-line-150331 ^refs/heads/users/hjl/version ^refs/heads/users/bheckel/fortran-vla-strings ^refs/heads/users/palves/thread_apply-v2 ^refs/heads/users/arnez/lk ^refs/heads/users/palves/whatis ^refs/heads/users/palves/cxx-target_ops ^refs/heads/users/hjl/output ^refs/heads/users/hjl/secondary/master ^refs/heads/users/hjl/mpx/pltext8 ^refs/heads/users/hjl/pr12639 ^refs/heads/users/palves/core-prstatus-rework ^refs/heads/users/hjl/pr18599 ^refs/heads/users/hjl/got ^refs/heads/users/mwk/s390-relro-old ^refs/heads/users/hjl/pr18028 ^refs/heads/users/palves/cxx-gdb_exceptions ^refs/heads/users/simark/user-selection-rfc ^refs/heads/users/hjl/link_assignments ^refs/heads/users/hl/pr21679 ^refs/heads/users/pinskia/gdb-aarch64-ilp32 ^refs/heads/users/rth/x86-seg ^refs/heads/users/hjl/gold-test ^refs/heads/users/simark/ptid-in-fetch-store-regs ^refs/heads/users/bheckel/fortran-oop-extend-type ^refs/heads/users/palves/dwarf2_per_objfile ^refs/heads/users/palves/fix-double-free ^refs/heads/users/hjl/noisa ^refs/heads/users/ccoutant/experimental-relr ^refs/heads/users/palves/interrupt-while-step-over-v1 ^refs/heads/users/mwk/s390-relro-rel ^refs/heads/users/palves/jit-speedup ^refs/heads/users/ARM/embedded-gdb-7.10-branch ^refs/heads/users/hjl/mpx/plt32 ^refs/heads/users/hjl/mpx/pltext16 ^refs/heads/users/aoliva/SFN ^refs/heads/users/alahay01/targetregcache ^refs/heads/users/palves/dwarf5-regression-for-jan ^refs/heads/users/hjl/compress ^refs/heads/users/hjl/lto-mixed/master ^refs/heads/users/hjl/pr21884 ^refs/heads/users/hjl/linux/master ^refs/heads/users/ccoutant/two-level-line-tables ^refs/heads/users/palves/line_header_leak ^refs/heads/users/qiyao/target-desc-2 ^refs/heads/users/qiyao/target-desc-3 ^refs/heads/users/ARM/sve ^refs/heads/users/hjl/pr20276 ^refs/heads/users/palves/cxx-enum-flags ^refs/heads/users/hjl/pr17878 ^refs/heads/users/ppalka/readline-7.0-update ^refs/heads/users/hjl/cet/master ^refs/heads/users/palves/amd64-tdesc ^refs/heads/users/bheckel/fortran-entry-point-nested-subroutines ^refs/heads/users/hjl/pr19818 ^refs/heads/users/palves/Wwrite-strings-v1.5 ^refs/heads/users/hjl/gpoff ^refs/heads/users/ppalka/readline-6.3-update ^refs/heads/users/hjl/sharable ^refs/heads/users/palves/fix-objc-tests ^refs/heads/users/hjl/property ^refs/heads/users/keiths/intelligent-breakpoint_re_set ^refs/heads/users/mwk/s390-relro ^refs/heads/users/hjl/tls ^refs/heads/users/hjl/gdb-8.0-branch ^refs/heads/users/hjl/binutils-2_25-branch ^refs/heads/users/palves/gdbserver-extract-unsigned-integer ^refs/heads/users/pmuldoon/c++compile ^refs/heads/users/ARM/embedded-binutils-2_26-branch ^refs/heads/users/gentoo/2.27 ^refs/heads/users/gentoo/2.28 ^refs/heads/users/hjl/relax-plt ^refs/heads/users/hjl/pr21964 ^refs/heads/users/hjl/pr21562 ^refs/heads/users/dje/google-7.10 ^refs/heads/users/palves/cxx-breakpoint-improvements ^refs/heads/users/keiths/c++compile-submit ^refs/heads/users/hjl/mmap/write ^refs/heads/users/palves/fix-var-update-for-registers ^refs/heads/users/hjl/cache ^refs/heads/users/ccoutant/gold-record ^refs/heads/users/hjl/relocs ^refs/heads/users/mmetzger/record-goto-mi ^refs/heads/users/palves/cxx-dwarf2read ^refs/heads/users/hjl/indbr ^refs/heads/users/palves/interrupt-while-step-over ^refs/heads/users/hjl/old-lto-mixed ^refs/heads/users/hjl/pr19827/binutils-2_26-branch ^refs/heads/users/hjl/pr19553/binutils-2_26-branch ^refs/heads/users/hjl/pr21903 ^refs/heads/users/hjl/linux/track ^refs/heads/users/palves/function_view ^refs/heads/users/hjl/linux/applied ^refs/heads/users/hjl/mpx/master ^refs/heads/users/palves/cp-linespec-for-keiths ^refs/heads/users/hjl/pr20882 ^refs/heads/users/bheckel/fortran-strides ^refs/heads/users/hjl/plt ^refs/heads/users/pkoning/multi-target ^329d5e7e56f852dcf9956683be4345c165d277db' returned non-zero exit status 128
remote: error: hook declined to update refs/heads/master
To ssh://palves@sourceware.org/git/binutils-gdb.git
 ! [remote rejected] HEAD -> master (hook declined)
error: failed to push some refs to 'ssh://palves@sourceware.org/git/binutils-gdb.git'

Thanks,
Pedro Alves

Re: can't push to binutils-gdb, git-hooks rejecting commits

[Joel Brobecker]

Hi Pedro,

> I'm trying to push a patch to master, but it's getting rejected by the
> server-side git hooks.  Anyone else seeing the same?  See below.
> 
> Repeating that big "git rev-list" command below locally shows:
> 
>   fatal: bad revision '^refs/heads/users/hjl/pr17709'
> 
> That branch doesn't appear to exist anymore.   Sounds like the hooks
> need to run "git remote prune origin" on their clone?  Does that make
> sense?

For me, I get a different error message, but in the same vein:

    fatal: bad revision '^refs/heads/users/hjl/gpoff'

I think it's related to the disk corruption. If the branch stopped
existing, git should have removed the associated reference.

I would try a "git fsck" to see if it detects any other kinds of
issues, and decide how to fix them. For instance, we could delete
those branches, and ask HJL to re-push.

I don't think the "git remote prune" command was meant for
that (I think it'll prune references from refs/remotes/ instead).

I can look into this, but as I traveling, availability on my side
is a little spotty.

-- 
Joel

Re: can't push to binutils-gdb, git-hooks rejecting commits

[Pedro Alves]

Hi Joel,

On 08/22/2017 04:05 PM, Joel Brobecker wrote:

> For me, I get a different error message, but in the same vein:
> 
>     fatal: bad revision '^refs/heads/users/hjl/gpoff'
> 
> I think it's related to the disk corruption. If the branch stopped
> existing, git should have removed the associated reference.
> 
> I would try a "git fsck" to see if it detects any other kinds of
> issues, and decide how to fix them. For instance, we could delete
> those branches, and ask HJL to re-push.
> 
> I don't think the "git remote prune" command was meant for
> that (I think it'll prune references from refs/remotes/ instead).
> 
> I can look into this, but as I traveling, availability on my side
> is a little spotty.

I don't have sourceware.org shell access, so it'll have
to be someone other than me, I'm afraid.  Any takers?

Thanks,
Pedro Alves

Re: can't push to binutils-gdb, git-hooks rejecting commits

[H.J. Lu]

On Tue, Aug 22, 2017 at 8:05 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hi Pedro,
>
>> I'm trying to push a patch to master, but it's getting rejected by the
>> server-side git hooks.  Anyone else seeing the same?  See below.
>>
>> Repeating that big "git rev-list" command below locally shows:
>>
>>   fatal: bad revision '^refs/heads/users/hjl/pr17709'
>>
>> That branch doesn't appear to exist anymore.   Sounds like the hooks
>> need to run "git remote prune origin" on their clone?  Does that make
>> sense?
>
> For me, I get a different error message, but in the same vein:
>
>     fatal: bad revision '^refs/heads/users/hjl/gpoff'
>
> I think it's related to the disk corruption. If the branch stopped
> existing, git should have removed the associated reference.
>

I deleted the old users/hjl/gpoff and pushed a new one.


-- 
H.J.

Re: can't push to binutils-gdb, git-hooks rejecting commits

[Pedro Alves]

On 08/22/2017 04:22 PM, H.J. Lu wrote:
> On Tue, Aug 22, 2017 at 8:05 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Hi Pedro,
>>
>>> I'm trying to push a patch to master, but it's getting rejected by the
>>> server-side git hooks.  Anyone else seeing the same?  See below.
>>>
>>> Repeating that big "git rev-list" command below locally shows:
>>>
>>>   fatal: bad revision '^refs/heads/users/hjl/pr17709'
>>>
>>> That branch doesn't appear to exist anymore.   Sounds like the hooks
>>> need to run "git remote prune origin" on their clone?  Does that make
>>> sense?
>>
>> For me, I get a different error message, but in the same vein:
>>
>>     fatal: bad revision '^refs/heads/users/hjl/gpoff'
>>
>> I think it's related to the disk corruption. If the branch stopped
>> existing, git should have removed the associated reference.
>>
> 
> I deleted the old users/hjl/gpoff and pushed a new one.

Eh, that worked, thanks.  I managed to push to master now.
I had thought of trying something like that, but assumed that
the hooks would reject pushing that too.

Funny that you didn't need to create users/hjl/pr17709.

Might still be a good idea to run "git fsck" on the server,
though.

Thanks,
Pedro Alves

Re: can't push to binutils-gdb, git-hooks rejecting commits

[Andreas Schwab]

On Aug 22 2017, Pedro Alves <palves@redhat.com> wrote:

> Repeating that big "git rev-list" command below locally shows:
>
>   fatal: bad revision '^refs/heads/users/hjl/pr17709'

You need to translate all refs to your remote-tracking branches inside
origin (eg. refs/remotes/origin/users/hjl/pr17709), or run that command
inside a bare mirror.  Doing that results in no error, execpt that the
first rev does not exist for me, but that is probably the rev you are
about to push.

> That branch doesn't appear to exist anymore.   Sounds like the hooks
> need to run "git remote prune origin" on their clone?  Does that make
> sense?

The hook is running directly inside the bare repository, there is no
remote.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: can't push to binutils-gdb, git-hooks rejecting commits

[H.J. Lu]

On Tue, Aug 22, 2017 at 8:28 AM, Pedro Alves <palves@redhat.com> wrote:
> On 08/22/2017 04:22 PM, H.J. Lu wrote:
>> On Tue, Aug 22, 2017 at 8:05 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>>> Hi Pedro,
>>>
>>>> I'm trying to push a patch to master, but it's getting rejected by the
>>>> server-side git hooks.  Anyone else seeing the same?  See below.
>>>>
>>>> Repeating that big "git rev-list" command below locally shows:
>>>>
>>>>   fatal: bad revision '^refs/heads/users/hjl/pr17709'
>>>>
>>>> That branch doesn't appear to exist anymore.   Sounds like the hooks
>>>> need to run "git remote prune origin" on their clone?  Does that make
>>>> sense?
>>>
>>> For me, I get a different error message, but in the same vein:
>>>
>>>     fatal: bad revision '^refs/heads/users/hjl/gpoff'
>>>
>>> I think it's related to the disk corruption. If the branch stopped
>>> existing, git should have removed the associated reference.
>>>
>>
>> I deleted the old users/hjl/gpoff and pushed a new one.
>
> Eh, that worked, thanks.  I managed to push to master now.
> I had thought of trying something like that, but assumed that
> the hooks would reject pushing that too.
>
> Funny that you didn't need to create users/hjl/pr17709.
>

I removed users/hjl/pr17709.


-- 
H.J.

Re: can't push to binutils-gdb, git-hooks rejecting commits

[Joel Brobecker]

> > I can look into this, but as I traveling, availability on my side
> > is a little spotty.
> 
> I don't have sourceware.org shell access, so it'll have
> to be someone other than me, I'm afraid.  Any takers?

I'm running it now... I'll let everyone know if anything turns up
(just letting everyone know to avoid multiple people repeating
the same effort).

-- 
Joel

Re: can't push to binutils-gdb, git-hooks rejecting commits

[Joel Brobecker]

> I'm running it now... I'll let everyone know if anything turns up
> (just letting everyone know to avoid multiple people repeating
> the same effort).

The first run of "git fsck" reported a number of dangling
commits, which can be normal:

     /git/binutils-gdb.git % git fsck
     dangling commit b376a372a6a884258517ca0e4074c44497b52e2d
     dangling commit e0b06424ffba39b97c5bcf75c1d56d1da39a1d76
     dangling commit b325e68abacbefa85b3a9ed928e9d989f150a9a9
     dangling commit 9b4ac9ab75b1941fd3f340240c56bf4f6a73816e
     dangling commit 2f8c2964d70f6fb0a0223d82dafdcaf5c60736a6
     dangling commit dc044a14027136c864d69c83598f3ba37c44fc9c
     dangling commit 70700c92be133d5b144a34c3a3bc11401bc746f4
     dangling commit b97c8e894e84f67560cc520e3b2c95e44fca5591
     dangling commit 9dd2eee60fd96cce402319a03d4d41a9cb781ae6
     dangling commit 471a2f625914dda90a3188e7adc871ce8ab68021
     dangling commit 3575703e8e24fd37d59452a567a74faca7a7f099
     dangling commit 5ce8d065bc9f0fe02c0fe2ad1ab321a145a6f3b8
     dangling commit 028e31e41c75a03a9a4a4f32d8659c7253e541d8
     dangling commit 9bc99112bf8baa35080b89f76f7594fe5f578d47
     dangling commit 4d2b345dd00dc2d681ab65733b79edcaaf118201
     dangling commit 4edbf4492560418a8981389f2a121f5d413c2956
     dangling commit 3730b7a6c6b490386b6bb35bcfbb64692e056059
     dangling commit 910dd8d20edfab20b589f0844d1ba167df3886a5
     dangling commit bf2cd8bd1bf0ce196a2e22bafa83eb5a2e918e68
     dangling commit 5a2659aecf698e7ec457e198139b0ae55cd24d4c
     dangling commit 7695993f6c0b379f69c955c93ddacc0a32fa3531
     dangling commit 48283a3eb56bfba30c5430d31a22d9ab60f02367
     dangling commit 4563fa4ef6449402b2c01f0a3e847004e48f9e6c
     dangling commit 57db1a42615d23e5dd4892e50baeb8e50de7b35f
     dangling commit 3bdf1a7669b5ac083d21ebb6269010c970e00511
     dangling commit 80d27d03fd16f97f709ce37e20607f09624b633d
     dangling commit 1104df157fa02eab8d0688f2870183e787b98b7e
     dangling commit 7e7dffec482bba8fad3f963bfd0c9bfbb5873c74

I did a quick "git gc"...

     /git/binutils-gdb.git % git gc
     Counting objects: 914618, done.
     Delta compression using up to 16 threads.
     Compressing objects: 100% (143171/143171), done.
     Writing objects: 100% (914618/914618), done.
     Total 914618 (delta 760464), reused 913469 (delta 759471)

... which took care of a number of them, but (as expected)
still kept around the more recent commits:

     /git/binutils-gdb.git % git fsck
     dangling commit b325e68abacbefa85b3a9ed928e9d989f150a9a9
     dangling commit 9b4ac9ab75b1941fd3f340240c56bf4f6a73816e
     dangling commit 70700c92be133d5b144a34c3a3bc11401bc746f4
     dangling commit 3575703e8e24fd37d59452a567a74faca7a7f099
     dangling commit 028e31e41c75a03a9a4a4f32d8659c7253e541d8
     dangling commit 5a2659aecf698e7ec457e198139b0ae55cd24d4c
     dangling commit 7695993f6c0b379f69c955c93ddacc0a32fa3531
     dangling commit 48283a3eb56bfba30c5430d31a22d9ab60f02367
     dangling commit 3bdf1a7669b5ac083d21ebb6269010c970e00511
     dangling commit 7e7dffec482bba8fad3f963bfd0c9bfbb5873c74

In any case, looks like all references are now OK, and "git fsck"
did not detect any further issues in the repository.

-- 
Joel

Re: can't push to binutils-gdb, git-hooks rejecting commits

[Pedro Alves]

On 08/22/2017 08:32 PM, Joel Brobecker wrote:

> In any case, looks like all references are now OK, and "git fsck"
> did not detect any further issues in the repository.

Phew, thanks much for doing that!

-- 
Pedro Alves

Re: can't push to binutils-gdb, git-hooks rejecting commits

[Joseph Myers]

One file corrupted in the disk corruption was the packed-refs file for 
binutils-gdb.  It was restored from backup, but it's possible the 
resulting refs might either have conflicted with unpacked refs in the refs 
directory (perhaps someone should check for such conflicts), or have been 
out of date compared to the tips of those branches at the time of the disk 
corruption.

I don't know if that's how refs got into a problem state rejecting pushes, 
but it's at least plausible.

-- 
Joseph S. Myers
joseph@codesourcery.com