| Age | Commit message (Collapse) | Author |
|---|
|
|
|
9front has several tests scattered throughout the source,
as well as more tests in an external 'regress' repository.
Many of these tests are broken, because there is no easy
way to build and track all of them.
This pulls in several tests from different sources, deletes
the broken tests, tests with missing data, and adds a single
command that can be run from the root of the src directory
to test our system.
The hope is that as we develop new code, we add more tests,
and eventually start running the tests on every commit.
Please enter the commit message for your changes. Lines starting
|
|
|
|
|
|
|
|
git/walk had some confusing behavior, where git/add
of a file and then immediate removal would leave
it in the list of files as 'removed'.
This was harmless, but confusing to users. Now,
'git/add' and 'git/rm' without a commit in between
will not list the file as removed.
|
|
|
|
$gitroot has a trailing slash only when the repository is at /. When
it is not, this path construction doesn't work. Use $gitfs/... like
the other git scripts.
|
|
Otherwise, they stick around in the index even though they aren't
present in the checkout or the commit. This causes various git tools
to bail out since they think the tree is dirty.
|
|
The while condition was wrong, there was an ls command (presumably for
debugging), and it turned --bare into git/init -b, but those do
different things and the latter takes an additional argument.
|
|
Now that a..b handles the case where a isn't an ancestor of b, we
don't need to compute the LCA first.
|
|
The current range algorithm does not work correctly when merge
commits are involved with an ancestor of the base commit.
For example, consider the graph
b
↙ ↖
a d ← e ← f
↖ ↙
c
where b is d's first parent, and c is d's second parent.
This graph is symmetrical, so we should get the same results for
b..f and c..d (modulo the symmetry), but currently range() returns
[d] for b..f and [d, e, f] for c..f. In the first case, we traverse
to b, our base, then unwind to d and add [d] to our results. Then,
we traverse [c, a], but don't find b this time, so unwind back to
f. In the second case, we traverse all the way to a through b,
unwind to d, then find our base, c, and unwind back to f and add
[d, e, f] to our results.
The problem here is that the determining factor for whether a commit
is pushed during unwinding is whether the *last* parent reached the
base commit, when it should be if *any* parent reached the base
commit.
Also, when a is not an ancestor of b, the current algorithm traverses
the entire graph then returns an empty list, despite git's behavior
and git9's documentation ("Between is defined as the set of all
commits which are reachable from b but not reachable from a"). For
the above example, we'd expect that b..f contain c, since c is not
reachable from b.
Range is almost identical to findtwixt, so to fix this we can reuse
the same paint() algorithm for both operations. The only difference
is that we want results in traversal order (rather than an arbitrary
ordering). Add a third mode to paint() to save 'keep' commits in
an array in the order we reach them, then return the non-dropped
and non-skipped commits, preserving that order.
|
|
|
|
our native diff now supports the expected patch formats, lets use it.
|
|
Here, patch grows a dry run option (-n), which allows
git/import to bail out early if it would patch files
that are dirty in tree.
Once git/import refuses to patch dirty files, git/rebase
can skip checking if the whole tree is clean, which is
both convenient and much faster on large trees.
|
|
|
|
|
|
|
|
when logging with `git/log -c count', we would count all messages
that we inspected, rather than just the ones that got printed.
This isn't what we should have done.
While we're in here, refactor show() to only show the message,
rather than filtering and then showing.
|
|
saved wrong version when rebasing, oops.
|
|
go bootstrap uses more of git than we supported, so
stub in enough that we can bootstrap go.
|
|
this is useful for scripting, and convenient for
interactive use.
|
|
ssh signatures confused our commit parsing; teach our
commit parsing to skip them.
|
|
Git9 was sloppy about telling git what commits we have.
We would list the commits at the tip of the branch, but not
walk down it, which means we would request too much data if
our local branches were ahead of the remote.
This patch changes that, sending the tips *and* the first
256 commits after them, so that git can produce a better
pack for us, with fewer redundant commits.
|
|
we have a new, pretty patch(1), lets use it.
|
|
Inspired by some changes made in game of trees, I've
implemented a number of speedups in git9.
First, hashing the chunks during deltification with
murmurhash instead of sha1 speeds up the delta search
significantly.
The stretch function was micro-optimized a bit as well,
since that was taking a large portion of the time when
chunking.
Finally, the full path is not stored. We only care about
grouping files with the same name and path. We don't care
about the ordering. Therefore, only the hash of the path
xored with the hash of the diretory is kept, which saves
a bunch of mallocs and string munging.
This reduces the time spent repacking some test repos
significantly.
9front:
% time git/repack
deltifying 97473 objects: 100%
writing 97473 objects: 100%
indexing 97473 objects: 100%
58.85u 1.39s 61.82r git/repack
% time /sys/src/cmd/git/6.repack
deltifying 97473 objects: 100%
writing 97473 objects: 100%
indexing 97473 objects: 100%
43.86u 1.29s 47.51r /sys/src/cmd/git/6.repack
openbsd:
% time git/repack
deltifying 2092325 objects: 100%
writing 2092325 objects: 100%
indexing 2092325 objects: 100%
1589.48u 45.03s 1729.18r git/repack
% time /sys/src/cmd/git/6.repack
deltifying 2092325 objects: 100%
writing 2092325 objects: 100%
indexing 2092325 objects: 100%
1238.68u 41.49s 1373.15r /sys/src/cmd/git/6.repack
go:
% time git/repack
deltifying 529507 objects: 100%
writing 529507 objects: 100%
indexing 529507 objects: 100%
345.32u 7.71s 369.25r git/repack
% time /sys/src/cmd/git/6.repack
deltifying 529507 objects: 100%
writing 529507 objects: 100%
indexing 529507 objects: 100%
248.07u 4.47s 257.59r /sys/src/cmd/git/6.repack
|
|
we don't recover from an invalid packet, so just
sysfatal with a useful message.
|
|
we do the right thing by default now, let's not
add knobs that nobody cares about.
|
|
This caused some confusion, so to make it clear that
it's plumbing and has nothing to do with 'git fetch',
rename it.
|
|
When pushing, git/send would sometimes decide we had all the
objects that we'd need to update the remote, and would try
to pack and send the entire history of the repository. This
is because we only set the 'theirs' ref when we had the object.
If we didn't have the object, we would set a zero hash,
then when deciding if we needed to force, we would think
that we were updating a new branch and send everything,
which would fail to update the remote.
|
|
Sending the packet on failure could junk the errstr,
so set it after we send the message.
|
|
A while ago, qwx noticed that we clobbered the exec
bit when merging files. This is not what we want, so
we changed the operator precedence to avoid merging
dirty files implicitly.
But we do want to merge, because it's convenient for
maintaining permissions. So, instead, we should do a
3 way merge of the exec bit.
This patch does that, as well as reverting the rollback
of that change.
While we're here, we adjust the timestamps correctly
in git/branch.
This requires changes to git/fs, because without an open
handler, lib9p allows opening any file with any mode,
which confuses 'test -x'.
|
|
there was a diff that went in a while ago to improve
this, but it got backed out because it encounters a
bug in upstream git -- the spec says that a single
ACK should be sent when not using multi-ack modes,
but they send back multiple ones.
This commit brings back the functionality, and works
around the upstream git bug in two different ways.
First, it skips the packets up until it finds the
start of a pack header.
Second, it deduplicates the want messages, which
is what seems to trigger the duplicate ACKs that
cause us trouble.
|
|
This fixes importing patches with multiline commit messages generated
by git-format-patch. It also matches commit message sanitation done
by git-am.
|
|
|
|
|
|
|
|
Although git9 always uses the same commit date and author date, other
implementation do make a distinction. Since commit date is more
representative of the commit graph order, use this as a traversal hint
instead of author date.
|
|
If the server only supports the dumb protocol, the first 4 bytes of
response will be the initial part of the hash of the first ref.
The http-protocol documentation says that we should fall back to the
dumb protocol when we don't see a content-type of
application/x-$servicename-advertisement. Check this before
attempting to read a smart git packet.
|
|
We now keep track of 3 sets during traversal:
- keep: commits we've reached from head commits
- drop: commits we've reached from tail commits
- skip: ancestors of commits in both 'keep' and 'drop'
Commits in 'keep' and/or 'drop' may be added later to the 'skip' set
if we discover later that they are part of a common subgraph of the
head and tail commits.
From these sets we can calculate the commits we are interested in:
lca commits are those in 'keep' and 'drop', but not in 'skip'.
findtwixt commits are those in 'keep', but not in 'drop' or 'skip'.
The "LCA" commit returned is a common ancestor such that there are no
other common ancestors that can reach that commit. Although there can
be multiple commits that meet this criteria, where one is technically
lower on the commit-graph than the other, these cases only happen in
complex merge arrangements and any choice is likely a decent merge
base.
Repainting is now done in paint() directly. When we find a boundary
commit, we switch our paint color to 'skip'. 'skip' painting does
not stop when it hits another color; we continue until we are left
with only 'skip' commits on the queue.
This fixes several mishandled cases in the current algorithm:
1. If we hit the common subgraph from tail commits first (if the tail
commit was newer than the head commit), we ended up traversing the
entire commit graph. This is because we couldn't distinguish
between 'drop' commits that were part of the common subgraph, and
those that were still looking for it.
2. If we traversed through an initial part of the common subgraph from
head commits before reaching it from tail commits, these commits
were returned from findtwixt even though they were also reachable
from tail commits.
3. In the same case as 2, we might end up choosing an incorrect
commit as the LCA, which is an ancestor of the real LCA.
|
|
when reverting files, 'cp -x' updates the mtime
to the time the file was committed. this prevents
'mk' from rebuilding the file, leading to stale
builds.
this change touches the file on revert, so that
we rebuild the file.
|
|
|
|
This prevents commits from getting reordered incorrectly during rebase
or export.
|
|
when running outside of a repository, we would try to
remove '$msgfile.tmp', but we had never actually set
'$msgfile'.
the error is harmless, but annoying.
|
|
due to the way the size of buf was calculated, the parent
file had one trailing null byte for each parent. also, while
we're here, replace the sprint with seprint, and compute the
size from how much we printed in.
|
|
Commiter => Committer
|
|
git used to track cache size in object
count, rather than bytes. This had the
unfortunate effect of making memory use
depend on the size of objects -- repos
with lots of large objects could cause
out of memory deaths.
now, we track sizes in bytes, which should
keep our memory usage flatter.
|
|
We seem to have a botch in the protocol negotiation, where
we leak some protocol packets into the packfile; this will
need to be fixed before we put this change in.
|
|
when the remote side creates a new branch, it is
desirable to have it show up in the repo.
|
|
we were leaving objq.best uninitialized, and
would therefore read garbage if we didn't
find a best match.
|
