On Wed, Feb 2, 2011 at 2:02 AM, Kevin Ottens <er...@kde.org> wrote: > On Wednesday 2 February 2011 07:21:44 Dawit A wrote: >> On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell <johnf...@gmail.com> wrote: >> >> But how would a similar work flow except there are multiple fixes >> >> present in the local repo ? How would you push only a single fix in >> >> such case ? >> > >> > git rebase -i origin #Bring up a list of your changes. >> > >> > <Reorder them in the editor so that the commit you want to push is at >> > the top of the list, save> >> > >> > <Fix any conflicts that might have arisen because you reordered the >> > commits> >> > >> > git pull --rebase #make sure we are up to date >> > >> > git log #copy the SHA of the commit you want to push up to >> > >> > git push origin SHA:head #paste the SHA that you just copied where I >> > wrote "SHA" >> > >> > >> > Does that make sense? There are other ways to do it, but this way >> > avoids most of the common problems. >> >> Yes. Great. IMHO that type of documentation is what is needed in techbase. >> >> One question though... why would i need to do git rebase -i origin if >> I always do git pull --rebase in the first place ? Wouldn't simply >> following the steps you mentioned after "git pull --rebase" suffice >> since I am going to be using the commit SHA to do the push ? > > Because the order matters. git will push everything up to the commit with the > SHA1 passed as parameter. git rebase -i allows you to reorder your commits > first.
Ahh... I see. It is push everything upto that commit, not just push that commit. Ouch! That is almost as much a hassle as the convoluted method I am following now. Do not commit anything that is not ready to be pushed into my own local branch. Use git stash to save the uncommited changes before doing the pull --rebase and apply the stashed changes after doing the push...