[Development] Pushing rebases and unrelated changes together is a sin

Samuel Rødal samuel.rodal at digia.com
Wed Feb 20 09:43:52 CET 2013


On 02/20/2013 09:22 AM, Thiago Macieira wrote:
> On quarta-feira, 20 de fevereiro de 2013 08.47.40, Samuel Rødal wrote:
>> The correct process when doing rebases is:
>>
>> git pull --rebase # or your favorite git work-flow
>> git push gerrit HEAD:refs/for/some_branch
>> # add comment in change on gerrit about being a pure rebase
>> # do some changes
>> git commit -a --amend
>> git push gerrit HEAD:refs/for/some_branch
>
> Actually, I'll go further: the above should be done ONLY if you are trying to
> solve a conflict. If you're not trying to solve a conflict, DON'T REBASE.

I thought that went without saying :)

> If you rebase your branch often, like I do, then never push an update from the
> actual branch. Instead, check out the old base for the commit, cherry-pick the
> new commit, and push that.
>
> You can get the old base for the commit from the Gerrit interface. It lists
> the SHA-1 of the previous commits, so it's just that plus ~.

After I push my changes to Gerrit I don't keep them around locally, 
since Gerrit keeps track of them. My branchless work-flow for a new fix is:

git fetch gerrit
git checkout gerrit/stable
# do necessary changes
git commit -a
git push gerrit HEAD:refs/for/stable

If I need to push some modifications to any of my changes I simply use 
the "checkout" Download option in the Gerrit interface which gives you a 
command-line of the form:

git fetch ssh://rodal@codereview.qt-project.org:29418/qt/qtbase 
refs/changes/37/48337/2 && git checkout FETCH_HEAD

Gerrit has greatly cut down on the amount of local branches I need to 
have when working on multiple fixes intermittently.

--
Samuel



More information about the Development mailing list