how to list the files for the next git push command -
i trying push branch origin
git push --set-upstream origin v0.8 this seems take forever , stops error
counting objects: 180, done. delta compression using 4 threads. compressing objects: 100% (92/92), done. writing objects: 100% (180/180), 538.00 mib | 72.00 kib/s, done. total 180 (delta 142), reused 110 (delta 87) remote: error: gh001: large files detected. may want try git large file storage - https://git-lfs.github.com. remote: error: trace: eef60ca4521006cb11e4b7f181bc7a1a remote: error: see http://git.io/iept8g more information. remote: error: file x.sql 1537.98 mb; exceeds github's file size limit of 100.00 mb https://github.com/x/x.git ! [remote rejected] v0.8 -> v0.8 (pre-receive hook declined) error: failed push refs 'https://github.com/x/x.git' so apparently tries push file 1.5gb named x.sql...? can't see file anywhere? had @ log
git log v0.8 --not --remotes=origin which gave
commit 046332334e1f944f64a110f92434cdc26e9fafd0 author: x date: thu jun 9 23:47:27 2016 +0100 search branch pushed remote commit 4b6d7c87a34bcd43f098d54263a032bb66baf9db merge: 631d55a 539e3dc author: x date: sun jun 5 22:10:28 2016 +0100 merge branch 'master' of https://github.com/x commit 631d55a0998e99ebc7614bf4f58b85baa4e85403 author: x date: sun jun 5 22:10:15 2016 +0100 once commit 4aa7275f4381c222fff7ba9ae22ab00df886ba3b author: fbeutler x date: sun jun 5 22:09:27 2016 +0100 once how can see files connected commit? check 1 has large file? answers below saw committed large file , deleted it. in case git rebase way remove it. however, rebase not work if there no upstream branch? here output rebase
git rebase -i there no tracking information current branch. please specify branch want rebase against. see git-rebase(1) details git rebase <branch> if wish set tracking information branch can with: git branch --set-upstream-to=origin/<branch> v0.8 if follow advise get
git branch --set-upstream-to=origin/v0.8 v0.8 error: requested upstream branch 'origin/v0.8' not exist hint: hint: if planning on basing work on upstream hint: branch exists @ remote, may need hint: run "git fetch" retrieve it. hint: hint: if planning push out new local branch hint: track remote counterpart, may want use hint: "git push -u" set upstream config push. my problem solved deleting current commits , re-committing , pushing current version... possible?
edit: here output
git log --graph --decorate --oneline --all * 408ef30 (master) h |\ | * 7d4ecd3 (origin/master, origin/head) new every | * c63f869 every bug | * a60a14a querydate bug fixed | * 957a6d3 problem in every | * 602891c problem in every | * 9e827d2 problem in every | | * 0463323 (head -> v0.8, test) branch pushed remote | |/ |/| * | 4b6d7c8 merge branch 'master' of https://github.com/x/x |\ \ | |/ | * 539e3dc pagedown removed, bibtex bug resolved * | 631d55a once * | 4aa7275 once |/
edit: have git log --graph --decorate --oneline --all output it's easier see what's going on , make suggestions.
the easy way: bfg repo cleaner
there's java based tool work below you. have never used myself, has own tag here on stackoverflow.
the harder way: git filter-branch
since know name of file, can use git filter-branch of steps below in automated fashion. use index filter git rm --cached --ignore-unmatch path/to/x.sql, , filter of master, test, , v0.8 branches. in general, should use filter-branch once know doing, , can follow steps below.
the hard way: lot filter-branch do, manually
this has gotten quite long, , quoting here going make longer still, think clearer way, here go. :-)
the actual graph looks this:
* 408ef30 (master) h |\ | * 7d4ecd3 (origin/master, origin/head) new every | * c63f869 every bug | * a60a14a querydate bug fixed | * 957a6d3 problem in every | * 602891c problem in every | * 9e827d2 problem in every | | * 0463323 (head -> v0.8, test) branch pushed remote | |/ |/| * | 4b6d7c8 merge branch 'master' of https://github.com/x/x |\ \ | |/ | * 539e3dc pagedown removed, bibtex bug resolved * | 631d55a once * | 4aa7275 once |/ we can see v0.8 branch (not tag: useful know makes no difference in terms of pushing, in terms of when fixing things). particular branch points commit 0463323. there's branch name, test, points same commit.
the parent of 0463323 4b6d7c8 merge branch 'master' of .... because 4b6d7c8 is merge, has two parents. 2 parent commits 539e3dc pagedown removed, bibtex bug resolved , 631d55a once.
commit 539e3dc on origin/master , hence on github. cannot possibly have large file in question, nor can of parent commits (which on github). commit 631d55a, however, not on github, nor parent commit 4aa7275. there's 1 row further down missing can see |/ line commit 4aa7275 , commit 539e3dc must have histories join @ whatever commit goes there.
we still cannot tell sure big file has crept in, nor subsequently removed, start 4 possibilities:
0463323 branch pushed remote(which, despite name, not pushed; it's failed-to-push)4b6d7c8 merge branch 'master' of ...631d55a once4aa7275 once
(these 4 in git log v0.8 --not --remotes=origin output).
the reasoning in original answer still valid. big file cannot in topmost commit (the 1 pointed-to branch name v0.8), because see big file there. cannot in commit's parent either, because if were, see file being deleted when @ top-most commit, , don't.
that leaves commits 631d55a once , 4aa7275 once remaining potential culprits. @ least 1 of these commits, , possibly both, has big file not want.
we can fix this, but...
starting v0.8 , following chain down (back through history) found these 4 candidate commits. however, take @ top of graph, commit labeled master (408ef30 h) resides. commit also merge commit, 2 parents. 1 parent 7d4ecd3 new every, labeled origin/master. other parent 4b6d7c8 merge branch 'master' of ....
this merge commit 4b6d7c8 connects pagedown removed commit fine , on origin/master, recent of 2 once commits suspect bad.
what means in order clear up, need to:
- find of 2
oncecommits bad (it may both of them); no longer want these. - write @ least 1 new commit do want, has parent, parent of
4aa7275 once: commit not shown off bottom of graph.
there multiple ways go this, here 1 think simplest. i'm assuming there good in 2 once commits, , do want merge after these 2 commits, , do want create branch called v0.8 subsequent merge, , do want master merge commit atop of new chain, including intermediate merge commit, merges origin/master new chain.
if these assumptions wrong, is not want (nor filter-branch or bfg cleaner "easy" methods want). beyond scope of answer.
in case, before take steps, work tree should clean (git status should show nothing commit, , should not have modified files can staged commit). if have in-progress work, need commit or stash (this commit or stash can added on "repair" branch later if desired). i'll assume, though, work tree clean.
making new "repaired" branch
the first step new branch, in we'll right things. new branch should branch off parent commit of 4aa7275 once, parent commit of 539e3dc pagedown removed, bibtex bug resolved. if had actual id of particular commit use here, don't. instead, can use ^ or ~ suffix syntax gitrevisions:
git checkout -b repairwork 539e3dc~1 this creates new branch named repairwork pointing parent commit off bottom of our graph.
next, want take parts of 4aa7275, without taking bad parts:
git cherry-pick -n 4aa7275 the -n (which can spell out --no-commit) tells git cherry-pick extract changes 4aa7275, not commit them yet. git status show changes staged commit.
let's say, simplicity, commit cherry-picked 1 adds large file don't want. have remove it: git rm hugefile, instance. or, perhaps commit 631d55a once commit removes it, , you'd squash whatever other changes in new commit. in case, instead of git rm hugefile can git cherry-pick -n, time 631d55a.
let's say, simplicity again, while 631d55a removes big file, contains additional change you'd keep separate, i.e., want still have 2 commits. in case should git rm huge file, git commit result, , git cherry-pick 631d55a (without -n / --no-commit: since not add huge file it's ok commit now).
let's draw have far:
* xxxxxxx (head -> repairwork) once * xxxxxxx once | | * 408ef30 (master) h | |\ | | * 7d4ecd3 (origin/master, origin/head) new every | | * c63f869 every bug | | * a60a14a querydate bug fixed | | * 957a6d3 problem in every | | * 602891c problem in every | | * 9e827d2 problem in every | | | * 0463323 (v0.8, test) branch pushed remote | | |/ | |/| | * | 4b6d7c8 merge branch 'master' of https://github.com/x/x | |\ \ | | |/ | | * 539e3dc pagedown removed, bibtex bug resolved | * | 631d55a once | * | 4aa7275 once | |/ |// * xxxxxxx commit msg note here adds new commits repository. git the borg star trek, in every time anything, add collective. doing here adding new commits strongly resemble originals, except huge file no longer included.
now have 2 once commits—or, if makes more sense, have squashed 2 once commits down single once commit—that (or is) similar omit(s) giant file, can redo merge branch 'master' of ... step, i.e., copy commit 4b6d7c8.
unfortunately, there no way copy merge directly. easiest thing re-perform merge. we're on new commit on repairwork can run git merge 539e3dc. merge our new once commit(s) 539e3dc pagedown removed, bibtex bug resolved in same way did before, when ran git merge create 4b6d7c8. when merge done , have opportunity edit merge commit message, can put in whatever message want, may same "merge branch 'master' ..." thing, or can write our own more-meaningful message, such "re-merge without huge file".
let's draw part of result:
* xxxxxxx (head -> repairwork) "re-merge without huge file" |\ * | xxxxxxx once * | xxxxxxx once we're @ point can create corrected v0.8 branch.
all have git checkout -b v0.8-fixed (it needs different name, v0.8 in use) , git cherry-pick v0.8 or git cherry-pick 0463323. either cherry-pick command same thing: we're resolving name, v0.8, target commit. once we've finished cherry-pick, done old, broken v0.8, can rename , rename our corrected 1 v0.8:
git checkout -b v0.8-fixed # make new branch git cherry-pick v0.8 # copy 1 commit git branch -m v0.8 v0.8-broken # rename broken branch git branch -m v0.8 # rename our branch if git log --graph --decorate --oneline --all now, starts this:
* xxxxxxx (head -> v0.8) branch pushed remote * xxxxxxx (repairwork) "re-merge without huge file" |\ * | xxxxxxx once * | xxxxxxx once it should possible push v0.8 remote. still has 4 commits transfer, none of these four have huge file.
we can delete old test branch (git branch -d test) , make test point current commit (git branch test).
note huge file is still in our repository:
it's under
v0.8-broken, has chain of 4 commits, @ least 1 of has huge file.we can forcibly delete
v0.8-brokenonce we're sure done it, i.e., once "fixed"v0.8pushed , looks everyone.it's also underneath
master, though, have not yet repairedmaster: 1 ofmaster's parents4b6d7c8 merge branch 'master' of https://github.com/x/x, particular commit has631d55a once1 of parents, ,631d55aand/or4aa7275have huge file.
we can repair master same process, namely making new "good" or "repair" branches, copying commits and/or re-doing merges. making new branch lose current master upstream setting (though that's fixed well). there shortcut repairing master though, due fact there 1 merge re-do. can onto master, hard-reset commit, re-do merge:
git checkout master git reset --hard <some commit> git merge <another commit> when we have our choice of commit hard-reset-to, , 1 merge. merge result has, first parent, commit hard-reset-to. second parent whatever commit name in git merge command.
in original sequence, first parent other merge, , second origin/master. may want, although has been nicknamed "foxtrot merge" , wrong way around. (it's using git pull, , git pull wrong thing do, reasons described in other question , links.)
(original answer below line.)
as noted in comment on other question, git push works identifying commits have in common remote you're pushing to, , commits have don't.1 in case remote named origin. cannot tell commits , have in common, , ones have don't, this:
git push --set-upstream origin v0.8
but can. we'll in moment. first, here's same background information in comment made, in more detail.
your git push command needs send commit (or annotated tag object) v0.8 resolves (i guessing 046332334e1f944f64a110f92434cdc26e9fafd0 showing, although have not shown how got particular id). git push sends commit, plus whatever other commits, trees, , blobs needed, , asks git set branch or tag (it's not obvious 1 is) named v0.8 point commit id. , in sync, @ least respect v0.8.
somewhere associated set of commits git push, there git tree large file (or blob) object. commit have pin down , about.
here example of how such thing comes about. suppose, instance, start in sync upstream repository. add, on existing or new branch, new commit, doing this:
git add . && git commit -m 'add stuff' in "stuff" enormous file. whoops, well, can remove , commit again, right?
git rm bigfile && git commit -m 'rm 1.5 gb file' if tried push @ point, push fail, because (the remote, in case github) have set detect , reject large files. we'll pushing 2 commits: 1 adds bigfile , second 1 deletes it. means have push big file itself, takes forever because data rate limited (approximately 500 mib @ approximately 72 kib/s = 7111 seconds = 118.5 minutes = 2 hours).
apparently it's not particular point, though, because if were, assuming git diff-tree argument correct, we'd see removal of big file in diff-tree output. however, if don't push yet, instead go on add still more commits, , then push, still have push enormous file: it's in 1 of commits, , have push all of them: commit valid if id matches hash of of contents, , commit's contents include ids of parent commits, include parents, , on, way beginning of time.2 repository must have of intermediate commits in order have final commits.3
the trick, then, find commit(s) refer big file. can because have big file.
how find commit(s)
here how list commits git push. start running git fetch origin update repository if needed—it's not needed, it's worth doing anyway—and run command:
git log v0.8 --not --remotes=origin (this not quite perfect, ignores tags on origin, @ worst list many commits, not few).
the idea here simple: remote-tracking branches record every commit have on every branch have. (this why ran git fetch, information updated.) have commit(s) on v0.8 not. use v0.8 select every commit is on v0.8, add --not --remotes=origin de-select every commit on origin/* remote-tracking branch. (this error creeps in: should exclude commits have on tags have, cannot tell tags they have, @ point. if git kept "remote tags", instead of stuffing them single namespace, fix here.)
whatever left, commit have push, can git log those. add -m -p --name-status name-and-status diff of every commit (including pesky merge commits, git log skips diff-ing; -m flag).
we have more information, though, it's don't need that. let's take @ git , github's git talked through:
counting objects: 180, done.
from this, know after git , git had conversation determine commits, trees, blobs, , annotated-tag objects had, didn't, git have send, git had 180 such objects.
delta compression using 4 threads. compressing objects: 100% (92/92), done.
your git able compress 92 of objects against objects git knows git has, or against objects git sending, virtue of fact if git has commit, has every tree , blob go commit, and every commit, tree, , blob in all of history of commit, beginning of time. (see footnote 2 again.)
writing objects: 100% (180/180), 538.00 mib | 72.00 kib/s, done. total 180 (delta 142), reused 110 (delta 87)
all 180 objects made across. i'm not sure off-hand additional numbers mean (just come git pack-objects --fix-thin).
remote: error: gh001: large files detected. may want try ... remote: error: trace: eef60ca4521006cb11e4b7f181bc7a1a remote: error: see http://git.io/iept8g more information. remote: error: file x.sql 1537.98 mb; exceeds ...
all of these messages prefixed remote: come scripts git runs. 1 of things github (obviously) scan incoming commits large files. found 1 such, x.sql @ 1.5 gb (which compressed 1/3 of size since git had send mere 0.5 gb :-) ).
one of them says trace: , prints git hash value.
i cannot find specifics on trace message showing, directly useful, should commit id.
you can test yourself:
git cat-file -t eef60ca4521006cb11e4b7f181bc7a1a will show type of object in question (if valid object). if turns out blob or tree, rather commit, reason it's not documented it's kind of useless—not cannot find commit containing specific tree or blob, had most-useful bit of information right there, gave less-useful information instead.
if is commit id, @ particular commit (git log -1 eef60ca4521006cb11e4b7f181bc7a1a, instance). use git rebase -i amend commit, or squash commit commit removes large file. since large file not in end-point commit, have removal commit in there already; whether it's suitable squashing depends on commit, , want have show in commit history present rest of world pushing.
just completeness:
to https://github.com/x/x.git ! [remote rejected] v0.8 -> v0.8 (pre-receive hook declined) error: failed push refs 'https://github.com/x/x.git'
this tells large-file-rejection happens in pre-receive hook, , pushing via https. v0.8 on left name , v0.8 on right theirs. git not distinguish between branch , tag push failures when explicitly pushing tags:
$ git push origin refs/tags/derp2 total 0 (delta 0), reused 0 (delta 0) remote: pre receive hook remote: found tag [redacted] ! [remote rejected] derp2 -> derp2 (pre-receive hook declined) error: failed push refs '[redacted]' although successes reported new tag. (i set test pre-receive hook rejects tags, check this).
1more precisely, git gets list of names (branches, tags, , other references) , object ids git. these could, in general, type of object. branch names, however, can point commits; tag names point either annotated tag, or directly commit. have played manually tagging blobs , trees, , work, it's not normal.
2this structure, non-leaf nodes of tree carry hash values of children, called hash tree or merkle tree. in version control systems git , mercurial, commit graph dag parent/child relationships reversed commits can read-only, theory still applies.
3a shallow repository 1 in rule relaxed. shallow repositories definition not authoritative, since merkle trees cannot verified. git's implementation allows shallow repositories work in "fetch" direction (the git doing fetching gets correct parent ids each "uprooted" commit, stubs off graph special graft entry make act if root commit). sender , receiver must both cooperate make work.
Comments
Post a Comment