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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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 just
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 definitely
Am 10/24/2013 22:04, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net 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
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
its
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 p...@peff.net
---
git-add--interactive.perl | 22
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
On Fri, Oct 25, 2013 at 8:14 AM, Jeff King p...@peff.net wrote:
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
On Fri, Oct 25, 2013 at 09:03:41AM +0200, Johan Herland wrote:
Actually, I don't think there's much refspec stuff to be done here.
When running git diff $remote/$branch, there are 3 possible
outcomes:
- $remote is not a valid remote name, the user probably meant
something different (like
Am 10/25/2013 0:21, schrieb Junio C Hamano:
+test_expect_success 'using reflog to find the fork point' '
+ git reset --hard
+ git checkout -b base $E
+
+ for count in 1 2 3 4 5
+ do
+ git commit --allow-empty -m Base commit #$count
+ git rev-parse
Hello everybody
I am looking into the git configuration mechanism and there seem to
be a hole in use cases I'm trying to figure out...
git configurations can be saved at various places
* /etc/gitconfig : system-wide configuration
* ~/.gitconfig : user-wide configuration
* .git/config :
On Fri, Oct 25, 2013 at 9:10 AM, Jeff King p...@peff.net wrote:
On Fri, Oct 25, 2013 at 09:03:41AM +0200, Johan Herland wrote:
1. Split the input on the first '/' into $remote/$branch, and use the
preceding part ($remote) as a potential remote name, and the following
part ($branch) as a
On Thu, Oct 17, 2013 at 08:47:05AM -0700, Junio C Hamano wrote:
In general, I don't think we know enough about patterns of recovery
corruption to say which commands would definitely be worth implementing.
Part of the reason I wrote this up is to document this one case. But
this is the
On Fri, Oct 25, 2013 at 09:12:10AM +0200, Johannes Sixt wrote:
Am 10/25/2013 0:21, schrieb Junio C Hamano:
+test_expect_success 'using reflog to find the fork point' '
+ git reset --hard
+ git checkout -b base $E
+
+ for count in 1 2 3 4 5
+ do
+ git commit
Am 10/25/2013 10:09, schrieb John Keeping:
On Fri, Oct 25, 2013 at 09:12:10AM +0200, Johannes Sixt wrote:
You could put the loops into a function from which you 'return', but that
is obscure in this case. The first iteration was better, IMO.
Wouldn't it be simpler to just return from the
On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:
however I can't find a way to have the repository's configuration
saved and transmited with the repository in a way similar to how
.gitignore is transmitted...
[...]
Knowing how mature git is I can only assume that this has
We offer Funds/ money to all in need at very low interest rate 3% no collateral
involved we will be able to give you any amount ranging from $ 5,000-$
5,000,000 interest rate negotiable, with repayment allowed from 1-20 years if
interested contact us now via email (misglorialoanf...@gmail.com)
(Jonathan, sorry if you got this multiple times, it seems I forgot to Cc list)
On Mon, Oct 21, 2013 at 8:40 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Should the git-diff(1) manpage get a note about this setting as
well (perhaps in a new CONFIGURATION section)?
I'll add a reference to the
Dear account owner
Your mailbox has exceeded the set storage limit which is 20GB.
You are currently running on 19.8GB due to hidden files and folder on
your mailbox.
Your email account would be blocked from sending and receiving emails
if your email account is not verified with in 48hrs.
You are
Jeff King peff at peff.net writes:
On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:
however I can't find a way to have the repository's configuration
saved and transmited with the repository in a way similar to how
.gitignore is transmitted...
[...]
Two, the config is
On Fri, Oct 25, 2013 at 3:21 AM, Jeff King p...@peff.net wrote:
[+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:
+
+
On Thu, Oct 24, 2013 at 6:03 PM, Jeff King p...@peff.net wrote:
If `prepare_bitmap_walk` runs successfully, the resulting bitmap is
stored and the equivalent of a `traverse_commit_list` call can be
performed by using `traverse_bitmap_commit_list`; the bitmap version
of this call yields the
On Thu, Oct 24, 2013 at 6:06 PM, Jeff King p...@peff.net wrote:
Note that most of the time we spend for --count invocations is on
generating the pack revindex. It may be worth storing a revidx (either
in a separate file, as part of the .idx, or as an optional section in
the .bitmap file).
On Thu, Oct 24, 2013 at 6:04 PM, Jeff King p...@peff.net wrote:
For bitmaps to be used, the following must be true:
1. We must be packing to stdout (as a normal `pack-objects` from
`upload-pack` would do).
2. There must be a .bitmap index containing at least one of the
have
On 10/24/2013 10:51 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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.name.refspec configuration to be
Hello,
Basically doing: git describe --abbrev=0 sha1 gives the closest tag
from sha1
I would expect adding --contains option would give the closest tag
containing sha1 but it seems that --abbrev=0 has no more effect in
that case:
$ git describe --tags --contains --abbrev=0
For projects with separate history lines and, thus, multiple root-commits, the
linear arrangement of `git log --graph --oneline` does not allow the user to
spot where the sequence ends, giving the impression that it's a contiguous
history. E.g.
History sequence A: a1 -- a2 -- a3 (root-commit)
Jeff King p...@peff.net writes:
3. Teach add--interactive to recognize the empty tree sha1 as an
unstage path.
I kind of like (3). At first glance, it is wrong; we will also treat
git reset -p $(git hash-object -t tree /dev/null) as if HEAD had
been passed. But if you are explicitly
Johannes Sixt j.s...@viscovery.net writes:
+for count in 1 2 3 4 5
+do
+git merge-base --reflog base $(cat derived$count) actual
+test_cmp expect$count actual || break
+done
This does not work as intended because the exit code of 'break' is always
Milton Soares Filho milton.soares.fi...@gmail.com writes:
git log --graph --oneline
* a1
* a2
x a3
* b1
* b2
x b3
I agree that the problem you are trying to solve is a good thing to
tackle, and I also agree that marking a root commit differently from
other
Add the --sticked-long option to output the options in their long form
if available, and with their arguments sticked.
Contrary to the default form (non sticked arguments and short options),
this can be parsed unambiguously when using options with optional
arguments :
- in the non sticked form,
On 25 October 2013 15:13, Junio C Hamano gits...@pobox.com wrote:
Milton Soares Filho milton.soares.fi...@gmail.com writes:
git log --graph --oneline
* a1
* a2
x a3
* b1
* b2
x b3
I agree that the problem you are trying to solve is a good thing to
tackle,
For projects with separate history lines and, thus, multiple root-commits, the
linear arrangement of `git log --graph --oneline` does not allow the user to
spot where the sequence ends, giving the impression that it's a contiguous
history. E.g.
History sequence A: a1 -- a2 -- a3 (root-commit)
On Fri, Oct 25, 2013 at 03:17:06AM -0400, Jeff King wrote:
I think that makes sense. Would you also want to suppress the probe
request in that case? It serves the same purpose, but would cause you to
do an extra auth for no reason (which potentially means user input,
which is annoying).
I
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, if
On Fri, Oct 25, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
diff --git a/Documentation/git-merge-base.txt
b/Documentation/git-merge-base.txt
index 87842e3..b383766 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -137,6 +143,31 @@ In
Nicolas Vigier bo...@mars-attacks.org writes:
Add the --sticked-long option to output the options in their long form
if available, and with their arguments sticked.
Hmph, doesn't verb stick conjugate to (present) stick (past) stuck
(pp) stuck?
--
To unsubscribe from this list: send the line
I was wondering : What if I had a malicious GIT repository who can
inject code via git hooks mechanism : someone clone my repo and
some malicious code is executed when a certain GIT hook is triggered
(for example on commit (prepare-commit-msg' hook)) ? What if I email
/etc/passwd for exemple ?
Olivier Revollat revol...@gmail.com writes:
I was wondering : What if I had a malicious GIT repository who can
inject code via git hooks mechanism : someone clone my repo and
some malicious code is executed when a certain GIT hook is triggered
(for example on commit (prepare-commit-msg'
On Fri, 25 Oct 2013, Junio C Hamano wrote:
Nicolas Vigier bo...@mars-attacks.org writes:
Add the --sticked-long option to output the options in their long form
if available, and with their arguments sticked.
Hmph, doesn't verb stick conjugate to (present) stick (past) stuck
(pp) stuck?
Nicolas Vigier bo...@mars-attacks.org writes:
On Fri, 25 Oct 2013, Junio C Hamano wrote:
Nicolas Vigier bo...@mars-attacks.org writes:
Add the --sticked-long option to output the options in their long form
if available, and with their arguments sticked.
Hmph, doesn't verb stick
Jeff King p...@peff.net writes:
diff --git a/pack-bitmap.c b/pack-bitmap.c
new file mode 100644
index 000..73c52fd
--- /dev/null
+++ b/pack-bitmap.c
@@ -0,0 +1,965 @@
+#include stdlib.h
+
+#include cache.h
You among all people already know why this is bad, no?
I'll remove the first
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
[git-scm.com/community doesn't say whether the address for bug reports
allows posting by non-list members, so hopefully this makes it through
the moderation process]
I'm building git 1.8.4.1 on x86_64-pc-solaris2.11 (OpenIndiana 151a8,
one of the opensource distributions that came out of the
No, the .git/hooks directory in your clone is created from your local
templates, installed with your Git distribution, not the remote hooks.
On Linux distributions, these templates are often in someplace like
/usr/share/git-core/templates (for normal packages), and on Windows
with msysgit they are
Normally parse_pathspec() is used on command line arguments where it
can do fancy thing like parsing magic on each argument or adding magic
for all pathspecs based on --*-pathspecs options.
There's another use of parse_pathspec(), where pathspec is needed, but
the input is known to be pure paths.
Milton Soares Filho milton.soares.fi...@gmail.com writes:
On 25 October 2013 15:13, Junio C Hamano gits...@pobox.com wrote:
Milton Soares Filho milton.soares.fi...@gmail.com writes:
git log --graph --oneline
* a1
* a2
x a3
* b1
* b2
x b3
I agree that the
In git 1.7.0.4, what's the correct way to preview what a git pull
would do, without actually doing it? Unlike most git subcommands,
pull seems not to understand --dry-run:
$ git pull --dry-run
sed: can't read {pathname suppressed}/.git/FETCH_HEAD: No such file or directory
You asked to pull from
Thanks for taking care of this! Maybe John or I can finally get the
changes to rebase done after this.
A few comments below. Sorry I didn't find time to review the earlier revisions.
On Fri, Oct 25, 2013 at 2:38 PM, Junio C Hamano gits...@pobox.com wrote:
+
+where `origin/master` used to point
On 10/24/2013 10:51 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
diff --git a/Documentation/fetch-options.txt
b/Documentation/fetch-options.txt
index ba1fe49..0e6d2ac 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -61,11
66 matches
Mail list logo
