search

mlange-42 / git-graph

Command line tool to show clear git graphs arranged for your branching model
MIT License
517 stars 20 forks source link

Branches merged from forks in separate columns/colors #44

Closed mlange-42 closed 3 years ago

mlange-42 commented 3 years ago

Currently, merges of branch master/main from forks are displayed left of master/main, which may leave unnecessary space to the left.

Find a way to distinguish fork branches from repo branches, match them in RegEx separately.

This seems to be possible only by taking into account branch prefixes (i.e. user names) from merge summaries. Also, this would require to set up or detect the "owning user's" prefix(es).

adamreichold commented 3 years ago

Find a way to distinguish fork branches from repo branches

You mean by checking if they track a branch from a remote?

mlange-42 commented 3 years ago

No, that is already done. I mean to detect when e.g. master from a fork is merged into master of the actual repository. I would like to provide the possibility to show these branches like feature/topic branches rather than next to master (particularly not to the left). I know that after the merge they become part of the actual repository, and it might impossible to do what I imagine.

adamreichold commented 3 years ago

The parents of merge commit are ordered, aren't they? So you should be able to determine which branch is your local main branch into which the remote main branch was merged by checking which branch contains the first parent of the merge commit?

mlange-42 commented 3 years ago

Ah, ok... So you mean when master is merged into master, the second parent must be from a fork? That sounds like a good idea! Didn't think of the "name clash" which should indeed have the potential to solve the problem. What remains is to figure out a way how to express that in BranchInfo and in the branching model...

Thanks!

adamreichold commented 3 years ago

So you mean when master is merged into master, the second parent must be from a fork?

IIRC, the definition is that the first parent is the current HEAD and the second parent is the tip of the merged branch, e.g.

git checkout first-parent
git merge second-parent

So I guess this assumes that the fork's main branch is always merged into the original main branch, never the other way around. This is probably not correct if back-merges are done to get the fork up-to-date, but I suppose it should always apply to the last merge commit and hence should apply if you trace backwards from the current tip of the main branch.

mlange-42 commented 3 years ago

Yes, it's always the second parent that is merged into the first. Probably "back-merges" require additional attention, but that should be solvable. I will, however, have to re-structure the algorithms a bit. Currently, persistence, visual groups and colors are determined in one go (simply from RegEx), but determining fork stuff is only possible after/during back-tracing (as I need to know the name of the "1st parent branch"), which occurs afterwards. Not a real problem, but it needs some more musing...

mlange-42 commented 3 years ago

This seems to work nicely! #43