Talk:Using Git
From BioPerl
Contents |
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 git@github.com:bioperl/bioperl-live.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'git@github.com: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)
Fork it
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 git@github.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
git@github.com: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
git@github.com:bioperl/bioperl-live.git; cd bioperl-live; git
remote add repo git@github.com: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
