1

I'm trying to find best approach here and I would need and advice, since as far as I understand, Gerrit takes all commits on the same branch as dependent on previous one.

  1. Avoiding dependencies

    Is the best approach creating a new branch locally and then merge back to local master branch after change set is merged on the remote master and being pulled and rebase from it?

  2. Breaking up existing unwanted dependencies

    I usually rebase interactively and reorder commits that I want to make independent at the top of commit list and then I git reset --hard HEAD~x and make new branch. I proceed then the same as in point 1. Is there any easier way to do it? Because just reordering commits does't really break dependencies on Gerrit, right? I can delete commit as well, but I don't want this, of course...

Community
  • 1
  • 1
mbpro
  • 2,460
  • 3
  • 22
  • 37
  • The terminology here is quite confusing (dependencies? ) - it looks like your doubts are about using git and have nothing to do with gerrit really. – AD7six Mar 19 '14 at 09:29
  • Question concerns both sides, but especially Gerrit, since if I'm not mistaken, Gerrit by default takes all susequent commits dependent on previous one. or I'm I wrong? – mbpro Mar 19 '14 at 11:12
  • @mbpro that is correct – Tim Mar 19 '14 at 11:47

2 Answers2

4

I'm an intern learning git in combination with gerrit myself and I've had the same issues as you recently.

Avoiding dependencies

Is the best approach creating a new branch locally and then merge back to local master branch after change set is merged on the remote master and being pulled and rebase from it?

This is indeed how I was taught to do it and if you think about it it makes sense. This way your local master is always in sync with the remote and because you create 'alot' of branches you have greater control of your repository.

Breaking up existing unwanted dependencies

I usually rebase interactively and reorder commits that I want to make independent at the top of commit list and then I git reset --hard HEAD~x and make new branch. I proceed then the same as in point 1. Is there any easier way to do it?

git rebase -i for reordering commits to change/break dependencies is indeed the way to go in this case. At least that is how I was taugh to deal with these situations.

Because just reordering commits does't really break dependencies on Gerrit, right?

It does. If you reorder your commits locally and then push to gerrit again, the new patch set will have different dependencies.

millimoose
  • 39,073
  • 9
  • 82
  • 134
Tim
  • 41,901
  • 18
  • 127
  • 145
  • `This way your local master is always in sync with the remote` - the advisable way to achieve that is to only merge origin/master. I.e. create a branch, propose a change, change is merged to origin/master, master pulls origin/master, feature branch is deleted. Otherwise you risk diverging by accidentally or otherwise introducing new commits to master. – AD7six Mar 19 '14 at 09:32
  • Yes, @AD7six, this is the safest way, although I hadn't had any problems up to now when merging feature branch back to local master and then pulled from origin/master. Thanks! – mbpro Mar 19 '14 at 11:16
  • @Tim, if I have commit B dependent on commit A and I rebase/reorder locally and push, then I will come up with A dependent on B. I don't want that, right? – mbpro Mar 19 '14 at 11:18
  • That depends on your situation. Sometimes you want a commit to depend on another commit. If you dont want these dependencies you should create different branches for each commit and push from there. – Tim Mar 19 '14 at 11:38
  • Thanks, @Tim, so I have the current approach confirmed! :) – mbpro Mar 19 '14 at 11:46
1

this is kind of Continuous Integration issue. Yes it is good to create a local branch for each feature, because you can avoid dependencies, and even you can easily switch between ongoing implementations - and of course to create new patchset on those commits easily. But it is not needed to merge the feature branch with any local branch. Feature branches can be kept updated (rebased) using only remote branch. I use git pull -r to avoid merge commits. Also when the commit is created before push, it good to update the local branch with this command. And when the commit/patchset is submitted to the remote branch by Gerrit, the local branch can be updated by git pull -r as well, or git fetch git reset --hard origin/<barnch>. With this workflow merge commit can be avoided. Merge commits is needed only, if you have more remote branches and want to merge them once a time. I am not using git rebase -i to rearrange commits at all. And keep it mind, that if a patchset once has been pushed you it is not needed to keep it locally furher. Every change/commit can be fetched from Gerrit to change and push a new patchset of it.

Community
  • 1
  • 1
laplasz
  • 3,359
  • 1
  • 29
  • 40
  • Well, code review happens before server build, so I'm not sure we can talk about CI issue here, really. But you put some value, information here, thanks! – mbpro Mar 19 '14 at 13:51