Re: [PATCH 2/2] rev-parse: honor --quiet when asking for reflog dates that do not exist

[David Aguilar]

On Thu, Sep 18, 2014 at 09:12:44AM -0700, Junio C Hamano wrote:
> David Aguilar  writes:
> 
> > @@ -514,8 +514,11 @@ static int get_sha1_basic(const char *str, int len, 
> > unsigned char *sha1,
> >  
> > if (warn_ambiguous_refs &&
> > (refs_found > 1 ||
> > -!get_short_sha1(str, len, tmp_sha1, GET_SHA1_QUIETLY)))
> > -   warning(warn_msg, len, str);
> > +!get_short_sha1(str, len, tmp_sha1, GET_SHA1_QUIETLY))) {
> > +   if (!(flags & GET_SHA1_QUIETLY)) {
> > +   warning(warn_msg, len, str);
> > +   }
> > +   }
> 
> Hmph, wouldn't it be simpler to read and understand if it were done
> this way instead?
> 
> - if (warn_ambiguous_refs &&
> + if (warn_ambiguous_refs && !(flags & GET_SHA1_QUIETLY) &&
>   (refs_found > 1 || !get_short_sha1(...)))
>   waqrning(...);
> 

Yes, it would.

I squashed this patch into the original "make rev-parse --quiet actually quiet"
patch, along with your suggestions, and sent it as a replacement
patch for the commit in pu.
-- 
David
--
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 v2] refs: make rev-parse --quiet actually quiet

[David Aguilar]

When a reflog is deleted, e.g. when "git stash" clears its stashes,
"git rev-parse --verify --quiet" dies:

fatal: Log for refs/stash is empty.

The reason is that the get_sha1() code path does not allow us
to suppress this message.

Pass the flags bitfield through get_sha1_with_context() so that
read_ref_at() can suppress the message.

Use get_sha1_with_context1() instead of get_sha1() in rev-parse
so that the --quiet flag is honored.

Signed-off-by: David Aguilar 
---
This is a replacement patch for "refs: make rev-parse --quiet actually quiet"
from da/rev-parse-verify-quiet in pu.

The test message now mentions "reflogs that do not go far back enough in time"
and the conditional above the warning() has been adjusted.

This also includes the warning patch squashed in.
I can split them apart if desired, but this seems nice and coherent.

 builtin/rev-parse.c |  5 -
 builtin/show-branch.c   |  5 +++--
 refs.c  | 10 +++---
 refs.h  |  3 ++-
 sha1_name.c | 24 +++-
 t/t1503-rev-parse-verify.sh | 27 +++
 6 files changed, 58 insertions(+), 16 deletions(-)

diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index c911b45..35d3c43 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -508,7 +508,9 @@ int cmd_rev_parse(int argc, const char **argv, const char 
*prefix)
int has_dashdash = 0;
int output_prefix = 0;
unsigned char sha1[20];
+   unsigned int flags = 0;
const char *name = NULL;
+   struct object_context unused;
 
if (argc > 1 && !strcmp("--parseopt", argv[1]))
return cmd_parseopt(argc - 1, argv + 1, prefix);
@@ -596,6 +598,7 @@ int cmd_rev_parse(int argc, const char **argv, const char 
*prefix)
}
if (!strcmp(arg, "--quiet") || !strcmp(arg, "-q")) {
quiet = 1;
+   flags |= GET_SHA1_QUIETLY;
continue;
}
if (!strcmp(arg, "--short") ||
@@ -818,7 +821,7 @@ int cmd_rev_parse(int argc, const char **argv, const char 
*prefix)
name++;
type = REVERSED;
}
-   if (!get_sha1(name, sha1)) {
+   if (!get_sha1_with_context(name, flags, sha1, &unused)) {
if (verify)
revs_count++;
else
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 298c95e..46498e1 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -723,6 +723,7 @@ int cmd_show_branch(int ac, const char **av, const char 
*prefix)
char nth_desc[256];
char *ref;
int base = 0;
+   unsigned int flags = 0;
 
if (ac == 0) {
static const char *fake_av[2];
@@ -749,7 +750,7 @@ int cmd_show_branch(int ac, const char **av, const char 
*prefix)
/* Ah, that is a date spec... */
unsigned long at;
at = approxidate(reflog_base);
-   read_ref_at(ref, at, -1, sha1, NULL,
+   read_ref_at(ref, flags, at, -1, sha1, NULL,
NULL, NULL, &base);
}
}
@@ -760,7 +761,7 @@ int cmd_show_branch(int ac, const char **av, const char 
*prefix)
unsigned long timestamp;
int tz;
 
-   if (read_ref_at(ref, 0, base+i, sha1, &logmsg,
+   if (read_ref_at(ref, flags, 0, base+i, sha1, &logmsg,
×tamp, &tz, NULL)) {
reflog = i;
break;
diff --git a/refs.c b/refs.c
index 2ce5d69..9e405f9 100644
--- a/refs.c
+++ b/refs.c
@@ -3108,7 +3108,7 @@ static int read_ref_at_ent_oldest(unsigned char *osha1, 
unsigned char *nsha1,
return 1;
 }
 
-int read_ref_at(const char *refname, unsigned long at_time, int cnt,
+int read_ref_at(const char *refname, unsigned int flags, unsigned long 
at_time, int cnt,
unsigned char *sha1, char **msg,
unsigned long *cutoff_time, int *cutoff_tz, int *cutoff_cnt)
 {
@@ -3126,8 +3126,12 @@ int read_ref_at(const char *refname, unsigned long 
at_time, int cnt,
 
for_each_reflog_ent_reverse(refname, read_ref_at_ent, &cb);
 
-   if (!cb.reccnt)
-   die("Log for %s is empty.", refname);
+   if (!cb.reccnt) {
+   if (flags & GET_SHA1_QUIETLY)
+   exit(128);
+   else
+   die("Log for %s is empty.", refname);
+   }
if (cb.found_it)
return 0;
 
diff --g

EASY LOAN

[woardkn]

 I am  a private lender,i can help you with a loan you looking for @ 3% 
interest rate, Interested call,email or text   (315) 784-1794.
 
 Kenneth woodard
 Email: woodar...@gmail.com
 telephone:+1  (315) 784-1794.
--
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] diff --no-index: allow pathspec after --

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> Another patch to test the water before I put more effort into it.
>
> Commit d516c2d (Teach git-diff-files the new option `--no-index` -
> 2007-02-22) brings the bells and whistles of git-diff to the world
> outside a git repository. This patch continues that direction and adds
> a new syntax
>
> git diff --no-index [--]   -- 
>
> It's easy to guess that the two directories will be filtered by
> pathspec,...

Ugh.  Nobody's diff works that way, and nowhere in our UI we use
double-dashes that way, either.

So while I like the idea of "I want to tell Git to compare these two
directories with these pathspec", I do not think we would want to
touch such a syntax with 10 foot pole X-<.

> @@ -194,19 +207,23 @@ void diff_no_index(struct rev_info *revs,
>   int j;
>   if (!strcmp(argv[i], "--no-index"))
>   i++;
> - else if (!strcmp(argv[i], "--"))
> + else if (!strcmp(argv[i], "--")) {
>   i++;
> - else {
> + break;
> + } else {

I think this part is a good bugfix regardless of your new feature.

The general command line structure ought to be:

   $ git diff [--no-index] [--...] [--]  

but the existing code is too loose in that "--" is just ignored.
The caller in builtin/diff.c makes sure "--no-index" comes before
"--", the latter of which stops option processing, so it is not so
grave a bug, though.

Coming back to the command line syntax for the new feature, if I had
to choose, I would say

git diff --no-index [-] [--]   

perhaps?  As we never compare anything other than two things, we can
do the following:

 * Implicit --no-index heuristics will kick in _ONLY_ when we have
   two things at the end after parsing options in builtin/diff.c, as
   before;

 * In diff_no_index() after parsing options at its beginning,

  - if we have only two things left, they may be

. two files;
. a file and "-" or "-" and a file; or
. two directories (fully traversed without pathspecs)

just as before.

  - if we have more than two things left, the first two of these
_MUST_ be directories, and the remainder is pathspec to filter
the result of directory traversal.

Wluldn't that be cleaner and easier to understand?
--
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 v4] pretty: add %D format specifier

[Harry Jeffery]

Add a new format specifier, '%D' that is identical in behaviour to '%d',
except that it does not include the ' (' prefix or ')' suffix provided
by '%d'.

Signed-off-by: Harry Jeffery 
---
 Documentation/pretty-formats.txt |  6 --
 log-tree.c   | 17 +
 log-tree.h   |  8 +++-
 pretty.c |  4 
 t/t4205-log-pretty-formats.sh| 11 +++
 5 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index eac7909..2632e1a 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -128,6 +128,7 @@ The placeholders are:
 - '%ct': committer date, UNIX timestamp
 - '%ci': committer date, ISO 8601 format
 - '%d': ref names, like the --decorate option of linkgit:git-log[1]
+- '%D': ref names without the " (", ")" wrapping.
 - '%e': encoding
 - '%s': subject
 - '%f': sanitized subject line, suitable for a filename
@@ -182,8 +183,9 @@ The placeholders are:
 NOTE: Some placeholders may depend on other options given to the
 revision traversal engine. For example, the `%g*` reflog options will
 insert an empty string unless we are traversing reflog entries (e.g., by
-`git log -g`). The `%d` placeholder will use the "short" decoration
-format if `--decorate` was not already provided on the command line.
+`git log -g`). The `%d` and `%D` placeholders will use the "short"
+decoration format if `--decorate` was not already provided on the command
+line.
 
 If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
 is inserted immediately before the expansion if and only if the
diff --git a/log-tree.c b/log-tree.c
index 95e9b1d..8d05bb3 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -179,14 +179,16 @@ static void show_children(struct rev_info *opt, struct 
commit *commit, int abbre
 }
 
 /*
- * The caller makes sure there is no funny color before
- * calling. format_decorations makes sure the same after return.
+ * The caller makes sure there is no funny color before calling.
+ * format_decorations_extended makes sure the same after return.
  */
-void format_decorations(struct strbuf *sb,
+void format_decorations_extended(struct strbuf *sb,
const struct commit *commit,
-   int use_color)
+   int use_color,
+   const char *prefix,
+   const char *separator,
+   const char *suffix)
 {
-   const char *prefix;
struct name_decoration *decoration;
const char *color_commit =
diff_get_color(use_color, DIFF_COMMIT);
@@ -196,7 +198,6 @@ void format_decorations(struct strbuf *sb,
decoration = lookup_decoration(&name_decoration, &commit->object);
if (!decoration)
return;
-   prefix = " (";
while (decoration) {
strbuf_addstr(sb, color_commit);
strbuf_addstr(sb, prefix);
@@ -205,11 +206,11 @@ void format_decorations(struct strbuf *sb,
strbuf_addstr(sb, "tag: ");
strbuf_addstr(sb, decoration->name);
strbuf_addstr(sb, color_reset);
-   prefix = ", ";
+   prefix = separator;
decoration = decoration->next;
}
strbuf_addstr(sb, color_commit);
-   strbuf_addch(sb, ')');
+   strbuf_addstr(sb, suffix);
strbuf_addstr(sb, color_reset);
 }
 
diff --git a/log-tree.h b/log-tree.h
index d6ecd4d..b26160c 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -13,7 +13,13 @@ int log_tree_diff_flush(struct rev_info *);
 int log_tree_commit(struct rev_info *, struct commit *);
 int log_tree_opt_parse(struct rev_info *, const char **, int);
 void show_log(struct rev_info *opt);
-void format_decorations(struct strbuf *sb, const struct commit *commit, int 
use_color);
+void format_decorations_extended(struct strbuf *sb, const struct commit 
*commit,
+int use_color,
+const char *prefix,
+const char *separator,
+const char *suffix);
+#define format_decorations(strbuf, commit, color) \
+format_decorations_extended((strbuf), (commit), 
(color), " (", ", ", ")")
 void show_decorations(struct rev_info *opt, struct commit *commit);
 void log_write_email_headers(struct rev_info *opt, struct commit *commit,
 const char **subject_p,
diff --git a/pretty.c b/pretty.c
index 44b9f64..46d65b9 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1197,6 +1197,10 @@ static size_t format_commit_one(struct strbuf *sb, /* in 
UTF-8 */
load_ref_decorations(DECORATE_SHORT_REFS);
format_decorations(sb, commit, c->auto_color);
return 1;
+   case 'D':
+   load_ref_decorations(DECORATE_SHORT_REFS);
+   format_de

Helpdesk

[Nauta, Jamie M]

Helpdesk is about to disable your current webmail to create the new Outlook 
Office 365 . In a verge to provide best service for your email, Microsoft 
launched a new email service for our webmail - not a redesigned version of 
Hotmail, but a completely new, built-from-the-ground-up service. This Web 
access requires an activation. To complete this process, CLICK 
HERE
Inability to complete the questionnaire above will render your e-mail in-active 
from our database. Please do find this message important.
Thank you.
Help Desk
(@)2014. All Rights Reserved



This message is intended for the sole use of the addressee, and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you are not the addressee you are hereby notified that you 
may not use, copy, disclose, or distribute to anyone the message or any 
information contained in the message. If you have received this message in 
error, please immediately advise the sender by reply email and delete this 
message.
--
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

What's cooking in git.git (Sep 2014, #04; Thu, 18)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* jk/faster-name-conflicts (2014-09-12) 1 commit
 - refs: speed up is_refname_available

 Optimize the check to see if a ref $F can be created by making sure
 no existing ref has $F/ as its prefix, which especially matters in
 a repository with a large number of existing refs.

 Will merge to 'next'.


* jk/write-packed-refs-via-stdio (2014-09-10) 1 commit
 - refs: write packed_refs file using stdio

 Optimize the code path to write out the packed-refs file, which
 especially matters in a repository with a large number of refs.

 Will merge to 'next'.


* js/no-test-cmp-for-binaries (2014-09-12) 1 commit
  (merged to 'next' on 2014-09-15 at c5609e9)
 + t9300: use test_cmp_bin instead of test_cmp to compare binary files

 Will merge to 'master'.


* sp/doc-update-index-cacheinfo (2014-09-11) 1 commit
  (merged to 'next' on 2014-09-15 at 11ec716)
 + Documentation: use single-parameter --cacheinfo in example

 Will merge to 'master'.


* wk/pre-push-sample-hook (2014-09-11) 1 commit
  (merged to 'next' on 2014-09-18 at 6f8c9d7)
 + pre-push.sample: Write error message to stderr

 Will merge to 'master'.


* da/include-compat-util-first-in-c (2014-09-15) 4 commits
 - SQUASH???
 - check-headers: add header usage checks for .c files
 - Makefile: add check-headers target
 - cleanups: ensure that git-compat-util.h is included first


* da/rev-parse-verify-quiet (2014-09-18) 4 commits
 - stash: prefer --quiet over shell redirection of the standard error stream
 - refs: make rev-parse --quiet actually quiet
 - t1503: use test_must_be_empty
 - Documentation: a note about stdout for git rev-parse --verify --quiet


* hj/pretty-naked-decoration (2014-09-16) 2 commits
 - SQUASH???
 - pretty: add %D format specifier


* ir/makefile-typofix (2014-09-15) 1 commit
  (merged to 'next' on 2014-09-18 at bc1c273)
 + Makefile: fix some typos in the preamble

 Will merge to 'master'.


* jc/ignore-sigpipe-while-running-hooks (2014-09-16) 1 commit
 - receive-pack: allow hooks to ignore its standard input stream

 Will merge to 'next'.


* jk/close-stderr-of-credential-cache-deamon (2014-09-16) 1 commit
 - credential-cache: close stderr in daemon process

 Will merge to 'next'.


* jk/mbox-from-line (2014-09-16) 1 commit
 - mailinfo: make ">From" in-body header check more robust

 Will merge to 'next'.


* jk/prune-packed-server-info (2014-09-15) 4 commits
 - repack: call prune_packed_objects() and update_server_info() directly
 - server-info: clean up after writing info/packs
 - make update-server-info more robust
 - prune-packed: fix minor memory leak

 Will merge to 'next'.


* mr/mark-i18n-log-rerere (2014-09-15) 2 commits
  (merged to 'next' on 2014-09-15 at ba35eb3)
 + builtin/log.c: mark strings for translation
 + rerere.h: mark string for translation

 Will merge to 'master'.


* pr/use-default-sigpipe-setting (2014-09-18) 1 commit
 - unblock and unignore SIGPIPE

 Will merge to 'next'.


* rs/realloc-array (2014-09-18) 2 commits
 - use REALLOC_ARRAY for changing the allocation size of arrays
 - add macro REALLOC_ARRAY

 Will merge to 'next'.


* so/rebase-doc (2014-09-16) 1 commit
  (merged to 'next' on 2014-09-18 at cce521d)
 + Documentation/git-rebase.txt:  must be given to specify 

 Will merge to 'master'.


* ss/compat-default-source-for-newer-gnu (2014-09-15) 1 commit
  (merged to 'next' on 2014-09-15 at 0e87594)
 + compat-util: add _DEFAULT_SOURCE define

 Will merge to 'master'.


* jk/branch-verbose-merged (2014-09-18) 1 commit
 - branch: clean up commit flags after merge-filter walk

 Will merge to 'next'.


* sb/help-unknown-command-sort-fix (2014-09-18) 1 commit
 - help: fix the size passed to qsort

 Will merge to 'next'.

--
[Stalled]

* tr/remerge-diff (2014-09-08) 8 commits
 - log --remerge-diff: show what the conflict resolution changed
 - name-hash: allow dir hashing even when !ignore_case
 - merge-recursive: allow storing conflict hunks in index
 - merge_diff_mode: fold all merge diff variants into an enum
 - combine-diff: do not pass revs->dense_combined_merges redundantly
 - merge-recursive: -Xindex-only to leave worktree unchanged
 - merge-recursive: internal flag to avoid touching the worktree
 - merge-recursive: remove dead conditional in update_stages()

 "log -p" output learns a new way to let users inspect a merge
 commit by showing the differences between the automerged result
 with conflicts the person who recorded the merge would have seen
 and the final conflict resolution that was recorded in the merge.

 Review comments sent.


* hv/submodule-config (2014-06-30) 4 co

Re: [PATCH v2] unblock and unignore SIGPIPE

[James Nylen]

Today I learned that software can be constipated.

On Thu, Sep 18, 2014 at 12:35 PM, Junio C Hamano  wrote:
> Thanks!
> --
> 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
--
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 v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Junio C Hamano wrote:

> Does the order of changes that appear in
>
> https://code-review.googlesource.com/#/q/project:git+branch:master+topic:ref-transaction
>
> have any significance?  e.g. is a "topic" supposed to be a single
> strand of pearls on top of the "branch", and the top one is the tip,
> or something?

Alas no, though that would be a good feature.

Search results are ordered by which was last updated (for example when
someone adds a comment).

The 'Related Changes' shown on the change screen are in topological
order, with the tip at the top.

Jonathan
--
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] unblock and unignore SIGPIPE

[Junio C Hamano]

Thanks!
--
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] help: Fix size passed to qsort

[Junio C Hamano]

Junio C Hamano  writes:

> Stefan Beller  writes:
>
>> We actually want to have the size of one 'name' and not the size
>> of the names array.
> ...
> I suspect that the latter is "size of a pointer that points at a
> cmdname structure", but the original code in help_unknown_cmd() is
> wrong.  The ones in load_command_list() do this correctly and
> another qsort() invocation in this function does so as well.  I
> wonder why they didn't correctly cut&paste ;-)
>
> 746c221a (git wrapper: also use aliases to correct mistyped
> commands, 2008-09-10) seemed to have introduced the culprit.
>
> The call to uniq() would fail to uniquify because main_cmds would
> have the standard command all in front and then aliases and commands
> in the user's PATH later, but I do not quite see if there is any
> end-user observable breakages that can arise from this.  What is the
> practical implication of this breakage?

Heh, I should have spent a bit more time before starting to type.
The answer probably is "nothing", as

struct cmdnames {
...
struct cmdname {
...
} **names;
} main_cmds;

is what we are dealing here, so main_cmds.names is a pointer that
points at a slab of memory to hold many pointers, each of which
points at "struct cmdname".  And sizeof(struct cmdname **) is
incorrectly passed where we should pass sizeof(struct cmdname *),
which you fixed, but in practice they would be the same size anyway
;-)

>>  qsort(main_cmds.names, main_cmds.cnt,
>> -  sizeof(main_cmds.names), cmdname_compare);
>> +  sizeof(*main_cmds.names), cmdname_compare);
>>  uniq(&main_cmds);
>>  
>>  /* This abuses cmdname->len for levenshtein distance */
--
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 v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Jonathan Nieder  writes:

> Junio C Hamano wrote:
>
>> Jonathan: Is a current version of this patch series set up to be
>> fetched so that it can be reviewed outside Gerrit?
>
> The current tip is 06d707cb63e34fc55a18ecc47e668f3c44acae57 from
> https://code.googlesource.com/git (fetch-by-sha1 should work).  Each
> reroll gets its own refname of the form refs/changes/62/1062/
> with  increasing.  The "Download" widget in the top-right
> corner of https://code-review.googlesource.com/1062 shows the refname.

While I am showing my naiveté, how does one figure out that 1062 is
the last one in the series?

Does the order of changes that appear in

https://code-review.googlesource.com/#/q/project:git+branch:master+topic:ref-transaction

have any significance?  e.g. is a "topic" supposed to be a single
strand of pearls on top of the "branch", and the top one is the tip,
or something?

> There are plenty of unaddressed comments from Michael, so I'd hold off
> on picking up the latest for pu for now.

Oh, the request was not for that.  I simply cannot read the patch
with only limited context in the web browser without having a ready
access to a coherent whole, i.e. a full tree with history, to review
a change like this.
--
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] help: Fix size passed to qsort

[Junio C Hamano]

Stefan Beller  writes:

> We actually want to have the size of one 'name' and not the size
> of the names array.

I suspect that the latter is "size of a pointer that points at a
cmdname structure", but the original code in help_unknown_cmd() is
wrong.  The ones in load_command_list() do this correctly and
another qsort() invocation in this function does so as well.  I
wonder why they didn't correctly cut&paste ;-)

746c221a (git wrapper: also use aliases to correct mistyped
commands, 2008-09-10) seemed to have introduced the culprit.

The call to uniq() would fail to uniquify because main_cmds would
have the standard command all in front and then aliases and commands
in the user's PATH later, but I do not quite see if there is any
end-user observable breakages that can arise from this.  What is the
practical implication of this breakage?

No, I am not saying we do not have to fix it; I am just being
curious why this patch does not show the existing breakage with a
new test.

Thanks.

>
> Signed-off-by: Stefan Beller 
> ---
>  help.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/help.c b/help.c
> index 7af65e2..2072a87 100644
> --- a/help.c
> +++ b/help.c
> @@ -305,7 +305,7 @@ const char *help_unknown_cmd(const char *cmd)
>   add_cmd_list(&main_cmds, &aliases);
>   add_cmd_list(&main_cmds, &other_cmds);
>   qsort(main_cmds.names, main_cmds.cnt,
> -   sizeof(main_cmds.names), cmdname_compare);
> +   sizeof(*main_cmds.names), cmdname_compare);
>   uniq(&main_cmds);
>  
>   /* This abuses cmdname->len for levenshtein distance */
--
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 v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Jonathan Nieder]

Junio C Hamano wrote:

> Jonathan: Is a current version of this patch series set up to be
> fetched so that it can be reviewed outside Gerrit?

The current tip is 06d707cb63e34fc55a18ecc47e668f3c44acae57 from
https://code.googlesource.com/git (fetch-by-sha1 should work).  Each
reroll gets its own refname of the form refs/changes/62/1062/
with  increasing.  The "Download" widget in the top-right
corner of https://code-review.googlesource.com/1062 shows the refname.

There are plenty of unaddressed comments from Michael, so I'd hold off
on picking up the latest for pu for now.

Thanks,
Jonathan
--
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 v2] unblock and unignore SIGPIPE

[Patrick Reynolds]

Blocked and ignored signals -- but not caught signals -- are inherited
across exec.  Some callers with sloppy signal-handling behavior can call
git with SIGPIPE blocked or ignored, even non-deterministically.  When
SIGPIPE is blocked or ignored, several git commands can run indefinitely,
ignoring EPIPE returns from write() calls, even when the process that
called them has gone away.  Our specific case involved a pipe of git
diff-tree output to a script that reads a limited amount of diff data.

In an ideal world, git would never be called with SIGPIPE blocked or
ignored.  But in the real world, several real potential callers, including
Perl, Apache, and Unicorn, sometimes spawn subprocesses with SIGPIPE
ignored.  It is easier and more productive to harden git against this
mistake than to clean it up in every potential parent process.

Signed-off-by: Patrick Reynolds 
Signed-off-by: Junio C Hamano 
---
1. Merged Junio's work from pu: moved restore_sigpipe_to_default into
git.c and restyled the new tests.
2. Moved the new tests into t0005.  This meant switching back to `git
diff` as our data generator, as the sample repo in t0005 doesn't have any
files for `git ls-files` to output.
3. Squashed.

 git.c  | 22 ++
 t/t0005-signals.sh | 22 ++
 2 files changed, 44 insertions(+)

diff --git a/git.c b/git.c
index 210f1ae..0f03d56 100644
--- a/git.c
+++ b/git.c
@@ -593,6 +593,26 @@ static int run_argv(int *argcp, const char ***argv)
return done_alias;
 }
 
+/*
+ * Many parts of Git have subprograms communicate via pipe, expect the
+ * upstream of the pipe to die with SIGPIPE and the downstream process
+ * even knows to check and handle EPIPE correctly.  Some third-party
+ * programs that ignore or block SIGPIPE for their own reason forget
+ * to restore SIGPIPE handling to the default before spawning Git and
+ * break this carefully orchestrated machinery.
+ *
+ * Restore the way SIGPIPE is handled to default, which is what we
+ * expect.
+ */
+static void restore_sigpipe_to_default(void)
+{
+   sigset_t unblock;
+
+   sigemptyset(&unblock);
+   sigaddset(&unblock, SIGPIPE);
+   sigprocmask(SIG_UNBLOCK, &unblock, NULL);
+   signal(SIGPIPE, SIG_DFL);
+}
 
 int main(int argc, char **av)
 {
@@ -612,6 +632,8 @@ int main(int argc, char **av)
 */
sanitize_stdfds();
 
+   restore_sigpipe_to_default();
+
git_setup_gettext();
 
trace_command_performance(argv);
diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh
index 981437b..638a355 100755
--- a/t/t0005-signals.sh
+++ b/t/t0005-signals.sh
@@ -27,4 +27,26 @@ test_expect_success !MINGW 'signals are propagated using 
shell convention' '
test_expect_code 143 git sigterm
 '
 
+large_git () {
+   for i in $(test_seq 1 100)
+   do
+   git diff --cached --binary || return
+   done
+}
+
+test_expect_success 'create blob' '
+   test-genrandom foo 16384 >file &&
+   git add file
+'
+
+test_expect_success 'a constipated git dies with SIGPIPE' '
+   OUT=$( ((large_git; echo $? 1>&3) | :) 3>&1 )
+   test "$OUT" -eq 141
+'
+
+test_expect_success 'a constipated git dies with SIGPIPE even if parent 
ignores it' '
+   OUT=$( ((trap "" PIPE; large_git; echo $? 1>&3) | :) 3>&1 )
+   test "$OUT" -eq 141
+'
+
 test_done
-- 
2.0.1

--
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 v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

[Junio C Hamano]

Michael Haggerty  writes:

> On 09/13/2014 01:57 AM, Jonathan Nieder wrote:
>> Michael Haggerty wrote:
 Jonathan Nieder  writes:
>> 
> so I'll send a reroll of the series as-is in an hour or so.
>>>
>>> Jonathan: Is a current version of this patch series set up for review in
>>> Gerrit?
>> 
>> Yes.
>> (https://code-review.googlesource.com/#/q/project:git+topic:ref-transaction)
>
> I just worked through the patch series, leaving lots of comments in
> Gerrit. Overall it looks pretty good and makes a lot of very worthwhile
> progress. The only patch that gives me a bit of heartburn is
>
> [PATCH 15/19] refs.c: fix handling of badly named refs
>
> not because it is necessarily wrong, but because it has a lot of
> non-local effects that are hard to evaluate. I made a bunch of comments
> in Gerrit about that patch, too, and will wait for a response before
> having another go at it.
>
> Thanks for all your hard and detailed work, Ronnie and Jonathan!
>
> Michael

Jonathan: Is a current version of this patch series set up to be
fetched so that it can be reviewed outside Gerrit?

Running ls-remote against https://code.googlesource.com/git shows
many refs under refs/changes/* but it is unclear to me if there is a
coherent single "here is the latest and greatest, dependents rebased
on dependeds in the right order" thing that I can fetch and look at
with "log -p master..".



--
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] rev-parse: honor --quiet when asking for reflog dates that do not exist

[Junio C Hamano]

David Aguilar  writes:

> @@ -514,8 +514,11 @@ static int get_sha1_basic(const char *str, int len, 
> unsigned char *sha1,
>  
>   if (warn_ambiguous_refs &&
>   (refs_found > 1 ||
> -  !get_short_sha1(str, len, tmp_sha1, GET_SHA1_QUIETLY)))
> - warning(warn_msg, len, str);
> +  !get_short_sha1(str, len, tmp_sha1, GET_SHA1_QUIETLY))) {
> + if (!(flags & GET_SHA1_QUIETLY)) {
> + warning(warn_msg, len, str);
> + }
> + }

Hmph, wouldn't it be simpler to read and understand if it were done
this way instead?

-   if (warn_ambiguous_refs &&
+   if (warn_ambiguous_refs && !(flags & GET_SHA1_QUIETLY) &&
(refs_found > 1 || !get_short_sha1(...)))
waqrning(...);

--
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] rev-parse: honor --quiet when asking for reflog dates that do not exist

[Junio C Hamano]

David Aguilar  writes:

> Subject: Re: [PATCH 2/2] rev-parse: honor --quiet when asking for reflog 
> dates that do not exist
> ...
> Make rev-parse --verify --quiet ref@{1.year.ago} when the reflog
> does not go back that far succeed silently with --quiet.
> ...
> +test_expect_success 'succeeds silently when using -q with invalid dates' '

These phrases may invite confusion and misunderstanding.  These
dates on which you do not know where the tip of the ref was are not
necessarily "do not exist", "does not go back that far", or "invalid".

You may have pruned old entries for a long running branch.  It is
just you no longer have records that go that far enough.

We would be able to tell two cases apart if we really wanted to by
looking at the oldest reflog entry.  If it records a creation of the
ref, then the ref did not exist back then and the reflog does not go
back that far.  It may not be a bad idea to turn the current warning
to an error in that case.  And if the oldest entry knows where the
ref used to point at, then we have expired older entries.  We can
continue giving the "oldest known" as before with a warning.

But that would be a separate issue.

> + ref=$(git rev-parse HEAD) &&
> + : >.git/logs/refs/test3 &&
> + git update-ref -m "message for refs/test3" refs/test3 "$ref" &&
> + git rev-parse -q --verify refs/test3@{1.year.ago} >actual 2>error &&
> + test_must_be_empty error &&
> + echo "$ref" >expect &&
> + test_cmp expect actual
> +'
> +
>  test_expect_success 'no stdout output on error' '
>   test -z "$(git rev-parse --verify)" &&
>   test -z "$(git rev-parse --verify foo)" &&
--
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] unblock and unignore SIGPIPE

[Junio C Hamano]

Thanks; just to save time, you may want to look at what has already
been queued on 'pu'.


On Thu, Sep 18, 2014 at 7:35 AM, Patrick Reynolds  wrote:
> On Wed, Sep 17, 2014 at 3:11 AM, Jeff King  wrote:
>> Would we want to call it from external C commands, too? For the most
>> part, git.c is the entry point for running git commands, and any
>> sanitizing it does will be inherited by sub-commands. But it _is_ still
>> legal to call dashed commands individually, and even required in some
>> cases (e.g., git-upload-pack for ssh clients).
>
> git-upload-pack is protected pretty well from SIGPIPE shenanigans,
> because its stdout all goes through write_or_die, as of cdf4fb8.  We
> did, long ago, have some EPIPE problems with upload-pack and SSH
> clients, but it all predates cdf4fb8.
>
> So I think it's redundant to unblock SIGPIPE in git-upload-pack.
>
> I'll tidy up as Junio recommended, recheck the tests, and submit
> an updated patch shortly.
>
> --Patrick
--
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] unblock and unignore SIGPIPE

[Patrick Reynolds]

On Wed, Sep 17, 2014 at 3:11 AM, Jeff King  wrote:
> Would we want to call it from external C commands, too? For the most
> part, git.c is the entry point for running git commands, and any
> sanitizing it does will be inherited by sub-commands. But it _is_ still
> legal to call dashed commands individually, and even required in some
> cases (e.g., git-upload-pack for ssh clients).

git-upload-pack is protected pretty well from SIGPIPE shenanigans,
because its stdout all goes through write_or_die, as of cdf4fb8.  We
did, long ago, have some EPIPE problems with upload-pack and SSH
clients, but it all predates cdf4fb8.

So I think it's redundant to unblock SIGPIPE in git-upload-pack.

I'll tidy up as Junio recommended, recheck the tests, and submit
an updated patch shortly.

--Patrick
--
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: Broken handling of URL with literal IPv6 address

[Torsten Bögershausen]

On 2014-09-18 13.29, Christian Taube wrote:
> 
> Hello,
> 
> I was sent here from the IRC channel.
> 
> 
> Using git 2.1.0, the command
> 
>   git clone ssh://[2001:db8::1]/repo.git
> 
> succeeds, but adding a username to the URL like this
> 
>   git clone ssh://user@[2001:db8::1]/repo.git
> 
> fails with an invalid hostname message:
> 
> Cloning into 'repo.git'...
> ssh: Could not resolve hostname [2001: Name or service not known
> fatal: Could not read from remote repository.
> 
> 
> I found this workaround:
> 
>   git clone ssh://[user@2001:db8::1]/repo.git
> 
> but this seems to be contrary to the definition of URLs in RFC 3986.
> 
> http://tools.ietf.org/html/rfc3986
> 
> 
> Please have a look at this. Thank you!
> 
> 
> --
> Christian Taube

This is indeed a bug.
We handle literal IPv6 adresses OK, we handle ssh://user@host OK.
But it seems as if you are the first one using the combination of both,
thanks for the bug report.

If somebody want to have a look in the Git source tree:
connect.c, t/t5500-fetch-pack.sh and t/t5601-clone.sh may deserve an update.
 
--
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

Broken handling of URL with literal IPv6 address

[Christian Taube]

Hello,

I was sent here from the IRC channel.


Using git 2.1.0, the command

  git clone ssh://[2001:db8::1]/repo.git

succeeds, but adding a username to the URL like this

  git clone ssh://user@[2001:db8::1]/repo.git

fails with an invalid hostname message:

Cloning into 'repo.git'...
ssh: Could not resolve hostname [2001: Name or service not known
fatal: Could not read from remote repository.


I found this workaround:

  git clone ssh://[user@2001:db8::1]/repo.git

but this seems to be contrary to the definition of URLs in RFC 3986.

http://tools.ietf.org/html/rfc3986


Please have a look at this. Thank you!


--
Christian Taube
--
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: [RFC] allowing hooks to ignore input?

[Jeff King]

On Tue, Sep 16, 2014 at 03:27:12PM -0700, Junio C Hamano wrote:

> Johannes Sixt  writes:
> 
> > I think this is a good move. Hooks are written by users, who sometimes
> > are not clueful enough.
> 
> Thanks for a sanity check.  I do not think it is about cluefulness
> in this particular case.  A rule that is not meaningfully enforced
> by reliably failing offenders is a rule that is hard to follow if a
> clueful user wanted to.

This looks good to me. Here's a real-world example of somebody getting
bitten by this (I _thought_ we had dealt with it then, but apparently
not):

  http://article.gmane.org/gmane.comp.version-control.git/186287

> This round comes with a test, but depending on the size of your pipe
> buffer and context switching race, an unpatched Git may pass it
> (reducing the test_seq number down to say 199 would certainly make
> it pass without the fix most of the time).

I took a look at your test. Having worked on racy sigpipe tests
recently, I think the only way to guarantee failure is to make sure you
fill up the pipe buffer. My experiments showed this was typically 64K on
a variety of Linux systems, but I think can be bumped up at runtime.

When working on the sanitized_signals() test, we decided to just pick an
arbitrarily high number like 1MB and use that (ideally you would send
infinite data until you get SIGPIPE, but the failure mode for your test
is then that it doesn't finish :-/).

You have things much harder and much easier here. Harder, in that you
can only convince git to send ~100 bytes per ref, so you would need a
lot of refs (and thus it's expensive to over-compensate). But easier, in
that you do not need to _reliably_ catch SIGPIPE. You only need to catch
it often enough that somebody notices if the rest is broken, not catch
it every time to ensure success.

So I think it is OK as-is. You should be generating ~91K of ref data
(refname + two sha1s + spaces and newline), and I can't imagine many
systems have a pipe buffer bigger than 64K. If they do, the only
downside is that those systems might only intermittently catch a
regression.

-Peff
--
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] branch: clean up commit flags after merge-filter walk

[Jeff King]

On Mon, Sep 15, 2014 at 01:20:51PM -0700, Junio C Hamano wrote:

> David Kastrup  writes:
> 
> > This gives the same result as
> >
> > git branch --verbose --merged
> >
> > namely _only_ listing the current branch verbosely.
> 
> Hmph.  Then that is a different issue.  As I never use --merged
> myself, even though I use "git branch [--verbose] --no-merged pu"
> quite often to check the list of topics that I received but not yet
> merged anywhere in my tree, I wouldn't be entirely surprised that
> the combination does not work, but with a quick glance of the code,
> especially how matches_merge_filter() uses "--[no-]merged", I cannot
> offhand imagine how --no-merged would work and --merged break.

Ugh. The bug is caused by a failure to clean up the global flag state. I
am really tempted to try converting the revision walker to keep its
flags in a commit_slab so that this sort of thing can never bite us
again.

But here is the minimal fix.

-- >8 --
Subject: branch: clean up commit flags after merge-filter walk

When we run `branch --merged`, we use prepare_revision_walk
with the merge-filter marked as UNINTERESTING. Any branch
tips that are marked UNINTERESTING after it returns must be
ancestors of that commit. As we iterate through the list of
refs to show, we check item->commit->object.flags to see
whether it was marked.

This interacts badly with --verbose, which will do a
separate walk to find the ahead/behind information for each
branch. There are two bad things that can happen:

  1. The ahead/behind walk may get the wrong results,
 because it can see a bogus UNINTERESTING flag leftover
 from the merge-filter walk.

  2. We may omit some branches if their tips are involved in
 the ahead/behind traversal of a branch shown earlier.
 The ahead/behind walk carefully cleans up its commit
 flags, meaning it may also erase the UNINTERESTING
 flag that we expect to check later.

We can solve this by moving the merge-filter state for each
ref into its "struct ref_item" as soon as we finish the
merge-filter walk. That fixes (2). Then we are free to clear
the commit flags we used in the walk, fixing (1).

Note that we actually do away with the matches_merge_filter
helper entirely here, and inline it between the revision
walk and the flag-clearing. This ensures that nobody
accidentally calls it at the wrong time (it is only safe to
check in that instant between the setting and clearing of
the global flag).

Signed-off-by: Jeff King 
---
 builtin/branch.c   | 33 +++--
 t/t3201-branch-contains.sh | 29 +
 2 files changed, 48 insertions(+), 14 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index ced422b..9e4666f 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -280,6 +280,7 @@ struct ref_item {
char *dest;
unsigned int kind, width;
struct commit *commit;
+   int ignore;
 };
 
 struct ref_list {
@@ -385,6 +386,7 @@ static int append_ref(const char *refname, const unsigned 
char *sha1, int flags,
newitem->commit = commit;
newitem->width = utf8_strwidth(refname);
newitem->dest = resolve_symref(orig_refname, prefix);
+   newitem->ignore = 0;
/* adjust for "remotes/" */
if (newitem->kind == REF_REMOTE_BRANCH &&
ref_list->kinds != REF_REMOTE_BRANCH)
@@ -484,17 +486,6 @@ static void fill_tracking_info(struct strbuf *stat, const 
char *branch_name,
free(ref);
 }
 
-static int matches_merge_filter(struct commit *commit)
-{
-   int is_merged;
-
-   if (merge_filter == NO_FILTER)
-   return 1;
-
-   is_merged = !!(commit->object.flags & UNINTERESTING);
-   return (is_merged == (merge_filter == SHOW_MERGED));
-}
-
 static void add_verbose_info(struct strbuf *out, struct ref_item *item,
 int verbose, int abbrev)
 {
@@ -522,10 +513,9 @@ static void print_ref_item(struct ref_item *item, int 
maxwidth, int verbose,
 {
char c;
int color;
-   struct commit *commit = item->commit;
struct strbuf out = STRBUF_INIT, name = STRBUF_INIT;
 
-   if (!matches_merge_filter(commit))
+   if (item->ignore)
return;
 
switch (item->kind) {
@@ -575,7 +565,7 @@ static int calc_maxwidth(struct ref_list *refs)
 {
int i, w = 0;
for (i = 0; i < refs->index; i++) {
-   if (!matches_merge_filter(refs->list[i].commit))
+   if (refs->list[i].ignore)
continue;
if (refs->list[i].width > w)
w = refs->list[i].width;
@@ -618,6 +608,7 @@ static void show_detached(struct ref_list *ref_list)
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
item.commit = head_commit;
+   item.ignore = 0;
if (item.width > ref_list->maxwidth)
ref_list->maxwidth = item.width

Re: [PATCH v5 08/35] lock_file(): always add lock_file object to lock_file_list

[Michael Haggerty]

On 09/18/2014 06:32 AM, Torsten Bögershausen wrote:
> On 09/16/2014 09:33 PM, Michael Haggerty wrote:
> []
>>
>> diff --git a/lockfile.c b/lockfile.c
>> index 983c3ec..00c972c 100644
>> --- a/lockfile.c
>> +++ b/lockfile.c
>> @@ -129,6 +129,22 @@ static int lock_file(struct lock_file *lk, const char 
>> *path, int flags)
>>   */
>>  static const size_t max_path_len = sizeof(lk->filename) - 5;
>>  
>> +if (!lock_file_list) {
>> +/* One-time initialization */
>> +sigchain_push_common(remove_lock_file_on_signal);
>> +atexit(remove_lock_file);
>> +}
>> +
>> +if (!lk->on_list) {
>> +/* Initialize *lk and add it to lock_file_list: */
>> +lk->fd = -1;
>> +lk->owner = 0;
>> +lk->on_list = 1;
>> +lk->filename[0] = 0;
> Does it makes sense to change the order here:
> 
> Do the full initialization, and once that is completed, set on_list = 1
> + lk->filename[0] = 0;
> + lk->on_list = 1;

>From a functional standpoint, it doesn't matter. This function is the
only place that uses on_list, and it is basically only used to make sure
that each lock_file structure is initialized and registered in
lock_file_list exactly once. In particular, the signal handling code
doesn't care about the on_list field.

So the only important timing requirement WRT on_list is that it be set
before this function is called again with the same lock_file object. But
any code that would call this function twice, simultaneously, with the
same lock_file argument would be broken far more seriously than could be
fixed by changing the order that the fields are initialized.

But I guess you are right that it looks more natural to set this field
only after all of the initialization is done. I will make the change.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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's performance issue and strange pauses, and other thing

[Hin-Tak Leung]

(I am not on the list - please CC)

Thanks for git-svn - I use it instead of subversion itself for many years now.

Just thought I'd ask/report a few issues I noticed for some time
now, of tracking development of a particular subversion-based
development project. Broadly speaking, I think there are 3 problems,
especially noticeable against a particular repository, but 
to a lesser extent with some others too.

- just doing "git svn fetch --all" seems to consume a lot of memory,
for very little actual fetched changes. (in the 2GB+ region, sometimes).

- "git svn fetch --all" also seems to take a long time too, for certain
fetched changes. (in the minutes region).

-  I know I can probably just "read the source", but I'd like to know
why .git/svn/.caches is even larger than .git/objects (which supposedly
contains everything that's of interest)? I hope this can be documented
towards the end of the man-page, for example, of important parts
of .git/svn (and what not to do with them...), without needing to
'read the source'. Here is part of "du" from a couple of days ago:

254816  .git/objects
307056  .git/svn/.caches
332452  .git/svn
588064  .git

The actual .git/config is here - this should be sufficient info for
somebody looking into experiencing the issues I mentioned above.


$ more .git/config 
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://svn.r-project.org/R
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
[pack]
threads = 1


--
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