Re: [PATCH 1/2] tree-diff: rework diff_tree() to generate diffs for multiparent cases as well
On Fri, Feb 14, 2014 at 09:37:00AM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@mns.spb.ru writes:
Previously diff_tree(), which is now named __diff_tree_sha1(), was
That name with two leading underscores is a rather unfortunate,
especially for a function that is not a file scope static. No way
to rename this to something more sensible?
I agree. In preparatory patches I thought this will go away, but it
stayed. I'll try to come up with something reasonable.
That impedance mismatch *hurts* *performance* *badly* for generating
combined diffs - in c839f1bd (combine-diff: optimize combine_diff_path
Please avoid referring to a commit that is not in 'master' by its
object name. It can be reworked later and get a different name.
I agree, this makes sense. Is it ok to refer to nearby commits, by say
HEAD~3, if we know we are referring to 3-times previous commit?
That slowness comes from the fact that currently, while generating
combined diff, a lot of time is spent computing diff(commit,commit^2)
just to only then intersect that huge diff to almost small set of files
from diff(commit,commit^1).
Good observation.
|a| |b|a b - a ∉ B - D(A,B) += +aa↓
|-| |-|a b - b ∉ A - D(A,B) += -bb↓
| | | |a = b - investigate δ(a,b)a↓ b↓
In both the n-parallel and diff-tree, when an entry 'a' is a
tree, I take this D(A,B) += +a to mean (recursively) adding all
the paths within 'a' to the result as addition. Sounds sensible.
Correct.
D(A,B)
is by definition the same as combined diff
D(A,[B]),
so if we could rework the code for common case and make it be not slower
for nparent=1 case, usual diff(t1,t2) generation will not be slower, and
multiparent diff tree-walker would greatly benefit generating
combine-diff.
OK.
Thanks. My first goal was to demonstrate it is doable - i.e. we could
join two diff tree-walkers into generalized one, and that approach would
be sound and have chances to be accepted.
What we do is as follows:
1) diff tree-walker __diff_tree_sha1() is internally reworked to be
a paths generator (new name diff_tree_paths()), with each generated path
being `struct combine_diff_path` with info for path, new sha1,mode and
for
every parent which sha1,mode it was in it.
2) From that info, we can still generate usual diff queue with
struct diff_filepairs, via exporting generated
combine_diff_path, if we know we run for nparent=1 case.
(see emit_diff() which is now named emit_diff_p0only())
s/p0/first_parent_/; perhaps?
Ok.
3) In order for diff_can_quit_early(), which checks
DIFF_OPT_TST(opt, HAS_CHANGES))
to work, that exporting have to be happening not in bulk, but
incrementally, one diff path at a time.
Good thinking.
Yes. This requirement made the diff-paths producer be real generator,
which emits paths incrementally, which is imho, could be a good design
for making the component more reusable.
Some notes(*):
1) For loops,
i = 0; do { ... } while (++i nparent);
is used instead of
for (i = 0; i nparent; ++i)
...
because for the former case, the compiler have to emit additional
prologue code which checks for i = nparent case before entering the
loop.
As we require nparent must be 0, that additional overhead
conflicts with the runs not slower for nparent=1 case than before
goal.
Unfortunate. I'd rather see us stick to more readable and familiar
form for maintainability if this were not measurable.
The most effect on performance were avoiding mallocs and reduce register
pressure. This too, was measurable, but of lower impact. If giving away
some part of percent for nparent=1 case is ok, this could be back to
usual for loops.
By the way, I find it a bit unfortunate, we don't have some for-loop
form with post-conditions in C, only do-while. Another observation, is
that it would be good to say to compiler e.g.
assume nparent 0;
and then in e.g.
for (i = 0; i nparent; i++)
...
the compiler could know it should not do pre-conditions checks before
entering the loop.
I've verified, that such behaviour, at least with gcc, could be achieved
with
if (nparent = 0)
return;
in function prologue - then the compiler deduces, at least with O2, that
after return point, nparent is 0, but this adds slight overhead on each
entry to function, and we have as many calls as there would be
recursions.
To me, the do-while is still readable, but if fors are preferred, I'll
re-measure what it costs and come back.
2) alloca(), for small arrays, is used for the same reason - if we change
it to xmalloc()/free() the timings get worse
Do you see any use of it outside compat/?
I thought we specifically avoid alloca() for portability. Also we
do not use variable-length-arrays on the stack either, I think.
No, no usage outside
Re: [PATCH 0/3] Wider exposure for index-v4
Duy Nguyen pclo...@gmail.com writes: On Sun, Feb 16, 2014 at 2:23 AM, Thomas Gummerer t.gumme...@gmail.com wrote: Hi, since index-v5 didn't seem to generate enough interest to be merged, I I thought there were some comments last time that you were going to address and resubmit? Yes, there were some comments to the last round, which I already fixed locally, I'd just have to rebase it to make sure it stell applies cleanly. No responses from Junio to [1] and [2] gave me the impression that it's not going to be applied. I would be happy to rebase and submit if there is a chance for it getting in. [1] http://thread.gmane.org/gmane.comp.version-control.git/238414/focus=239065 [2] http://thread.gmane.org/gmane.comp.version-control.git/232488/focus=233504 have a few patches that give users users easier access to index-v4. Until now users have to go into the source code and compile git themselves to use index-v4 by default, or use git-update-index to change the index file to the new version. Not objecting this, but I think something like [1] would give v4 more exposure. Reading the patch again, I think putting that detection code in unpack_trees() or git-merge may make more sense because people will be advised about upgrading to v4 at the next fast-forward. Thanks, I forgot about this patch. I still think at least the first two patches of this series make sense in addition to your patch, allowing developers to easily run the test suite with index-v4. [1] http://article.gmane.org/gmane.comp.version-control.git/216307 With this patches it's possible to set the default index file format either in gitconfig or in an environment variable. It also simplifies testing index-v4 by adding a Makefile knob to use it for running the test suite. For safety, existing repositories are not changed when the environment or the config variables are set. I'm not sure about the precedence in patch 3, right now the environment variable has precedence, but it should be easy to give the config option precedence over that. Thomas Gummerer (3): introduce GIT_INDEX_VERSION environment variable test-lib: allow setting the index format version read-cache: add index.version config variable Documentation/config.txt | 4 +++ Documentation/git.txt | 5 Makefile | 7 + read-cache.c | 36 +++- t/t1600-index.sh | 52 +++ t/t2104-update-index-skip-worktree.sh | 2 ++ t/test-lib-functions.sh | 5 t/test-lib.sh | 3 ++ 8 files changed, 113 insertions(+), 1 deletion(-) create mode 100755 t/t1600-index.sh -- 1.8.3.2 -- 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 -- Duy -- 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
Re: [PATCH 2/2] check-attr: move to the top of working tree when in non-bare repository
On 02/06/2014 09:17 PM, Jonathan Nieder wrote: How do I use the only-look-at-HEAD mode from a non-bare repo? If I want attributes with respect to some other commit instead of HEAD, is there a syntax for that? The command doesn't seem to have been well thought out. I agree that it would be nice for git check-attr to handle this case. Currently, I believe that one has to resort to a temporary index file via something like ( export GIT_INDEX_FILE=$(mktemp) git read-tree HEAD git check-attr --cached ... rm $GIT_INDEX_FILE ) Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
[PATCH] config: teach git config --file - to read from the standard input
The patch extends git config --file interface to allow read config from
stdin.
Editing stdin or setting value in stdin is an error.
Include by absolute path is allowed in stdin config, but not by relative
path.
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
builtin/config.c | 11 +
cache.h | 1 +
config.c | 58 ---
t/t1300-repo-config.sh| 17 --
t/t1305-config-include.sh | 16 -
5 files changed, 82 insertions(+), 21 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index de41ba50e9ca..5677c942b693 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -360,6 +360,9 @@ static int get_colorbool(int print)
static void check_write(void)
{
+ if (given_config_source.use_stdin)
+ die(writing to stdin is not supported);
+
if (given_config_source.blob)
die(writing config blobs is not supported);
}
@@ -472,6 +475,12 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
usage_with_options(builtin_config_usage,
builtin_config_options);
}
+ if (given_config_source.file
+ !strcmp(given_config_source.file, -)) {
+ given_config_source.file = NULL;
+ given_config_source.use_stdin = 1;
+ }
+
if (use_global_config) {
char *user_config = NULL;
char *xdg_config = NULL;
@@ -558,6 +567,8 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
check_argc(argc, 0, 0);
if (!given_config_source.file nongit)
die(not in a git directory);
+ if (given_config_source.use_stdin)
+ die(editing stdin is not supported);
if (given_config_source.blob)
die(editing blobs is not supported);
git_config(git_default_config, NULL);
diff --git a/cache.h b/cache.h
index 9d94bd69f7db..4db19b537059 100644
--- a/cache.h
+++ b/cache.h
@@ -1147,6 +1147,7 @@ extern int update_server_info(int);
#define CONFIG_GENERIC_ERROR 7
struct git_config_source {
+ unsigned int use_stdin:1;
const char *file;
const char *blob;
};
diff --git a/config.c b/config.c
index 6269da907964..7b42608f5c89 100644
--- a/config.c
+++ b/config.c
@@ -443,10 +443,20 @@ static int git_parse_source(config_fn_t fn, void *data)
if (get_value(fn, data, var) 0)
break;
}
- if (cf-die_on_error)
- die(bad config file line %d in %s, cf-linenr, cf-name);
- else
- return error(bad config file line %d in %s, cf-linenr,
cf-name);
+ if (cf-die_on_error) {
+ if (cf-name)
+ die(bad config file line %d in %s,
+ cf-linenr, cf-name);
+ else
+ die(bad config file line %d, cf-linenr);
+
+ } else {
+ if (cf-name)
+ return error(bad config file line %d in %s,
+ cf-linenr, cf-name);
+ else
+ return error(bad config file line %d, cf-linenr);
+ }
}
static int parse_unit_factor(const char *end, uintmax_t *val)
@@ -1030,24 +1040,34 @@ static int do_config_from(struct config_source *top,
config_fn_t fn, void *data)
return ret;
}
-int git_config_from_file(config_fn_t fn, const char *filename, void *data)
+static int do_config_from_file(config_fn_t fn, const char *filename, FILE *f,
+ void *data)
{
- int ret;
- FILE *f = fopen(filename, r);
+ struct config_source top;
- ret = -1;
- if (f) {
- struct config_source top;
+ top.u.file = f;
+ top.name = filename;
+ top.die_on_error = 1;
+ top.do_fgetc = config_file_fgetc;
+ top.do_ungetc = config_file_ungetc;
+ top.do_ftell = config_file_ftell;
- top.u.file = f;
- top.name = filename;
- top.die_on_error = 1;
- top.do_fgetc = config_file_fgetc;
- top.do_ungetc = config_file_ungetc;
- top.do_ftell = config_file_ftell;
+ return do_config_from(top, fn, data);
+}
+
+static int git_config_from_stdin(config_fn_t fn, void *data)
+{
+ return do_config_from_file(fn, NULL, stdin, data);
+}
- ret = do_config_from(top, fn, data);
+int git_config_from_file(config_fn_t fn, const char *filename, void *data)
+{
+ int ret = -1;
+ FILE *f;
+ f = fopen(filename, r);
+ if (f) {
+ ret = do_config_from_file(fn, filename, f, data);
fclose(f);
}
return ret;
@@ -1188,7 +1208,9 @@ int git_config_with_options(config_fn_t fn, void *data,
*
Re: [BUG?] git http connection reuse
On Sat, 15 Feb 2014, Kyle J. McKay wrote: If pipelining is off (the default) and total connections is not 1 it sounds to me from the description above that the requests will be executed on separate connections until the maximum number of connections is in use and then there might be some reuse. Not exactly. When about to do a request, libcurl will always try to find an existing idle but open connection in its connection pool to re-use. With the multi interface you can of course easily start N requests at once to the same host and then they'll only re-use connections to the extent there are connections to pick, otherwise it'll create new connections. Daniel Stenberg (7 Jan 2014) - ConnectionExists: fix NTLM check for new connection Looks like you're just lucky as that above change first appears in 7.35.0. But it seems there are some patches for older versions so they might be affected as well [2]. Right, the problem is there to make sure that a NTLM-auth connection with different credentials aren't re-used. NTLM with its connection-oriented authentication breaks the traditional HTTP paradigms and before this change there was a risk that libcurl would wrongly re-use a NTLM connection that was done with different credentials! I suspect we introduced a regression here with that fix. I'll dig into this. -- / daniel.haxx.se -- 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
Re: [BUG?] git http connection reuse
On Sun, 16 Feb 2014, Daniel Stenberg wrote: Right, the problem is there to make sure that a NTLM-auth connection with different credentials aren't re-used. NTLM with its connection-oriented authentication breaks the traditional HTTP paradigms and before this change there was a risk that libcurl would wrongly re-use a NTLM connection that was done with different credentials! I suspect we introduced a regression here with that fix. I'll dig into this. Thanks for pointing this out! I could repeat this problem with a curl test case so I wrote up two, and then I made a fix to curl: https://github.com/bagder/curl/commit/d765099813f5 -- / daniel.haxx.se -- 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
Re: [RFH] hackday and GSoC topic suggestions
On Sun, Feb 9, 2014 at 2:03 AM, Thomas Rast t...@thomasrast.ch wrote: Easy: * Add -p 'e' when it fails to apply should offer an obvious way of starting from the original hunk (not the broken one) or both If it's too easy, you can add a command to change diff display settings (--color-words, context size...) -- Duy -- 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
Re: [RFH] hackday and GSoC topic suggestions
Duy Nguyen pclo...@gmail.com writes: On Sun, Feb 9, 2014 at 2:03 AM, Thomas Rast t...@thomasrast.ch wrote: Easy: * Add -p 'e' when it fails to apply should offer an obvious way of starting from the original hunk (not the broken one) or both If it's too easy, you can add a command to change diff display settings (--color-words, context size...) If you mean for GSoC, that violates the previously suggested rule -- I had it as a project proposal for at least two years and nobody was ever interested. -- Thomas Rast t...@thomasrast.ch -- 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
Re: Profiling support?
David Kastrup d...@gnu.org writes: Looking in the Makefile, I just find support for coverage reports using gcov. Whatever is there with profile in it seems to be for profile-based compilation rather than using gprof. [...] Is there a reason there are no prewired recipes or advice for using gprof on git? Is there a way to get the work done, namely seeing the actual distribution of call times (rather than iterations) using gcov so that this is not necessary? No reason I'm aware of, other than that nobody ever wrote it. Note that I wouldn't exactly be surprised if the gcov targets had bitrotted without anyone noticing. I haven't heard of any heavy users. I originally wrote them to do some basic test coverage analysis, but that's about it. -- Thomas Rast t...@thomasrast.ch -- 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
Re: Profiling support?
Thomas Rast t...@thomasrast.ch writes: David Kastrup d...@gnu.org writes: Looking in the Makefile, I just find support for coverage reports using gcov. Whatever is there with profile in it seems to be for profile-based compilation rather than using gprof. [...] Is there a reason there are no prewired recipes or advice for using gprof on git? Is there a way to get the work done, namely seeing the actual distribution of call times (rather than iterations) using gcov so that this is not necessary? No reason I'm aware of, other than that nobody ever wrote it. A solid testing/benchmarking framework would quite seem like a useful GSoC project as it would make it easy for casual programmers to dip their feet into their personal bottlenecks, and it would make it much easier to find worthwhile hotspots for future projects taking the challenge of speeding up core and/or specific operations. Note that I wouldn't exactly be surprised if the gcov targets had bitrotted without anyone noticing. I haven't heard of any heavy users. I originally wrote them to do some basic test coverage analysis, but that's about it. I've managed to make use of the outer sandwich layers: the prepare and the evaluate stuff. I ran my own tests for benchmarking though. It's enfuriatingly hard to get the stuff in the right directories and with the right options, so that was already more helpful than it probably should have been. -- David Kastrup -- 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
[PATCH 0/5] Miscellaneous fixes from static analysis
The first two of these fix real bugs, the rest just clean up some of the less obviously not actually a problem issues identified by Clang's static analyzer [1] and stack[2]. Stack is interesting in that it is designed to detect potentially undesirable optimizations where undefined behaviour may be being invoked unwittingly. It only detected two error's in git.git, the first of which is fixed by the final patch. The second it describes as: bug: anti-algebra model: | %11 = icmp ult i8* %extra_args, %7, !dbg !342 -- %10 = icmp slt i64 %9, 0, !dbg !342 %extra_args u ((sext i32 %buflen to i64) + %extra_args)nsw -- (-1 * (sext i32 %buflen to i64)) s 0 stack: - daemon.c:522:0 ncore: 1 core: - daemon.c:520:0 - pointer overflow which shows that Clang has converted (simplifying from daemon.c:520): char *end = extra_args + buflen; if (extra_args end) into: if (buflen 0) This doesn't look like it can ever be subject to pointer overflow, so I have not considered the churn worth it here. [1] http://clang-analyzer.llvm.org/ [2] https://github.com/xiw/stack John Keeping (5): notes-utils: handle boolean notes.rewritemode correctly utf8: fix iconv error detection utf8: use correct type for values in interval table builtin/mv: don't use memory after free streaming: simplify attaching a filter builtin/mv.c | 3 ++- notes-utils.c | 2 +- streaming.c | 5 + utf8.c| 6 +++--- 4 files changed, 7 insertions(+), 9 deletions(-) -- 1.9.rc0.187.g6292fff -- 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
[PATCH 2/5] utf8: fix iconv error detection
iconv(3) returns (size_t) -1 on error. Make sure that we cast the
-1 properly when checking for this.
Signed-off-by: John Keeping j...@keeping.me.uk
---
utf8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utf8.c b/utf8.c
index 0d20e0a..24c3c5c 100644
--- a/utf8.c
+++ b/utf8.c
@@ -529,7 +529,7 @@ char *reencode_string_iconv(const char *in, size_t insz,
iconv_t conv, int *outs
while (1) {
size_t cnt = iconv(conv, cp, insz, outpos, outsz);
- if (cnt == -1) {
+ if (cnt == (size_t) -1) {
size_t sofar;
if (errno != E2BIG) {
free(out);
--
1.9.rc0.187.g6292fff
--
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
[PATCH 3/5] utf8: use correct type for values in interval table
We treat these as unsigned everywhere and compare against unsigned
values, so declare them using the typedef we already have for this.
While we're here, fix the indentation as well.
Signed-off-by: John Keeping j...@keeping.me.uk
---
utf8.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/utf8.c b/utf8.c
index 24c3c5c..a831d50 100644
--- a/utf8.c
+++ b/utf8.c
@@ -5,8 +5,8 @@
/* This code is originally from http://www.cl.cam.ac.uk/~mgk25/ucs/ */
struct interval {
- int first;
- int last;
+ ucs_char_t first;
+ ucs_char_t last;
};
size_t display_mode_esc_sequence_len(const char *s)
--
1.9.rc0.187.g6292fff
--
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
[PATCH 1/5] notes-utils: handle boolean notes.rewritemode correctly
If we carry on after outputting config_error_nonbool then we're
guaranteed to dereference a null pointer.
Signed-off-by: John Keeping j...@keeping.me.uk
---
notes-utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/notes-utils.c b/notes-utils.c
index 2975dcd..4aa7023 100644
--- a/notes-utils.c
+++ b/notes-utils.c
@@ -75,7 +75,7 @@ static int notes_rewrite_config(const char *k, const char *v,
void *cb)
return 0;
} else if (!c-mode_from_env !strcmp(k, notes.rewritemode)) {
if (!v)
- config_error_nonbool(k);
+ return config_error_nonbool(k);
c-combine = parse_combine_notes_fn(v);
if (!c-combine) {
error(_(Bad notes.rewriteMode value: '%s'), v);
--
1.9.rc0.187.g6292fff
--
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
[PATCH 5/5] streaming: simplify attaching a filter
We are guaranteed that 'nst' is non-null because it is allocated with
xmalloc(), and in fact we rely on this three lines later by
unconditionally dereferencing it.
Signed-off-by: John Keeping j...@keeping.me.uk
---
streaming.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/streaming.c b/streaming.c
index d7c9f32..8a7135d 100644
--- a/streaming.c
+++ b/streaming.c
@@ -151,10 +151,7 @@ struct git_istream *open_istream(const unsigned char *sha1,
}
if (filter) {
/* Add !is_null_stream_filter(filter) for performance */
- struct git_istream *nst = attach_stream_filter(st, filter);
- if (!nst)
- close_istream(st);
- st = nst;
+ st = attach_stream_filter(st, filter);
}
*size = st-size;
--
1.9.rc0.187.g6292fff
--
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
Re: [PATCH] web--browse: Use powershell on Windows
On Sun, Feb 16, 2014 at 2:22 AM, Steven Penny svnp...@gmail.com wrote:
On Windows you can have either MinGW or Cygwin. As has been shown in this
script
MinGW uses start while Cygwin uses cygstart. The cygstart command is
robust but the start command breaks on certain URLs
$ git web--browse 'http://wikipedia.org/wiki/Key__Peele'
'_Peele' is not recognized as an internal or external command,
operable program or batch file.
An alternative is to use PowerShell. PowerShell is a component of Windows and
will work with both MinGW and Cygwin.
Signed-off-by: Steven Penny svnp...@gmail.com
---
diff --git a/Documentation/git-web--browse.txt
b/Documentation/git-web--browse.txt
index 2de575f..02cccf9 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -33,8 +33,7 @@ The following browsers (or commands) are currently
supported:
* lynx
* dillo
* open (this is the default under Mac OS X GUI)
-* start (this is the default under MinGW)
-* cygstart (this is the default under Cygwin)
+* powershell (this is the default under Windows)
* xdg-open
Custom commands may also be specified.
diff --git a/git-web--browse.sh b/git-web--browse.sh
index ebdfba6..72fbe32 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -34,7 +34,7 @@ valid_tool() {
firefox | iceweasel | seamonkey | iceape | \
chrome | google-chrome | chromium | chromium-browser | \
konqueror | opera | w3m | elinks | links | lynx | dillo | open | \
- start | cygstart | xdg-open)
+ powershell | xdg-open)
;; # happy
*)
valid_custom_tool $1 || return 1
@@ -124,13 +124,10 @@ if test -z $browser ; then
then
browser_candidates=open $browser_candidates
fi
- # /bin/start indicates MinGW
- if test -x /bin/start; then
- browser_candidates=start $browser_candidates
- fi
- # /usr/bin/cygstart indicates Cygwin
- if test -x /usr/bin/cygstart; then
- browser_candidates=cygstart $browser_candidates
+ # OS indicates Windows
+ if test -n $OS
+ then
+ browser_candidates=powershell $browser_candidates
fi
Doesn't this penalize users who don't have powershell installed?
for i in $browser_candidates; do
@@ -179,11 +176,11 @@ konqueror)
;;
esac
;;
-w3m|elinks|links|lynx|open|cygstart|xdg-open)
+w3m|elinks|links|lynx|open|xdg-open)
$browser_path $@
;;
-start)
- exec $browser_path 'web-browse' $@
+powershell)
+ $browser_path saps '$@'
;;
opera|dillo)
$browser_path $@
--
1.8.5.3
--
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
[PATCH 4/5] builtin/mv: don't use memory after free
If 'src' already ends with a slash, then add_slash() will just return it, meaning that 'free(src_with_slash)' is actually 'free(src)'. Since we use 'src' later, this will result in use-after-free. In fact, this cannot happen because 'src' comes from internal_copy_pathspec() without the KEEP_TRAILING_SLASH flag, so any trailing '/' will have been stripped; but static analysis tools are not clever enough to realise this and so warn that 'src' could be used after having been free'd. Fix this by checking that 'src_w_slash' is indeed newly allocated memory. Signed-off-by: John Keeping j...@keeping.me.uk --- builtin/mv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/builtin/mv.c b/builtin/mv.c index 21c46d1..7e26eb5 100644 --- a/builtin/mv.c +++ b/builtin/mv.c @@ -162,7 +162,8 @@ int cmd_mv(int argc, const char **argv, const char *prefix) if (strncmp(path, src_w_slash, len_w_slash)) break; } - free((char *)src_w_slash); + if (src_w_slash != src) + free((char *)src_w_slash); if (last - first 1) bad = _(source directory is empty); -- 1.9.rc0.187.g6292fff -- 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
Re: [PATCH 1/3] wt-status.c: make cut_lines[] const to shrink .data section a bit
On Sun, Feb 16, 2014 at 10:37:18AM +0700, Nguyễn Thái Ngọc Duy wrote: -static char cut_line[] = +static const char cut_line[] = Your subject says cut_lines[], but the variable is cut_line[] (no s). -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH 1/5] notes-utils: handle boolean notes.rewritemode correctly
John Keeping j...@keeping.me.uk writes: If we carry on after outputting config_error_nonbool then we're guaranteed to dereference a null pointer. Not really relevant to this patch, but looking at the output of git grep config_error_nonbool seems like a serious amount of ridiculousness going on. The header shows cache.h:extern int config_error_nonbool(const char *); cache.h:#define config_error_nonbool(s) (config_error_nonbool(s), -1) and the implementation config.c:#undef config_error_nonbool config.c:int config_error_nonbool(const char *var) Presumably this was done so that the uses of config_error_nonbool can be recognized as returning -1 unconditionally. But is that worth the obfuscation? Why not let config_error_nonbool return -1 in the first place? It does not appear like any caller would call the function rather than the macro, so why declare the function as returning an int at all? And why give it the same name as the macro (risking human/computer confusion and requiring an explicit #undef for the definition or was that declaration?) instead of config_error_nonbool_internal or whatever else? -- David Kastrup -- 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
[PATCH] diff: do not reuse_worktree_file for submodules
The GIT_EXTERNAL_DIFF calling code attempts to reuse existing worktree
files for the worktree side of diffs, for performance reasons.
However, that code also tries to do the same with submodules. This
results in calls to $GIT_EXTERNAL_DIFF where the old-file is a file of
the form Submodule commit $sha1, but the new-file is a directory in
the worktree.
Fix it by never reusing a worktree file in the submodule case.
Reported-by: Grégory Pakosz gregory.pak...@gmail.com
Signed-off-by: Thomas Rast t...@thomasrast.ch
---
diff.c | 5 +++--
t/t4020-diff-external.sh | 30 +-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 7c59bfe..e9a8874 100644
--- a/diff.c
+++ b/diff.c
@@ -2845,8 +2845,9 @@ static struct diff_tempfile *prepare_temp_file(const char
*name,
remove_tempfile_installed = 1;
}
- if (!one-sha1_valid ||
- reuse_worktree_file(name, one-sha1, 1)) {
+ if (!S_ISGITLINK(one-mode)
+ (!one-sha1_valid ||
+reuse_worktree_file(name, one-sha1, 1))) {
struct stat st;
if (lstat(name, st) 0) {
if (errno == ENOENT)
diff --git a/t/t4020-diff-external.sh b/t/t4020-diff-external.sh
index bcae35a..0446201 100755
--- a/t/t4020-diff-external.sh
+++ b/t/t4020-diff-external.sh
@@ -226,12 +226,13 @@ keep_only_cr () {
}
test_expect_success 'external diff with autocrlf = true' '
- git config core.autocrlf true
+ test_config core.autocrlf true
GIT_EXTERNAL_DIFF=./fake-diff.sh git diff
test $(wc -l crlfed.txt) = $(cat crlfed.txt | keep_only_cr | wc -c)
'
test_expect_success 'diff --cached' '
+ test_config core.autocrlf true
git add file
git update-index --assume-unchanged file
echo second file
@@ -239,4 +240,31 @@ test_expect_success 'diff --cached' '
test_cmp $TEST_DIRECTORY/t4020/diff.NUL actual
'
+test_expect_success 'clean up crlf leftovers' '
+ git update-index --no-assume-unchanged file
+ rm -f file*
+ git reset --hard
+'
+
+test_expect_success 'submodule diff' '
+ git init sub
+ ( cd sub test_commit sub1 )
+ git add sub
+ test_tick
+ git commit -m add submodule
+ ( cd sub test_commit sub2 )
+ write_script gather_pre_post.sh -\EOF
+ echo $1 $4 # path, mode
+ cat $2 # old file
+ cat $5 # new file
+ EOF
+ GIT_EXTERNAL_DIFF=./gather_pre_post.sh git diff actual
+ cat expected -EOF
+ sub 16
+ Subproject commit $(git rev-parse HEAD:sub)
+ Subproject commit $(cd sub git rev-parse HEAD)
+ EOF
+ test_cmp expected actual
+'
+
test_done
--
1.9.0.313.g3d0a325
--
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
Re: Profiling support?
David Kastrup d...@gnu.org writes: Thomas Rast t...@thomasrast.ch writes: David Kastrup d...@gnu.org writes: Looking in the Makefile, I just find support for coverage reports using gcov. Whatever is there with profile in it seems to be for profile-based compilation rather than using gprof. [...] Is there a reason there are no prewired recipes or advice for using gprof on git? Is there a way to get the work done, namely seeing the actual distribution of call times (rather than iterations) using gcov so that this is not necessary? No reason I'm aware of, other than that nobody ever wrote it. A solid testing/benchmarking framework would quite seem like a useful GSoC project as it would make it easy for casual programmers to dip their feet into their personal bottlenecks, and it would make it much easier to find worthwhile hotspots for future projects taking the challenge of speeding up core and/or specific operations. Note that I wouldn't exactly be surprised if the gcov targets had bitrotted without anyone noticing. I haven't heard of any heavy users. I originally wrote them to do some basic test coverage analysis, but that's about it. I've managed to make use of the outer sandwich layers: the prepare and the evaluate stuff. I ran my own tests for benchmarking though. Umm, are we even discussing the same thing here? Are you saying you ran profiling-instrumented code under the t/perf/ support code? Sounds nice... -- Thomas Rast t...@thomasrast.ch -- 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
Re: Profiling support?
Thomas Rast t...@thomasrast.ch writes: David Kastrup d...@gnu.org writes: Thomas Rast t...@thomasrast.ch writes: David Kastrup d...@gnu.org writes: Looking in the Makefile, I just find support for coverage reports using gcov. Whatever is there with profile in it seems to be for profile-based compilation rather than using gprof. [...] Is there a reason there are no prewired recipes or advice for using gprof on git? Is there a way to get the work done, namely seeing the actual distribution of call times (rather than iterations) using gcov so that this is not necessary? No reason I'm aware of, other than that nobody ever wrote it. A solid testing/benchmarking framework would quite seem like a useful GSoC project as it would make it easy for casual programmers to dip their feet into their personal bottlenecks, and it would make it much easier to find worthwhile hotspots for future projects taking the challenge of speeding up core and/or specific operations. Note that I wouldn't exactly be surprised if the gcov targets had bitrotted without anyone noticing. I haven't heard of any heavy users. I originally wrote them to do some basic test coverage analysis, but that's about it. I've managed to make use of the outer sandwich layers: the prepare and the evaluate stuff. I ran my own tests for benchmarking though. Umm, are we even discussing the same thing here? Maybe not. Are you saying you ran profiling-instrumented code under the t/perf/ support code? No. I used the toplevel Makefile targets coverage-clean, coverage-compile and, after running my own problematic test cases, coverage-report. I did not use the coverage-test target, nor did I venture into t/perf/ in any other way. -- David Kastrup -- 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
How to delete all merged branches?
Hi, so I tend to accumulate lots of branches as I'd do one branch per feature. When cleaning up, I'd like to delete all branches, which have been merged. I could use $ git branch -d (which was merged already?) ^C $ git branch --merged # let's find out ... $ # Now run git branch -d with each of the branches. This kind of question has already been discussed, http://stackoverflow.com/questions/6127328/how-can-i-delete-all-git-branches-which-are-already-merged suggests: git branch --merged | grep -v \* | xargs -n 1 git branch -d Now it seems as if this operation would be needed by quite a few people actually. Maybe it's time to integrate into git? I'd be interested, which way would be the most git-like way to do it. I could think of: $ git branch -d --merged # no need to specifiy a branch iff --merged is given with -d $ git branch --delete-merged# comes as an new extra option, doesn't clutter other commands $ git branch -d keyword-for-all-merged-branches Before starting such a feature, I'd like to hear input of others. Thanks, Stefan -- 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
Re: [PATCH v2] reset: optionally setup worktree and refresh index on --mixed
On Sat, Feb 15, 2014 at 9:28 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: Refreshing index requires work tree. So we have to options: always set up work tree (and refuse to reset if failing to do so), or make refreshing index optional. As refreshing index is not the main task, it makes more sense to make it optional. Reported-by: Patrick Palka patr...@parcs.ath.cx Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com Thanks! I can confirm that this change fixes my use case. -- 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
Re: How to delete all merged branches?
On Sun, Feb 16, 2014 at 06:37:12PM +0100, Stefan Beller wrote: Hi, so I tend to accumulate lots of branches as I'd do one branch per feature. When cleaning up, I'd like to delete all branches, which have been merged. I could use $ git branch -d (which was merged already?) ^C $ git branch --merged # let's find out ... $ # Now run git branch -d with each of the branches. This kind of question has already been discussed, http://stackoverflow.com/questions/6127328/how-can-i-delete-all-git-branches-which-are-already-merged suggests: git branch --merged | grep -v \* | xargs -n 1 git branch -d probably saner to check where you are first, and have it conform to some branch naming scheme; maybe someting like: - check you're on master - only consider branches that begin with first-last-/ -- 8 -- head=$(git rev-parse --verify HEAD) master=$(git rev-parse --verify master) if test $head != $master; then echo You must be on master exit 1 fi git branch --merged | sed -n -e 's/\ *//' -e '/^[^/][^/]\//p' | xargs git branch -d -- 8 -- Now it seems as if this operation would be needed by quite a few people actually. Maybe it's time to integrate into git? I'd be interested, which way would be the most git-like way to do it. I could think of: $ git branch -d --merged # no need to specifiy a branch iff --merged is given with -d $ git branch --delete-merged# comes as an new extra option, doesn't clutter other commands $ git branch -d keyword-for-all-merged-branches Before starting such a feature, I'd like to hear input of others. -- 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
Ambiguous branch names...
Hello, while trying out git (version 1.7.9.5), I did this: git clone -- ssh://myserver/~rohloff/git/w1.git w1 So I just cloned a test repository. The in the cloned w1 repository I executed: git branch origin/master git branch remotes/origin/master git branch refs/remotes/origin/master I now have got three *local* branches with the above names, which now seems to make it impossible to refer to the master branch from the origin *remote* repository. Wouldn't it make sense to forbid such names for local branches ? For example to enforce some rules like a local branch name *must not* start with remotes/ or refs/ ? so long Ingo -- 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
Re: Ambiguous branch names...
On Mon, Feb 17, 2014 at 3:34 AM, Ingo Rohloff lund...@gmx.de wrote: Hello, while trying out git (version 1.7.9.5), I did this: git clone -- ssh://myserver/~rohloff/git/w1.git w1 So I just cloned a test repository. The in the cloned w1 repository I executed: git branch origin/master git branch remotes/origin/master git branch refs/remotes/origin/master I now have got three *local* branches with the above names, which now seems to make it impossible to refer to the master branch from the origin *remote* repository. Wouldn't it make sense to forbid such names for local branches ? For example to enforce some rules like a local branch name *must not* start with remotes/ or refs/ ? See http://thread.gmane.org/gmane.comp.version-control.git/242096/focus=242181. The proposal basically is you can't create those branches without -f. -- Duy -- 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
Re: diff weirdness (bug?)
On 02/14/2014 09:03 PM, Junio C Hamano wrote: This is a combined diff, and yaml-related lines are added relative to your _other_ branch you are merging (notice these + are indented by one place). Relative to what you had at the tip of your branch before you started this operation that ended up conflicted, the half-merged result removes if/else that sets DIST_MODULE_PATH and replaces it with a single line (their +/- are on the first column, signifying that these are differences relative to the first parent, i.e. your state before you started the operation). if we remove these 3 lines, we'll get this diff: With that understanding, I think the output after removing these three lines is perfectlyh understandable and correct. You are looking at the three lines that used to exist in the version you started from, that were missing from the other side. If you remoe them, it will show as removal from _your_ version (notice these - that shows what _you_ did manually are on the first column, saying that that is relative to _your_ version). Thank you, I was completely unaware of combined diffs. Still: I can't see how this would explain the empty diff when deleting 4 lines instead of 3. Also: in the diff output I get 2 hashes, but these are not the hashes of the commits, but the contents of the files apparently. One should be HEAD (but if I run sha1sum over the file the hash doesn't match), but the other can't be the commit which I reverted: the diff is too small... or at least this is what I understand By the way, in the man of git diff there's the briefly mentioned '-m' flag. If anyone else reading this mail in the archives is confused by the combined diff output, just use git diff -m HEAD... I'll probably add this in my git aliases -- xmpp: berda...@gmail.com bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just for signing commits) -- 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
Serious flaws in git cvsimport
Hello, I really hate working with CVS, so I have set up a cronjob running git cvsimport on regular basis to create a mirror of gnuplot sources. I would use another tool, but until a few days ago I wasn't aware of anything else that supported incremental updates, so that I could run the conversion every few hours without the need to trash the old conversions and make all my local/testing branches incompatible with future development. I had a lot of problems with the tool, but I was tolerating it (in the spirit of numerous warnings that the tool isn't working properly): - Files that have been deleted from CVS long ago don't get removed from git (that's very very very annoying) - I have numerous problems with file permissions (executable vs. non-executable) - The first time when I do the import, all seems fine. But soon after that I start getting numerous warnings during conversion in the spirit of revision 1.X of file Y is tagged but not present But maybe that's a bug in CVS. But recently I discovered that a commit in the main branch of CVS (trunk/master/whatever-they-call-it-in-cvs) which was important to me was simply ignored by git cvsimport. The commit modified three files. Immediately after the commit, cvsimport claimed the repository was already up-to-date. After other changes have been done in CVS, bits and pieces from that important commit started appearing randomly, together with other commits to CVS – for example when the same file was modified in another commit, changes from that important commit to the same file were included as well in that later commit (but they didn't belong to each other). My understanding was that warnings about bad behaviour of git cvsimport were related mostly to inability to reproduce complicated branching and merging with zillions of branches. That would be acceptable to me because I wasn't interested in those zillions of branches and tags anyway. But it turned out that whatever is currently in the master branch of the repository created by git cvsimport isn't even corresponding to what's currently in CVS and some commits are simply missing from history along with their commit messages. The git repository contains too many files (those that have been deleted in CVS) and random other differences in random files, so that I'm not even able to compile the project any longer as a consequence. I'm willing to provide the exact details about the failures, but from what I understand the previous maintainer of the underlying tool (cvsps) deprecated it due to too numerous problems and flawed design, so I'm not sure if anyone would be willing to fix the bugs I'm running into. I'm currently testing cvs-fast-export of which I only heard a few days ago in the desperate search for a replacement for git cvsimport. It would be nice to see if manuals of cvsimport would at least mention the existence of that tool in the same way as it mentions cvs2git (it took me a while to learn about cvs-fast-export) or even better, to consider it as an alternative for cvsps via a special argument to cvsimport if that's possible. Thank you very much, Mojca (Please CC me in replies.) -- 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
git svn clone not work. It's stop with no error message.
Hi, I really wonder about this happen. I want svn→git migrate, and I use this command. git svn clone https://my.svn.repo/url --stdlayout When I test a small svn repository and 'real working repository 1' with same this command, it's complete successfully. But it's not work in a 'real working repository 2', it just stop suddenly. CMD console not shown any error message, last message are like this. r1 = 67f4093b82b7b764171b01f1566eca57f6c29ac2 I don't know about why this process stop.. 'real repository 2' configured same with 'real repository 1'. 'Real working repository 2' are very large but I don't know accurate size.. I working on Windows server 2008, 16GB RAM memory, 16 cores cpu, upper then 100GB hard disk space. I'm sorry. I'm not speak English well. But I really want someone help me.. Anybody have some idea about this happen? -- View this message in context: http://git.661346.n2.nabble.com/git-svn-clone-not-work-It-s-stop-with-no-error-message-tp7603785.html Sent from the git mailing list archive at Nabble.com. -- 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
