The add--interactive --patch mode adjusts the UI based on
whether we are pulling changes from HEAD or elsewhere (in
the former case it asks to unstage the reverse hunk, rather
than apply the forward hunk).
Commit 166ec2e taught reset to work on an unborn branch, but
in doing so, switched to always
The list_modified function already knows how to handle an
unborn branch by diffing against the empty tree. However,
the diff we perform to get the actual hunks does not. Let's
use the same logic for both diffs.
Signed-off-by: Jeff King
---
git-add--interactive.perl | 22 +-
1
On Thu, Oct 24, 2013 at 10:42:52PM -0700, Martin von Zweigbergk wrote:
> > I think that's the correct fix for the regression. You are restoring
> > the original, pre-166ec2e9 behavior for just the HEAD case. I do not
> > think add--interactive does any other magic between a symbolic rev and
> > i
Am 10/24/2013 22:04, schrieb Junio C Hamano:
> Johannes Sixt writes:
>> That said, I don't think that --change-id option that the user must not
>> forget to use is any better than a hook that the user must not forget to
>> install.
>
> That is why I said this in my first response to this thread:
On Fri, Oct 25, 2013 at 02:14:07AM -0400, Jeff King wrote:
> > Could this error message be improved for interactive commands by
> > first checking to see whether or not the path starts with a remote,
> > then recommend that the remote be pulled?
>
> That might be worth doing. We cannot defini
On Thu, Oct 24, 2013 at 11:07:05AM -0700, yaneurabeya . wrote:
> I added an arbitrary upstream remote thinking that I could just
> git diff the upstream remote's master. Turns out I needed to run git
> pull --all in order to be able to diff the file (I forgot that step).
Actually, you can jus
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
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
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).
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.
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
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
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
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: 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
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
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/
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
The POSIX standard doesn't currently define a `nothll`/`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.
Signed-off-by: Vice
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
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
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
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
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
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
On Thu, Oct 24, 2013 at 01:59:15PM -0400, Jeff King wrote:
> This series implements JGit-style pack bitmaps to speed up fetching and
> cloning.
Here is a re-roll fixing the comments so far. I know that nobody is
likely to have had a chance to read through it carefully yet, but given
the compiler
Sorry about the regression and thanks for report and fixes.
On Thu, Oct 24, 2013 at 9:24 PM, Jeff King wrote:
> On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote:
>
>> Maarten de Vries writes:
>>
>> > Some more info: It used to work as intended. Using a bisect shows it
>> > has been
On Fri, Oct 25, 2013 at 11:37 AM, Jeff King wrote:
> On Thu, Oct 24, 2013 at 12:40:44PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > That would also provide people who do not like the change of default an
>> > escape hatch to keep the current behavior. And I do not think scripted
>
On Thu, Oct 24, 2013 at 12:40:44PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > That would also provide people who do not like the change of default an
> > escape hatch to keep the current behavior. And I do not think scripted
> > use will be inconvenienced; they will already have to u
Karsten Blees wrote:
> (2) Index
>
> An index, as in a library, maps almost perfectly to what the git index is
> _and_ what we do with it.
Not really. An index in the context of a library, and in any other context, is
a tool that indicates where something is, in order to find it quickly.
That is
On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote:
> Maarten de Vries writes:
>
> > Some more info: It used to work as intended. Using a bisect shows it
> > has been broken by commit 166ec2e9.
>
> Thanks.
>
> A knee-jerk change without thinking what side-effect it has for you
> to
On Fri, Oct 25, 2013 at 11:16:08AM +0700, Nguyen Thai Ngoc Duy wrote:
> > All of the GUARD_PATHSPEC calls indicate that everybody understands
> > PATHSPEC_LITERAL. It is not technically true that git-blame understands
> > the literal pathspec magic:
> >
> > $ git blame -- ':(literal)revision.c'
On Fri, Oct 25, 2013 at 11:04 AM, Jeff King wrote:
> On Thu, Oct 24, 2013 at 11:49:47PM -0400, Jeff King wrote:
>
>> We get another change with a16bf9d (pathspec: make --literal-pathspecs
>> disable pathspec magic, 2013-07-14), which I would think would fix
>> things, but doesn't.
>>
>> $ git bl
On Fri, Oct 25, 2013 at 10:49 AM, Jeff King wrote:
> $ git --literal-pathspecs blame ':(foo)bar'
> fatal: :(foo)bar: pathspec magic not supported by this command: 'literal'
>
> The first one remains good, but the second one is still broken. I
> haven't dug further yet, but I thought it might b
On Thu, Oct 24, 2013 at 11:49:47PM -0400, Jeff King wrote:
> We get another change with a16bf9d (pathspec: make --literal-pathspecs
> disable pathspec magic, 2013-07-14), which I would think would fix
> things, but doesn't.
>
> $ git blame ':(foo)bar'
> fatal: Invalid pathspec magic 'foo' in
There seems to be a bad interaction with --literal-pathspecs and the
pathspec magic that is in master. Here's an example:
[setup]
$ git init
$ echo content >':(foo)bar'
$ git add . && git commit -m foo
[with git v1.8.4]
$ git blame ':(foo)bar'
^6b07eb4 (Jeff King 2013-10-24 22:59:02
Maarten de Vries writes:
> Some more info: It used to work as intended. Using a bisect shows it
> has been broken by commit 166ec2e9.
Thanks.
A knee-jerk change without thinking what side-effect it has for you
to try out.
builtin/reset.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(
On Fri, Oct 25, 2013 at 10:21 AM, Jeff King wrote:
> But if you want to simply add extra
> data that would be ignored by an existing implementation, it would be OK
> to add the data and mark it with a flag:
>
>> > + 2-byte flags (network byte order)
>> > +
>> > +
On Fri, Oct 25, 2013 at 08:21:12AM +0700, Nguyen Thai Ngoc Duy wrote:
> > If bitmap writing is enabled for a given repository (either by calling
> > `pack-objects` with the `--write-bitmap-index` flag or by having
> > `pack.writebitmaps` set to `true` in the config) and pack-objects is
> > writing
[+cc spearce; sorry, I really should have cc'd the whole series to you
in the first place]
On Fri, Oct 25, 2013 at 08:16:18AM +0700, Nguyen Thai Ngoc Duy wrote:
> > + - A header appears at the beginning:
> > +
> > + 4-byte signature: {'B', 'I', 'T', 'M'}
> > +
> > +
On Thu, Oct 24, 2013 at 04:34:48PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > 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).
>
> I think I've already pointed out s
On Thu, Oct 24, 2013 at 9:46 AM, Duy Nguyen wrote:
> On Thu, Oct 24, 2013 at 2:49 PM, Perry Hutchison
> wrote:
>> Duy Nguyen wrote:
>>
>>> ... it's not easy to determine ambiguity here, especially when the
>>> repo finding code does not know anything about "bar/barz.c" (is it
>>> a pathname or
This is only to tentatively work-around the compilation breakages;
the fixes need to be split into the respective patches that
introduce breakages when the series is rerolled (the one I sent for
pack-bitmap.c separately is also included in this message).
Thanks.
ewah/ewah_bitmap.c | 22
John Keeping writes:
> To clarify: the particular commit in the calls above happens to be the
> oldest entry in the reflog, if I pick a newer entry then it works.
>
> It seems that for_each_reflog_ent isn't returning the oldest entry;
> revs.nr is 62 whereas "git rev-list -g origin/master | wc -l
On Thu, Oct 24, 2013 at 12:40 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> That would also provide people who do not like the change of default an
>> escape hatch to keep the current behavior. And I do not think scripted
>> use will be inconvenienced; they will already have to use "." or ":
On Fri, Oct 25, 2013 at 1:06 AM, Jeff King wrote:
> 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
On Fri, Oct 25, 2013 at 1:03 AM, Jeff King wrote:
> diff --git a/Documentation/technical/bitmap-format.txt
> b/Documentation/technical/bitmap-format.txt
> new file mode 100644
> index 000..c686dd1
> --- /dev/null
> +++ b/Documentation/technical/bitmap-format.txt
> @@ -0,0 +1,131 @@
> +GIT bit
On Fri, Oct 25, 2013 at 2:49 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Thu, Oct 24, 2013 at 12:52 AM, Junio C Hamano wrote:
>>> Nguyễn Thái Ngọc Duy writes:
>>>
The strcpy call in open_output_fd() implies that the output buffer
must be at least 25 chars long.
>>>
>>> Hmph
Jeff King writes:
> 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).
I think I've already pointed out some when the original series was
posted, but this does not seem to compile with -
Some more info: It used to work as intended. Using a bisect shows it
has been broken by commit 166ec2e9.
Kinds regards,
Maarten de Vries
On 25 October 2013 01:05, Maarten de Vries wrote:
> Hi,
>
> I noticed that reset -p HEAD is inconsistent with checkout -p HEAD.
> When running checkout -p you
Hi,
I noticed that reset -p HEAD is inconsistent with checkout -p HEAD.
When running checkout -p you are asked to discard hunks from the index
and worktree, but when running reset -p you are asked to apply hunks
to the index. It would make more sense if reset -p asked to discard
(reversed) hunks f
Renich Bon Ciric writes:
> I think file permissions are really important for source code as well.
>
> For example, in web development, you want configuration files to be
> read only; specially if you're deploying with git.
That is not _source code_; you are talking about deployed set of
files, a
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example
Eric Sunshine writes:
> On Thu, Oct 24, 2013 at 5:26 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>>> On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano wrote:
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index f80bba8..3a1abee 100755
--- a/t/t6010-merge-base
On Thu, Oct 24, 2013 at 10:40:07PM +0100, John Keeping wrote:
> On Thu, Oct 24, 2013 at 10:31:35PM +0100, John Keeping wrote:
> > On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
> > > John Keeping writes:
> > >
> > > > On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 24, 2013 at 5:26 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano wrote:
>>> diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
>>> index f80bba8..3a1abee 100755
>>> --- a/t/t6010-merge-base.sh
>>> +++ b/t/t6010-merge-base
On Thu, Oct 24, 2013 at 10:31:35PM +0100, John Keeping wrote:
> On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
> > John Keeping writes:
> >
> > > On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
> > >> The first one is a clean-up of the code to parse command line
>
Hello,
I think file permissions are really important for source code as well.
For example, in web development, you want configuration files to be
read only; specially if you're deploying with git.
Also, you would want some executable file to not be writable ; but
executable by world.
Permission
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
> >> The first one is a clean-up of the code to parse command line
> >> options to "git merge-base". Options such as "--independent",
> >>
Eric Sunshine writes:
> On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano wrote:
>> diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
>> index f80bba8..3a1abee 100755
>> --- a/t/t6010-merge-base.sh
>> +++ b/t/t6010-merge-base.sh
>> @@ -230,4 +230,31 @@ test_expect_success 'criss-cross mer
I finished reading thru the remainder and all looked good (again
except minor nits I sent reviews for separately).
Thanks, will queue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.
John Keeping writes:
> On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
>> The first one is a clean-up of the code to parse command line
>> options to "git merge-base". Options such as "--independent",
>> "--is-ancestor" and "--octopus" are mutually exclusive and it is
>> better e
Michael Haggerty writes:
> ...
> Signed-off-by: Michael Haggerty
Everything in the proposed log message made sense to me.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index d4d93c9..83c1700 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2
On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano wrote:
> diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
> index f80bba8..3a1abee 100755
> --- a/t/t6010-merge-base.sh
> +++ b/t/t6010-merge-base.sh
> @@ -230,4 +230,31 @@ test_expect_success 'criss-cross merge-base for
> octopus-step' '
Ramsay Jones wrote:
> Commit 1bbcc224 ("http: refactor options to http_get_*", 28-09-2013)
> changed the type of final 'options' argument of the http_get_file()
> function from an int to an 'struct http_get_options' pointer.
> However, it neglected to update the (single) call site. Since this
> ca
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
> The first one is a clean-up of the code to parse command line
> options to "git merge-base". Options such as "--independent",
> "--is-ancestor" and "--octopus" are mutually exclusive and it is
> better expressed in terms of the rece
Michael Haggerty writes:
> Previously, fetch's "--tags" option was considered equivalent to
> specifying the refspec "refs/tags/*:refs/tags/*" on the command line;
> in particular, it caused the remote..refspec configuration to be
> ignored.
>
> But it is not very useful to fetch tags without als
On Mon, Oct 21, 2013 at 10:40:22PM -0700, Martin von Zweigbergk wrote:
> On Wed, Oct 16, 2013 at 11:53 AM, John Keeping wrote:
> > Commit 15a147e (rebase: use @{upstream} if no upstream specified,
> > 2011-02-09) says:
> >
> > Make it default to 'git rebase @{upstream}'. That is also what
Jeff King writes:
> A similar series has been running on github.com for the past couple of
> months, though not every repository has had bitmaps turned on (but some
> very busy ones have). We've hopefully squeezed out all of the bugs and
> corner cases over that time. However, I did rebase this
Commit 1bbcc224 ("http: refactor options to http_get_*", 28-09-2013)
changed the type of final 'options' argument of the http_get_file()
function from an int to an 'struct http_get_options' pointer.
However, it neglected to update the (single) call site. Since this
call was passing '0' to that arg
Johannes Sixt writes:
> Am 10/24/2013 7:25, schrieb Duy Nguyen:
>> On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi
>> wrote:
> It is not clear to me how you envision to make it work.
I don't have the source code.
>>>
>>> Now you do:
>>> https://gerrit.googlesource.com/gerrit/+/
Michael Haggerty writes:
>> As long as you have checked that our local 'master' should be at the
>> same commit as the origin's 'master' at this point, I think this
>> change is OK.
>
> It doesn't matter what the reference points at; the only point of these
> tests is to check whether branches th
Duy Nguyen writes:
> On Thu, Oct 24, 2013 at 12:52 AM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> The strcpy call in open_output_fd() implies that the output buffer
>>> must be at least 25 chars long.
>>
>> Hmph, where does that 25 come from?
>>
>> [snipped]
>
> Much better. T
Jeff King writes:
> That would also provide people who do not like the change of default an
> escape hatch to keep the current behavior. And I do not think scripted
> use will be inconvenienced; they will already have to use "." or ":/" to
> be explicit (if they care) since the behavior is changi
The "git pull --rebase" command computes the fork point of the
branch being rebased using the reflog entries of the "base" branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the "base" branch has been
rewound and rebuilt. For example
The first one is a clean-up of the code to parse command line
options to "git merge-base". Options such as "--independent",
"--is-ancestor" and "--octopus" are mutually exclusive and it is
better expressed in terms of the recently introduced OPT_CMDMODE.
The second one implements the entire logic
The --octopus, --independent and --is-ancestor are mutually
exclusive command modes (in addition to not giving any of these
options), so represent them as such using the recent OPT_CMDMODE
facility available since 11588263 (parse-options: add OPT_CMDMODE(),
2013-07-30), which is in v1.8.4-82-g366b8
Martin von Zweigbergk writes:
> I think
>
> git merge-base HEAD $(git rev-list -g "$upstream_name")
>
> is roughly correct and hopefully fast enough. That can lead to too
> long a command line, so I was planning on teaching merge-base a
> --stdin option, but never got around to it.
Sorry for c
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
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).
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
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
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
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.
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
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
Hi!
I added an arbitrary upstream remote thinking that I could just
git diff the upstream remote's master. Turns out I needed to run git
pull --all in order to be able to diff the file (I forgot that step).
Could this error message be improved for interactive commands by
first checking to s
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
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
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
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
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/
From: Vicent Marti
The POSIX standard doesn't currently define a `nothll`/`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.
Signed-off-by: Vice
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 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
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
This series implements JGit-style pack bitmaps to speed up fetching and
cloning. For example, here is a simulation of the server side of a clone
of a fully-packed kernel repo (measuring actual clones is harder,
because the client does a lot of work on resolving deltas):
[before]
$ time git p
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
1 - 100 of 119 matches
Mail list logo
