8000 Make SkipPatchBuilding property public to allow faster file-diffs when the actual patch-sets aren't needed · Issue #483 · libgit2/libgit2sharp · GitHub
[go: up one dir, main page]

Skip to content
Make SkipPatchBuilding property public to allow faster file-diffs when the actual patch-sets aren't needed #483
Closed
@Spiralis

Description

@Spiralis

With reference to the discussion in the pull request here: bcc25ce

@nulltoken requested that this perhaps was discussed in a proper issue thread.

My use-case is to walk the graph backwards and detect if the changes in the changesets match a given sub-folder. What the changes are really doesn't matter to me, and it is clearly a waste of time to generate the patch-sets which will then never be used. However, I also noticed that the Compare method now also takes a sub-folder before starting to create the patch-sets and that change was very welcome too (or maybe it was always there and I didn't notice it...). To support my use I made the property public myself, but haven't committed it or created a pull request - as I felt that this was in @nulltoken's domain, sort of.

I didn't profile "a lot" (and by now I've done housecleaning and removed the profiling code again), but from what I could see my biggest gains were in adding the subfolder-specs. I did also see a considerable speedup for skipping patch-building, but I don't recall the numbers.

Having said that, asking for a list of changes in files without wanting to see the the actual patch-sets seems very valuable to me. I find it hard to believe that wanting to see the files changed from a changeset is that unusual. And, like in my case, I am not looking for if one changeset has changed files. I am iterating over a number of changesets and checking each of these. On top of that I am reiterating that process too for a number of different paths. The larger the changesets and the larger the span in changesets to analyze this all adds up to a lot of extra time. In my case with the two changes of narrowing down using path and skipping patch building together cuts down my builds (where I am using this tool) with minutes (even tens of minutes, maybe even more).

Making one property public and gaining this kind of speed advantages seems like a very good idea to me. I know that I will end up using this anyway, even if that means that I have to maintain my own patch/fork of this. But, I hope I don't have to and that the common repo can gain from this.

BTW: I noticed that the default git commands for listing which files that have changed for a given path is really fast. I somehow doubt that it generates patches when it doesn't show them...

I noticed that @dahlbyk 👍'ed for the change. Might be one vote for doing the change? 😃

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0