-
-
Notifications
You must be signed in to change notification settings - Fork 89
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
feat(smartlog): Support for rendering a sparse smartlog #619
Conversation
8718514
to
eaa874c
Compare
Just updated and rebased onto master after #620 was merged. Still just a proof of concept; I didn't look at tests yet, nor really dig too far into what changes to the original implementation could be made based on the new changes from #620. The output seems to match what I was getting before. Now that the hidden commits have been dealt with though, and there's general sense that this change desired, I'll work on updating tests and such. |
dd4eac6
to
08134fa
Compare
3cac073
to
8d3d175
Compare
👋 Thanks for the review. I've marked this a ready, though I always do so w/ some trepidation on these substantial PRs, for fear that I've forgotten to take care of some expedient This seems to be working just fine in my experimentation. If you have any add'l tests you'd like me to add, I'll be happy to. I also took care of a few performance issues that were making sparse lots significantly slower then connected logs. From my casual benchmarks, on a repo w/ ~12 branches and probably 80 draft commits, the sparse log is ever so slightly faster than a connected log. Note too the commit message for the first commit in this stack, regarding clap and the default value for Finally, I think this will get really interesting when/if we give users that ability to set a custom revset. For example, I'm been playing with |
8d3d175
to
063a401
Compare
Marking as draft again. Just encountered this locally:
|
Do we need
(Jujutsu also has a weird revset for its default log output.) |
I posted https://github.com/claytonrcarter/git-branchless/pull/25/files with my changes; let me know what you think. |
You beat me to it! I have a very similar changeset locally, though mine is stuck on the
As you figured out, the answer is "no not at all". I had also been wondering about replacing the "connected" part w/ the default revset, but didn't pursue it. Turns out: revsets are amazing!
Yes, that works! 🎉 In fact, I think we can even simplify it by removing the |
4fadf9a
to
326e768
Compare
OK, I've updated my changes and incorporated yours. 🔥 I did make some slight edits to your changes, mostly to remove some (I think unneeded) extra braces and what now. I also removed the Oh, final note, this PR also includes the single commit from #632. If that's merged first, I can remove it from this, or if it's small enough and acceptable, it can be merged as part of this, which ever you prefer. (There are some small conflicts, so it's non-trivial to push them independently.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
This doesn't do much for us now, but will soon be used to help us determine what type of smartlog we should be rendering. Unfortunately, this prevents clap from rendering the default revset in the help message, but I believe this is the only way (via the derive API) to detect if the user has or has not not supplied an arg for a particular value. See clap-rs/clap#3846 fmi on getting the value_source of an arg via the derive API.
This should only happen when the user has requested to render a specific revset, as opposed to calling `smartlog` without any arguments, or when any of the other commands trigger a call to `smartlog`. Note that HEAD and the head of the main branch are always displayed, regardless of the revset provided by the user.
326e768
to
405fe06
Compare
I merged that commit and rebased this PR for you (and enabled auto-merge). If you like, you can push the branches to this repository and stack the PRs. You would set this PR's "base branch" to the branch containing the other commit. Then, once the other PR is merged, this PR's base branch will be updated to |
This description is still TBD, but I've cleaned up my local hacks. (A bit ... still more to do.) This version aims to target the sparse smartlog only at cases where the user has a requested a specific revset, eg by calling
git smartlog foo()
vs justgit smartlog
or via the internal calls thereof.The main ideas is that there are different use cases for the smartlog. Sometimes you just want the default set, but if you ask for a revset maybe you don't want the ancestors filled in.
This expands the usage of the vertical ellipsis to indicate non-immediate ancestor links in the smartlog, as well as "false heads", where a commit has visible descendants, but none of them are included in the smartlog.
This includes the fix for the undo issues I mentioned in chat, but it still seems to have problems with being too aggressive about excluding rewritten/obsolete commits.
Example: