git merge/push troubleshooting
Chris, could you double-check about that troubleshooting block you moved? -Dave Messina 15:34, 27 May 2010 (UTC)
For me the merge command was clean, which makes sense I think since that's a local command and doesn't look at the remote repo. It wasn't until I tried to push that I got the error:
$ git merge topic/davemessina-multiphylip Updating 95025c0..b8ae20c Fast-forward Bio/AlignIO/phylip.pm | 15 +++++++++++++-- 1 files changed, 13 insertions(+), 2 deletions(-) $ git push To email@example.com:bioperl/bioperl-live.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'firstname.lastname@example.org:bioperl/bioperl-live.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.
Developing as a non collaborator?
Hi, I'd like to clone BioPerl from github, develop code, then push back changes (correct words there?) onto a project in my own github account. From there BP devs could get the changes from my project and merge them with the BP project.
How do I push my changes back onto a project for my user on github?
Cheers, --DanBolser 12:49, 8 July 2010 (UTC)
Dan, you generally should do this by (1) logging in to GitHub, (2) going to the main BioPerl github repo and forking the repository, and (3) checking out the forked code from your local account. The process is described here. --Chris Fields 18:02, 26 July 2010 (UTC)
Helping a noob...
04:35 < kai> http://gist.github.com/439745#file_git_rebase_explained.txt <-- is my explanation of rebase I gave in #bioperl a while ago 04:37 < kai> ok, so here's how I work on bioperl.. 04:37 < kai> git clone email@example.com:bioperl/bioperl-live.git 04:38 < kai> that gives me the local clone with the "upstream" bioperl repository as "origin" 04:38 < kai> cd bioperl-live; git remote add repo firstname.lastname@example.org:kblin/bioperl-live.git 04:39 < kai> that adds my fork of bioperl-live as remote "repo" 04:39 < kai> if you don't have commit access to the official bioperl repo, you need to clone from git://github.com/bioperl/bioperl-live.git 04:40 < kai> the rest of the setup remains the same, after all you of course have commit access to your own fork 04:40 < kai> you'll have to use your github user name of course 04:41 < kai> now, when I want to work on a new feature, I create a feature branch, like so: 04:41 < kai> git checkout -b my_new_feature origin/master 04:42 < kai> this creates the new branch "my_new_feature", branched off whereever the official bioperl-live repository's master branch is at 04:43 < kai> the checkout command I gave also changes to the my_new_feature branch right away 04:44 < kai> now I just do my coding, git add the changed/new files and git commit them 04:47 < kai> to push my changes, I use my "repo" remote, which as you'll remember is my personal fork of bioperl-live 04:47 < kai> git push repo my_new_feature 04:48 < kai> now, let's make things a bit more complicated, so I'll go and set up another box for development as well 04:49 < kai> first steps, same thing as before, git clone email@example.com:bioperl/bioperl-live.git; cd bioperl-live; git remote add repo firstname.lastname@example.org:kblin/bioperl-live.git 04:50 < dbolser> so how come you don't just clone kblin 04:51 < kai> I like the convention that "origin" always is the "official" repository, and "repo" always is my personal repository 04:50 < kai> now, I'm still sitting on branch "master" of my local repository, but I want to work on my_new_feature, so I need to create that branch locally 04:50 < kai> git checkout -b my_new_feature repo/my_new_feature 04:52 < kai> by creating the branch based on repo/my_new_feature, this is the same as on the first box 04:52 < dbolser> OK, so it's like you go home to continue work on the feature you started at work 04:52 < kai> yeah 04:53 < kai> there's nothing stopping you from doing "git checkout -b my_new_feature origin/master" and creating a new branch with the same name as a branch you have in another repository, but that gets confusing as hell 04:54 < kai> ok, so let's say I had a brillian idea at home and committed that to my personal github fork by doing "git push repo my_new_feature" again 04:55 < kai> on the next morning at work I obviously need to update the checkout on my work pc 04:55 < kai> and now here's where things get a bit confusing. (there's more than one way to do it, perl hackers should like this) 04:56 < kai> git remote update 04:59 < kai> basically it's a shorthand for "for every remote configured do 'git fetch remote'" 04:56 < kai> git rebase repo/my_new_feature 04:57 < kai> git remote update grabs the updates from all remote repositories, so from "origin" which is the official repo and "repo", my personal fork 05:02 < kai> an alternative approach would be to use "git pull repo my_new_feature" 05:03 < kai> but that won't make sure your copy of "origin" is up-to-date, so you'll miss out on those changes if you create a new branch off origin/master 05:11 < kai> assuming you're "done" with your new feature and now want to push it to your "master" branch (doesn't relly make sense on your personal fork, but let's assume you have commit rights to the official repo) 05:12 < kai> in order to be able to push, you need to be up-to-date in your current branch, so "git remote update; git rebase origin/master" takes care of that 05:12 < kai> git log (or gitk) helps to check that there's no temporary or simply wrong commit in your local branch 05:13 < kai> now you can push to the "master" branch of "origin" like so: git push origin my_new_feature:master 05:14 < kai> that will push changes from the local branch "my_new_feature" to the remote branch "master" 05:14 < dbolser> if you don't have commit, would you just ask someone to review your branch? 05:14 < kai> yeah 05:14 < kai> that's why rebase is handy as well, keeps all the "for review" commits on top of the history 05:15 < kai> there's only one catch. if you rebase your work tree and there are new commits you rebase on, a plain "git push" to your personal fork will fail 05:16 < kai> that's because the history gets rewritten on a rebase and the remote branch doesn't match 05:17 < kai> however, you can tell git push to overwrite the remote history using git push repo +my_new_feature
Random Notes: Ammend a commit
To amend a commit before pushing onto a remote, try one of the following:
10:03 < dbolser> how to edit a commit message before pushing onto a remote? 10:03 < ciaranm> dbolser: git commit --amend or git rebase -i