The docs seem to say that doing
git show-ref --head --tags
would show both the HEAD ref and all the tag refs. However, doing
both --head and either of --tags or --heads would filter out the HEAD
ref.
Signed-off-by: Doug Bell madcity...@gmail.com
---
I think this patch could be done
On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
Hello,
I am Mr. Fang Yong from Wing Lung Bank.I have a secured business proposal worth
US$16.5M .Get back to me for more details.
Regards,
Fang L. Yong
--
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
On Thu, May 30, 2013 at 1:14 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Wed, May 29, 2013 at 12:09 AM,
On Wed, May 29, 2013 at 11:40 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 30, 2013 at 1:14 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 30, 2013 at 12:30 AM, Martin
2013/5/26 Jiang Xin worldhello@gmail.com:
2013/5/22 Michael Haggerty mhag...@alum.mit.edu:
The old and new versions both seem to be (differently) inconsistent
about when the output has a trailing slash. What is the rule?
The reason for introducing patch 02/15 is that we don't want to
Am 30.05.2013 04:55, schrieb Jeff King:
So while it would be nice to work on paths with colons everywhere, I
doubt it is worth the effort to start checking it through the whole test
suite.
And on top of it, on Windows, you can't have a path component or file
name that contains a colon...
--
This includes bugfixes related to handling of --suppress-cc=self
flag. Tests are also included.
Changes from v1:
- tweak coding style in tests to address comments by Junio
Michael S. Tsirkin (6):
t/send-email.sh: add test for suppress-cc=self
send-email: fix suppress-cc=self on cccmd
This adds a basic test for --suppress-cc=self
option of git send-email.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
t/t9001-send-email.sh | 43 +++
1 file changed, 43 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index
When cccmd is used, old-style suppress-from filter
is applied by the newer suppress-cc=self isn't.
Fix this up.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
git-send-email.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
Check that suppress-cc=self works when applied
to output of cccmd.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
t/t9001-send-email.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index e1a7f3e..452b362 100755
---
--suppress-cc=self fails to filter sender address in many cases where it
needs to be sanitized in some way, for example quoted:
A U. Thor aut...@example.com
To fix, make send-email sanitize both sender and the address it is
compared against.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
add test where sender address needs to be quoted.
Make sure --suppress-cc=self works well in this case.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
t/t9001-send-email.sh | 20
1 file changed, 20 insertions(+)
diff --git a/t/t9001-send-email.sh
test suppress-cc=self when sender is non-acsii
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
t/t9001-send-email.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 42fb809..430e8de 100755
--- a/t/t9001-send-email.sh
+++
Jonathan Nieder wrote:
That's detectable and could be made to error out, so it's not too bad.
Sure it's possible, but I'm arguing about whether it's worth the
effort. There can be loops like a - b - c - d - e - a. Given
that nobody has even bothered to get git to print an error message
when a
Hi Junio,
On Tue, May 28, 2013 at 10:04:46AM -0700, Junio C Hamano wrote:
Matthijs Kooijman matth...@stdin.nl writes:
Did you consider how to implement this? Looking at the code, it seems
the deepen parameter in the wire protocol now means:
- 0: Do not change anything about the
Case folding is not done correctly when matching against the [:upper:]
character class and uppercased character ranges (e.g. A-Z).
Specifically, an uppercase letter fails to match against any of them
when case folding is requested because plain characters in the pattern
and the whole string and
On Thu, May 30, 2013 at 3:45 PM, Anthony Ramine n.ox...@gmail.com wrote:
Case folding is not done correctly when matching against the [:upper:]
character class and uppercased character ranges (e.g. A-Z).
Specifically, an uppercase letter fails to match against any of them
when case folding is
Let's do one more review.
Felipe Contreras wrote:
diff --git a/contrib/related/git-related b/contrib/related/git-related
new file mode 100755
index 000..1b9b1e7
--- /dev/null
+++ b/contrib/related/git-related
@@ -0,0 +1,120 @@
+#!/usr/bin/env ruby
+
+# This script finds people that
Junio C Hamano gits...@pobox.com writes:
* rr/die-on-missing-upstream (2013-05-22) 2 commits
- sha1_name: fix error message for @{N}, @{date}
- sha1_name: fix error message for @{u}
When a reflog notation is used for implicit current branch, we
did not say which branch and worse said
On Thu, May 30, 2013 at 5:29 AM, Anthony Ramine n.ox...@gmail.com wrote:
Yes indeed. Will amend. Should I add your name in Reviewed-by as well?
No. I merely spotted a minor typographical error.
--
Anthony Ramine
Le 30 mai 2013 à 11:07, Eric Sunshine a écrit :
On Thu, May 30, 2013 at 4:45
Case folding is not done correctly when matching against the [:upper:]
character class and uppercased character ranges (e.g. A-Z).
Specifically, an uppercase letter fails to match against any of them
when case folding is requested because plain characters in the pattern
and the whole string are
Hi,
I'm a fairly heavy user of the magit Emacs extension for interacting
with my git repos. However I've noticed there are some cases where lag
is very high. By analysing strace output of emacs calling git I found
two commands that where particularly problematic when interrogating
the repo:
On Thu, May 30, 2013 at 4:01 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Let's do one more review.
Felipe Contreras wrote:
diff --git a/contrib/related/git-related b/contrib/related/git-related
new file mode 100755
index 000..1b9b1e7
--- /dev/null
+++
Alex Bennée wrote:
time /usr/bin/git --no-pager
traversed 223 commits
real0m4.817s
user0m4.320s
sys 0m0.464s
I'm quite clueless about why it is taking this long: I think it's IO
because there's nothing to compute? I really can't trace anything
unless you can reproduce it on a
Add const for pointers that are only dereferenced for reading by the
inline functions copy_cache_entry and ce_mode_from_stat. This allows
callers to pass in const pointers.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
cache.h | 6 --
1 file changed, 4 insertions(+), 2
ie_match_stat and ie_modified only derefence their struct cache_entry
pointers for reading. Add const to the parameter declaration here and
do the same for the static helper function used by them, as it's the
same there as well. This allows callers to pass in const pointers.
Signed-off-by: René
The merge functions duplicate entries as needed and they don't free
them. Release them in unpack_nondirectories, the same function
where they were allocated, after we're done.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
unpack-trees.c | 11 ---
1 file changed, 8
While we're add it, mark the struct cache_entry pointer of add_entry
const because we only read from it and this allows callers to pass in
const pointers.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
unpack-trees.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
Duplicate the merge entry right away and work with that instead of
modifying the entry we got and duplicating it only at the end of
the function. Then mark that pointer const to document that we
don't modify the referenced cache_entry.
This change is safe because all existing merge functions
Add const to struct cache_entry pointers throughout the tree which are
only used for reading. This allows callers to pass in const pointers.
Signed-off-by: René Scharfe rene.scha...@lsrfire.ath.cx
---
builtin/read-tree.c | 2 +-
diff-lib.c | 23 +++---
unpack-trees.c | 91
On Thu, May 30, 2013 at 9:25 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This makes git use wildmatch by default for all fnmatch() calls. Users
who want to use system fnmatch (or compat fnmatch) need to set
NO_WILDMATCH flag.
wildmatch is a
On Thu, May 30, 2013 at 11:38:32AM +0100, Alex Bennée wrote:
One factor might be the size of my repo (.git is around 2.4G). Could
this just be due to computational cost of searching through large
packs to walk the commit chain? Is there any way to make this easier
for git to do?
What does git
We free each entry, but not the array of entries themselves.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
read-cache.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index 04ed561..9d9b886 100644
--- a/read-cache.c
+++ b/read-cache.c
@@
We created them, and nobody else is going to destroy them.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
unpack-trees.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index eff2944..9f19d01 100644
---
Before overwriting the destination index, first let's discard it's
contents.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
unpack-trees.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index ede4299..eff2944 100644
---
On Thu, May 30, 2013 at 6:34 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
The merge functions duplicate entries as needed and they don't free
them. Release them in unpack_nondirectories, the same function
where they were allocated, after we're done.
Ah, you beat me to this change,
Felipe Contreras wrote:
What's your objective? Block this patch from ever going in?
Not a single one of these comments makes a difference at all, all of
them can wait until after the patch is merged, many of them are a
matter of preferences, and some of them have already been addressed as
On Thu, May 30, 2013 at 7:08 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
What's your objective? Block this patch from ever going in?
Not a single one of these comments makes a difference at all, all of
them can wait until after the patch is merged, many of them
Felipe Contreras felipe.contre...@gmail.com writes:
We are supposedly adding files, to to which cache if 'the_index' is
discarded?
[...]
if (!current_head) {
discard_cache();
+ if (read_cache() 0)
+ die(_(cannot read the index));
The repo is a fairly hairy one as it includes two historically
un-related but content related repos which I'm the process of
cherry-picking stuff across.
11:58 ajb@sloy/x86_64 [work.git] git count-objects -v
count: 493
size: 4572
in-pack: 399307
packs: 1
size-pack: 1930755
prune-packable: 0
On Thu, May 30, 2013 at 7:17 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
We are supposedly adding files, to to which cache if 'the_index' is
discarded?
[...]
if (!current_head) {
discard_cache();
+ if
Am 30.05.2013 07:30, schrieb Martin von Zweigbergk:
On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
+# f
+# /
+# a---b---c---g---h
+# \
+# d---G---i
...
+test_run_rebase () {
+
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 30, 2013 at 7:17 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
We are supposedly adding files, to to which cache if 'the_index' is
discarded?
[...]
if (!current_head) {
On Thu, May 30, 2013 at 7:58 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 30, 2013 at 7:17 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
We are supposedly adding files, to to which
On Thu, May 30, 2013 at 7:17 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
We are supposedly adding files, to to which cache if 'the_index' is
discarded?
[...]
if (!current_head) {
discard_cache();
+ if
It looks like it's a file caching effect combined with my repo being
more pathalogical in size and contents. Note run 1 (cold) vs run 2 on
the linux file tree:
13:52 ajb@sloy/x86_64 [linux.git] time git describe --debug --long
--tags HEAD~1
searching to describe HEAD~1
annotated
You may find that performance improves if you repack with git gc
--aggressive.
It seems that increases the time to get to where it wants to:
14:12 ajb@sloy/x86_64 [work.git] time /usr/bin/git --no-pager
describe --long --tags --debug
searching to describe HEAD
lightweight 10
On Thu, May 30, 2013 at 7:29 PM, Alex Bennée kernel-hac...@bennee.com wrote:
I ran perf on it and the top items in the report where:
41.58% git libcrypto.so.1.0.0 [.] 0x6ae73
33.96% git libz.so.1.2.3.4 [.] 0xe0ec
10.39% git libz.so.1.2.3.4 [.] adler32
2.03% git
We don't free 'istate-cache' properly.
Apparently 'initialized' doesn't really mean initialized, but loaded, or
rather 'not-empty', and the cache can be used even if it's not
'initialized', so we can't rely on this variable to keep track of the
'istate-cache'.
So assume it always has data, and
We created them, and nobody else is going to destroy them.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
unpack-trees.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index eff2944..9f19d01 100644
---
Before overwriting the destination index, first let's discard it's
contents.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
unpack-trees.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index ede4299..eff2944 100644
---
Hi,
A small change since v1; one patch is dropped and another is updated to make up
for it.
Felipe Contreras (3):
read-cache: plug a few leaks
unpack-trees: plug a memory leak
unpack-trees: free created cache entries
read-cache.c | 4
unpack-trees.c | 16 +---
2 files
On 05/30/2013 03:34 PM, Felipe Contreras wrote:
Before overwriting the destination index, first let's discard it's
s/it's/its/
contents.
[SNIP]
Regards,
Stefano
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
On Thu, May 30, 2013 at 8:34 PM, Alex Bennée kernel-hac...@bennee.com wrote:
From the following run:
14:31 ajb@sloy/x86_64 [work.git] time /usr/bin/git --no-pager
describe --long --tags
ajb-build-test-5224-11-g9660048
real0m14.720s
user0m12.985s
sys 0m1.700s
14:31
5f44324 (core: log offset pack data accesses happened - 2011-07-06)
provides a way to observe pack access patterns via a config
switch. Setting an environment variable looks more obvious than a
config var, especially when you just need to _observe_, and more
inline with other tracing knobs we
This can help with debugging object negotiation or other protocol
issues.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3e74440..12ef7a2 100644
---
If the user set --ff, it's expected that if theres's nothing to do we
fast-forward our current HEAD, which is a no-op.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index
Hi,
Here's a bunch of trivial patches, mostly syle, but the first one might be
important.
Felipe Contreras (4):
read-cache: fix wrong 'the_index' usage
read-cache: trivial style cleanups
unpack-trees: trivial cleanup
sha1_file: trivial style cleanup
read-cache.c | 6 +++---
We are dealing with the 'istate' index, not 'the_index'.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index 04ed561..5253ec5 100644
--- a/read-cache.c
+++ b/read-cache.c
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
read-cache.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 5253ec5..7040e79 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -979,7 +979,7 @@ int add_index_entry(struct
dfc has not been initialized at this point.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
unpack-trees.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index ede4299..36f4ff7 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sha1_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index 67e815b..b114cc9 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2138,7 +2138,7 @@ void *unpack_entry(struct packed_git *p,
On 30 May 2013 14:45, Duy Nguyen pclo...@gmail.com wrote:
On Thu, May 30, 2013 at 8:34 PM, Alex Bennée kernel-hac...@bennee.com wrote:
snip
Thanks. Can you share verify-pack -v output of
pack-a9ba133a6f25ffa74c3c407e09ab030f8745b201.pack? I think you need
to put it somewhere on Internet
Alex Bennée wrote:
And through my special repo:
41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3
33.62% git libz.so.1.2.3.4 [.] inflate_fast
10.39% git libz.so.1.2.3.4 [.] adler32
2.03% git [kernel.kallsyms] [k] clear_page_c
I'm not sure why
Felipe Contreras felipe.contre...@gmail.com writes:
First expected, then actual.
Ack. That is the prevalent (almost universal, but not quite) style.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5407-post-rewrite-hook.sh | 4 ++--
1 file changed, 2 insertions(+), 2
Am 30.05.2013 14:04, schrieb Felipe Contreras:
On Thu, May 30, 2013 at 6:34 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
The merge functions duplicate entries as needed and they don't free
them. Release them in unpack_nondirectories, the same function
where they were allocated, after
Am 30.05.2013 15:34, schrieb Felipe Contreras:
We created them, and nobody else is going to destroy them.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
unpack-trees.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/unpack-trees.c
Felipe Contreras wrote:
On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder jrnie...@gmail.com wrote:
A bigger problem (in my opinion) with allowing arbitrary changes to
the meaning of existing
On Thu, May 30, 2013 at 5:54 AM, Johannes Sixt j...@kdbg.org wrote:
Am 30.05.2013 07:30, schrieb Martin von Zweigbergk:
On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
+# f
+# /
+# a---b---c---g---h
+#
On 30 May 2013 15:32, Ramkumar Ramachandra artag...@gmail.com wrote:
Alex Bennée wrote:
And through my special repo:
41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3
33.62% git libz.so.1.2.3.4 [.] inflate_fast
10.39% git libz.so.1.2.3.4 [.] adler32
2.03%
Am 30.05.2013 15:34, schrieb Felipe Contreras:
We don't free 'istate-cache' properly.
Apparently 'initialized' doesn't really mean initialized, but loaded, or
rather 'not-empty', and the cache can be used even if it's not
'initialized', so we can't rely on this variable to keep track of the
Hi Karsten,
On Thu, 30 May 2013, Karsten Blees wrote:
Am 25.05.2013 21:16, schrieb Pat Thoyts:
On that note -- with this merge as it now stands I get the following
test failures:
t0008-ignores.sh 155, 158, 162, 164
These tests fail because they use absolute
Alex Bennée wrote:
15:50 ajb@sloy/x86_64 [work.git] time git log --pretty=oneline | wc -l
24648
real0m0.434s
user0m0.388s
sys 0m0.112s
Although it doesn't take too long to walk the whole mainline history
(obviously ignoring all the other branches).
Damn, non-starter.
On Thu, May 30, 2013 at 9:40 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 30.05.2013 14:04, schrieb Felipe Contreras:
On Thu, May 30, 2013 at 6:34 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
The merge functions duplicate entries as needed and they don't free
them. Release
On Thu, May 30, 2013 at 9:54 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder jrnie...@gmail.com
wrote:
A bigger problem
Alex Bennée kernel-hac...@bennee.com writes:
41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3
33.62% git libz.so.1.2.3.4 [.] inflate_fast
10.39% git libz.so.1.2.3.4 [.] adler32
2.03% git [kernel.kallsyms] [k] clear_page_c
Do you have any large blobs
On 30 May 2013 16:15, Johannes Schindelin johannes.schinde...@gmx.de wrote:
Hi Karsten,
On Thu, 30 May 2013, Karsten Blees wrote:
Am 25.05.2013 21:16, schrieb Pat Thoyts:
On that note -- with this merge as it now stands I get the following
test failures:
t0008-ignores.sh
In the hope that the Pat Thoyts who just posted in another thread from a
GMail address is the same one that maintains git-gui, let's see if that
address works...
On Sat, May 11, 2013 at 10:03:25PM -0400, Andrew Wong wrote:
Sorry for the late reply. I was able to reproduce the problem that you
Alex Bennée kernel-hac...@bennee.com writes:
On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote:
Alex Bennée kernel-hac...@bennee.com writes:
41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3
33.62% git libz.so.1.2.3.4 [.] inflate_fast
10.39% git
I have my global git config pager set to 'cat', but when I do a git
help command, it still uses a pager. This is especially irksome in
emacs shell buffers, where I am most of the time. I know I can do a
M-x man - git-whatever, but wondered if this was a bug or user
error. (git --no-pager help
Hey all,
I've be burnt by what someone on IRC referred to as evil merges,
that is loss of history after amending a merge commit:
git merge anotherbranch
git add something
git commit --amend
After the steps above the addition of something can't be found in
the history anymore, but the file is
Michael Campbell michael.campb...@gmail.com writes:
I have my global git config pager set to 'cat', but when I do a git
help command, it still uses a pager. This is especially irksome in
emacs shell buffers, where I am most of the time. I know I can do a
M-x man - git-whatever, but wondered
Ramkumar Ramachandra artag...@gmail.com writes:
It just needs to set $PAGER or $MANPAGER before the exec(), no?
Yes, that should do the same as man -P.
I would argue that it should do this. $GIT_PAGER works everywhere
else, but obviously man has no knowledge about it.
I find it a bit weird
Matthieu Moy wrote:
I find it a bit weird that Git sets the configuration for external
commands, but it may make sense. No strong opinion here.
I don't mean a setenv() kind of thing: how would we unset it after
that? Perhaps something like execvpe(), passing in the environment as
an argument?
On Thu, May 30, 2013 at 10:38:59PM +0530, Ramkumar Ramachandra wrote:
Matthieu Moy wrote:
I find it a bit weird that Git sets the configuration for external
commands, but it may make sense. No strong opinion here.
I don't mean a setenv() kind of thing: how would we unset it after
that?
Hi Pat,
On Thu, 30 May 2013, Pat Thoyts wrote:
On 30 May 2013 16:15, Johannes Schindelin johannes.schinde...@gmx.de wrote:
On Thu, 30 May 2013, Karsten Blees wrote:
Am 25.05.2013 21:16, schrieb Pat Thoyts:
On that note -- with this merge as it now stands I get the following
test
The culprit, according to some callgrind investigation, is
lookup_commit_reference_gently() [for the unannotated case] or
deref_tag() [annotated case] calling parse_object().
Using the scenario you described earlier, I think it ends-up spending
most of its time in check_sha1_signature (both
Am 30.05.2013 01:58, schrieb Junio C Hamano:
* jl/submodule-mv (2013-04-23) 5 commits
(merged to 'next' on 2013-04-23 at c04f574)
+ submodule.c: duplicate real_path's return value
(merged to 'next' on 2013-04-19 at 45ae3c9)
+ rm: delete .gitmodules entry of submodules removed from the
Am 30.05.2013 01:58, schrieb Junio C Hamano:
* jk/submodule-subdirectory-ok (2013-04-24) 3 commits
(merged to 'next' on 2013-04-24 at 6306b29)
+ submodule: fix quoting in relative_path()
(merged to 'next' on 2013-04-22 at f211e25)
+ submodule: drop the top-level requirement
+
On 05/29/2013 10:21 AM, Thomas Rast wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Since string_list_add_one_ref() adds refname to the string list, but
the lifetime of refname is limited, it is important that the
string_list passed to string_list_add_one_ref() has strdup_strings
set.
On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
Alex Bennée kernel-hac...@bennee.com writes:
On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote:
Alex Bennée kernel-hac...@bennee.com writes:
41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3
33.62%
On 05/29/2013 10:25 AM, Thomas Rast wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I read the entire series on Monday, and give it an Ack at maybe 90%
confidence level -- sorry, I was short on caffeine and sleep ;-)
Thanks very much. I'll buy you a coffee the next time I see you :-)
lookup_commit_reference_gently unconditionally parses the object given
to it. This slows down git-describe a lot if you have a repository
with large tagged blobs in it: parse_object() will read the entire
blob and verify that its sha1 matches, only to then throw it away.
Speed it up by checking
sha1_object_info() returns -1 (OBJ_BAD) if it cannot find the object
for some reason, which suggests that it wants the _caller_ to report
this error. However, part of its work happens in
sha1_loose_object_info, which _does_ report errors itself. This is
doubly strange because:
*
On 05/29/2013 06:18 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
The old version copied one entry to its destination position, then
deleted any matching entries from the tail of the array. This
required the tail of the array to be copied multiple times. It didn't
On Thu, May 30, 2013 at 10:00:23PM +0200, Thomas Rast wrote:
lookup_commit_reference_gently unconditionally parses the object given
to it. This slows down git-describe a lot if you have a repository
with large tagged blobs in it: parse_object() will read the entire
blob and verify that its
On 05/29/2013 06:53 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
[...]
+current_bad_sha1 = xmalloc(20);
+hashcpy(current_bad_sha1, sha1);
This, together with 18/25, may hint that we want hashdup()?
I thought about it, but was surprised
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Junio, would you mind squashing this patch onto mh/reflife 22/25?
notes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/notes.c b/notes.c
index 602d956..b69c0b8 100644
--- a/notes.c
+++ b/notes.c
@@ -932,6 +932,7 @@ static int
From: Michael Haggerty mhag...@alum.mit.edu
Sent: Thursday, May 30, 2013 10:51 PM
On 05/29/2013 06:53 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
[...]
+ current_bad_sha1 = xmalloc(20);
+ hashcpy(current_bad_sha1, sha1);
This, together with 18/25, may hint that we
1 - 100 of 107 matches
Mail list logo
