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..HEAD
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" <djpo...@gmail.com> 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
>
On Thu, Feb 23, 2017 at 01:17:49PM -0800, Junio C Hamano wrote:
> "Devin J. Pohly" <djpo...@gmail.com> writes:
>
> > Previously, the git_commit_non_empty_tree function would always pass any
> > commit with no parents to git-commit-tree, regardless of whether t
be 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 <djpo...@gmail.com>
---
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
Sanity check before changing the logic in git_commit_non_empty_tree.
Signed-off-by: Devin J. Pohly <djpo...@gmail.com>
---
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
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-by: Devin J
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.
...
Oh,
From: Devin J. Pohly djpo...@gmail.com
Allow a fetch-style remote helper to issue the notification
ref sha1 name
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 list command
10 matches
Mail list logo
