Can you squash the two commits as one?

Can you squash the two commits as one?

Thanks for point out. but the PR not finished that I will rebase and squash after PR finished.

Hmm. I don't think this belongs in the git_commit part of the API.

To me, something like this feels like an addition to the git_revwalk API (something like git_revwalk_next_for_path that finds the next revision in the walk where the OID for the given path changed), or maybe even as something that could be done as an extension of the work that started in #2181 to make it easier to do more complex searches with revwalks.

Alternatively, something like this could conceptually be grouped with the git_blame API, but I'm not sure about that. From what I can tell, there is no code from the blame that could be reused for this.

I'm curious what @carlosmn thinks (and, of course, what @vmg thinks if he has an opinion).

something like this feels like an addition to the git_revwalk API (something like git_revwalk_next_for_path that finds the next revision in the walk where the OID for the given path changed)

OK for the function xxx_entry_last_commit_id, but for the function xxx_tree_last_commit_id(not pushed yet) which compute last effected commit of all children of tree(most like the tree view on the github). How return a list of commits via git_revwalk_next_xxx?

something like this could conceptually be grouped with the git_blame API

I think this is a good proposal.

This feels like something that should be in snippets, rather than integrated directly into the library. It's a very specific wrapping of the revision walker. Why go inside the revwalk's guts instead of using it?

This feels like something that should be in snippets, rather than integrated directly into the library. It's a very specific wrapping of the revision walker. Why go inside the revwalk's guts instead of using it?

That makes sense to me, although I think this feature is asked for frequently enough that making it super simple to walk to the last commit to modify a file would be a nice helper to add.

I'm also wondering what we can do to make it easier to write code like this without feeling like we need to expose internal APIs. When we discussed the callback function for the revwalk, one idea was exposing the commit list node - I'm wondering if this is a use case for that so that you can more easily get the list of parents.

Actually, I guess there is not much advantage to that because since you need to get the tree and the parent trees, you'll need to do the full lookups anyhow. There isn't much efficiency to be gained by exposing revwalk internals.

As for labeling every blob in a tree with the latest commit to change it, it seems like that's mostly a bookkeeping exercise as you do a revwalk, yes? If you want, you can use git_diff_tree_to_tree with a git_diff_notify_callback to do the changed blob marking (just return 1 all the time and you can avoid all the allocations, so that will be pretty efficient, I think).

It's a common request, but it doesn't represent the underlying work that would be done. Getting the last commit is a special case of filtering by path. We can add that to the revwalk as long as we make sure to advertise the limitation that it's not history simplification at all and the resulting history will be disconnected.

If we're adding that, then we should should start by adding filtering for a single path, rather than something like git_revwalk_next_for_path which would require book-keeping for every path we might have ever seen in case the user ever changes their mind on what path they want to use.

As for the whole-tree one, that would be something like git_blame_tree, as that's what the git script is called, which would do it all at once using the revwalk. But I think that should be a different PR, as it refers to something that's orthogonal to this.

So, in summary,

• In the cases of finding the last effected commit for single blob/tree/link, implement it in the namespace git_revwalk_xxx
• In the cases of whole-tree search, implement it in the namepsace git_blame_xxx (should open a new issue)

right? It's OK for me. I'd like continue to complete it.

Yeah, it should be in git_revwalk, but not just in that namespace, but as an option to the revwalk, just like the first-parent choice or where to start and stop.

I've opened issue #3041 to keep track of the interface which would allow for use-cases such as this one in a way which doesn't assume knowledge of the internals.