[PATCH (resend)] show-branch --upstream: add upstream branches to the list of branches to display
`git show-branch` is a useful tool to display topics, but when you have
several local topic branches based on different upstream branches, it
can get cumbersome to use the right upstream branch with the right set
of topic branches.
The --upstream flag automatically adds the upstream branch for every
topic branch given, such that:
`git show-branch --upstream` is equivalent to `git show-branch
$(git for-each-ref refs/heads --format '%(refname:short)')
$(git for-each-ref refs/heads --format '%(upstream:short)')`
`git show-branch --upstream foo bar` is equivalent to `git show-branch
foo bar $(git for-each-ref refs/heads/foo refs/heads/bar
--format '%(upstream:short)')`
Furthermore, the --topics argument only takes one upstream ref. However,
when combined with --upstream, all the upstream branches are considered,
and show-branch only shows commits that are NOT on ANY of those upstream
branches.
Signed-off-by: Mike Hommey m...@glandium.org
---
Documentation/git-show-branch.txt | 6 ++
builtin/show-branch.c | 42 +--
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-show-branch.txt
b/Documentation/git-show-branch.txt
index b91d4e5..fd29c8d 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -53,6 +53,10 @@ OPTIONS
branch to the list of revs to be shown when it is not
given on the command line.
+--upstream::
+ With this option, the command includes the upstream
+ branch of each rev to be shown.
+
--topo-order::
By default, the branches and their commits are shown in
reverse chronological order. This option makes them
@@ -102,6 +106,8 @@ OPTIONS
--topics::
Shows only commits that are NOT on the first branch given.
+ When used with `--upstream`, shows only commits that are NOT
+ on any upstream branch.
This helps track topic branches by hiding any commit that
is already in the main line of development. When given
git show-branch --topics master topic1 topic2, this
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 270e39c..90e2ac3 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -4,9 +4,10 @@
#include builtin.h
#include color.h
#include parse-options.h
+#include remote.h
static const char* show_branch_usage[] = {
-N_(git show-branch [-a|--all] [-r|--remotes] [--topo-order |
--date-order] [--current] [--color[=when] | --no-color] [--sparse]
[--more=n | --list | --independent | --merge-base] [--no-name | --sha1-name]
[--topics] [(rev | glob)...]),
+N_(git show-branch [-a|--all] [-r|--remotes] [--topo-order |
--date-order] [--current] [--upstream] [--color[=when] | --no-color]
[--sparse] [--more=n | --list | --independent | --merge-base] [--no-name |
--sha1-name] [--topics] [(rev | glob)...]),
N_(git show-branch (-g|--reflog)[=n[,base]] [--list] [ref]),
NULL
};
@@ -640,6 +641,7 @@ int cmd_show_branch(int ac, const char **av, const char
*prefix)
int sha1_name = 0;
int shown_merge_point = 0;
int with_current_branch = 0;
+ int with_upstream_branches = 0;
int head_at = -1;
int topics = 0;
int dense = 1;
@@ -658,6 +660,8 @@ int cmd_show_branch(int ac, const char **av, const char
*prefix)
OPT_BOOL(0, no-name, no_name, N_(suppress naming strings)),
OPT_BOOL(0, current, with_current_branch,
N_(include the current branch)),
+ OPT_BOOL(0, upstream, with_upstream_branches,
+N_(include upstream branches)),
OPT_BOOL(0, sha1-name, sha1_name,
N_(name commits with their object names)),
OPT_BOOL(0, merge-base, merge_base,
@@ -848,7 +852,41 @@ int cmd_show_branch(int ac, const char **av, const char
*prefix)
if (commit-object.flags == flag)
commit_list_insert_by_date(commit, list);
rev[num_rev] = commit;
+
+ if (with_upstream_branches) {
+ unsigned char branch_sha1[20];
+ struct branch *branch;
+ int current_ref_name_cnt = ref_name_cnt;
+
+ /* If this ref is already marked as an upstream, skip */
+ if (topics flag)
+ continue;
+
+ branch = branch_get(ref_name[num_rev]);
+
+ if (!branch || !branch-merge || !branch-merge[0] ||
+ !branch-merge[0]-dst)
+ continue;
+ if (get_sha1(branch-merge[0]-dst, branch_sha1))
+ continue;
+ append_remote_ref(branch-merge[0]-dst, branch_sha1,
0, 0);
+ /* If append_remote_ref didn't add a ref, it's either
+
Re: [PATCH] test: add git apply whitespace expansion tests
On Jan 18, 2015, at 14:11, Junio C Hamano wrote: On Sun, Jan 18, 2015 at 2:49 AM, Kyle J. McKay mack...@gmail.com wrote: * Here's some tests. With apply: make update_pre_post_images() sanity check the given postlen but not apply: count the size of postimage correctly test 1/4 and 4/4 trigger the 'die(BUG: postlen...' but test 2/4 and 3/4 do not although they fail because git apply generates garbage. Do the failing cases that do not trigger the new postlen check fail because the original (mis)counting thinks (incorrectly) that the rewritten result _should_ fit within the original postlen (hence we allow an in-place rewrite by passing postlen=0 to the helper), but in fact after rewriting postimage-len ends up being longer due to the miscounting? I'm not 100%, but I think so because: Before 250b3c6c (apply --whitespace=fix: avoid running over the postimage buffer, 2013-03-22), tests 1 and 4 tend to easily cause seg faults whereas 2 and 3 just give garbage. After 250b3c6c (apply --whitespace=fix: avoid running over the postimage buffer, 2013-03-22), tests 1 and 4 may pass without seg faulting although clearly there's some memory corruption going on because after apply: make update_pre_post_images() sanity check the given postlen they always die with the BUG message. I created the tests after reading your description in apply: count the size of postimage correctly. I made a guess about what would trigger the problem -- I do not have a deep understanding of the builtin/apply.c code though. Tests 2 and 3 were attempts to make the discrepancy between counted and needed (assuming the apply: count the size of postimage correctly fix has not been applied) progressively worse and instead I ended up with a different kind of failure. Test 4 was then an alternate attempt to create a very large discrepancy and it ended up with BUG: values not that dissimilar from test 1. FYI, without the counting fix, test 1 causes BUG: postlen = 390, used = 585 and test 4 causes BUG: postlen = 396, used = 591. So while I did manage to increase the discrepancy a bit from the values you reported for clojure (postlen = 262, used = 273), I was actually aiming for a difference big enough to pretty much always guarantee a core dump. The garbage tests 2 and 3 produce without the counting fix is reminiscent of what you get when you use memcpy instead of memmove for an overlapping memory copy operation. A slightly modified version of these 4 tests can be run as far back a v1.7.4 (when apply --whitespace=fix started fixing tab-in-indent errors) and you get core dumps or garbage there too for all 4. So since I've not been able to get test 2 or 3 to core dump (even before 250b3c6c) I tend to believe you are correct in that the code thinks (incorrectly) that the result should fit within the buffer. I say buffer because the test 3 patch inserts 100 lines into a 6 line file and yet it never seems to cause a core dump (even in v1.7.4), so the buffer size must be based on the patch, not the original -- I'm sure that would make sense if I understood what's going on in the apply code. I did manage to create a test 5 that causes BUG: postlen = 3036, used = 3542, but its verbose output has unfriendly long lines and it's fixed by the same counting fix as the others so it doesn't seem worthwhile to include it. -Kyle -- 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] l10n: de.po: translate 3 messages
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/po/de.po b/po/de.po index 38183fb..0b93b0f 100644 --- a/po/de.po +++ b/po/de.po @@ -6595,14 +6595,12 @@ msgid trailer(s) to add msgstr Anhang/Anhänge hinzufügen #: builtin/log.c:41 -#, fuzzy msgid git log [options] [revision range] [[--] path...] -msgstr git log [Optionen] [Commitbereich] [[--] Pfad...]\n +msgstr git log [Optionen] [Commitbereich] [[--] Pfad...] #: builtin/log.c:42 -#, fuzzy msgid git show [options] object... -msgstroder: git show [Optionen] Objekt... +msgstr git show [Optionen] Objekt... #: builtin/log.c:81 #, c-format @@ -9679,17 +9677,16 @@ msgid Linewrap output msgstr Ausgabe mit Zeilenumbrüchen #: builtin/show-branch.c:9 -#, fuzzy msgid git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order]\n \t\t [--current] [--color[=when] | --no-color] [--sparse]\n \t\t [--more=n | --list | --independent | --merge-base]\n \t [--no-name | --sha1-name] [--topics] [(rev | glob)...] msgstr -git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order] [-- -current] [--color[=Wann] | --no-color] [--sparse] [--more=n | --list | -- -independent | --merge-base] [--no-name | --sha1-name] [--topics] [(Commit -| glob)...] +git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order]\n +\t\t [--current] [--color[=Wann] | --no-color] [--sparse]\n +\t\t [--more=n | --list | --independent | --merge-base]\n +\t [--no-name | --sha1-name] [--topics] [(Commit | glob)...] #: builtin/show-branch.c:13 msgid git show-branch (-g|--reflog)[=n[,base]] [--list] [ref] -- 2.3.0.rc0.211.g05e7197 -- 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
Pretty format specifier for commit count?
I'd like to use git-log to generate a Debian changelog file (with one entry per commit), which has entries like this: package-name (version-number) unstable; urgency=low * ... -- Example Person per...@example.org RFC822-date Since I'm intentionally generating one entry per commit, I can generate *almost* all of this with git log: git log --pretty='format:packagename (FIXME) unstable; urgency=low%n%n * %s%n%w(0,4,4)%+b%w(0,0,0)%n -- %an %ae %aD%n' This produces entries like this: packagename (FIXME) unstable; urgency=low * Example change Long description of example change. -- Josh Triplett j...@joshtriplett.org Thu, 8 Jan 2015 16:36:52 -0800 packagename (FIXME) unstable; urgency=low * Initial version -- Josh Triplett j...@joshtriplett.org Thu, 8 Jan 2015 16:36:51 -0800 Would it be possible to add a format specifier producing a commit count, similar to that provided by git-describe? Such a specifier would allow filling in the version number in the format above (replacing the FIXME). (Note that the version numbers need to monotonically increase; otherwise I would just use the commit hash as the version numer.) - Josh Triplett -- 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] transport-helper: do not request symbolic refs to remote helpers
A typical remote helper will return a `list` of refs containing a symbolic
ref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all
the refs are being requested through `fetch` or `import`, including the
symbolic ref.
While this works properly, in some cases of a fetch, like `git fetch url`
or `git fetch origin HEAD`, or any fetch command involving a symbolic ref
without also fetching the corresponding ref it points to, the fetch command
fails with:
fatal: bad object
error: remote did not send all necessary objects
(in the case the remote helper returned '?' values to the `list` command).
This is because there is only one ref given to fetch(), and it's not
further resolved to something at the end of fetch_with_import().
While this can be somehow handled in the remote helper itself, by adding
a refspec for the symbolic ref, and storing an explicit ref in a private
namespace, and then handling the `import` for that symbolic ref
specifically, very few existing remote helpers are actually doing that.
So, instead of requesting the exact list of wanted refs to remote helpers,
treat symbolic refs differently and request the ref they point to instead.
Then, resolve the symbolic refs values based on the pointed ref.
This assumes there is no more than one level of indirection (a symbolic
ref doesn't point to another symbolic ref).
Signed-off-by: Mike Hommey m...@glandium.org
---
git-remote-testgit.sh | 8 +++-
t/t5801-remote-helpers.sh | 24
transport-helper.c| 13 -
3 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/git-remote-testgit.sh b/git-remote-testgit.sh
index a9c75a2..752c763 100755
--- a/git-remote-testgit.sh
+++ b/git-remote-testgit.sh
@@ -1,7 +1,13 @@
#!/bin/sh
# Copyright (c) 2012 Felipe Contreras
-alias=$1
+# The first argument can be a url when the fetch/push command was a url
+# instead of a configured remote. In this case, use a generic alias.
+if test $1 = testgit::$2; then
+ alias=_
+else
+ alias=$1
+fi
url=$2
dir=$GIT_DIR/testgit/$alias
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 2419407..c9d3ed1 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -281,4 +281,28 @@ test_expect_success 'push messages' '
)
'
+test_expect_success 'fetch HEAD' '
+ (cd server
+ git checkout master
+ echo more file
+ git commit -a -m more
+ )
+ (cd local
+ git fetch origin HEAD
+ )
+ compare_refs server HEAD local FETCH_HEAD
+'
+
+test_expect_success 'fetch url' '
+ (cd server
+ git checkout master
+ echo more file
+ git commit -a -m more
+ )
+ (cd local
+ git fetch testgit::${PWD}/../server
+ )
+ compare_refs server HEAD local FETCH_HEAD
+'
+
test_done
diff --git a/transport-helper.c b/transport-helper.c
index 0224687..27c82f7 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -356,7 +356,8 @@ static int fetch_with_fetch(struct transport *transport,
continue;
strbuf_addf(buf, fetch %s %s\n,
- sha1_to_hex(posn-old_sha1), posn-name);
+ sha1_to_hex(posn-old_sha1),
+ posn-symref ? posn-symref : posn-name);
}
strbuf_addch(buf, '\n');
@@ -454,7 +455,8 @@ static int fetch_with_import(struct transport *transport,
if (posn-status REF_STATUS_UPTODATE)
continue;
- strbuf_addf(buf, import %s\n, posn-name);
+ strbuf_addf(buf, import %s\n,
+ posn-symref ? posn-symref : posn-name);
sendline(data, buf);
strbuf_reset(buf);
}
@@ -487,14 +489,15 @@ static int fetch_with_import(struct transport *transport,
* fast-forward or this is a forced update.
*/
for (i = 0; i nr_heads; i++) {
- char *private;
+ char *private, *name;
posn = to_fetch[i];
if (posn-status REF_STATUS_UPTODATE)
continue;
+ name = posn-symref ? posn-symref : posn-name;
if (data-refspecs)
- private = apply_refspecs(data-refspecs,
data-refspec_nr, posn-name);
+ private = apply_refspecs(data-refspecs,
data-refspec_nr, name);
else
- private = xstrdup(posn-name);
+ private = xstrdup(name);
if (private) {
read_ref(private, posn-old_sha1);
free(private);
--
2.2.2.dirty
--
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
See my offer
Please read my email for a transfer offer of 6.5 Million Euro -- 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 v7 0/1] http: Add Accept-Language header if possible
From: Yi EungJun eungjun...@navercorp.com Changes since v6 From Junio C Hamano's review: * Fix check_language() in t5550-http-fetch-dumb.sh as his suggestion. From Eric Sunshine's review: * Rewrite the parser without state. Yi EungJun (1): http: Add Accept-Language header if possible http.c | 152 + remote-curl.c | 2 + t/t5550-http-fetch-dumb.sh | 42 + 3 files changed, 196 insertions(+) -- 2.2.0.44.g37b3e56.dirty -- 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] git-p4: support exclude in 'git p4 sync'
l...@diamand.org wrote on Sat, 17 Jan 2015 20:56 +: The git-p4 'clone' subcommand has long had the option to specify parts of the repo to be excluded, on the command line. But this has not been present in 'sync', which makes it less than useful: as soon as you do a sync, the excluded parts start being repopulated as those directories are changed. (You can achieve the same effect by using a client specification to do the exclusion, but that's then an extra step). The code for doing the exclusion is actually all present in the base 'P4Sync' class: this change turns that on by moving the definition of the command-line switch. It also updates the documentation and adds a test-case. Thanks, Luke And yes, I'm back to using version control systems other than git :-( So sorry. I on the other hand have been fortunate enough to switch to using only git. Nevertheless, I read through the patch and it looks good and makes sense. You've got my ack on this for what it's worth. Hopefully someone else starts picking up the git-p4 maintenance work. Hint. -- Pete -- 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
[L10N] Startup of Git 2.3.0 l10n round 2
Hi, Five l10n teams (Vietnamese, French, Swedish, Simplified Chinese and German) have already accomplished the 1st round l10n for Git 2.3.0. Now let's start l10n round 2 for the upcoming Git 2.3.0, because there are 3 new i18n updates found in Git master. The new git.pot is generated in commit v2.3.0-rc0-56-g105979f: l10n: git.pot: v2.3.0 round 2 (3 updated) Generate po/git.pot from v2.3.0-rc0-44-ga94655d for git v2.3.0 l10n round 2. Signed-off-by: Jiang Xin worldhello@gmail.com You can get it from the usual place: https://github.com/git-l10n/git-po/ As how to update your XX.po and help to translate Git, please see Updating a XX.po file and other sections in po/README file. -- Jiang Xin 2015-01-13 14:41 GMT+08:00 Jiang Xin worldhello@gmail.com: Hi, Since Git v2.3.0-rc0 had already been released, it's time to start new round of git l10n. This time there are 13 new messages need to be translated since last update for v2.2.0: l10n: git.pot: v2.3.0 round 1 (13 new, 11 removed) Generate po/git.pot from v2.3.0-rc0 for git v2.3.0 l10n round 1. Signed-off-by: Jiang Xin worldhello@gmail.com You can get it from the usual place: https://github.com/git-l10n/git-po/ As how to update your XX.po and help to translate Git, please see Updating a XX.po file and other sections in “po/README file. -- Jiang Xin -- 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 v7 1/1] http: Add Accept-Language header if possible
On 18.01.15 13:26, Yi EungJun wrote:
From: Yi EungJun eungjun...@navercorp.com
diff --git a/http.c b/http.c
index 040f362..349b033 100644
--- a/http.c
+++ b/http.c
@@ -68,6 +68,8 @@ static struct curl_slist *no_pragma_header;
static struct active_request_slot *active_queue_head;
+static char *cached_accept_language;
+
size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
{
size_t size = eltsize * nmemb;
@@ -515,6 +517,11 @@ void http_cleanup(void)
cert_auth.password = NULL;
}
ssl_cert_password_required = 0;
+
+ if (cached_accept_language) {
+ free(cached_accept_language);
+ cached_accept_language = NULL;
+ }
Minor remark:
free(NULL) is legal and does nothing.
We can simplify the code somewhat:
ssl_cert_password_required = 0;
free(cached_accept_language);
cached_accept_language = NULL;
}
struct active_request_slot *get_active_slot(void)
@@ -986,6 +993,145 @@ static void extract_content_type(struct strbuf *raw,
struct strbuf *type,
strbuf_addstr(charset, ISO-8859-1);
}
+/*
+ * Guess the user's preferred languages from the value in LANGUAGE
environment
+ * variable and LC_MESSAGES locale category if NO_GETTEXT is not defined.
+ *
+ * The result can be a colon-separated list like ko:ja:en.
+ */
+static const char *get_preferred_languages(void)
+{
+ const char *retval;
+
+ retval = getenv(LANGUAGE);
+ if (retval *retval)
+ return retval;
+
+#ifndef NO_GETTEXT
+ retval = setlocale(LC_MESSAGES, NULL);
+ if (retval *retval
+ strcmp(retval, C)
+ strcmp(retval, POSIX))
+ return retval;
+#endif
+
+ return NULL;
+}
+
+static void write_accept_language(struct strbuf *buf)
+{
+ /*
+ * MAX_DECIMAL_PLACES must not be larger than 3. If it is larger than
+ * that, q-value will be smaller than 0.001, the minimum q-value the
+ * HTTP specification allows. See
+ * http://tools.ietf.org/html/rfc7231#section-5.3.1 for q-value.
+ */
+ const int MAX_DECIMAL_PLACES = 3;
+ const int MAX_LANGUAGE_TAGS = 1000;
+ const int MAX_ACCEPT_LANGUAGE_HEADER_SIZE = 4000;
+ struct strbuf *language_tags = NULL;
+ int num_langs;
+ const char *s = get_preferred_languages();
+
+ /* Don't add Accept-Language header if no language is preferred. */
+ if (!s)
+ return;
+
+ /*
+ * Split the colon-separated string of preferred languages into
+ * language_tags array.
+ */
+ do {
+ /* increase language_tags array to add new language tag */
+ REALLOC_ARRAY(language_tags, num_langs + 1);
+ strbuf_init(language_tags[num_langs], 0);
+
+ /* collect language tag */
+ for (; *s (isalnum(*s) || *s == '_'); s++)
+ strbuf_addch(language_tags[num_langs], *s == '_' ? '-'
: *s);
+
+ /* skip .codeset, @modifier and any other unnecessary parts */
+ while (*s *s != ':')
+ s++;
+
+ if (language_tags[num_langs].len 0) {
+ num_langs++;
+ if (num_langs = MAX_LANGUAGE_TAGS - 1) /* -1 for '*' */
+ break;
+ }
+ } while (*s++);
+
+ /* write Accept-Language header into buf */
+ if (num_langs = 1) {
+ int i;
+ int last_buf_len;
+ int max_q;
+ int decimal_places;
+ char q_format[32];
+
+ /* add '*' */
+ REALLOC_ARRAY(language_tags, num_langs + 1);
+ strbuf_init(language_tags[num_langs], 0);
+ strbuf_addstr(language_tags[num_langs++], *);
+
+ /* compute decimal_places */
+ for (max_q = 1, decimal_places = 0;
+ max_q num_langs decimal_places =
MAX_DECIMAL_PLACES;
+ decimal_places++, max_q *= 10)
+ ;
+
+ sprintf(q_format, ;q=0.%%0%dd, decimal_places);
+
+ strbuf_addstr(buf, Accept-Language: );
+
+ for(i = 0; i num_langs; i++) {
+ if (language_tags[i].len == 0)
+ continue;
+
+ if (i 0)
+ strbuf_addstr(buf, , );
+
+ strbuf_addstr(buf, strbuf_detach(language_tags[i],
NULL));
+
+ if (i 0)
+ strbuf_addf(buf, q_format, max_q - i);
+
+ if (buf-len MAX_ACCEPT_LANGUAGE_HEADER_SIZE) {
+ strbuf_remove(buf, last_buf_len, buf-len -
last_buf_len);
+ break;
+ }
+
+ last_buf_len = buf-len;
+
[PATCH] test: add git apply whitespace expansion tests
When git apply fixes whitespace, the result can end up being longer than the initial text if whitespace ends up being expanded (such as with the tab-in-indent option). Since 250b3c6c (apply --whitespace=fix: avoid running over the postimage buffer, 2013-03-22) an attempt has been made to compute the correct final length in such a case. These tests all stress the whitespace-expansion-during-apply condition and can result in core dump failures when the final length is not computed correctly. Signed-off-by: Kyle J. McKay mack...@gmail.com --- * Here's some tests. With apply: make update_pre_post_images() sanity check the given postlen but not apply: count the size of postimage correctly test 1/4 and 4/4 trigger the 'die(BUG: postlen...' but test 2/4 and 3/4 do not although they fail because git apply generates garbage. * After applying apply: count the size of postimage correctly all 4 tests pass whereas they all fail without that. It's interesting that the BUG: postlen check does not trigger for 2/4 or 3/4 but the output is garbage in those cases without the fix. * Theses tests can easily trigger core dumps. It seems to depend on how the git binary was built and what exactly ends up getting stepped on as I have several different Git builds and some of them core dump on tests that others pass or just produce garbage for, but none of them passes 2/4 or 3/4 without the count postimage size correctly fix. t/t4138-apply-ws-expansion.sh | 121 ++ 1 file changed, 121 insertions(+) create mode 100755 t/t4138-apply-ws-expansion.sh diff --git a/t/t4138-apply-ws-expansion.sh b/t/t4138-apply-ws-expansion.sh new file mode 100755 index ..140ed9ac --- /dev/null +++ b/t/t4138-apply-ws-expansion.sh @@ -0,0 +1,121 @@ +#!/bin/sh +# +# Copyright (C) 2015 Kyle J. McKay +# + +# NOTE: To facilitate separate testing, this script can be run +# standalone to just create the test files and do nothing else +# by first setting the environment variable MAKE_PATCHES=1. + +test_description='git apply test patches with whitespace expansion.' + +[ -n $MAKE_PATCHES ] || \ +. ./test-lib.sh + +# +## create test-N, patchN.patch, expect-N files +# + +# test 1 +printf '\t%s\n' 1 2 3 4 5 6 before +printf '\t%s\n' 1 2 3 after +printf '%64s\n' a b c $x after +printf '\t%s\n' 4 5 6 after +git diff --no-index before after | \ +sed -e 's/before/test-1/' -e 's/after/test-1/' patch1.patch +printf '%64s\n' 1 2 3 4 5 6 test-1 +printf '%64s\n' 1 2 3 a b c 4 5 6 expect-1 + +# test 2 +printf '\t%s\n' a b c d e f before +printf '\t%s\n' a b c after +n=10 +x=1 +while [ $x -lt $n ]; do + printf '%63s%d\n' '' $x after + x=$(( $x + 1 )) +done +printf '\t%s\n' d e f after +git diff --no-index before after | \ +sed -e 's/before/test-2/' -e 's/after/test-2/' patch2.patch +printf '%64s\n' a b c d e f test-2 +printf '%64s\n' a b c expect-2 +x=1 +while [ $x -lt $n ]; do + printf '%63s%d\n' '' $x expect-2 + x=$(( $x + 1 )) +done +printf '%64s\n' d e f expect-2 + +# test 3 +printf '\t%s\n' a b c d e f before +printf '\t%s\n' a b c after +n=100 +x=0 +while [ $x -lt $n ]; do + printf '%63s%02d\n' '' $x after + x=$(( $x + 1 )) +done +printf '\t%s\n' d e f after +git diff --no-index before after | \ +sed -e 's/before/test-3/' -e 's/after/test-3/' patch3.patch +printf '%64s\n' a b c d e f test-3 +printf '%64s\n' a b c expect-3 +x=0 +while [ $x -lt $n ]; do + printf '%63s%02d\n' '' $x expect-3 + x=$(( $x + 1 )) +done +printf '%64s\n' d e f expect-3 + +# test 4 + before +x=0 +while [ $x -lt 50 ]; do + printf '\t%02d\n' $x before + x=$(( $x + 1 )) +done +cat before after +printf '%64s\n' a b c after +while [ $x -lt 100 ]; do + printf '\t%02d\n' $x before + printf '\t%02d\n' $x after + x=$(( $x + 1 )) +done +git diff --no-index before after | \ +sed -e 's/before/test-4/' -e 's/after/test-4/' patch4.patch + test-4 +x=0 +while [ $x -lt 50 ]; do + printf '%63s%02d\n' '' $x test-4 + x=$(( $x + 1 )) +done +cat test-4 expect-4 +printf '%64s\n' a b c expect-4 +while [ $x -lt 100 ]; do + printf '%63s%02d\n' '' $x test-4 + printf '%63s%02d\n' '' $x expect-4 + x=$(( $x + 1 )) +done + +# cleanup +rm before after + +[ -z $MAKE_PATCHES ] || exit 0 + +# +## Run the tests +# + +# Note that `patch` can successfully apply all patches when run +# with the --ignore-whitespace option. + +for t in 1 2 3 4; do + test_expect_success apply with ws expansion (t=$t) ' + git -c core.whitespace=tab-in-indent,tabwidth=63 \ + apply --whitespace=fix patch$t.patch + test_cmp test-$t expect-$t + ' +done + +test_done -- -- 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 v7 1/1] http: Add Accept-Language header if possible
From: Yi EungJun eungjun...@navercorp.com
Add an Accept-Language header which indicates the user's preferred
languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
Examples:
LANGUAGE= -
LANGUAGE=ko:en - Accept-Language: ko, en;q=0.9, *;q=0.1
LANGUAGE=ko LANG=en_US.UTF-8 - Accept-Language: ko, *;q=0.1
LANGUAGE= LANG=en_US.UTF-8 - Accept-Language: en-US, *;q=0.1
This gives git servers a chance to display remote error messages in
the user's preferred language.
Limit the number of languages to 1,000 because q-value must not be
smaller than 0.001, and limit the length of Accept-Language header to
4,000 bytes for some HTTP servers which cannot accept such long header.
Signed-off-by: Yi EungJun eungjun...@navercorp.com
---
http.c | 152 +
remote-curl.c | 2 +
t/t5550-http-fetch-dumb.sh | 42 +
3 files changed, 196 insertions(+)
diff --git a/http.c b/http.c
index 040f362..349b033 100644
--- a/http.c
+++ b/http.c
@@ -68,6 +68,8 @@ static struct curl_slist *no_pragma_header;
static struct active_request_slot *active_queue_head;
+static char *cached_accept_language;
+
size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
{
size_t size = eltsize * nmemb;
@@ -515,6 +517,11 @@ void http_cleanup(void)
cert_auth.password = NULL;
}
ssl_cert_password_required = 0;
+
+ if (cached_accept_language) {
+ free(cached_accept_language);
+ cached_accept_language = NULL;
+ }
}
struct active_request_slot *get_active_slot(void)
@@ -986,6 +993,145 @@ static void extract_content_type(struct strbuf *raw,
struct strbuf *type,
strbuf_addstr(charset, ISO-8859-1);
}
+/*
+ * Guess the user's preferred languages from the value in LANGUAGE environment
+ * variable and LC_MESSAGES locale category if NO_GETTEXT is not defined.
+ *
+ * The result can be a colon-separated list like ko:ja:en.
+ */
+static const char *get_preferred_languages(void)
+{
+ const char *retval;
+
+ retval = getenv(LANGUAGE);
+ if (retval *retval)
+ return retval;
+
+#ifndef NO_GETTEXT
+ retval = setlocale(LC_MESSAGES, NULL);
+ if (retval *retval
+ strcmp(retval, C)
+ strcmp(retval, POSIX))
+ return retval;
+#endif
+
+ return NULL;
+}
+
+static void write_accept_language(struct strbuf *buf)
+{
+ /*
+* MAX_DECIMAL_PLACES must not be larger than 3. If it is larger than
+* that, q-value will be smaller than 0.001, the minimum q-value the
+* HTTP specification allows. See
+* http://tools.ietf.org/html/rfc7231#section-5.3.1 for q-value.
+*/
+ const int MAX_DECIMAL_PLACES = 3;
+ const int MAX_LANGUAGE_TAGS = 1000;
+ const int MAX_ACCEPT_LANGUAGE_HEADER_SIZE = 4000;
+ struct strbuf *language_tags = NULL;
+ int num_langs;
+ const char *s = get_preferred_languages();
+
+ /* Don't add Accept-Language header if no language is preferred. */
+ if (!s)
+ return;
+
+ /*
+* Split the colon-separated string of preferred languages into
+* language_tags array.
+*/
+ do {
+ /* increase language_tags array to add new language tag */
+ REALLOC_ARRAY(language_tags, num_langs + 1);
+ strbuf_init(language_tags[num_langs], 0);
+
+ /* collect language tag */
+ for (; *s (isalnum(*s) || *s == '_'); s++)
+ strbuf_addch(language_tags[num_langs], *s == '_' ? '-'
: *s);
+
+ /* skip .codeset, @modifier and any other unnecessary parts */
+ while (*s *s != ':')
+ s++;
+
+ if (language_tags[num_langs].len 0) {
+ num_langs++;
+ if (num_langs = MAX_LANGUAGE_TAGS - 1) /* -1 for '*' */
+ break;
+ }
+ } while (*s++);
+
+ /* write Accept-Language header into buf */
+ if (num_langs = 1) {
+ int i;
+ int last_buf_len;
+ int max_q;
+ int decimal_places;
+ char q_format[32];
+
+ /* add '*' */
+ REALLOC_ARRAY(language_tags, num_langs + 1);
+ strbuf_init(language_tags[num_langs], 0);
+ strbuf_addstr(language_tags[num_langs++], *);
+
+ /* compute decimal_places */
+ for (max_q = 1, decimal_places = 0;
+ max_q num_langs decimal_places =
MAX_DECIMAL_PLACES;
+ decimal_places++, max_q *= 10)
+ ;
+
+ sprintf(q_format, ;q=0.%%0%dd, decimal_places);
+
+ strbuf_addstr(buf, Accept-Language: );
+
+ for(i = 0; i
Re: [PATCH] .clang-format: introduce the use of clang-format
Am 17.01.2015 um 22:30 schrieb Ramkumar Ramachandra:
Instead of manually eyeballing style in reviews, just ask all
contributors to run their patches through [git-]clang-format.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
The idea is to introduce the community to this new toy I found called
clang-format. Whether or not it's actually going to be used doesn't
bother me too much.
I'm not 100% sure of the style, but I'll leave you to tweak that
using http://clang.llvm.org/docs/ClangFormatStyleOptions.html
The current code isn't terribly conformant, but I suppose that'll
change with time.
.clang-format | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 .clang-format
diff --git a/.clang-format b/.clang-format
new file mode 100644
index 000..63a53e0
--- /dev/null
+++ b/.clang-format
@@ -0,0 +1,7 @@
+BasedOnStyle: LLVM
+IndentWidth: 8
+UseTab: Always
+BreakBeforeBraces: Linux
+AllowShortBlocksOnASingleLine: false
+AllowShortIfStatementsOnASingleLine: false
+IndentCaseLabels: false
\ No newline at end of file
Why no newline on the last line?
These one would be needed as well to match our style, I think:
AllowShortFunctionsOnASingleLine: None
ContinuationIndentWidth: 8
And probably this one:
Cpp11BracedListStyle: false
However, even then struct declarations that are combined with variable
declaration and initialization get mangled:
struct a {
int n;
const char *s;
} arr[] = {
{ 1, one },
{ 2, two }
};
becomes:
struct a
{
int n;
const char *s;
} arr[] = { { 1, one }, { 2, two } };
It gets formatted better if arr is declared separately.
And this one helps get rid of the added line break between struct a and
the following brace:
BreakBeforeBraces: Stroustrup
--
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] Introducing different handling for small/large transactions
On 01/15/2015 11:36 PM, Stefan Beller wrote: For everyday use we want git to be fast. Creating one commit should not touch the packed refs file. If we do other stuff involving more than one ref, we may accept touching the packed refs file and have a process which takes slightly longer but can handle more complex requests correctly, such as renaming into and from directories (topic/1 - topic and reverse). Renaming is currently not part of the transaction API because of the (D/F) problems. This proposed change would enable having renames being part of the transactions API. A transaction covers creating, deleting and updating a ref and its reflog. Renaming would be a deletion followed by creating a new ref atomically. A rename is a little bit more than a generic delete+create pair; it also moves the reflog from the old name to the new name. Is your plan to add an extra rename operation to the refs-transactions API, or to automatically detect delete+create pairs and treat them as renames? So for here is my proposal for small transactions: (just one ref [and/or reflog] touched): In ref_transaction_update: * create $REF.lock file * write new content to the lock file In ref_transaction_commit * commit the .lock file to its destination * in case this is a deletion: * remove the loose ref * and repack the packed refs file if necessary The above describes the current algorithm, but FYI it is not entirely correct. The deletion of the loose ref might expose an old version of the reference in the packed-refs file (which might even point at an object that has been garbage-collected. So the reference has to be deleted from the packed-refs file before the loose ref version is deleted. However, it is important that the packed-ref lock be held during the whole procedure, so that a pack-refs process doesn't rewrite the loose ref version of the reference into the (now-unlocked) packed-refs file, causing the reference to survive its supposed deletion. (At least that was the status a while ago; I don't know if recent changes to pack-refs might have removed this problem in another way.) But activating a new packed-refs file while still holding the packed-refs lock is not supported by our current lockfile API. In fact, working towards enabling this was one of the reasons for the big lockfile refactoring that I did a while back. Though I never got as far as fixing this bug. The larger transactions would be handled differently by relying on the packed refs file: In ref_transaction_update: * detect if we transition to a large transaction (by having more than one entry in transaction-updates) if so: * Pack all currently existing refs into the packed refs file, commit the packed refs file and delete all loose refs. This will avoid (d/f) conflicts. * Keep the packed-refs file locked and move the first transaction update into the packed-refs.lock file NB: this requires not just one but two rewrites of the packed-refs file, sharpening the performance concerns expressed elsewhere in this thread. But couldn't one of the rewrites be avoided if the transaction doesn't involve any deletes? * Any update(delete, create, update) is put into the locked packed refs file. * Additionally we need to obtain the .lock for the loose refs file to keep guarantees, though we should close the file descriptor as we don't wand to run out of file descriptors. In ref_transaction_commit: * We only need to commit the packed refs file * Discard all other lock files as the changes get committed as a whole by the packed refs file 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
Re: [L10N] Startup of Git 2.3.0 l10n round 2
2015-01-18 23:53 GMT+08:00 Jean-Noël AVILA jn.av...@free.fr: Hi, One of the new strings mixes tabs and spaces at begining of lines. Is it really to be applied? Jean-Noël Yes, it's wrong to using mixed tabs and spaces in the message. It comes from commit v2.0.5-5-g9990273, and it should be fixed. commit 99902739174be82851143d4be2a0f85727a9efe0 Author: Alexander Kuleshov kuleshovm...@gmail.com Date: Fri Jan 9 00:08:36 2015 +0600 show-branch: line-wrap show-branch usage Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com -- Jiang Xin -- 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: .gitattributes on branch behaves unexpected. Should it be more stateless?
Hi philip, thanks for your reply. You don't say which parts you believe should be identical, nor why. I expected my representation to be identical, nevertheless what path I have taken to come there. e.g. git clone -b branch git clone; git checkout branch should result in a binary-indentical representation of the files tracked by git. But they don't. Why did I expect this? Good question. Feels more intuitive for me. Like don't worry what you have done before. When your HEAD is on a certain commit, git will make sure all your files in your filesystem are they way you (and the other committers) want them to be. [..] Does that help? Yes, it helped me to distinguish better between data and representation. New understanding: .gitattributes determines how to represent data. As .gitattributes is under git control there can be 2 versions of .gitattributes in 2 branches. So I can tell git - on branch foo with gitattributes * eol=LF show me all files with LF - on branch bar with gitattributes * eol=CRLF show me all files with CRLF But this doesn't work. The representation of the files is determined/depending on how I cloned or fetched the repo. A git checkout bar does not change the representation. Does this help to show where my concerns / my issue is? Best Regards, Max 2015-01-17 14:16 GMT+01:00 Philip Oakley philipoak...@iee.org: Hi, I am asking myself if git and .gitattributes should be more stateless? i.e. whatever you have done before is irrelevant, when you reach status XYZ with your git repo, it is EXACTLY and BINARY the same all the time and everywhere. It took some time for me to figure out, that depending on HOW you clone, the resulting local repo may differ. I did not expect this. I assumed that when I clone, it is a clone (meaning: 100% identical). And that the things I have done in my local repo before, don't have any relevance at all. You don't say which parts you believe should be identical, nor why. Internally Git can represent its object store in many ways based on some objects being 'loose' and some objects being 'packed'. However both styles of representation are of the same base objects and their contents. Then we have external OS representation, in particular the end of line representations between the three main OS types Win/Mac/'nix. Git gives _you_ the ability the use any of these representations for the same base objects. Thus the object file with text Hello World/EOL/Goodbye World will have three different binary representations once you export them to the selected file system type (according to you .gitattributes settings). If you always select LF endings for text files (both on the way in and on the way out of the repo), then you will get identical files on the different clones. Git has many settings for personalisation. Does that help? ** How to reproduce ** 1) create a repo, add a file with LF ending, add a .gitattributes telling git to do a CRLF conversion 2) clone the repo 3) on brach development, change .gitattributes to LF 4) clone again 5) clone again, directly onto the branch development (git clone -b) ** Expected result, (I) ** clone 2) and original repo 1) are bytewise identical ** Actual result (I) ** clone 2) and original repo 1) differ, 1) has LF, 2) has CRLF as I have been warned before, I am (more or less) fine/OK with this ** Expected result, (II) ** - clone without -b (4) and clone with -b (5) are bytewise identical - I would have expected, that whatever I do, as soon as I have a clone and I am on branch development, my file should be LF - I would have expected, that HOW you clone is irrelevant ** Actual result (II) ** without -b (4) I have a CRLF file on my disk. with -b (5) I have a LF file on my disk. The clones are not bytewise indentical. It appears as if the .gitattributes in branch development does not have any reliable effect. A potential solution might be be that - checkout - commit (a modified .gitattribues) - further git commands do change the files in the local repo. As of now my understanding is that this is not how .gitattributes (or .gitignore) are designed. .gitattributes only has influence on pushing/fetching. I don't know if and which side effects would occur if this design would be changed. Hence I am glad to hear any feedback on the issue described above. And yes, I agree that this is a minor issue and that all .gitattribute things are kind of edge cases. Thanks and with best regards, Max 1) mkdir git-bug-or-feature cd git-bug-or-feature git init echo foo.bar eol=crlf .gitattributes echo hello world foo.bar git add . git commit -m now crlf # [master (root-commit) 7f3f6b0] now crlf # warning: LF will be replaced by CRLF in foo.bar. # The file will have its original line endings in your working directory. file foo.bar # foo.bar: ASCII text cd .. 2) git clone git-bug-or-feature git-bug-or-feature_clone cd
[ANNOUNCE] git-deps: commit dependency analysis / visualization
On Sun, Jan 04, 2015 at 01:08:03AM +, Adam Spiers wrote: Hi all, Thanks to my employer's generous Hack Week policy[0], I have the luxury of being able to spend most of next week hacking on a git commit dependency inference tool which I built 14 months ago but never got round to polishing up or publically announcing. In this email I'll briefly explain the tool and some ideas I have for adding a web-based UI to it next week - any feedback is most welcome. [snipped] Request for feedback Any kind of feedback is very welcome - obviously sooner rather than later, as my Hack Week starts on Monday. Here's the project page: https://hackweek.suse.com/11/projects/366 Many thanks in advance! Adam Noone told me this was a stupid idea, so I went ahead and added a web UI to the tool :-) I'm pleased to announce this is ready for testing; here are more details along with a short screencast demonstration: http://blog.adamspiers.org/2015/01/19/git-deps/ Cheers, Adam -- 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] test: add git apply whitespace expansion tests
On Sun, Jan 18, 2015 at 2:49 AM, Kyle J. McKay mack...@gmail.com wrote: * Here's some tests. With apply: make update_pre_post_images() sanity check the given postlen but not apply: count the size of postimage correctly test 1/4 and 4/4 trigger the 'die(BUG: postlen...' but test 2/4 and 3/4 do not although they fail because git apply generates garbage. Do the failing cases that do not trigger the new postlen check fail because the original (mis)counting thinks (incorrectly) that the rewritten result _should_ fit within the original postlen (hence we allow an in-place rewrite by passing postlen=0 to the helper), but in fact after rewriting postimage-len ends up being longer due to the miscounting? -- 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
