On Thu, Nov 7, 2013 at 12:57 AM, Junio C Hamano wrote:
>
> * "git replace" helper no longer allows an object to be replaced with
>another object of a different type to avoid confusion (you can
>still manually craft such replacement using "git update-ref", as an
>escape hatch).
Maybe
Jonathan Nieder writes:
> When push.default is set to 'matching', git will push local branches
> to remote branches that already exist with the same (matching) name.
Yes, that's better than the original patch (and remains two lines).
> + "In Git 2.0 the new push.default of 'si
On Thu, Nov 7, 2013 at 1:12 AM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>>> The old name followed the pattern anything-cmp(), which suggests
>>> a general comparison function suitable for e.g. sorting objects.
>>> But this was not the case for suffixcmp().
>>
>> It's not clear to me tha
Also here:
https://github.com/kblees/git/commits/kb/hashmap-v4
Sorry for the delay, but the promised static use-after-free analysis [1] turned
out to be much more involved than I had anticipated.
The Good News is that the static analysis independently found the four
use-after-free issues that w
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 never be
freed, but
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
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
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
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
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..d996c6a 100644
--- a/diffcore-rename.c
+++
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
+++
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
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 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
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 ---
Dear user,
Your mailbox has Exceeded the quota limit set by the administrator, you will
not be able to send or receive mail
until you revalidates your account.
Please click the link below or copy paste to your browser to validate your
mailbox.
http://tinylink.net/quotalimit
Failure to do th
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
On Wed, Nov 6, 2013 at 9:42 PM, Junio C Hamano wrote:
> Christian Couder writes:
>> From: Junio C Hamano
>>
>>> But that is insufficient to emulate what we do, no? I.e. append
>>> unless the last one is from the same person we are about to add.
>>
>> Yeah, but, with DONT_REPEAT_PREVIOUS, it wou
On 13-11-06 07:01 PM, Junio C Hamano wrote:
>
> There is a proposed rewording of advice message from "git push"
> patch, which is tentatively queued near the tip of 'pu' for now; it
> would be nice to get a few more sets of eyeballs. I am not sure if
> we should merge it before the 1.8.5 final, y
Also here:
https://github.com/kblees/git/commits/kb/gitignore-doc
These two patches were the result of a discussion mid-october [1] that I almost
forgot about...now including an example as suggested by Jeff.
[1] http://thread.gmane.org/gmane.comp.version-control.git/235753/focus=235856
Karsten
"**" means bold in ASCIIDOC, so we need to escape it.
Signed-off-by: Karsten Blees
---
Documentation/gitignore.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 54e334e..f971960 100644
--- a/Documentation
Additionally, precedence of negated patterns is exactly as outlined in
the DESCRIPTION section, we don't need to repeat this.
Signed-off-by: Karsten Blees
---
Documentation/gitignore.txt | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitigno
When a remote server is unavailable or very slow, some git commands can
stall out indefinitely. It would be a very good thing if remote
commands -- but especially git fetch -- could be given a timeout.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> ... users of for-each-ref format will be _more_ familiar with
>> formats used by for-each-ref, and it would make a lot more sense to
>> keep the syntactic resemblance between existing features to show
>> magic things in for-each-ref and the
Matthieu Moy writes:
> Jonathan Nieder writes:
>
>> When push.default is set to 'matching', git will push local branches
>> to remote branches that already exist with the same (matching) name.
>
> Yes, that's better than the original patch (and remains two lines).
>
>> + "In Git
Hello,
I’m developping a git command in shell and I would like colorize the output.
I don’t find anything in git-sh-setup.
What is the best way for don’t reinvent the wheel?
Thanks in advance.
Best regards.
Nicolas.
signature.asc
Description: OpenPGP digital signature
On Thu, Nov 07, 2013 at 07:10:11PM +0100, Nicolas wrote:
> I’m developping a git command in shell and I would like colorize the output.
>
> I don’t find anything in git-sh-setup.
>
> What is the best way for don’t reinvent the wheel?
I normally use "git config --get-color ..." either with standa
Karsten Blees writes:
> "**" means bold in ASCIIDOC, so we need to escape it.
>
> Signed-off-by: Karsten Blees
> ---
> Documentation/gitignore.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> index 54e
Junio C Hamano writes:
> Actually, to me, I found the "two sentences" the worst part in the
> original. It made it sound as if the default will be switching to
> 'upstream', and all readers need to read the second sentence that
> clarifies that it is not the case, in a somewhat round-about
> way
Karsten Blees writes:
> Additionally, precedence of negated patterns is exactly as outlined in
> the DESCRIPTION section, we don't need to repeat this.
Very good, thanks.
Even though I have a suspicion that somebody else may be able to
come up with a better phrase that does not sound unnecessar
Junio C Hamano writes:
> Karsten Blees writes:
>
>> Additionally, precedence of negated patterns is exactly as outlined in
>> the DESCRIPTION section, we don't need to repeat this.
>
> Very good, thanks.
>
> Even though I have a suspicion that somebody else may be able to
> come up with a better
On Thu, Nov 07, 2013 at 11:37:38AM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Karsten Blees writes:
> >
> >> Additionally, precedence of negated patterns is exactly as outlined in
> >> the DESCRIPTION section, we don't need to repeat this.
> >
> > Very good, thanks.
> >
> > Eve
Am 07.11.2013 20:55, schrieb Jeff King:
> On Thu, Nov 07, 2013 at 11:37:38AM -0800, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>>> Karsten Blees writes:
>>>
Additionally, precedence of negated patterns is exactly as outlined in
the DESCRIPTION section, we don't need to repeat
On Thu, Nov 07, 2013 at 09:27:16PM +0100, Karsten Blees wrote:
> > How about:
> >
> > It is not possible to re-include a file if a parent directory of that
> > file is excluded. Once git considers a directory excluded, it does not
> > descend into the directory to consider its contents furt
Additionally, precedence of negated patterns is exactly as outlined in
the DESCRIPTION section, we don't need to repeat this.
Signed-off-by: Karsten Blees
---
I also force-pushed to git://github.com/kblees/git.git kb/gitignore-doc.
Documentation/gitignore.txt | 19 +--
1 file c
Karsten Blees writes:
> +`void hashmap_add(struct hashmap *map, void *entry)`::
> +
> + Adds a hashmap entry. This allows to add duplicate entries (i.e.
> + separate values with the same key according to hashmap_cmp_fn).
> ++
> +`map` is the hashmap structure.
> ++
> +`entry` is the entry
Karsten Blees writes:
> - if (p < path || p > path + strlen(path))
> - free((char *)p);
> + free(p);
The non-const cast was there for a reason. I'll locally fix it up
(there is another instance of the same) to get it compile be
Karsten Blees writes:
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index b654d27..acd992d 100644
> --- a/builtin/update-index.c
> +++ b/builtin/update-index.c
> @@ -559,6 +559,7 @@ static int do_reupdate(int ac, const char **av,
> const struct cache_entry *ce = a
100% обеспечите королеве удовлетворение http://goo.gl/n5lfgw
--
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
Karsten Blees writes:
> '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.
Interesting.
This look
Signed-off-by: Ramsay Jones
---
compat/bswap.h | 97 --
1 file changed, 68 insertions(+), 29 deletions(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index ea1a9ed..c18a78e 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -17,7 +17,20
Hi Jeff,
These patches fix various errors/warnings on the cygwin, MinGW and
msvc builds, provoked by the jk/pack-bitmap branch.
Note that this does not fix all problems on the msvc build; I have
a solution, but I don't like it. :-D So, I'm going to try a different
fix. I had hoped to have done t
Noticed by sparse. ("Using plain integer as NULL pointer")
Signed-off-by: Ramsay Jones
---
khash.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/khash.h b/khash.h
index 0fdf39d..c4c1613 100644
--- a/khash.h
+++ b/khash.h
@@ -114,7 +114,7 @@ static const double __ac_HASH_UP
On MinGW, gcc complains as follows:
CC ewah/ewah_bitmap.o
ewah/ewah_bitmap.c: In function 'ewah_dump':
ewah/ewah_bitmap.c:389: warning: unknown conversion type \
character 'z' in format
ewah/ewah_bitmap.c:389: warning: unknown conversion type \
character 'z' in
Signed-off-by: Ramsay Jones
---
Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 07b0626..1950858 100644
--- a/Makefile
+++ b/Makefile
@@ -2484,8 +2484,9 @@ profile-clean:
$(RM) $(addsuffix *.gcno,$(addprefix $(PROFILE_DIR)/, $(o
Noticed by sparse. ("symbol '...' was not declared. Should it be
static?")
Signed-off-by: Ramsay Jones
---
builtin/pack-objects.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 423e85a..161bfc2 100644
--- a/builtin
On Thu, Nov 07, 2013 at 09:58:02PM +, Ramsay Jones wrote:
> These patches fix various errors/warnings on the cygwin, MinGW and
> msvc builds, provoked by the jk/pack-bitmap branch.
Thanks. Your timing is impeccable, as I was just sitting down to
finalize the next re-roll. I'll add these in.
Hi,
it looks like there is a "From: Jens ..." line missing on top of this patch.
Am 07.11.2013 15:33, schrieb Karsten Blees:
Commit 5fee995244e introduced the stage_updated_gitmodules() function to
add submodule configuration updates to the index. It assumed that even
after calling remove_cache
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.org/majordomo-info.html
Ramsay Jones writes:
> On MinGW, gcc complains as follows:
>
> CC ewah/ewah_bitmap.o
> ewah/ewah_bitmap.c: In function 'ewah_dump':
> ewah/ewah_bitmap.c:389: warning: unknown conversion type \
> character 'z' in format
> ewah/ewah_bitmap.c:389: warning: unknown convers
When "git checkout" wants to create a path, e.g. a/b/c/d/e, after
seeing if the entire thing already exists (in which case we check if
that is up-to-date and do not bother to check it out, or we unlink
and recreate it), we validate that the leading directory path is
without funny symlinks by seeing
Hi,
On Thu, Nov 07, 2013 at 09:59:38PM +, Ramsay Jones wrote:
> +static inline uint64_t default_bswap64(uint64_t val)
> +{
> + return (((val & (uint64_t)0x00ffULL) << 56) |
> + ((val & (uint64_t)0xff00ULL) << 40) |
> + ((val & (uint64_t)0x000
Thank you Ramsay, all the patches look OK to me.
On Thu, Nov 7, 2013 at 11:19 PM, Jeff King wrote:
> On Thu, Nov 07, 2013 at 09:58:02PM +, Ramsay Jones wrote:
>
>> These patches fix various errors/warnings on the cygwin, MinGW and
>> msvc builds, provoked by the jk/pack-bitmap branch.
>
> Tha
Обратить свою биографию помногообразнее, воспылать замечательнейшим делом.
Расширить круг общения. Применяются засекреченные экспресс-методы. Убыстренное
обучение. Экспресс-курс для делающих первые щаги а так же углублённых.
Приподнять личную цену на рынке работы. Вы сможете говорить по британск
56 matches
Mail list logo
