Signed-off-by: Michael Haggerty
---
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 *path)
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):
safe_create_leading_dir
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 to
Signed-off-by: Michael Haggerty
---
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 safe_create_leading_dir
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
---
sha1_file.c | 36 ++--
1 file change
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
Samuel Bronson 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 message
Adam Spiers 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: being able
Duy Nguyen 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 this wa
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 free_commit_extra_headers(struct commit_extra_hea
On Sat, Dec 21, 2013 at 4:42 AM, Jeff King 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, auto-dete
Jeff King 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 see in t
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
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
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
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 form
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 m
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
The sha1write function returns an int, but it will always be
"0". The failure-prone parts of the function happen in the
"flush" callback, which cannot pass an error back to us. So
we just end up calling die() during the flush.
Let's just drop the return value altogether, as it only
confuses caller
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 Ramsa
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: a
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. H
From: Vicent Marti
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 calling
`pack-object
From: Vicent Marti
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 would
use the path
From: Ramsay Jones
Signed-off-by: Ramsay Jones
Signed-off-by: Junio C Hamano
Signed-off-by: Jeff King
---
compat/mingw.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index 92cd728..8828ede 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -345,6 +345,7
From: Vicent Marti
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 walk during the
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: Nguyễn Thái Ngọc Duy
Count-objects will report any "garbage" files in the packs
directory, including files whose extensions it does not
know (case 1), and files whose matching ".pack" file is
missing (case 2). Without having learned about ".bitmap"
files, the current code reports all such
From: Vicent Marti
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 be found
in `Doc
From: Vicent Marti
This is the technical documentation for the JGit-compatible Bitmap v1
on-disk format.
Signed-off-by: Vicent Marti
Signed-off-by: Jeff King
---
Documentation/technical/bitmap-format.txt | 131 ++
1 file changed, 131 insertions(+)
create mode 1006
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.
Sig
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
---
builtin/repack.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/repack.c
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
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 goal of this word-al
From: Vicent Marti
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 if we are
repacki
From: Vicent Marti
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 blobs were found).
This is slightly more verbose, but will let us annotate the
extensions with further options in future commits.
Signed-off-by: Jeff King
---
builtin/repack.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index 2e88975..a
From: Vicent Marti
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.
Many thanks to Rams
From: Vicent Marti
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 each call.
Signed
From: Vicent Marti
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 and
adding entries
From: Vicent Marti
As the pack-objects system grows beyond the single
pack-objects.c file, more parts (like the soon-to-exist
bitmap code) will need to compute hashes for matching
deltas. Factor out name_hash to make it available to other
files.
Signed-off-by: Vicent Marti
Signed-off-by: Jeff K
From: Vicent Marti
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"
list of the rev
From: Vicent Marti
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
Signed-off-by: Jeff King
---
cache.h | 1 +
sha1_file.c | 4 +---
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/
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
---
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 53f5375..465971c 10064
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
-
On Sat, Dec 07, 2013 at 05:51:43PM +0100, Thomas Rast wrote:
> Jeff King 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 that
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
> matte
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. Re
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 archi
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 w
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
> + *
On Thu, Dec 19, 2013 at 7:58 PM, Junio C Hamano wrote:
> Christian Couder 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 tighten
> it recently?
>
> And that mak
52 matches
Mail list logo
