Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a --transposed option to the diagram subcommand #145

Open
waldyrious opened this issue Jan 9, 2020 · 4 comments
Open

Add a --transposed option to the diagram subcommand #145

waldyrious opened this issue Jan 9, 2020 · 4 comments

Comments

@waldyrious
Copy link
Contributor

If one of the branches has lots of commits, the diagram can become too wide for the terminal and even wrap around, which makes it very hard to read.

Here's an example from a rebase I did today:

❯ git imerge diagram
***********************************************************************************************************************************************************************************************************************************************************************************************************************
*????.*??????????????????????.#????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
*.............................?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

Key:
  * = merge done manually
  . = merge done automatically
  # = conflict that is currently blocking progress
  @ = merge was blocked but has been resolved
  ? = no merge recorded

...which, when wrapped, becomes this:

❯ git imerge diagram
********************************************************************************
********************************************************************************
********************************************************************************
***********************************************************************
*????.*??????????????????????.#?????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
???????????????????????????????????????????????????????????????????????
*.............................??????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
???????????????????????????????????????????????????????????????????????

Key:
  * = merge done manually
  . = merge done automatically
  # = conflict that is currently blocking progress
  @ = merge was blocked but has been resolved
  ? = no merge recorded

I think an option to rotate the diagram, so that the shortest branch grows horizontally and the longest one grows vertically, would be helpful in these situations:

❯ git imerge diagram
***
*?.
*?.
*?.
*?.
*..
**.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*?.
*..
*#?
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??
*??

Key:
  * = merge done manually
  . = merge done automatically
  # = conflict that is currently blocking progress
  @ = merge was blocked but has been resolved
  ? = no merge recorded
@mhagger
Copy link
Owner

mhagger commented Jan 10, 2020

I wouldn't mind such a feature, but I'm unlikely to have time to work on it.

@waldyrious
Copy link
Contributor Author

Any hints about how one should go about implementing it?

@mhagger
Copy link
Owner

mhagger commented Jan 10, 2020

I think the transposition would have to happen pretty late. Probably you'd want:

  • a function to transpose the output of Block.create_diagram() or MergeFrontier.create_diagram() (one function could probably do both). Remember that FRONTIER_BOTTOM_EDGE and FRONTIER_RIGHT_EDGE have to be swapped in the individual cells.
  • Block.format_diagram(), Block.write(), Block.writeppm(), MergeFrontier.write(), MergeFrontier.write_html(), and MergeFrontier.format_diagram() probably need a new optional transpose=false argument.

I think it would help to make a Diagram class to hold the output of *.create_diagram(). Class instances should know their lengths and know how to transpose themselves. Note that MergeFrontier.write_html() also accesses the SHA-1 of cells via the associated block using self.block.get_value(i1, i2). You could provide access to this via the new Diagram class. Probably the write*() methods could move to the Diagram class.

It's going to be subtle to implement this without adding conditional logic all over the place, but I think it's possible. If not, then it'd probably be better to live without this feature rather than complicating the code a lot.

@abitrolly
Copy link
Contributor

It would also be nice to see numbers that git-imerge uses explained somewhere on the diagram. I suspect that they map to dimensions, but I am not sure about their meaning and how start+end are determined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants