A caller of sha1_object_info_extended technically has enough
information to determine the base sha1 from the results of
the call. It knows the pack, offset, and delta type of the
object, which is sufficient to find the base.
However, the functions to do so are not publicly available,
and the code
This series lets you query the delta base for a particular object (or
set of objects), like:
$ git rev-list --objects --all |
git cat-file --batch-check='%(objectname) %(deltabase) %(rest)'
The only other way I know of to get this information is using
verify-pack (or index-pack), which is
It can be useful for debugging or analysis to see which
objects are stored as delta bases on top of others. This
information is available by running `git verify-pack`, but
that is extremely expensive (and is harder than necessary to
parse).
Instead, let's make it available as a cat-file query
Am 21.12.2013 10:48, schrieb fREW Schmidt:
Hello all,
I was on a plane, moving around some of the many (30ish) submodules in
my dotfiles and got really annoyed at how much work it is (move the
dir, remove old from git, add new to git, fix .gitmodules, fix
.git/config, fix all the parts of
On Sat, Dec 21, 2013 at 05:08:59PM +0100, Jens Lehmann wrote:
Am 21.12.2013 10:48, schrieb fREW Schmidt:
Thanks for sharing! Form a cursory look over your perl script it
looks like it does what stock git mv will do since 1.8.5 (except
for changing the name of the submodule, which I would not
Hello dear
I will be very happy to be your friend.
My name is miss. Ann Stokes. Please i will like you to
write me through my email address ( ann...@yahoo.fr ) .
I will send my pictures to you and also tell you more about
myself when i receive your email.
I will be waiting for your mail in my mail
Jeff King p...@peff.net writes:
Here's the v4 re-roll of the pack bitmap series.
The changes from v3 are:
- reworked add_object_entry refactoring (see patch 11, which is new,
and patch 12 which builds on it in a more natural way)
This now looks like this (pasting because it is hard to
On Sat, Dec 21, 2013 at 4:42 AM, Jeff King p...@peff.net wrote:
On Fri, Dec 20, 2013 at 10:45:01AM -0500, Samuel Bronson wrote:
These warnings don't really seem to make much sense for this file.
Agreed, though the advice so far has been to put -Wno-format-zero-length
in your CFLAGS.
Yes,
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
commit.c | 4 ++--
commit.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/commit.c b/commit.c
index 5df1df7..5ff5538 100644
--- a/commit.c
+++ b/commit.c
@@ -1356,7 +1356,7 @@ void
Duy Nguyen pclo...@gmail.com writes:
I am not happy with the choice of main/HEAD that would squat on a
good name for remote-tracking branch (i.e. s/origin/main/), though.
$GIT_DIR/COMMON_HEAD perhaps?
It's not just about HEAD. Anything worktree-specific of the main
checkout can be accessed
Adam Spiers g...@adamspiers.org writes:
I doubt it. 75% of the work for such a person to understand the
behaviour from such an example is to understand what kind of history
the example is building.
Agreed. And that's precisely why I wanted a real repository
manifesting the given example:
Samuel Bronson naes...@gmail.com writes:
I learned of git cherry some days ago, but only learned of --cherry
and related options to git log today[1] (more-or-less by chance).
If the git-cherry(1) manpage had mentioned --cherry, I would have
learned of these options sooner.
This proposed log
It could be that some other process is trying to clean up empty
directories at the same time that safe_create_leading_directories() is
attempting to create them. In this case, it could happen that
directory a/b was present at the end of one iteration of the loop
(either it was already present or
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
sha1_file.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index c9245a6..cc9957e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -108,9 +108,10 @@ int mkdir_in_gitdir(const char *path)
int
Keep track of the position of the slash character separately, and
restore the slash character at a single place, at the end of the while
loop. This makes the next change easier to implement.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
sha1_file.c | 36
When renaming a reflog file, it was possible that an empty directory
that we just created using safe_create_leading_directories() might get
deleted by another process before we have a chance to move the new
file into it.
So if the rename fails with ENOENT, then retry from the beginning.
Make up
There seem to be a lot of mkdir/rmdir races in the Git code. Fix two
of them.
It is hard to construct test cases for races without a lot of extra
test infrastructure. So I have tested them as best I can using
instrumented code (not included here).
Michael Haggerty (5):
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
sha1_file.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index daacc0c..c9245a6 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -125,8 +125,7 @@ int safe_create_leading_directories(char
On Thu, Dec 19, 2013 at 7:58 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder christian.cou...@gmail.com writes:
I think this last one might be useful for people replacing objects
with objects that have another type.
... which IIUC is strongly discouraged---didn't you have to
On Fri, Dec 20, 2013 at 10:45:01AM -0500, Samuel Bronson wrote:
These warnings don't really seem to make much sense for this file.
Agreed, though the advice so far has been to put -Wno-format-zero-length
in your CFLAGS.
+/* We have good reasons for using zero-length format strings, and
+ *
Hello all,
I was on a plane, moving around some of the many (30ish) submodules in
my dotfiles and got really annoyed at how much work it is (move the
dir, remove old from git, add new to git, fix .gitmodules, fix
.git/config, fix all the parts of the submodule config) so I wrote a
perl script to
On Sat, Dec 07, 2013 at 04:47:20PM +0100, Thomas Rast wrote:
+static off_t write_reused_pack(struct sha1file *f)
+{
+ uint8_t buffer[8192];
We usually just call this 'unsigned char'. I can see why this would be
more portable, but git would already fall apart badly on an architecture
On Sat, Dec 07, 2013 at 05:32:43PM +0100, Thomas Rast wrote:
+pack.writebitmaps::
+ When true, git will write a bitmap index when packing all
+ objects to disk (e.g., as when `git repack -a` is run). This
^^
Doesn't sound right in my ears. Remove the
On Sat, Dec 07, 2013 at 05:43:29PM +0100, Thomas Rast wrote:
One nit:
+test_expect_success JGIT 'jgit can read our bitmaps' '
+ git clone . compat-us.git
+ (
+ cd compat-us.git
The name suggests a bare repo, but it is a full clone. Not that it
matters.
It was
On Sat, Dec 07, 2013 at 05:51:43PM +0100, Thomas Rast wrote:
Jeff King p...@peff.net writes:
+test_perf 'simulated fetch' '
+ have=$(git rev-list HEAD --until=1.week.ago -1)
This will give you HEAD if your GIT_PERF_LARGE_REPO hasn't seen any
activity lately. I'd prefer something
Here's the v4 re-roll of the pack bitmap series.
The changes from v3 are:
- reworked add_object_entry refactoring (see patch 11, which is new,
and patch 12 which builds on it in a more natural way)
- better error/die reporting from write_reused_pack
- added Ramsay's PRIx64 compat fix
-
We are passed a void * and write it out without ever
touching it; let's indicate that by using const.
Signed-off-by: Jeff King p...@peff.net
---
csum-file.c | 6 +++---
csum-file.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/csum-file.c b/csum-file.c
index
From: Vicent Marti tan...@gmail.com
The `git_open_noatime` helper can be of general interest for other
consumers of git's different on-disk formats.
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 1 +
sha1_file.c | 4 +---
2 files changed,
From: Vicent Marti tan...@gmail.com
The hash table that stores the packing list for a given `pack-objects`
run was tightly coupled to the pack-objects code.
In this commit, we refactor the hash table and the underlying storage
array into a `packing_data` struct. The functionality for accessing
From: Vicent Marti tan...@gmail.com
This commit enables users of `struct rev_info` to peform custom limiting
during a revision walk (i.e. `get_revision`).
If the field `include_check` has been set to a callback, this callback
will be issued once for each commit before it is added to the pending
From: Vicent Marti tan...@gmail.com
The POSIX standard doesn't currently define a `ntohll`/`htonll`
function pair to perform network-to-host and host-to-network
swaps of 64-bit data. These 64-bit swaps are necessary for the on-disk
storage of EWAH bitmaps if they are not in native byte order.
From: Vicent Marti tan...@gmail.com
Allow users to efficiently lookup consecutive entries that are expected
to be found on the same revindex by exporting `find_revindex_position`:
this function takes a pointer to revindex itself, instead of looking up
the proper revindex for a given packfile on
From: Vicent Marti tan...@gmail.com
Since `pack-objects` will write a `.bitmap` file next to the `.pack` and
`.idx` files, this commit teaches `git-repack` to consider the new
bitmap indexes (if they exist) when performing repack operations.
This implies moving old bitmap indexes out of the way
From: Vicent Marti tan...@gmail.com
The bitmap reachability index used to speed up the counting objects
phase during `pack-objects` can also be used to optimize a normal
rev-list if the only thing required are the SHA1s of the objects during
the list (i.e., not the path names at which trees and
This is slightly more verbose, but will let us annotate the
extensions with further options in future commits.
Signed-off-by: Jeff King p...@peff.net
---
builtin/repack.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
Now that we can read and write bitmaps, we can exercise them
with some basic functionality tests. These tests aren't
particularly useful for seeing the benefit, as the test
repo is too small for it to make a difference. However, we
can at least check that using bitmaps does not break anything.
We have a static array of extensions, but hardcode the size
of the array in our loops. Let's pull out this magic number,
which will make it easier to change.
Signed-off-by: Jeff King p...@peff.net
---
builtin/repack.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
This function actually does three things:
1. Check whether we've already added the object to our
packing list.
2. Check whether the object meets our criteria for adding.
3. Actually add the object to our packing list.
It's a little hard to see these three phases, because they
happen
From: Vicent Marti tan...@gmail.com
EWAH is a word-aligned compressed variant of a bitset (i.e. a data
structure that acts as a 0-indexed boolean array for many entries).
It uses a 64-bit run-length encoding (RLE) compression scheme,
trading some compression for better processing speed.
The
From: Vicent Marti tan...@gmail.com
A bitmap index is a `.bitmap` file that can be found inside
`$GIT_DIR/objects/pack/`, next to its corresponding packfile, and
contains precalculated reachability information for selected commits.
The full specification of the format for these bitmap indexes can
From: Vicent Marti tan...@gmail.com
This is the technical documentation for the JGit-compatible Bitmap v1
on-disk format.
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
Documentation/technical/bitmap-format.txt | 131 ++
1
From: Vicent Marti tan...@gmail.com
In this patch, we use the bitmap API to perform the `Counting Objects`
phase in pack-objects, rather than a traditional walk through the object
graph. For a reasonably-packed large repo, the time to fetch and clone
is often dominated by the full-object revision
We ask pack-objects to pack to a set of temporary files, and
then rename them into place. Some files that pack-objects
creates may be optional (like a .bitmap file), in which case
we would not want to call rename(). We already call stat()
and make the chmod optional if the file cannot be accessed.
From: Vicent Marti tan...@gmail.com
When we use pack bitmaps rather than walking the object
graph, we end up with the list of objects to include in the
packfile, but we do not know the path at which any tree or
blob objects would be found.
In a recently packed repository, this is fine. A fetch
This adds a few basic perf tests for the pack bitmap code to
show off its improvements. The tests are:
1. How long does it take to do a repack (it gets slower
with bitmaps, since we have to do extra work)?
2. How long does it take to do a clone (it gets faster
with bitmaps)?
3.
From: Vicent Marti tan...@gmail.com
This commit extends more the functionality of `pack-objects` by allowing
it to write out a `.bitmap` index next to any written packs, together
with the `.idx` index that currently gets written.
If bitmap writing is enabled for a given repository (either by
From: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Jeff King p...@peff.net
---
compat/mingw.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index
On Sat, Dec 21, 2013 at 08:56:51AM -0500, Jeff King wrote:
Interdiff is below.
[01/23]: sha1write: make buffer const-correct
[02/23]: revindex: Export new APIs
[03/23]: pack-objects: Refactor the packing list
[04/23]: pack-objects: factor out name_hash
[05/23]: revision: allow
On Sat, Dec 21, 2013 at 08:56:51AM -0500, Jeff King wrote:
The changes from v3 are:
- reworked add_object_entry refactoring (see patch 11, which is new,
and patch 12 which builds on it in a more natural way)
- better error/die reporting from write_reused_pack
- added Ramsay's
49 matches
Mail list logo
