With "too many unreachable loose objects" git gc --auto will always
trigger. This clutters the output of git am and thus git rebase.
The work flow of the Wine project doesn't include git merge. git rebase
is therefor used to track the origin. This will produce soon too many
loose objects for git gc --auto's taste. Pruning the repository would
"fix" it. But we tell Wine developers new to git to NOT prune as long as
they aren't confident enough with git; just as a safety net in case they
have thrown away month of work.
Signed-off-by: Michael Stefaniuc <redacted>
---
git-am.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 65c634f..5f0f241 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -469,9 +469,9 @@ do
"$GIT_DIR"/hooks/post-applypatch
fi
- git gc --auto
-
go_next
done
+git gc --auto
+
rm -fr "$dotest"
--
1.5.4.rc2
On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
With "too many unreachable loose objects" git gc --auto will always
trigger. This clutters the output of git am and thus git rebase.
The work flow of the Wine project doesn't include git merge. git rebase
is therefor used to track the origin. This will produce soon too many
loose objects for git gc --auto's taste. Pruning the repository would
"fix" it. But we tell Wine developers new to git to NOT prune as long as
they aren't confident enough with git; just as a safety net in case they
have thrown away month of work.
The safety is the reflog. What it refers to doesn't get pruned.
Nicolas
Nicolas Pitre wrote:
On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
quoted
With "too many unreachable loose objects" git gc --auto will always
trigger. This clutters the output of git am and thus git rebase.
The work flow of the Wine project doesn't include git merge. git rebase
is therefor used to track the origin. This will produce soon too many
loose objects for git gc --auto's taste. Pruning the repository would
"fix" it. But we tell Wine developers new to git to NOT prune as long as
they aren't confident enough with git; just as a safety net in case they
have thrown away month of work.
The safety is the reflog. What it refers to doesn't get pruned.
Then git gc --auto should just prune too and not spam, right?
But the reflog is only there for branches that still exist; the rest is
gone. A git stash clear will also remove the reflog for the stash.
Regardless of the safety of git prune i don't see a reason why git gc
--auto needs to be called for every patch in a git-am run and not once
at the end.
bye
michael
On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
Nicolas Pitre wrote:
quoted
On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
quoted
With "too many unreachable loose objects" git gc --auto will always
trigger. This clutters the output of git am and thus git rebase.
The work flow of the Wine project doesn't include git merge. git rebase
is therefor used to track the origin. This will produce soon too many
loose objects for git gc --auto's taste. Pruning the repository would
"fix" it. But we tell Wine developers new to git to NOT prune as long as
they aren't confident enough with git; just as a safety net in case they
have thrown away month of work.
The safety is the reflog. What it refers to doesn't get pruned.
Then git gc --auto should just prune too and not spam, right?
Pruning might be dangerous if some other operation is happening
concurrently, which is why it is not done by default.
But the reflog is only there for branches that still exist; the rest is
gone. A git stash clear will also remove the reflog for the stash.
But the reflog for HEAD remains nevertheless, and it contains everything
that happened to be the current branch.
Regardless of the safety of git prune i don't see a reason why git gc
--auto needs to be called for every patch in a git-am run and not once
at the end.
Indeed.
Nicolas