Nick Dokos <nicholas.do...@hp.com> writes: > Bernt Hansen <be...@norang.ca> wrote: > >> Nick Dokos <nicholas.do...@hp.com> writes: >> >> > Thomas S. Dye <t...@tsdye.com> wrote: >> > > From what I gather, Tom is getting additional merge commits every time > he pulls (which accounts for the extras and the different SHA1). I think > I used to have that problem, but I don't any more, and I don't remember > (so what's new?) how it came about and/or I resolved it. Any ideas > about that? I may have just deleted the master branch and recreated > it.
Tom should run gitk on his master branch - then the merge commits (if that is what they are) will be very obvious. If Tom create even a single commit in the past and then subsequently added new commits from origin/master with git pull then he'll get an extra merge commit for everytime he updates. There is a write up on worg about how to keep local commits on top of origin/master by rebasing the local commits each time git pull is run. http://orgmode.org/worg/org-faq.html#keeping-local-changes-current-with-Org-mode-development Assuming his has local commits buried in his history somewhere Tom can 'fix' it by doing $ git checkout master $ git reset --hard origin/master $ git cherry-pick <whatever local commits he wants to keep> so the new commits are on top of origin/master, and set his master branch to automatically rebase on pulls as described in the link above. HTH, -- Bernt
