[TYPO3-core] git/gerrit maintain patches stacked on each other - best practice

[Steffen Gebert]

Hi Christian,

> // create a branch
> /* hack up a first patch, commit, squash, create forge issue */
> // push to gerrit
 >>
> /* hack up a second patch in same branch that depends on first patch,
> first patch was _not_ yet accepted in gerrit. Mark change with
> 'Depends: #<issue-id1>' in commit message */
I'd say you can omit the "Depends" line. Gerrit will show the dependency 
to the reviewer.

> // push to gerrit (is this correct, or will it push _both_ changes now?
No, if the first commit exists already in Gerrit, it will only push the 
second (or at least Gerrit would not create a new issue for the first 
one - maybe it's transferred through the wire).

> I end up with a branch having something like the following structure:
> patch 3 - Change-id 'id3', git-sha1 'git3', not yet pushed to gerrit
> patch 2 - Change-id 'id2', git-sha1 'git2', pushed, issue '2'
> patch 1 - Change-id 'id1', git-sha1 'git1', pushed, issue '1'
> master - latest git-sha1 'git0' when branch was created
>
> Alternative (is this more easy?):
> - Create a branch for first issue, push to gerrit
> - Create a second branch, based on first branch, push to gerrit
> - ...
I think it's fine, as long as the branch points to the latest commit 
(then you can step backwards and always reach the previous ones).

> Questions:
> - Master changes at unrelated places: Which commands are needed to
> rebase my branch(es) to new latest 'git0' version again?
Development in your branch and the master branch went on, so you want to 
merge the master branch in your branch:
git merge origin/master (while being in you topic branch)

> - Master changes at related places, so for example 'patch 1' must be
> changed to apply to master again: Which commands are needed to rebase my
> branch(es) to new latest 'git0' version,
Merging ends up in a conflict state. You have to resolve this state 
manually.

 > how do I push 'patch 1' (and
> only this one) to gerrit again, so that this issue applies to master
> again for someone to review?
I'd step back to this commit:
git checkout <SHA>
git merge origin/master
Check git log or git log origin/master..HEAD to see, what will be pushed.
Instead of using the SHA, you can also use HEAD^ (or HEAD^^) to get one 
(or two) commits backwards from HEAD (or any other revision pointer.

> - While hacking 'patch 3' I realize that 'patch 1' missed something. I
> fix this and would like to change my 'patch 1' commit accordingly and
> push this again to gerrit. Which commands are needed to commit/amend(?)
> the 'patch 1' commit and to push only this patch to gerrit again?
As before.. step back to this commit and amend it, then push it.
Afterwards you can check out your topic branch again (as you're in 
detached head in the meantime) and have the third commit back.

> - Someone reviewed 'patch 1' in gerrit and pushed a new patch set for
> this issue. Which commands are needed to substitute my current patch set
> in the line of patches with the new one that was submitted to gerrit,
> keeping my 'line-of-patches' intact? (Remove my 'patchSet 1' of 'patch
> 1' and insert 'patchSet 2' of 'patch 1' at this position).
Uh.. dunno. You can use the cherry-pick command to stay in your branch 
and apply a commit on top. So you *could* start from master, cherry-pick 
the commit from Gerrit and then cherry-pick your commits 2 and 3. 
However, this ends up in a new branch/detached head. But it could work.

> - A final 'patch 1' was merged to master. How do I tell my branches,
> that this patch is now in master?
rebase your branch. Never did it before, so I have no experience.

Kind regards
Steffen

-- 
Steffen Gebert
TYPO3 v4 Core Team Member

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org