Hello,
I just wanted to ask a question: why is there no bugzilla website for git ?
It's better to put bugs into such a tool to follow there evolution than to
manage bugs via a developpment mailing list ...
Best regards,
YC
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
On Wed, Nov 13, 2013 at 03:07:54PM -0800, Junio C Hamano wrote:
> * nd/liteal-pathspecs (2013-10-28) 1 commit
> (merged to 'next' on 2013-11-01 at 1a91775)
> + pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses
>
> Will cook in 'next'.
I think we want this to be part of v1
On Thu, Nov 14, 2013 at 8:44 PM, Jason St. John wrote:
> On Wed, Nov 13, 2013 at 4:56 PM, Junio C Hamano wrote:
>> "Jason St. John" writes:
>>
>>> Documentation/git-log.txt:
>>> -- replace single quotes around options/commands with backticks
>>> -- use single quotes around references to sections
2013/11/15 Torstein Hegge :
> Commit f2e0873 (branch: report invalid tracking branch as gone) removed
> an early return from fill_tracking_info() in the path taken when 'git
> branch -v' lists a branch in sync with its upstream. This resulted in an
> unconditionally added space in front of the subj
On Wed, Nov 13, 2013 at 4:56 PM, Junio C Hamano wrote:
> "Jason St. John" writes:
>
>> Documentation/git-log.txt:
>> -- replace single quotes around options/commands with backticks
>> -- use single quotes around references to sections
>> -- replaced some double quotes with proper AsciiDoc quotes
Various fixes:
-- fix typos (e.g. "show" -> "shown")
-- use "regular expression(s)" instead of "regexp" where appropriate
-- reword some sentences for easier reading
-- fix/improve some grammatical issues (e.g. comma usage)
-- add missing articles (e.g. "the")
-- change "E-mail" to "email"
Signed-
rev-list-options.txt:
-- Remove blank lines after some options subheadings to fix syntax
highlighting in Vim
-- Typeset literal options, commands, and path names in monospace
-- Remove AsciiDoc escapes with literal
-- Replace some double quotes with proper AsciiDoc quotes (e.g. ``foo'')
Signe
On 14/11/13 21:33, Jeff King wrote:
> On Thu, Nov 14, 2013 at 07:19:38PM +, Ramsay Jones wrote:
>
>> Unfortunately, I didn't find time this weekend to finish the msvc build
>> fixes. However, after a quick squint at these patches, I think you have
>> almost done it for me! :-D
>>
>> I must hav
The man pages contain inconsistent usage of backticks vs. single quotes
around options, commands, etc. that are in paragraphs. This commit states
that backticks should always be used around literal examples.
This commit states that "--" and friends should not be escaped
(e.g. use `--pretty=oneline
On Thu, Nov 14, 2013 at 07:11:31PM +0400, Konstantin Khomoutov wrote:
> > I just guess, that this limit comes from the O(N^2) complexity of the
> > comparison algorithm. Since the max 32-bit signed value is 2^31, then
> > the 2^15 = 32768 is somehow correlated with its square root, maybe,
> > like
Am 14.11.2013 20:08, schrieb Karsten Blees:
> Changes since v3:
s/v3/v4/
--
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, Nov 14, 2013 at 07:19:38PM +, Ramsay Jones wrote:
> Unfortunately, I didn't find time this weekend to finish the msvc build
> fixes. However, after a quick squint at these patches, I think you have
> almost done it for me! :-D
>
> I must have misunderstood the previous discussion, bec
Jeff King writes:
> This code is weird to follow because of the fall-throughs. I do not
> think you have introduced any bugs with your patch, but it seems weird
> to me that we set the offset at the top of the hunk. If we hit the
> conditional in the bottom half, we do actually increment storer.s
Am 29.10.2013 10:09, schrieb Karsten Blees:
> On Mon, Oct 28, 2013 at 10:04 PM, Vicent Martí wrote:
>>
>> On Mon, Oct 28, 2013 at 8:45 PM, Karsten Blees
>> wrote:
>>
>>> Regarding performance, khash uses open addressing, which requires more key
>>> comparisons (O(1/(1-load_factor))) than chaini
The existing hashtable implementation (in hash.[ch]) uses open addressing
(i.e. resolve hash collisions by distributing entries across the table).
Thus, removal is difficult to implement with less than O(n) complexity.
Resolving collisions of entries with identical hashes (e.g. via chaining)
is lef
When cache_entry structs are removed from index_state.cache, they are not
properly freed. Freeing those entries wasn't possible before because we
couldn't remove them from index_state.name_hash.
Now that we _do_ remove the entries from name_hash, we can also free them.
Add 'free(cache_entry)' to a
'git update-index --verbose' consistently reports paths relative to the
work-tree root. The only exception is the '--again' option, which reports
paths relative to the current working directory.
Change do_reupdate to use non-prefixed paths.
Signed-off-by: Karsten Blees
---
builtin/update-index.
do_reupdate calls update_one with a cache_entry.name, there's no need for
the extra sanitation / normalization that happens in prefix_path.
cmd_update_index calls update_one with an already prefixed path, no need to
prefix_path twice.
Remove the extra prefix_path from update_one. Also remove the n
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
Documentation/technical/api-hash.txt | 52 -
Makefile | 2 -
cache.h | 1 -
hash.c | 110 ---
The new hashmap implementation supports remove, so really remove unused
cache entries from the name hashmap instead of just marking them.
The CE_UNHASHED flag and CE_STATE_MASK are no longer needed.
Keep the CE_HASHED flag to prevent adding entries twice.
Signed-off-by: Karsten Blees
Signed-off
Note: the "ce->next = NULL;" in unpack-trees.c::do_add_entry can safely be
removed, as ce->next (now ce->ent.next) is always properly initialized in
name-hash.c::hash_index_entry.
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
cache.h| 8 +---
name-hash.c| 24 ++
The new hashmap implementation supports remove, so remove and free
directory entries that are no longer referenced by active cache entries.
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
name-hash.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --gi
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
cache.h | 3 ++-
name-hash.c | 77 +++--
2 files changed, 20 insertions(+), 60 deletions(-)
diff --git a/cache.h b/cache.h
index d1f3c71..84e9ad6 100644
--- a/cache.h
+++
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
diffcore-rename.c | 48 +---
1 file changed, 13 insertions(+), 35 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index cfeb408..9b4f068 100644
--- a/diffcore-rename.c
+++
On 14/11/13 12:41, Jeff King wrote:
> Here's another iteration of the pack bitmaps series. Compared to v2, it
> changes:
>
> - misc style/typo fixes
>
> - portability fixes from Ramsay and Torsten
Unfortunately, I didn't find time this weekend to finish the msvc build
fixes. However, after a q
The find_exact_renames function currently only uses the hash table for
grouping, i.e.:
1. add sources
2. add destinations
3. iterate all buckets, per bucket:
4. split sources from destinations
5. iterate destinations, per destination:
6. iterate sources to find best match
This can be simplified b
No actual code changes, just move hash_filespec up and outdent part of
find_identical_files.
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
diffcore-rename.c | 98 +++
1 file changed, 49 insertions(+), 49 deletions(-)
diff --g
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
builtin/describe.c | 53 -
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 6f62109..0b2cef4 100644
--- a/builtin/descri
From: Jens Lehmann
Commit 5fee995244e introduced the stage_updated_gitmodules() function to
add submodule configuration updates to the index. It assumed that even
after calling remove_cache_entry_at() the same cache entry would still be
valid. This was true in the old days, as cache entries could
Also here:
https://github.com/kblees/git/commits/kb/hashmap-v5
Changes since v3:
- changed table resizing and grow / shrink thresholds (#02)
- hashmap_free: changed free_function to boolean (#02, #06, #07, #09)
- swapped xcalloc args (num elements, element size) (#02)
- fixed pointer cast formatti
Commit f2e0873 (branch: report invalid tracking branch as gone) removed
an early return from fill_tracking_info() in the path taken when 'git
branch -v' lists a branch in sync with its upstream. This resulted in an
unconditionally added space in front of the subject line:
$ git branch -v
*
---
Mostly just tweaks, although I did change the "foo^{tag}" description a lot.
M.
Documentation/RelNotes/1.8.5.txt | 158 ---
1 file changed, 80 insertions(+), 78 deletions(-)
diff --git a/Documentation/RelNotes/1.8.5.txt b/Documentation/Re
On 13-11-13 06:07 PM, Junio C Hamano wrote:
> A release candidate Git v1.8.5-rc2 is now available for testing
> at the usual places.
[ snip ]
> Updates since v1.8.4
>
>
> Foreign interfaces, subsystems and ports.
>
> * "git-svn" used with SVN 1.8.0 when talking over https
I can't resist...
On 11/14/2013 08:12 PM, Stephen Bash wrote:
[snipped some stuff from Peff]
[snipped 60 lines of python]
In honor of your last name, here's what I would do if I needed to log
ref updates (and wasn't using Gitolite):
#!/bin/bash
# -- use this as a post-receive hook
while read
On 11/14/2013 01:44 PM, Jeff King wrote:
> On Thu, Nov 14, 2013 at 05:48:50AM +0530, Sitaram Chamarty wrote:
>
>> Is there *any* way we can preserve a reflog for a deleted branch,
>> perhaps under logs/refs/deleted//full/ref/name ?
>
> I had patches to do something like this here:
>
> http://t
Hi guys,
I'm using git as a subversion client, which works great so far. But
today I tried to push back a rename to the subversion server, which
resulted in the following error:
perl: subversion/libsvn_subr/dirent_uri.c:2489:
svn_fspath__skip_ancestor: Assertion
`svn_fspath__is_canonical(child_fs
On Thu, 14 Nov 2013 18:55:52 +0400
Лежанкин Иван wrote:
> I hit this limit in file 'diffcore-rename.c':
>
> if (rename_limit <= 0 || rename_limit > 32767)
> rename_limit = 32767;
>
> I just guess, that this limit comes from the O(N^2) complexity of the
> comparison algorithm. Since the
I hit this limit in file 'diffcore-rename.c':
if (rename_limit <= 0 || rename_limit > 32767)
rename_limit = 32767;
I just guess, that this limit comes from the O(N^2) complexity of the
comparison algorithm. Since the max 32-bit signed value is 2^31, then
the 2^15 = 32768 is somehow correl
Can you be more specific about the limitation you suspect you are hitting?
32,768 is not the "max 32-bit value."
> On Nov 14, 2013, at 6:58, Лежанкин Иван wrote:
>
> Hi!
>
> Do you plan to implement the 64-bit support in git? - Right now I have
> a problems sometimes with a huge repo and re
- Original Message -
> From: "Jeff King"
> Sent: Thursday, November 14, 2013 3:14:56 AM
> Subject: Re: can we prevent reflog deletion when branch is deleted?
>
> On Thu, Nov 14, 2013 at 05:48:50AM +0530, Sitaram Chamarty wrote:
>
> > Is there *any* way we can preserve a reflog for a dele
On 11/14/2013 04:47 PM, Luca Milanesio wrote:
> Would be really useful anyway to have the ability to create a
> server-side reference based on a SHA-1, using the Git protocol.
> Alternatively, just fetching a remote repo based on a SHA-1 (not
> referenced by any ref-spec but still existent) so that
On 11/14/2013 04:39 PM, Jeff King wrote:
> On Thu, Nov 14, 2013 at 04:26:46PM +0530, Sitaram Chamarty wrote:
>
>>> I do not know about any particular debate in git circles, but I assume
>>> Sitaram is referring to this incident:
>>>
>>> https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/t
On Thu, 14 Nov 2013 16:58:31 +0400
Лежанкин Иван wrote:
> Do you plan to implement the 64-bit support in git? - Right now I have
> a problems sometimes with a huge repo and renaming detection. If I
> merge more than 32768 files at once, then the renaming detection
> fails, because of limitation
Hi!
Do you plan to implement the 64-bit support in git? - Right now I have
a problems sometimes with a huge repo and renaming detection. If I
merge more than 32768 files at once, then the renaming detection
fails, because of limitation inside git. The limitation is put by max
32-bit value.
I twea
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
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
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
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
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
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
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 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
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 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).
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
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
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
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
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/
Here's another iteration of the pack bitmaps series. Compared to v2, it
changes:
- misc style/typo fixes
- portability fixes from Ramsay and Torsten
- count-objects garbage-reporting patch from Duy
- disable bitmaps when is_repository_shallow(); this also covers the
case where the client
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
Would be really useful anyway to have the ability to create a server-side
reference based on a SHA-1, using the Git protocol.
Alternatively, just fetching a remote repo based on a SHA-1 (not referenced by
any ref-spec but still existent) so that you can create a new reference locally
and push.
On Thu, Nov 14, 2013 at 04:26:46PM +0530, Sitaram Chamarty wrote:
> > I do not know about any particular debate in git circles, but I assume
> > Sitaram is referring to this incident:
> >
> > https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/t4nkXONp8qgJ
> >
> > in which a Jenkins dev
On 11/14/2013 01:37 PM, Jeff King wrote:
> On Thu, Nov 14, 2013 at 08:56:07AM +0100, Thomas Rast wrote:
>
>>> Whatever it was that happened to a hundred or more repos on the Jenkins
>>> project seems to be stirring up this debate in some circles.
>>
>> Making us so curious ... and then you just le
On Thu, Nov 14, 2013 at 08:50:43AM +0100, Thomas Rast wrote:
> git-config used a static match array to hold the matches we want to
> unset/replace when using --unset or --replace-all. Use a
> variable-sized array instead.
>
> This in particular fixes the symptoms git-svn had when storing large
>
I am not able to clone via https because gerrit doesn't propose this way
of cloning.
When I clone via http, I see that git is starting the download of objects:
remote: Counting objects: 256, done
remote: Finding sources: 100% (256/256)
Receiving objects: 46% ... (this part always fails at 46 %).
On Thu, Nov 14, 2013 at 05:48:50AM +0530, Sitaram Chamarty wrote:
> Is there *any* way we can preserve a reflog for a deleted branch,
> perhaps under logs/refs/deleted//full/ref/name ?
I had patches to do something like this here:
http://thread.gmane.org/gmane.comp.version-control.git/201715/f
On Thu, Nov 14, 2013 at 08:56:07AM +0100, Thomas Rast wrote:
> > Whatever it was that happened to a hundred or more repos on the Jenkins
> > project seems to be stirring up this debate in some circles.
>
> Making us so curious ... and then you just leave us hanging there ;-)
>
> Any pointers to
On Tue, Nov 12, 2013 at 10:33:49AM -0800, H. Peter Anvin wrote:
> > Which means that your original wish may not be granted with
> > SO_KEEPALIVE at all, no? I was wondering if you wanted a forced
> > timeout based on alarm(2), something similar to what you added to
> > git-daemon in 960deccb (git
74 matches
Mail list logo
