On Fri, Mar 03, 2017 at 02:56:05AM -0500, Jeff King wrote:
> On Thu, Feb 23, 2017 at 02:27:36AM -0600, Devin J. Pohly wrote:
>
> > +test_perf 'noop prune-empty' '
> > + git checkout --detach tip &&
> > + git filter-branch -f --prune-empty base.
On Fri, Mar 03, 2017 at 02:55:35AM -0500, Jeff King wrote:
> The only objectionable thing I noticed in the test additions is that
> the early ones should be marked test_expect_failure until the fix from
> 3/4 flips them to "success". Otherwise it breaks bisectability.
>
> -Peff
Good point. Will
On Thu, Mar 02, 2017 at 11:36:18AM -0800, Junio C Hamano wrote:
> "Devin J. Pohly" writes:
>
> > I think your point is interesting too, though. If a commit is also
> > TREESAME to its parent(s?) in the _pre-filtered_ branch, it seems
> > reasonable that som
On Thu, Feb 23, 2017 at 01:17:49PM -0800, Junio C Hamano wrote:
> "Devin J. Pohly" writes:
>
> > Previously, the git_commit_non_empty_tree function would always pass any
> > commit with no parents to git-commit-tree, regardless of whether the
> > tree was nonem
correctly filtered.
With this change, parentless commits with an empty tree are correctly
pruned, and an empty file is recorded in the revision map, signifying
that it was rewritten to "no commits." This works naturally with the
parent mapping for subsequent commits.
Signed-off-by: Devi
Signed-off-by: Devin J. Pohly
---
t/perf/p7000-filter-branch.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/perf/p7000-filter-branch.sh b/t/perf/p7000-filter-branch.sh
index 15ee5d1d5..b029586cc 100755
--- a/t/perf/p7000-filter-branch.sh
+++ b/t/perf/p7000-filter-branch.sh
Sanity check before changing the logic in git_commit_non_empty_tree.
Signed-off-by: Devin J. Pohly
---
t/t7003-filter-branch.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 2dfe46250..7cb60799b 100755
--- a/t/t7003-filter
New test to expose a bug in filter-branch whereby the root commit is
never pruned, even though its tree is empty and --prune-empty is given.
The setup isn't exactly pretty, but I couldn't think of a simpler way to
create a parallel commit graph sans the first commit.
Signed-off-b
On Thu, Sep 13, 2012 at 11:10:26PM -0700, Junio C Hamano wrote:
> I do not think it is a good idea to allow such a helper to claim that
> it supports "fetch" capability, for at least two reasons:
>
> * Being able to "list" is essential for "fetch" based helpers.
>think, far from "arbitrary".
From: "Devin J. Pohly"
Allow a fetch-style remote helper to issue the notification
ref
to specify a ref's value during the fetch operation.
Currently, a remote helper with the "fetch" capability cannot fetch a
ref unless its sha1 was known when the "li
10 matches
Mail list logo
