Git question

[swaldman]

Scenario:

- I worked on bug A and submitted a pull request. That hasn't yet been accepted.
- I want to work on bug B, which expands upon A and changes the same bits of code.
- Since A has not yet been accepted, its changes are not yet in the develop branch. However, I still have A's branch available to me.

Is there a way in which I can base B on A and (assuming that A is accepted without changes) have it all merge nicely in the end? Or do I need to wait for A to be merged into develop first?

Also, if there is a way, is there going to be a big problem if A then *isn't* accepted / requires changes / whatever?

Thanks :-)

Comments

[randomling]

This from someone who hasn't worked with Git for some weeks because brain, but I think you can just switch to branch A, and then create branch B from branch A. This will start you off with all of branch A's changes, and you can then go from there.

[swaldman]

that's correct, but then what happens when I want to submit it? Normally pull requests are based on a develop branch that is common between my repo and the dw one, but in this case the DW one wouldn't have branch A (and the contents of A might or might not already have been merged)

[kareila]

I /think/ you can go ahead and do the work on B branched off of A, but don't submit the pull request until A is accepted on the main branch. Once that happens, you can rebase B to the main branch and submit. At least, that's what I would try to do.

[swaldman]

That makes sense. Then presumably if A has minor changes before it's merged, then at best it works anyway, and at worst there's a little bit of manual fixing in the rebase.

[cesy]

As others have said, you can work on B branched off A, and even pull request B to dev, so long as you include a comment to remind reviewers they should merge A first. If they merge A with no changes, they can then merge B and it's all great. If A has changes that clash, you may then need to rebase B off the latest A or latest develop afterwards (and your pull request will automatically update when you push to your fork). If they fail to see your note and merge B first, they're implicitly merging A along with it, which is clear when they're reviewing code or commits.

[fu]

This.

Although, if you comment on A, referring to B, B will end up having a nice big section pointing back to A, which makes it harder for a committer to accidentally commit B before A. (Harder even than a note because the section is nice and big)

AS an example, we sometimes have style-related commits that need to modify both dw-free and dw-nonfree. so if you look at the pull request in dw-nonfree (B), it contains this text:

dreamwidth/dw-free#147


If you then go to the pull request in dw-free (A), you'll see a nice big reminder to check dw-nonfree as well.

[swaldman]

Ooh, that's worth knowing - thanks, cesy & fu :-)