New features in v0.2.6 #64
initialcommit-io
started this conversation in
Show and tell
Replies: 1 comment
-
Thank you for the detailed description @initialcommit-io. This is will be helpful |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@paketb0te @abhijitnathwani
This is where I should have posted my note about v0.2.6. The most important item in that update is an overhaul of how git-sim parses the commit history. Previously, git-sim could only show a linear history of 5 commits in most commands, with the exception of Log which had the --commits option (a non-git option) to display a longer series of (still linear) commits.
Obviously displaying commits linearly is nice, but it leaves a lot to be desired when Git repos can have a rich and diverse branching structure. My thinking is that we must capture that in Git-Sim with as many commands as possible, and not just with "git-sim log".
So I first did some local development with the "git log" command, to recursively parse parent/child relationships using GitPython's model
commit.parents
, instead of creating a static list of N commits and iterating over it as it had done previously.The
parse_commits()
method is recursively called starting with any commit, but usually HEAD or a branch head. Commits are parsed backwards until the new "-n " setting, (which has a default of 5) is reached. Because of the recursion, this will display N commits back from each branch head included in the graph.For now, the logic just places each commit behind the previous, and obviously doesn't re-draw any commits that have already been drawn (since commits can be reachable by multiple branches) - we track those in the dictionary
self.drawnCommits
. We also check to make sure a commit won't be drawn on top of another by making sure the center of each new commit doesn't intersect with a list of drawn commit centers. If so, we move that commit Down below the location where it would be drawn. There are also some rules to make sure arrows don't intersect with drawn commits, and if so, curve the arrow around the commit to avoid messy overlapping collisions. It turns out these basic rules are enough to allow complex Git graphs that look pretty decent and support multiple branches.So next (still for Log) was to add the --all flag to show all unrelated branch heads in the graph. I added a new
parse_all()
method for this, which only does anything if the --all flag is set. This just creates a list of non-ancestral branch heads, i.e. branch tips with no children since we mimic "git log --graph --all" which only shows true branch tips since branches that are ancestors of other branches will be included downstream.I implemented
-n <number>
and--all
as subcommand options forgit-sim log
since these flags are real Git flags forgit log
, and I removed the--commits
flag since it's not a Git subcommand flag for "git log". Going forward I think subcommand options/flags in Git-Sim should only be implemented as a direct 1-1 match to Git. Any new Git-Sim flags/options should be implemented as global options.Once this was all working for
git-sim log
subcommand, I then added global options for-n <number>
and--all
so that they could be extended to other subcommands. I did this as global options since they don't exist as corresponding Git subcommand options for commands besides log.Note that these flags can ONLY work properly for now with Git-Sim subcommands that DON'T show the table/zones for filesnames/working directory/staging area/etc, such as
git-sim status
,git-sim add
, etc. The reason is that only 5 commits can be show above the table, or else its placement will get messed up.So for stuff like this and added the global option
--hide-merged-branches
, which tells Git-Sim to only display a linear set of commits from the first parent of each commit. This can be combined with-n 5
to show a linear set of 5 commits for display above the table/zones.Lastly, I added global option
--invert-branches
which allows reorientation of the drawn graph by flipping the order that parent commits are parsed from a merge commit with multiple parents.I tested things myself pretty thoroughly (different combinations of these new options for every subcommand), but it would be great if you want to play around with them and create an Issue for any bugs you find.
Beta Was this translation helpful? Give feedback.
All reactions