Git error: Tidak dapat menambahkan .git / logs / refs / remote / origin / master: Izin ditolak

87

Saya mengalami masalah aneh yang sepertinya tidak dapat saya selesaikan. Inilah yang terjadi:

Saya memiliki beberapa file log di repositori github yang tidak saya inginkan di sana. Saya menemukan skrip ini yang menghapus file sepenuhnya dari riwayat git seperti:

    #!/bin/bash
set -o errexit

# Author: David Underhill
# Script to permanently delete files/folders from your git repository.  To use 
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2

if [ $# -eq 0 ]; then
    exit 0are still
fi

# make sure we're at the root of git repo
if [ ! -d .git ]; then
    echo "Error: must run this script from the root of a git repository"
    exit 1
fi

# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD

# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

Saya, tentu saja, membuat backup terlebih dahulu dan kemudian mencobanya. Sepertinya bekerja dengan baik. Saya kemudian melakukan git push -f dan disambut dengan pesan berikut:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.

Semuanya tampaknya telah didorong dengan baik, karena file-file tersebut tampaknya hilang dari repositori GitHub, jika saya mencoba dan mendorong lagi saya mendapatkan hal yang sama:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.
Everything up-to-date

EDIT

$ sudo chgrp {user} .git/logs/refs/remotes/origin/master
$ sudo chown {user} .git/logs/refs/remotes/origin/master
$ git push
Everything up-to-date

Terima kasih!

EDIT

Uh oh. Masalah. Saya telah mengerjakan proyek ini sepanjang malam dan baru saja melakukan perubahan saya:

error: Unable to append to .git/logs/refs/heads/master: Permission denied
fatal: cannot update HEAD ref

Jadi saya:

sudo chown {user} .git/logs/refs/heads/master
sudo chgrp {user} .git/logs/refs/heads/master

Saya mencoba komit lagi dan saya mendapatkan:

error: Unable to append to .git/logs/HEAD: Permission denied
fatal: cannot update HEAD ref

Jadi saya:

sudo chown {user} .git/logs/HEAD
sudo chgrp {user} .git/logs/HEAD

Dan kemudian saya mencoba komit lagi:

16 files changed, 499 insertions(+), 284 deletions(-)
create mode 100644 logs/DBerrors.xsl
delete mode 100644 logs/emptyPHPerrors.php
create mode 100644 logs/trimXMLerrors.php
rewrite public/codeCore/Classes/php/DatabaseConnection.php (77%)
create mode 100644 public/codeSite/php/init.php
$ git push
Counting objects: 49, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (27/27), done.
Writing objects: 100% (27/27), 7.72 KiB, done.
Total 27 (delta 15), reused 0 (delta 0)
To [email protected]:IAmCorbin/MooKit.git
59da24e..68b6397  master -> master

Hore. Saya membuka http://GitHub.com dan memeriksa repositori, dan komit terbaru saya tidak ada di mana bisa ditemukan. :: garuk kepala :: Jadi saya dorong lagi:

Everything up-to-date

Umm ... tidak terlihat seperti itu. Saya belum pernah mengalami masalah ini sebelumnya, mungkinkah ini masalah dengan github? atau apakah saya mengacaukan sesuatu dengan proyek git saya?

EDIT

Tidak masalah, saya melakukan yang sederhana:

git push origin master

dan itu mendorong dengan baik.

Corbin Tarrant
sumber

Jawaban:

219

Sepertinya Anda menjalankan git sebagai root secara lokal, sehingga mengubah kepemilikan pada beberapa file yang melacak lokasi origincabang.

Perbaiki kepemilikan file, dan Anda akan baik-baik saja:

# run this from the root of the git working tree
sudo chown -R "${USER:-$(id -un)}" .
Charles Duffy
sumber
1
Perintah itu berhasil untuk saya. Saya menjalankannya dari root klon. Terima kasih @CharlesDuffy!
ariestav
4
@ Tn. Stranger, hanya jika Anda memiliki nilai IFS dan nama pengguna yang wajar (nama pengguna dengan spasi dapat terjadi, misalnya di cygwin). Lebih aman untuk mengutip:, sudo chown -R "$USER" .dan tidak mengasumsikan kewarasan. :)
Charles Duffy
@ Mr.Stranger, ... juga, USERtidak dijamin oleh pubs.opengroup.org/onlinepubs/009695399/utilities/… , jadi mungkin lebih aman untuk digunakan "$(id -un)".
Charles Duffy
Ia mengatakan pengguna saya is not in the sudoers file. This incident will be reported.- ada tip tentang apa yang dapat saya lakukan? Terima kasih.
giovannipds
1
Sintaks di atas adalah perluasan parameter ; "${var:-default}"meluas ke nilai variabel "$var", kecuali nilai itu kosong atau tidak disetel, dalam hal ini ditetapkan ke default. Jadi, kami memperluas ke "$USER", atau keluaran yang dihasilkan dengan menjalankan id -un.
Charles Duffy
4

Mari kita berkonsentrasi pada apa yang sebenarnya dikeluhkan:

Kesalahan izin ditolak: Tidak dapat memperbarui ref 'refs / remote / origin / master'.

Sebelum melakukan perubahan mod / kepemilikan rekursif, lewati jalan Anda ke file itu dan perbaiki izin yang salah.

Saya rasa saya menyebabkan masalah ini dengan membuat cabang saat saya root dan kemudian mencoba mengacaukan cabang itu sebagai pengguna saya.

Andrew E
sumber
3
Apakah memperbaiki file yang dimiliki oleh orang lain selain pengguna diharapkan untuk memiliki seluruh struktur pohon sumber satu per satu benar-benar merupakan peningkatan?
Charles Duffy
2

Dalam kasus saya, saya membuat file dengan izin root secara lokal dan mencoba mendorong kode ke jarak jauh dengan izin lokal. Jadi saya menjalankan perintah ini

$find . -user root

untuk mengetahui semua file yang memiliki "root" sebagai pemilik. Dan kemudian saya mengubah pemilik untuk semua file yang berada di bawah root ke lokal menggunakan perintah berikut

$sudo chown parineethat `find . -user root`

Kemudian saya bisa mendorong kode saya dari lokal ke jarak jauh.

Parineetha
sumber
sudo chown parineethat `find . -user root` tidak dapat diandalkan - tidak akan berfungsi dengan baik dengan nama file dengan spasi. Sebaliknya sudo find . -user root -exec chown parineethat {} +,. Lihat BashPitfalls # 1 untuk diskusi yang relevan.
Charles Duffy
1

Ini akan mengubah semua file dan direktori .git Anda secara rekursif (dari root menjadi 1000) dan memberi Anda daftar lengkap dari semua perubahan yang dibuat di terminal.

sudo chown -Rc $ UID .git /

Donald L Wilson
sumber
0

Saya sudah mencoba memperbaiki kepemilikan untuk Git, tetapi tetap tidak berhasil.

Tapi, saya berhasil memperbaikinya dengan membuat cabang lokal dengan nama yang berbeda dan menghapusnya.

Kemudian, saya memeriksa nama cabang yang sama lagi dan berhasil.

TLDR;

Saya tidak dapat memeriksa `staging / rc '.

Jadi, saya melakukan checkout dengan menggunakan stagingremote yang mengarah ke `staging / rc '.

Dan, saya menghapusnya dan melakukan pembayaran lagi. Tapi, kali ini saya gunakan staging/rcsebagai nama cabang lokal saya.

Ini berhasil dan saya tidak tahu mengapa.

Morgan Koh
sumber
-16

Mohon terlebih dahulu berikan izin dari rootakun seperti di bawah ini

chmod -R 777 foldername

setelah itu jalankan perintah komit

Viru
sumber
7
Ini sangat berbahaya - ini memberikan akun apa pun di sistem, termasuk daemon yang disusupi dengan hanya hak istimewa "tidak ada", akses tulis ke file Anda. Daemon sistem menggunakan "tidak ada" (atau akun tidak berhak lainnya) untuk komponen sensitif keamanan karena akun siapa pun seharusnya tidak dapat melakukan sesuatu yang terlalu berisiko bahkan jika akun itu disusupi. Dengan mengizinkan semua pengguna, bahkan tidak seorang pun, memiliki akses tulis ke file Anda, Anda membuat tindakan keamanan penting menjadi tidak berguna.
Charles Duffy
1
Jika karena alasan tertentu Anda ingin file Anda dimiliki oleh root dan dapat ditulis oleh pengguna non-root tertentu, cara aman untuk melakukannya (pada sistem di mana setiap pengguna memiliki grup mereka sendiri, seperti praktik standar) adalah dengan chown -R root:user directory, dan lalu chmod -R 775 directory(atau 770, jika akun lain juga tidak memerlukan akses baca).
Charles Duffy
1
@JasonGlisson, sesuatu yang "berfungsi" hanya dengan membuat lubang keamanan besar-besaran mungkin adalah sesuatu yang lebih baik jika tetap rusak.
Charles Duffy
1
@JasonGlisson, sejauh kami memberikan nasihat baik sebagai dan kepada komunitas, sebagai anggota komunitas itu, jenis dan kualitas nasihat yang kami berikan adalah bisnis saya seperti halnya orang lain - dan, sebagai seseorang yang bekerja di bidang keamanan , Saya memiliki posisi yang tepat untuk mengomentari subjek. Lihat komentar awal, re: dampak.
Charles Duffy
1
@JasonGlisson, ... mengenai mengapa saran saya tidak berhasil untuk Anda, saya perlu melihat detailnya - log dari perintah yang dijalankan, secara berurutan, dengan prompt yang menampilkan direktori kerja saat ini sebelum masing-masing; teks dari setiap kesalahan yang muncul; dll - untuk memberi komentar; tetapi tempat untuk diskusi itu akan dilampirkan pada jawaban yang Anda laporkan hasil buruknya, bukan di sini.
Charles Duffy