CODEWITHSUNDEEP
git
Mark Canlas
Mark Canlas

Reputation: 9583

How do I deal with nested branches in git?

Not sure what to Google for regarding this issue. The above should be my X question. My Y question is

How do you deal with a parent branch that is frequently rebased?

Let's say I have the following branches:

STACK-123 [origin/master: ahead 3]
STACK-456 [STACK-123: ahead 7]
STACK-789 [STACK-456: ahead 4]

Note that they also have this dependency chain

origin/master <- STACK-123 <- STACK-456 <- STACK-789

Essentially I want to treat all of them as a set of patches. But if any of them get rebased, the downstream branches still retain the old versions of the commits.

So let's say we have this list of commits:

STACK-123 (a, b, c, d) atop origin/master
STACK-456 (e, f, g) and implicitly (a, b, c, d) atop origin/master

If STACK-123 is rebased, we get:

STACK-123 (a', b', c', d') atop origin/master
STACK-456 (a, b, c, d, e, f, g) atop origin/master

Notice how STACK-456 keeps the old commits?

What workflow is there that just links the branch to a set of commits and doesn't encounter this problem after rebasing?

Short of manually repairing each branch.

(Also, well aware of the dangers of rebasing already-published commits, so please forego repeating. None of these branches are published/mainlined.)

Upvotes: 4

Views: 2726

Answers (3)

Mark Canlas
Mark Canlas

Reputation: 9583

Use topgit

This answer will be scant on details since I just found this and I'm having some trouble getting it to work... But it seems to pretty much be the exact answer to this type of workflow. It encodes the originating branch in metadata files stored in git. It has its own update command that Does The Right Thing in terms of updating descendant branches.

https://github.com/greenrd/topgit

Upvotes: 0

Mark Canlas
Mark Canlas

Reputation: 9583

One solution I've been thinking about... Which I currently hate... Is to encode which commits really belong to the topic branch by encoding that into the commit messages (something JIRA-style developers do anyway).

STACK-123 (a', b', c', d') atop origin/master
STACK-456 (a, b, c, d, e*, f*, g*) atop origin/master

If commits e f g had some sort of marker (a string to grep for) in their commits, you could use a utility script (outside of git) to filter them out.

a [self] STACK-123 ... relics before rebase, will be filtered
b [self] STACK-123 ...
c [self] STACK-123 ...
d [self] STACK-123 ...
f [self] STACK-456 ... contains the string 'STACK-456', will be kept
g [self] STACK-456 ...
h [self] STACK-456 ...

Upvotes: 0

Cogwheel
Cogwheel

Reputation: 23237

You should only rebase local branches before pushing them out to the world. Having a shared repo which is regularly being rebased is simply the wrong way to use Git.

(Also, well aware of the dangers of rebasing already-published commits, so please forego repeating.)

But it's the correct answer.

Rebasing rewrites history. The set of commits on a rebased branch is effectively unrelated to the set of commits on your local branches that haven't seen the rebase. Rebasing is basically a shortcut for doing a bunch of related cherry-picks.

Merging & branching are the way you should be sharing code with git. Rebasing is meant to clean up your local work before exposing it to the world.

Upvotes: 1

Related Questions