put THEIR commits AFTER my commits with a single rebase command

I asked this on stackoverflow, but no reply.
http://stackoverflow.com/questions/15971244/git-put-their-commits-after-my-commits-with-a-single-rebase-command

Suppose master and origin/master diverged.
I'm on master and I want to put the commits from origin/master after my commits and then push --force.

         A---B---C origin/master
        /
    D---E---F---G *master

desired result:

         A---B---C origin/master
        /
    D---E---F---G---A'---B'---C' *master

Variant 1:

git branch -f tmp
git reset --hard origin/master
git rebase tmp

This variant is bad, because 'git reset --hard' checks out some files and 'git rebase' rewrites them again before applying commits. It's a redundant job. Variant 2:

git branch -f tmp origin/master
git rebase --onto master master tmp
git branch -f master
git checkout master

Too many commands. I want to do this with just one command. And I want to stay be on branch master in case of rebase conflicts.

Am 4/18/2013 7:18, schrieb Ilya Basin:

Variant 1a:

   git reset --hard origin/master
   git rebase @{1}

redundant job.

Perhaps this one:

git merge origin/master
git rebase ORIG_HEAD

-- Hannes

JS> Perhaps this one:

JS> git merge origin/master
JS> git rebase ORIG_HEAD

JS> -- Hannes

Wouldn't I have to resolve conflicts twice?

BTW, during the rebase, can I tell git to rewrite a different branch upon rebase success or abort?

git branch -f tmp origin/master
git rebase --onto master master tmp
if [ $? -ne 0 ]; then
# modify some file in .git/ ?
else
git branch -f master
git checkout master
fi

Am 4/18/2013 10:33, schrieb Ilya Basin:

Yes. But you did run 'git config rerere.enabled true' when you started with git, didn't you? ;-)

Anyway, Johan's idea to use git cherry-pick is much better.

What do you expect here? Failure of git rebase means that it is not complete, yet. So far, nothing has been rewritten. So what? Perhaps you mean:

	# never mind
	git rebase --abort

-- Hannes

Note that if other people are working on top of origin/master, then what you are proposing is quite rude to them, since they must now manually rebase their own work on top of your rebased history. Rewriting public history is generally considered evil.

git cherry-pick master..origin/master

...Johan

--
Johan Herland, <[email protected]>
www.herland.net

JH> git cherry-pick master..origin/master

Thanks Johan.