| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Closes #1.
|
|
|
|
| |
Closes #125.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running git deps on FOO^! is effectively answering the question "which
commits would I need in order to be able to cleanly cherry-pick commit
FOO?" Drilling down further, that could be rephrased more precisely
as "which commits would I need in my current branch in order to be
able to cleanly apply the diff which commit FOO applies to its
parent?"
However, in the case where FOO is a merge commit with multiple
parents, typically the first parent P1 is the parent which is
contained by the merge's target branch B1. That means that the merge
commit FOO has the effect of applying the diff between P1's tree and
the FOO's tree to P1. This could be expressed as:
tree(P1) + diff(tree(P1), tree(FOO)) == tree(FOO)
Therefore the question git-deps needs to answer when operating on a
commit with multiple parents is "which commits would I need in my
current branch in order to be able to cleanly apply diff(tree(P1),
tree(FOO)) to it?"
However, the current algorithm runs the blame analysis not only on
diff(tree(P1), tree(FOO)), but on diff(tree(Px), tree(FOO)) for
*every* parent. This is problematic, because for instance if the
target branch contains commits which are not on P2's branch, then
diff(tree(P2), tree(FOO))
will regress any changes provided by those commits. This will
introduce extra dependencies which incorrectly answer the above
question we are trying to answer.
Therefore change the algorithm to only diff against the first parent.
This is very similar in nature to the -m option of git cherry-pick:
https://stackoverflow.com/questions/12626754/git-cherry-pick-syntax-and-merge-branches/12628579#12628579
In the future it may be desirable to add an analogous -m option to
git-deps.
Sem-Ver: api-break
|
|
|
|
|
| |
This was introduced by recent refactoring which split blame_hunk()
into several smaller methods.
|
|
|
|
|
| |
In the future, this will let us control the verbosity of the debug
output.
|
| |
|
|
|
|
| |
This makes it a bit clearer where the hunk came from.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
https://stackoverflow.com/questions/15817420/subprocess-and-type-str-doesnt-support-the-buffer-api/15817457#15817457
|
|
|
|
|
|
|
|
|
| |
When a new dependency is discovered, its target may have already been
placed on the TODO list via a different source (and maybe even analysed
for dependencies), e.g. if find_dependencies() was previously called on
it, or if it was previously found via recursion. In this case we still
need to notify listeners of the dependency, even though we won't add it
to the TODO list.
|
|
|
|
|
|
|
|
| |
Avoid any errors if find_dependencies() is called repeatedly.
Previously this could fail when recursion was enabled, because
a commit could be processed via recursion, and then again via
a subsequent call to the TODO list, at which point the sanity
check that each blame line hadn't been seen before would fail.
|
| |
|
|
|
|
| |
Avoid calling hex() repeatedly
|
| |
|
| |
|
| |
|
|
|
|
| |
This helper can be reused elsewhere, e.g. in git-explode.
|
|
|
|
|
| |
It has nothing to do with DependencyDetector, and this will let us
reuse it from git-explode too.
|
|
|
|
|
|
| |
pygit2.revparse_single(annotated_tag) returns a pygit2.Tag object, and
this extra layer of indirection has to be resolved to obtain the
pygit2.Commit.
|
| |
|
|
|
|
| |
This is cleaner and will allow it to be reused elsewhere.
|
| |
|
|
Sem-Ver: api-break
|