Allow extracting To/Cc addresses from cover letter.
Signed-off-by: Michael S. Tsirkin
---
Is there interest in this kind of feature?
I find it easier than adding --cc to send-email command line.
git-send-email.perl | 16
1 file changed, 16 insertions(+)
diff --git a/git-send-
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 majord...@vger.kern
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 fo
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.
My
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.
--
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 f
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
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 all
Signed-off-by: Karsten Blees
---
Documentation/technical/api-hash.txt | 52 -
Makefile | 2 -
cache.h | 1 -
hash.c | 110 ---
hash.h
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
---
cache
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
---
name-hash.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/name-hash.c b/name-hash.c
i
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
---
cache.h| 8 +---
name-hash.c| 24
unpack-
Signed-off-by: Karsten Blees
---
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 +4,7 @@
#inc
Signed-off-by: Karsten Blees
---
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
+++ b/diffcore-rename.c
@@ -4,7 +4,
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
---
diffcore-rename.c | 98 +++
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/diffcore-rename.c b/diffco
Signed-off-by: Karsten Blees
---
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
+++ b/builtin/describe.c
@
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
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 r
19 matches
Mail list logo
