On Tue, Oct 1, 2013 at 6:07 AM, Eric Wong normalper...@yhbt.net wrote:
Johan Herland jo...@herland.net wrote:
git-svn by default puts its Subversion-tracking refs directly in
refs/remotes/*. This runs counter to Git's convention of using
refs/remotes/$remote/* for storing remote-tracking
Also here:
https://github.com/kblees/git/tree/kb/hashmap-v3
Previous discussion:
http://thread.gmane.org/gmane.comp.version-control.git/234508
Changes since v2:
- move documentation from hashmap.h to Documentation/technical/api-hashmap.txt
- simpler way to deal with FLEX_ARRAY keys: instead of
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
Signed-off-by: Karsten Blees bl...@dcon.de
---
builtin/describe.c | 53 -
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 7d73722..ae8d32c 100644
--- a/builtin/describe.c
+++
No actual code changes, just move hash_filespec up and outdent part of
find_identical_files.
Signed-off-by: Karsten Blees bl...@dcon.de
---
diffcore-rename.c | 98 +++
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git
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
Signed-off-by: Karsten Blees bl...@dcon.de
---
cache.h | 3 ++-
name-hash.c | 77 +++--
2 files changed, 20 insertions(+), 60 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..bf6e2f0 100644
--- a/cache.h
+++ b/cache.h
@@ -4,6
Signed-off-by: Karsten Blees bl...@dcon.de
---
diffcore-rename.c | 48 +---
1 file changed, 13 insertions(+), 35 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 82b7975..c6bd776 100644
--- a/diffcore-rename.c
+++
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 bl...@dcon.de
---
name-hash.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/name-hash.c
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 bl...@dcon.de
---
cache.h| 8 +---
name-hash.c| 24
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-by: Karsten Blees bl...@dcon.de
---
Documentation/technical/api-hash.txt | 52 -
Makefile | 2 -
cache.h | 1 -
hash.c | 110 ---
hash.h
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
On 30.09.2013 20:55, Jonathan Nieder wrote:
Hi,
Marc Strapetz wrote:
On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote:
I'm looking for a specification or guidelines on how a Git client should
integrate with bug tracking systems.
[...]
Finally, I've created a minimal spec
On 30.09.2013 21:42, James Sharpe wrote:
You could also use git notes to store the information. The advantage
there is they can be added to commits without changing the history.
Gerrit and jenkins can auto generate this sort of metadata via plugins.
git notes could be the preferred storage for
On 13-09-30 11:28 PM, Nicolas Pitre wrote:
But with my proposal, you'd get a message saying that the tag baz is
ambigous, and that you'd have to use either libfoo/baz or
libbar/baz.
Yes, and that's good. I agree with your proposal. Sorry if that wasn't
clear.
M.
--
To
Hi,
Thanks for your patch.
Unfortunately, in my case still crash...
But PATH_MAX length kinds issues interesting.
I'll try investigate a little more.
- PATH_MAX and O2
Thanks.
(2013/10/01 2:00), René Scharfe wrote:
Am 29.09.2013 04:56, schrieb Wataru Noguchi:
Hi,
Thanks for comments.
Hi,
Thanks for your advice.
I see. I'll try following tool for optimization affection.
Thanks.
(2013/09/29 20:01), Stefan Beller wrote:
On 09/29/2013 04:56 AM, Wataru Noguchi wrote:
- gcc optimization level is O2.(fail)
- gcc O0, O1 works fine.
Maybe you could try to compile with
STACK
On 2013-10-01 12:01, Lucas Sandery [three am design] wrote:
For RTL languages
I meant LTR languages but I'm guessing that, if their is a RTL version
of gitk, it needs fixing, too.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
19 matches
Mail list logo
