Repository navigation
Increase contributions to the project #124
Description
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/
Activity
mlange-42 commentedon Oct 26, 2025
@peso Can we have a personal communication on this? You find me on Discord under the same user name, without the minus.
peso commentedon Nov 7, 2025
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 commentedon Nov 7, 2025
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 commentedon Nov 7, 2025
That sounds good. Which parts would you like to contribute to?
alerque commentedon Nov 7, 2025
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 commentedon Nov 8, 2025
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 commentedon Nov 8, 2025
First itch scratched here and here.
peso commentedon Nov 10, 2025
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:
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 commentedon Nov 10, 2025
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, withgit-graphon the PATH, one can also use: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 commentedon Nov 10, 2025
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:
mlange-42 commentedon Nov 10, 2025
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 commentedon Nov 10, 2025
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/--interactiveflag. 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.git-<baseword>git-<baseword>/git-<baseword>-libgit-<baseword>/git-<baseword>git-<baseword>/git-i<baseword>(or just an-iflag 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 commentedon Nov 10, 2025
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
trackor something similar, railway-related quite appropriate, as the graphs with their straight lines that avoid intersections somehow remind to railywards.alerque commentedon Nov 10, 2025
Both
git-trackandgit-tracksare available as GH org names and CLI tooling names (git-trackerbeing 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. Thebahnbaseword idea isn't actually that bad either for that matter.alerque commentedon Nov 10, 2025
git-railmight be another option, a bit more direct than track and more unique to search as well.peso commentedon Nov 11, 2025
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 commentedon Nov 11, 2025
On the merge TUI+CLI to one binary I'm undecided.
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 commentedon Nov 11, 2025
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 commentedon Nov 11, 2025
@alerque Yes, I know, this is why I want this repo (moved & renamed) to be the CLI tool.
Ok, thanks, good to know. But as I will likely be a (rather inactive) maintainer, I see no reason to make a fork.
alerque commentedon Nov 11, 2025
Of course, that makes sense. Folks that need the library edition will find it without stars and redirects ;-)
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.