Increase contributions to the project

[peso]

Since this project has some original and valuable ideas, I feel it deserves more attention than it currently gets. The original author is not completely gone, but has many other tasks with higher priority, so the PR process is rather sluggish.

I would like to propose moving the project towards a more independent status, where a group of contributors collaborate on maintaining and evolving the code base.

A start could be to write a CONTRIBUTING guideline, on how to add small corrections and what it takes to get commit and review permissions. More info here: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

This document has some more thoughts on governance: https://opensource.guide/leadership-and-governance/

This might also have relevance: https://ben.balter.com/2017/11/10/twelve-tips-for-growing-communities-around-your-open-source-project/

[mlange-42]

@peso Can we have a personal communication on this? You find me on Discord under the same user name, without the minus.

[peso]

Thank you for the discussion on discord. We agree that a separate github organization to handle git-graph (the library) and its spin-off projects git-graph (cli tool) and git-igitt (tui application) would be a good idea. Also splitting git-graph into two repositories will make issue tracking more clear.

I would like to ask the community for suggestions names for these for entities. Please comment below.

[alerque]

I would also like to be considered for involvement in helping with this if it is going to be split off into an org (I think that's a great idea). I have extensive background in contributing to and managing FOSS projects, both personal and in orgs. I hold a lot of trusted keys and can prove I'm not a particular risk to the supply chain. Would you like me to elaborate?

[peso]

That sounds good. Which parts would you like to contribute to?

[alerque]

Issue triage, PR review, helping split the library from the CLI, CI and release stuff, whatever is needed... I could for example fix the report I made on git-igitt earlier today before landing there and setup CI to verify it at or prior to releases.

After a discussion is had and names agreed on for the library vs. CLI I can probably help with filtering a repo or otherwise shaping it so so the library component and CLI repositories history (whichever way the split happens) that is relevant to the issues.

Subject to time constrains of course, but I can jump in on a lot of different things as needed.

[peso]

In that case, I think you should start by scratching your itch: A CI setup for git-igitt would raise the quality and is a good opportunity for fixing the build problem you mentioned. I guess you should also discuss the process for a release with @mlange-42.

Welcome onboard.

[alerque]

First itch scratched here and here.

[peso]

Name suggestion

git-graph (this cli) repository was started in 2021, but git-graph (vs code extension) can be found on the wayback machine before 2020. Therefore this repo should probably change name.

Suggesting a line theme:

• Project: git-lines
• git-graph lib: line-graph
• git-graph cli: line-map
• git-igitt tui: line-browser

This is one suggestion of names. Please feel free to add more. We can use the React-icon to vote up or down on suggestions.

[mlange-42]

I would suggest that both the CLI and TUI names should start with git-, as this allows to run them as git commands. So currently, with git-graph on the PATH, one can also use:

git graph

Further, if the CLI tool gets a rename, I would suggest to rename/move this repo, but let it stay the CLI tool. This is probably the most used part of the family, and it deserves to keep its GH stars.

[peso]

Here is another one, this time with a rail theme. As rails is pretty much taken by ruby, the German word "bahn" is used instead:

• Project: gitbahn
• git-graph lib: bahnlib
• git-graph cli: bahnmap
• git-igitt tui: bahnhof

[mlange-42]

Now that you are coming up with "German" names, just as a side note, git-igitt (which actually stands for Interactive GIT Terminal) also plays on the German language, spelling similar to "igitt!" or "igitt-igitt!", which means something like "Yuck!" or "Ugh!" for disgust.

[alerque]

I agree on the git- prefix for the tools, but neither "bahn" (I work both with cartography where railroad graphs are actual maps, and language lexers where railroads graphs to me are these things) nor lines really trigger any great vibes for me. Obviously both are apropos, but both are so overused in related categories they don't stand out.

Having peeped at a thesaurus, how about 'sketch', 'track', 'depict', 'sculpt', 'relate', or 'peruse' as a base word to play with?

Also having picked a base word, I would skip the extra 'map' moniker and just keep the plain CLI the same as the project name.

Additionally I would kind of suggest merging the CLI and TUI projects such that the default ivocation is the CLI, and adding an -i / --interactive flag. Of course it could still be separated with another name like below, but having both an interactive and non-interactive viewer in one package is more expected than the current lib+cli mix. This seems like it would be more useful grouping issues too. People would be much less likely to report on the wrong repo.

• Project: git-<baseword>
• Library crate: git-<baseword>/git-<baseword>-lib
• CLI: git-<baseword>/git-<baseword>
• TUI: git-<baseword>/git-i<baseword> (or just an -i flag on the CLI)

Of course whatever the name you could also keep all the code in one repo with a Cargo workspace to split the lib/cli too, or even without a workspace with just a bin/lib build target mix.

[mlange-42]

I fully agree regarding the grouping, i.e. separate library, and CLI+TUI in the same repo and executable.

Regarding the base words, I find the general idea of track or something similar, railway-related quite appropriate, as the graphs with their straight lines that avoid intersections somehow remind to railywards.

[alerque]

Both git-track and git-tracks are available as GH org names and CLI tooling names (git-tracker being taken for something unrelated). There is some overlap with the git idea of tracking branches, so that is a point against this name for sure. That would make it relatively hard to search for too, so two points against. But I'm game too, it isn't a bad name. The bahn baseword idea isn't actually that bad either for that matter.

[alerque]

git-rail might be another option, a bit more direct than track and more unique to search as well.

[peso]

I think it is important to state explicitly the scope of the project. I hope we can agree on something like "Help navigating a branch graph". With this scope users cannot expect git-igitt to grow into a full git client - its purpose is to browse the graph.

[peso]

On the merge TUI+CLI to one binary I'm undecided.

• Against: The number of stars on git-graph and git-igitt are different, suggesting a different user base.
• For: By merging them more users would discover the other tool.
• Against: The unix philosophy - do just one thing but do it well.

Even if the tools are not merged, I believe git-igitt will see an increase in stars/users, because it is being maintained. Users are very sensitive to a long period with no commits on a project.

[alerque]

Just a heads up @mlange-42, when you do create a GH org to house this going forward and migrate the repositories there, that will create nice redirects from the existing locations (including for the Git protocol) so there will be very little disruption. One gotcha however is that it is important that you do not then fork the repository from the org back to your personal GH namespace. That would kill off all the redirects and things like search results would start landing on your fork instead of the parent repo. Given that we're likely renaming the repos in the process of moving them that might not matter, but if you were to fork the repos under the same name it would be a bit of a bummer for everybody else. Just thought I'd give you a heads up on that one (having been bitten before!).

[mlange-42]

that will create nice redirects from the existing locations (including for the Git protocol) so there will be very little disruption

@alerque Yes, I know, this is why I want this repo (moved & renamed) to be the CLI tool.

That would kill off all the redirects and things like search results would start landing on your fork instead of the parent repo.

Ok, thanks, good to know. But as I will likely be a (rather inactive) maintainer, I see no reason to make a fork.

[alerque]

@alerque Yes, I know, this is why I want this repo (moved & renamed) to be the CLI tool.

Of course, that makes sense. Folks that need the library edition will find it without stars and redirects ;-)

Ok, thanks, good to know. But as I will likely be a (rather inactive) maintainer, I see no reason to make a fork.

Yes, but one thing forks do is make it easy to play with CI automation without messing up the actual project and tagged releases. I ran into this one forking one of my own projects that grew into it's own org, then trying to hack on some release flow in a local fork. That inadvertently killed off the redirects.

[peso]

There seem to be a majority vote for the unified exe (2.5 vote) vs split exe (0.5 vote).
Here is another proposal

project: git-bahn .. as in Deutche Bahn
library: vtlt .. short for Vcs Track Layout Tool. Unique in search.
exe: git-igitt ... unique. Already established.

The Vcs in lib name is a hint on what the new backend can do. It will be able to have any vcs library as back-backend. The primary use case is to have git2 for git-igitt (same as today) and git oxide for gitui. But it will also work with a non-git system like subversion.
For the unified exe I suggest the interactive mode should be default, and option -save-to for generating a file. File extension determines type, but can be overwritten with --format=svg or =unicode. This could also be a function inside the TUI.

For completeness, here are names for a split-exe scenario with git- prefix
batch exe: git-tracks (the 's' gives less confusion with a tracking branch)
tui exe: git-igitt

[peso]

This is an argument for the non-unified version:
You could simply embrace the current very much to the point name, and state on the front page / readme that it is not the same as the vs-code extension.

project: git-bahn .. as in Deutche Bahn
library: vtlt .. short for Vcs Track Layout Tool. Unique in search.
batch exe: git-graph ... not unique but very intuitive. Already established.
tui exe: git-igitt ... unique. Already established.

Nothing prevents an eventual merge or rename to happen after the project is established, so maybe we should concentrate on finding just the project name for now?

[peso]

@mlange-42 have you decided on a project / organization name?

[mlange-42]

I was not aware that you expect me to make this decision, and I do actually not care too much about the organization name.

Not sure how well git-bahn works for people not speaking German. And Deutsche Bahn does not have a very good reputation 😆 I would slightly prefer git-rail, but there is already a user with this name. So fine for me to pick git-bahn.

For the repo names, I agree with your last comment @peso, as of course I had good reasons to pick these names originally.

Maybe this just delays the process further, but here are some more suggestions that are available as org names:

• git-vis (like visualization)
• git-vizz (mixing visualization and wizzard)
• git-topo
• git-rails (mentioned early in singular, but that is not available)

[peso]

My favorite organization name is gitbahn / git-bahn

• Rail-road associations: 90% as you need to look it up or know German to know.
• Search uniqueness: 100% - bahn is not an English word, so I expect the search "git bahn" to be rather unique. gitbahn without the dash most certainly isn't an English word.
• Available name on github: Yes

My second priority would be alerque's suggestion git-tracks as a good compromise:

• Rail-road associations: 100%
• Search uniqueness: 50% - git-tracker is taken and "git tracks something is quite common on the internet. Eg. "a local (git) branch that tracks a remote branch".
• Available name on github: Yes

[mlange-42]

Ok, so let's take the bahn. With or without hyphen? Slightly tending to gitbahn.

[alerque]

With, since we'll also be having a binary git-bahn so it can be used as git bahn. Having the org name be almost but not quite the same as the namesake binary is just going to add more mess.

[mlange-42]

Do we? I thought we rather stay with git-graph for the binary? But I guess this is an argument for using the hyphen?

[mlange-42]

So we go for git-bahn? @peso would you like to create a contact email address for it?

[peso]

Git-bahn is fine. I'm not familiar with GitHub organisations. What will the contact email be used for? Do we need another email besides our own? If we need an extra email i would create a google account or perhaps a google group so several persons cloud answer. lør. 20. dec. 2025 12.08 skrev Martin Lange ***@***.***>:

…

So we go for git-bahn? @peso <https://github.com/peso> would you like to create a contact email address for it? — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAB7V2HOX6KGPWWHJMS7ML4CUUZNAVCNFSM6AAAAACM4CXTDWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZQGQ4DMOI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mlange-42]

"Contact email" is a required field to create an organization. But I just tried it, and it is not public by default. So I will simply use a private one for now.

[mlange-42]

Git-bahn is fine.

But I would go for all lower case git-bahn.