rebase planning: determining blobs changed by multiple branches

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

rebase planning: determining blobs changed by multiple branches

From: Neal Kreitzinger <hidden>
Date: 2016-06-15 22:50:31

We have 15 branches that are unmerged, but are based on the same published 
history.  They branched off at different points in the history.  Each branch 
is comprised of a single squashed commit (except for master).  How can I 
compare all 15 branches with the tip of master to see which file merges 
(blobs) they have in common?

a-------b-------c-------d-------e-------f-------g-------i-------j-------k-------l
|           |            |           |           |                      | 
|          |           |---k1
|           |            |           |           |                      | 
|          |---j1
|           |            |           |           |                      | 
|---i1
|           |            |           |           | 
|---g1
|           |            |           |           |---e1
|           |            |           |           |---e2
|           |            |           |           |---e3
|           |            |           |---d1
|           |            |           |---d2
|           |            |           |---d3
|           |            |---c1
|           |            |---c2
|           |---b1
|           |---b2
|---a1

The goal is to create a sane plan for rebasing.  If the question is insane 
as it is stated, then please advise on any sane ways to approach this 
besides just rebasing one-by-one and making the last poor branch wait till 
the end to rebase with a ton of conflicts.  I'm dealing with users who 
refuse to do frequent rebases, so a plan the minimizes rebases while getting 
the most out of each rebase is desired, if practical.

v/r,
Neal 

Re: rebase planning: determining blobs changed by multiple branches

From: Marc Weber <hidden>
Date: 2016-06-15 22:50:31

Hi Neal,

I'm not quite sure what you want to do?
rebase all branches on top of commit l so that they are up to date?

Why do you want to find common blobs?
If the same conflict happens you could use gitrere and reuse a conflict
resolution.

git ls-files --with $HASH
gives you a list of files

git diff --name-only
should  give you a nice list of modified files.

So using the intersection of  ls-files of branch and tip should give you
common files. Substracting changed files using --name-only should yield
the files which were not modified.
Maybe there are nicer solutions though.

Rebasing is always bad. Have you considered using top-git?
This way you can merge with tip and create the rebased patches using the
export function.

Marc Weber

Re: rebase planning: determining blobs changed by multiple branches

From: Neal Kreitzinger <hidden>
Date: 2016-06-15 22:50:31

On 2/7/2011 6:59 PM, Marc Weber wrote:
Hi Neal,

I'm not quite sure what you want to do?
rebase all branches on top of commit l so that they are up to date?

Why do you want to find common blobs?
If the same conflict happens you could use gitrere and reuse a conflict
resolution.

git ls-files --with $HASH
gives you a list of files

git diff --name-only
should  give you a nice list of modified files.

So using the intersection of  ls-files of branch and tip should give you
common files. Substracting changed files using --name-only should yield
the files which were not modified.
Maybe there are nicer solutions though.

Rebasing is always bad. Have you considered using top-git?
This way you can merge with tip and create the rebased patches using the
export function.
Our master represents our new system and we want to have a linear 
history so we use rebase.  Each branch is a project.  If a project does 
not have any merges with other projects then it can rebase with little 
impact.  If projects are changing alot of the same blobs then they will 
have alot of merged blobs and can be rebased on eachother in 
throw-away-integration branches.  In this way the branches can be 
grouped into appropriate rebase groups so the merge-conflict resolutions 
of these groups can be resolved simultaneously in different integration 
repos.  So lets say you have 5 groups, then you can rebase those 5 
integration-branches onto master one-by-one instead of doing 15 project 
branches one-by-one.  I thought maybe git had a cool command for 
analyzing this in one fell swoop.

v/r,
Neal
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help