-
-
Notifications
You must be signed in to change notification settings - Fork 211
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
Submodule recursion #1058
base: main
Are you sure you want to change the base?
Submodule recursion #1058
Conversation
Thanks for opening this pull request! Please check out our contributing guidelines! ⛰️ |
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.
Good stuff, I left some comments that I think help moving further.
Tested it quickly, but didn't see this in action yet. Can you also check again?
git-cliff-core/src/commit.rs
Outdated
@@ -250,6 +252,29 @@ impl Commit<'_> { | |||
} | |||
} | |||
|
|||
/// Returns wether the commit changes the SHA of a submodule |
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.
/// Returns wether the commit changes the SHA of a submodule | |
/// Returns whether the commit changes the SHA of a submodule |
git-cliff/src/lib.rs
Outdated
} | ||
} | ||
} | ||
parse_commits(args, &tags, &mut commit_range, repository)?; |
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.
Why this has been extracted to a new function?
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.
interim derp, thought I might reuse it but I dont need to 😓
@@ -303,6 +279,36 @@ fn process_repository<'a>( | |||
releases.push(Release::default()); | |||
} | |||
} | |||
if recurse_submodules { |
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.
I guess we are updating the releases
vector here based on the commits in the submodules.
It would be nice to extract this to a function that takes &mut releases
maybe.
git-cliff/src/lib.rs
Outdated
if recurse_submodules { | ||
for (_submodule, _commits) in submodule_commits.values() { | ||
log::trace!("Recursing {:?}.", _submodule.path().to_str()); | ||
let _range = format!( |
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 seem to be used.
git-cliff/src/lib.rs
Outdated
_commits.last().unwrap().id | ||
); | ||
let _repo_path = _submodule.path().to_path_buf(); | ||
let _repo = Repository::init(_repo_path.clone())?; |
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.
You can get rid of the compiler error by doing this for now:
let repo = Box::leak(Box::new(Repository::init(repo_path.clone())?));
It's a bit bad, but this is also what I'm doing for the other repositories 💀
Oh yes, great, that's a feature I am very interested in. I volunteer for testing, we use this at work for changelog generation with about 200 submodules. Right now we use the repository flag to generate a merged changelog for each submodule. There is one particular issue on CI environments I ran into. If you don't specify |
It's great to hear there is some interest for this feature :)
Ah, it's probably related to the monorepo related changes. Would love to take a look into it if you have time to submit an issue about this. But I agree that proper submodule support would be indeed better here.
Interesting idea... |
Couldn't help myself and started tinkering with this code ;). Here are some thoughts:
|
Interesting... I didn't take a deeper look into this code but your take makes sense. I think we can wait for @yudjinn for incorporate some changes into this PR or feel free to put up a new draft based on those. |
I poked at it some more, but in short, @lehmanju is correct that we do need to get submodule changes as well. I am currently planning on doing that as a Vec based on the new/old filename that the commit sees, and then just diffing releases based on the first and last in that vec, but if you have a better idea to do that explosion earlier in one shot, I'd love to see it! |
I'd probably explode the commits between submodule before and after states somewhere in: git-cliff/git-cliff-core/src/repo.rs Lines 116 to 150 in 63129ce
git-cliff/git-cliff-core/src/repo.rs Lines 275 to 285 in 63129ce
And since this line already iterates through the diff, I'd extend it to look into the file contents to get the submodule commit id. However, I'm stuck at how to ask libgit2 to get me the file contents if I have a diff? |
Not sure how it would be possible to get the submodule information from a Here is an example from |
@@ -273,10 +281,34 @@ fn process_repository<'a>( | |||
let mut previous_release = Release::default(); | |||
let mut first_processed_tag = None; | |||
let repository_path = repository.path()?.to_string_lossy().into_owned(); | |||
let mut submodule_commits: HashMap<PathBuf, (&mut Repository, Vec<Commit>)> = |
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.
Why do we have this complex type? 🤔
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.
So we don't have to reinit The repo every time we want to parse commits, but tbh I put some of that together after a very full day so I plan on redoing it a bit. The pathbuf being the key is just to avoid having to impl comparisons for submodules
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.
Got it. it would be nice to refactor/simplify this a bit for sure :)
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.
I think I might just swap it to be a tuple and replace the end commit instead. Plan is that for any given submodule, the releases we include should be inclusive and in aggregate. So if a single release has multiple commits bumping the submodule underneath it, just aggregate all of those changes
the only way I was able to do it was checking the |
Description
Motivation and Context
How Has This Been Tested?
Screenshots / Logs (if applicable)
Types of Changes
Checklist: