Re: feature request: better support for typos
I believe They mean that if you type clone --branch mister, it should ask if you meant to clone --branch master instead, or something. Basically if you type a non existent branch name, calculate edit distance for each branch name, probably either using a timeout or edit distance to stop if something is too different from any branch so you don't run for too long, and then, if a branch is within a certain edit distance from the typo, suggest it. Lawrence On Sat, Aug 15, 2015 at 2:12 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Aug 8, 2015 at 1:12 AM, Ralf Thielow ralf.thie...@gmail.com wrote: Hi, when a user made a typo, Git is not good in guessing what the user could have meant, except for git commands. I think this is an area with room for improvements. Let's look into branches. When I clone --branch and make a typo, Git could show me what branch I could have meant. It's the same when I try to merge or track a branch. Good candidate for those micro-projects next year. It might even be possible to show suggestions for options for all Git commands. You mean if you type --brnch it should suggest --branch? I was bugged about this and wanted to do something, only to realize in most cases git would show git cmd -h, which does a much better job because it would explain what --branch is for as well. What I'm trying to say is, there are arguments with a limited amount of possible values that Git know, so Git can show suggestions when the user made a typo for such an argument. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- About Me: http://about.me/lawrencesiebert Constantly Coding: http://constantcoding.blogspot.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 00/13] port tag.c to use ref-filter APIs
On Sat, Aug 15, 2015 at 11:00 AM, Karthik Nayak karthik@gmail.com wrote: align:: - Implement an `align` atom which left-, middle-, or - right-aligns the content between %(align:..) and - %(end). Followed by `:position,width`, where the + left-, middle-, or right-align the content between %(align:..) + and %(end). Followed by `:position,width`, where the Everywhere else in the code seems to now put position second now, but the documentation here doesn't say this is allowed or required. Regards, Jake `position` is either left, right or middle and `width` is the total length of the content with alignment. If the contents length is more than the width then no alignment is - performed. Currently nested alignment is not supported. + performed. -- 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 v3] po/README: Update directions for l10n contributors
From: Philip Oakley philipoak...@iee.org Some Linux distributions (such as Ubuntu) have their own l10n workflows, and their translations may be different. Add notes for this case for l10n translators. Signed-off-by: Philip Oakley philipoak...@iee.org Signed-off-by: Jiang Xin worldhello@gmail.com --- po/README | 19 +++ 1 file changed, 19 insertions(+) diff --git a/po/README b/po/README index d8c9111..fef4c0f 100644 --- a/po/README +++ b/po/README @@ -10,10 +10,26 @@ coordinates our localization effort in the l10 coordinator repository: https://github.com/git-l10n/git-po/ +The two character language translation codes are defined by ISO_639-1, as +stated in the gettext(1) full manual, appendix A.1, Usual Language Codes. + + +Contributing to an existing translation +--- As a contributor for a language XX, you should first check TEAMS file in this directory to see whether a dedicated repository for your language XX exists. Fork the dedicated repository and start to work if it exists. +Sometime, contributors may find that the translations of their Git +distributions are quite different with the translations of the +corresponding version from Git official. This is because some Git +distributions (such as from Ubuntu, etc.) have their own l10n workflow. +For this case, wrong translations should be reported and fixed through +their workflows. + + +Creating a new language translation +--- If you are the first contributor for the language XX, please fork this repository, prepare and/or update the translated message file po/XX.po (described later), and ask the l10n coordinator to pull your work. @@ -23,6 +39,9 @@ coordinate among yourselves and nominate the team leader for your language, so that the l10n coordinator only needs to interact with one person per language. + +Translation Process Flow + The overall data-flow looks like this: +---++--+ -- 2.5.0.rc2.34.gfbdeabf.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 v11 00/13] port tag.c to use ref-filter APIs
On Sun, Aug 16, 2015 at 1:08 PM, Jacob Keller jacob.kel...@gmail.com wrote: On Sat, Aug 15, 2015 at 11:00 AM, Karthik Nayak karthik@gmail.com wrote: align:: - Implement an `align` atom which left-, middle-, or - right-aligns the content between %(align:..) and - %(end). Followed by `:position,width`, where the + left-, middle-, or right-align the content between %(align:..) + and %(end). Followed by `:position,width`, where the Everywhere else in the code seems to now put position second now, but the documentation here doesn't say this is allowed or required. Oops! you're right, that needs to be swapped. -- Regards, Karthik Nayak -- 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 v3 2/4] path: optimize common dir checking
On Sun, Aug 16, 2015 at 12:04 PM, David Turner dtur...@twopensource.com wrote: Duy Nguyen pclo...@gmail.com writes: On Thu, Aug 13, 2015 at 4:57 AM, David Turner dtur...@twopensource.com wrote: Instead of a linear search over common_list to check whether a path is common, use a trie. The trie search operates on path prefixes, and handles excludes. Just be careful that the given key from git_path is not normalized. I think you assume it is in the code, but I haven't read carefully. We could of course optimize for the good case: assume normalized and search, then fall back to explicit normalizing and search again. What does it mean for a key to be normalized? Do you mean normalized in terms of upper/lowercase on case-insensitive filesystems? If so, I think the assumption here is that this will be called with paths generated by git, which will always use the lowercase path. Mostly about duplicated slashes, abc//def instead of abc/def. Technically nothing forbids git_path(refs/../refs/foo), but that would fool even current code. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] untracked-cache: fix subdirectory handling
On Sun, Aug 16, 2015 at 12:17 PM, David Turner dtur...@twopensource.com wrote:
Previously, some calls lookup_untracked would pass a full path. But
lookup_untracked assumes that the portion of the path up to and
including to the untracked_cache_dir has been removed. So
lookup_untracked would be looking in the untracked_cache for 'foo' for
'foo/bar' (instead of just looking for 'bar'). This would cause
untracked cache corruption.
Instead, treat_directory learns to track the base length of the parent
directory, so that only the last path component is passed to
lookup_untracked.
Your v2 also fixes untracked_cache_invalidate_path(), which is not
included here. Maybe it's in another patch?
Helped-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: David Turner dtur...@twopensource.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
This version incorporates Duy's version of the dir.c code, and his
suggested test speedup.
---
dir.c | 14
t/t7063-status-untracked-cache.sh | 74
+--
2 files changed, 80 insertions(+), 8 deletions(-)
diff --git a/dir.c b/dir.c
index e7b89fe..cd4ac77 100644
--- a/dir.c
+++ b/dir.c
@@ -1297,7 +1297,7 @@ static enum exist_status
directory_exists_in_index(const char *dirname, int len)
*/
static enum path_treatment treat_directory(struct dir_struct *dir,
struct untracked_cache_dir *untracked,
- const char *dirname, int len, int exclude,
+ const char *dirname, int len, int baselen, int exclude,
const struct path_simplify *simplify)
{
/* The len-1 is to strip the final '/' */
@@ -1324,7 +1324,8 @@ static enum path_treatment treat_directory(struct
dir_struct *dir,
if (!(dir-flags DIR_HIDE_EMPTY_DIRECTORIES))
return exclude ? path_excluded : path_untracked;
- untracked = lookup_untracked(dir-untracked, untracked, dirname, len);
+ untracked = lookup_untracked(dir-untracked, untracked,
+dirname + baselen, len - baselen);
return read_directory_recursive(dir, dirname, len,
untracked, 1, simplify);
}
@@ -1444,6 +1445,7 @@ static int get_dtype(struct dirent *de, const char
*path, int len)
static enum path_treatment treat_one_path(struct dir_struct *dir,
struct untracked_cache_dir
*untracked,
struct strbuf *path,
+ int baselen,
const struct path_simplify
*simplify,
int dtype, struct dirent *de)
{
@@ -1495,8 +1497,8 @@ static enum path_treatment treat_one_path(struct
dir_struct *dir,
return path_none;
case DT_DIR:
strbuf_addch(path, '/');
- return treat_directory(dir, untracked, path-buf, path-len,
exclude,
- simplify);
+ return treat_directory(dir, untracked, path-buf, path-len,
+ baselen, exclude, simplify);
case DT_REG:
case DT_LNK:
return exclude ? path_excluded : path_untracked;
@@ -1557,7 +1559,7 @@ static enum path_treatment treat_path(struct dir_struct
*dir,
return path_none;
dtype = DTYPE(de);
- return treat_one_path(dir, untracked, path, simplify, dtype, de);
+ return treat_one_path(dir, untracked, path, baselen, simplify, dtype,
de);
}
static void add_untracked(struct untracked_cache_dir *dir, const char *name)
@@ -1827,7 +1829,7 @@ static int treat_leading_path(struct dir_struct *dir,
break;
if (simplify_away(sb.buf, sb.len, simplify))
break;
- if (treat_one_path(dir, NULL, sb, simplify,
+ if (treat_one_path(dir, NULL, sb, baselen, simplify,
DT_DIR, NULL) == path_none)
break; /* do not recurse into it */
if (len = baselen) {
diff --git a/t/t7063-status-untracked-cache.sh
b/t/t7063-status-untracked-cache.sh
index ff23f4e..6716f69 100755
--- a/t/t7063-status-untracked-cache.sh
+++ b/t/t7063-status-untracked-cache.sh
@@ -402,13 +402,14 @@ test_expect_success 'set up sparse checkout' '
echo done/[a-z]* .git/info/sparse-checkout
test_config core.sparsecheckout true
git checkout master
- git update-index --untracked-cache
+ git update-index --untracked-cache --force-untracked-cache
git status --porcelain /dev/null # prime the cache
test_path_is_missing done/.gitignore
test_path_is_file done/one
'
-test_expect_success 'create files, some of which are gitignored' '
+test_expect_success
Re: [PATCH v11 05/13] ref-filter: implement an `align` atom
I think we need to squash this in diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 3099631..17bd15e 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -129,7 +129,7 @@ color:: align:: left-, middle-, or right-align the content between %(align:..) - and %(end). Followed by `:position,width`, where the + and %(end). Followed by `:width,position`, where the `position` is either left, right or middle and `width` is the total length of the content with alignment. If the contents length is more than the width then no alignment is -- 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 v11 05/13] ref-filter: implement an `align` atom
Karthik Nayak karthik@gmail.com writes: I think we need to squash this in diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 3099631..17bd15e 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -129,7 +129,7 @@ color:: align:: left-, middle-, or right-align the content between %(align:..) - and %(end). Followed by `:position,width`, where the + and %(end). Followed by `:width,position`, where the s/// Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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 v11 04/13] utf8: add function to align a string into given strbuf
On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak karthik@gmail.com wrote:
Add strbuf_utf8_align() which will align a given string into a strbuf
as per given align_type and width. If the width is greater than the
string length then no alignment is performed.
A couple minor comments below...
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/utf8.c b/utf8.c
index 28e6d76..0fb8e9d 100644
--- a/utf8.c
+++ b/utf8.c
@@ -644,3 +644,24 @@ int skip_utf8_bom(char **text, size_t len)
*text += strlen(utf8_bom);
return 1;
}
+
+void strbuf_utf8_align(struct strbuf *buf, align_type position, unsigned int
width,
+ const char *s)
+{
+ int slen = strlen(s);
+ int display_len = utf8_strnwidth(s, slen, 0);
+ int utf8_compensation = slen - display_len;
Based upon the previous round review, I think you had intended to name
this merely 'compensation'.
+ if (display_len = width) {
+ strbuf_addstr(buf, s);
+ return;
+ }
+
+ if (position == ALIGN_LEFT)
+ strbuf_addf(buf, %-*s, width + utf8_compensation, s);
+ else if (position == ALIGN_MIDDLE) {
+ int left = (width - display_len)/2;
Style: spaces around '/'
+ strbuf_addf(buf, %*s%-*s, left, , width - left +
utf8_compensation, s);
+ } else if (position == ALIGN_RIGHT)
+ strbuf_addf(buf, %*s, width + utf8_compensation, s);
+}
diff --git a/utf8.h b/utf8.h
index 5a9e94b..7930b44 100644
--- a/utf8.h
+++ b/utf8.h
@@ -55,4 +55,19 @@ int mbs_chrlen(const char **text, size_t *remainder_p,
const char *encoding);
*/
int is_hfs_dotgit(const char *path);
+typedef enum {
+ ALIGN_LEFT,
+ ALIGN_MIDDLE,
+ ALIGN_RIGHT
+} align_type;
+
+/*
+ * Align the string given and store it into a strbuf as per the
+ * 'position' and 'width'. If the given string length is larger than
+ * 'width' than then the input string is not truncated and no
+ * alignment is done.
+ */
+void strbuf_utf8_align(struct strbuf *buf, align_type position, unsigned int
width,
+ const char *s);
+
#endif
--
2.5.0
--
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 v11 05/13] ref-filter: implement an `align` atom
On Sun, Aug 16, 2015 at 8:04 AM, Andreas Schwab sch...@linux-m68k.org wrote: Karthik Nayak karthik@gmail.com writes: I think we need to squash this in diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 3099631..17bd15e 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -129,7 +129,7 @@ color:: align:: left-, middle-, or right-align the content between %(align:..) - and %(end). Followed by `:position,width`, where the + and %(end). Followed by `:width,position`, where the s/// Also: s/left-/Left-/ -- 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 v11 05/13] ref-filter: implement an `align` atom
On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak karthik@gmail.com wrote:
Implement an `align` atom which left-, middle-, or right-aligns the
content between %(align:..) and %(end).
It is followed by `:width,position`, where the `position` is
either left, right or middle and `width` is the size of the area
into which the content will be placed. If the content between
%(align:) and %(end) is more than the width then no alignment is
performed. e.g. to align a refname atom to the middle with a total
width of 40 we can do: --format=%(align:middle,40)%(refname)%(end).
This is done by calling the strbuf_utf8_align() function in utf8.c.
Add documentation and tests for the same.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 3259363..eac99d0 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -10,6 +10,7 @@
#include quote.h
#include ref-filter.h
#include revision.h
+#include utf8.h
typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
@@ -53,16 +54,27 @@ static struct {
{ flag },
{ HEAD },
{ color },
+ { align },
+ { end },
+};
+
+struct align {
+ align_type position;
+ unsigned int width;
};
struct ref_formatting_state {
struct strbuf output;
struct ref_formatting_state *prev;
+ void (*attend)(struct ref_formatting_state *state);
Junio's suggestion for this member was at end; that is what to do
when you are at-the-%(end), not attend, which isn't meaningful
here. You could also call it 'end_scope', 'finish' or 'close' or
'finalize' or something.
+ void *cb_data;
int quote_style;
};
struct atom_value {
const char *s;
+ struct align *align;
+ void (*handler)(struct atom_value *atomv, struct ref_formatting_state
**state);
unsigned long ul; /* used for sorting when not FIELD_STR */
};
@@ -137,12 +149,12 @@ int parse_ref_filter_atom(const char *atom, const char
*ep)
static struct ref_formatting_state *push_new_state(struct
ref_formatting_state **state)
{
- struct ref_formatting_state *new_state = xcalloc(1, sizeof(struct
ref_formatting_state));
- struct ref_formatting_state *tmp = *state;
+ struct ref_formatting_state *new = xcalloc(1, sizeof(struct
ref_formatting_state));
+ struct ref_formatting_state *old = *state;
- *state = new_state;
- new_state-prev = tmp;
- return new_state;
+ *state = new;
+ new-prev = old;
+ return new;
}
What are these changes about? They appear only to be renaming some
variables which were introduced in patch 3. It would make more sense
to give them the desired names in the patch which introduces them.
static void pop_state(struct ref_formatting_state **state)
@@ -625,6 +637,34 @@ static inline char *copy_advance(char *dst, const char
*src)
return dst;
}
+static void align_handler(struct ref_formatting_state *state)
The names 'align_handler' and 'align_atom_handler' are confusingly
similar. Perhaps name this end_align() or do_align() or
apply_alignment() or something?
+{
+ struct strbuf aligned = STRBUF_INIT;
+ struct ref_formatting_state *return_to = state-prev;
+ struct align *align = (struct align *)state-cb_data;
+
+ strbuf_utf8_align(aligned, align-position, align-width,
state-output.buf);
+ strbuf_addbuf(return_to-output, aligned);
A couple comments:
First, why is 'strbuf aligned' needed? Can't you instead just invoke
strbuf_utf8_align(return_to-output, ...)?
Second, I realize that Junio suggested the 'return_to' idea, but it
seems like it could become overly painful since each handler of this
sort is going to have to perform the same manipulation to append its
collected output to its parent state's output. What if you instead
make it the responsibility of pop_state() to append the 'output' from
the state being popped to the prev state's 'output'? This way, it
happens automatically, thus reducing code in each individual handler,
and reducing the burden of having to keep writing the same code.
+ strbuf_release(aligned);
+}
+
+static void align_atom_handler(struct atom_value *atomv, struct
ref_formatting_state **state)
+{
+ struct ref_formatting_state *new = push_new_state(state);
+ strbuf_init(new-output, 0);
I think this strbuf_init() should be the responsibility of
push_new_state(), as mentioned in my patch 3 review, otherwise every
caller of push_new_state() will have to remember to do this.
+ new-attend = align_handler;
+ new-cb_data = atomv-align;
+}
+
+static void end_atom_handler(struct atom_value *atomv, struct
ref_formatting_state **state)
+{
+ struct ref_formatting_state *current = *state;
+ if (!current-attend)
+ die(_(format: `end` atom used without a supporting atom));
+ current-attend(current);
+
Re: git am --abort screwing up index?
On Sun, Aug 16, 2015 at 12:46 PM, Linus Torvalds torva...@linux-foundation.org wrote: Maybe it has always done this, and I just haven't noticed (I usually _just_ do the git reset --hard thing, don't ask me why I wanted to be doubly sure this time). But maybe it's an effect of the new built-in am. I bisected this. It's definitely used to work, and the regression is from the new built-in am. But I cannot bisect into that branch 'pt/am-builtin', because git am doesn't actually work in the middle of that branch. So I've verified that commit c1e5ca90dba8 (Merge branch 'es/worktree-add') is good, and that commit 7aa2da616208 (Merge branch 'pt/am-builtin') is bad, but I cannot pinpoint the exact commit where git am --abort starts breaking the index. But I assume it's simply that initial implementation of --abort in commit 33388a71d23e (builtin-am: implement --abort) that already ends up rewriting the index from scratch without applying the old stat data. The test-case is pretty simple: just force a git am failure, then do git am --abort, and then you can check whether the index stat() information is valid in various ways. For the kernel, doing a git reset --hard makes it obvious because the reset will force all files to be written out (since the index stat information doesn't match the current tree). But you can do it by just counting system calls for a git diff too. On the git tree, for example, when the index has matching stat information, you get something like [torvalds@i7 git]$ strace -cf git diff .. 0.040.25 126 4 open .. ie you only actually ended up with 26 open() system calls. When the index is not in sync with the stat information, git diff will have to open each file to see what the actual contents are, and you get [torvalds@i7 git]$ strace -cf git diff ... 0.300.70 0 5987 302 open ... so now it opened about 6k files instead (and for the kernel, that number will be much larger, of course). I _think_ it's because git-am (in clean_index()) uses read_tree(), while it probably should use unpack_trees with opts.update and opts.reset set (like reset_index() does in builtin/reset.h). I have to go off do my weekly -rc now, and probably won't get to debugging this much further. Adding Stefan to the cc, since he helped with that --abort implementation. Linus -- 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 v11 06/13] ref-filter: add option to filter out tags, branches and remotes
On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak karthik@gmail.com wrote:
Add a function called 'for_each_reftype_fullpath()' to refs.{c,h}
which iterates through each ref for the given path without trimming
the path and also accounting for broken refs, if mentioned.
Add 'filter_ref_kind()' in ref-filter.c to check the kind of ref being
handled and return the kind to 'ref_filter_handler()', where we
discard refs which we do not need and assign the kind to needed refs.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index eac99d0..abcd235 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1226,16 +1262,29 @@ int filter_refs(struct ref_array *array, struct
ref_filter *filter, unsigned int
{
struct ref_filter_cbdata ref_cbdata;
int ret = 0;
+ unsigned int broken = 0;
ref_cbdata.array = array;
ref_cbdata.filter = filter;
/* Simple per-ref filtering */
- if (type (FILTER_REFS_ALL | FILTER_REFS_INCLUDE_BROKEN))
- ret = for_each_rawref(ref_filter_handler, ref_cbdata);
- else if (type FILTER_REFS_ALL)
- ret = for_each_ref(ref_filter_handler, ref_cbdata);
- else if (type)
+ if (type FILTER_REFS_INCLUDE_BROKEN) {
+ type -= FILTER_REFS_INCLUDE_BROKEN;
The above is a somewhat unusual way to say the more idiomatic:
type = ~FILTER_REFS_INCLUDE_BROKEN;
when dealing with bit flags. Is there precedence elsewhere in the
project for choosing '-' over '~'?
+ broken = 1;
+ }
+
+ filter-kind = type;
+ if (type == FILTER_REFS_BRANCHES)
+ ret = for_each_reftype_fullpath(ref_filter_handler,
refs/heads/, broken, ref_cbdata);
+ else if (type == FILTER_REFS_REMOTES)
+ ret = for_each_reftype_fullpath(ref_filter_handler,
refs/remotes/, broken, ref_cbdata);
+ else if (type == FILTER_REFS_TAGS)
+ ret = for_each_reftype_fullpath(ref_filter_handler,
refs/tags/, broken, ref_cbdata);
+ else if (type FILTER_REFS_ALL) {
+ ret = for_each_reftype_fullpath(ref_filter_handler, ,
broken, ref_cbdata);
These cases are all the same except for the (string) second argument,
aren't they? This might be less noisy and easier to follow if you
assign the appropriate string to a variable first, and then invoke
for_each_reftype_fullpath() once with the string variable as an
argument.
+ if (type FILTER_REFS_DETACHED_HEAD)
+ head_ref(ref_filter_handler, ref_cbdata);
+ } else
die(filter_refs: invalid type);
/* Filters that need revision walking */
diff --git a/ref-filter.h b/ref-filter.h
index 144a633..64fedd3 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -14,8 +14,14 @@
-#define FILTER_REFS_INCLUDE_BROKEN 0x1
-#define FILTER_REFS_ALL 0x2
+#define FILTER_REFS_INCLUDE_BROKEN 0x0001
+#define FILTER_REFS_TAGS 0x0002
+#define FILTER_REFS_BRANCHES 0x0004
+#define FILTER_REFS_REMOTES0x0008
+#define FILTER_REFS_OTHERS 0x0010
+#define FILTER_REFS_ALL(FILTER_REFS_TAGS | FILTER_REFS_BRANCHES
| \
+ FILTER_REFS_REMOTES | FILTER_REFS_OTHERS)
+#define FILTER_REFS_DETACHED_HEAD 0x0020
I suppose there's some good reason that FILTER_REFS_DETACHED_HEAD is
not a member of FILTER_REFS_ALL? Perhaps add a comment explaining it?
diff --git a/refs.c b/refs.c
index 2db2975..0f18c34 100644
--- a/refs.c
+++ b/refs.c
@@ -2145,6 +2145,13 @@ int for_each_replace_ref(each_ref_fn fn, void *cb_data)
strlen(git_replace_ref_base), 0, cb_data);
}
+int for_each_reftype_fullpath(each_ref_fn fn, char *type, unsigned int
broken, void *cb_data)
+{
+ if (broken)
+ broken = DO_FOR_EACH_INCLUDE_BROKEN;
It's a bit ugly and confusing to have the same variable, 'broken', act
as both a boolean input argument and as a bit flag argument to the
called function.
+ return do_for_each_ref(ref_cache, type, fn, 0, broken, cb_data);
+}
+
int head_ref_namespaced(each_ref_fn fn, void *cb_data)
{
struct strbuf buf = STRBUF_INIT;
--
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 v11 08/13] ref-filter: add support to sort by version
On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak karthik@gmail.com wrote: Add support to sort by version using the v:refname and version:refname option. This is achieved by using the 'versioncmp()' function as the comparing function for qsort. This option is included to support sorting by versions in `git tag -l` which will eventaully be ported to use ref-filter APIs. s/eventaully/eventually/ Add documentation and tests for the same. Signed-off-by: Karthik Nayak karthik@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 13/13] tag.c: implement '--merged' and '--no-merged' options
On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak karthik@gmail.com wrote: Using 'ref-filter' APIs implement the '--merged' and '--no-merged' s/implement/to implement/ options into 'tag.c'. The '--merged' option lets the user to only list tags merged into the named commit. The '--no-merged' option lets the user to only list tags not merged into the named commit. If no object is provided it assumes HEAD as the object. Add documentation and tests for the same. Signed-off-by: Karthik Nayak karthik@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 03/13] ref-filter: introduce ref_formatting_state
On Sun, Aug 16, 2015 at 7:31 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak karthik@gmail.com wrote:
+struct ref_formatting_state {
+ struct strbuf output;
+ struct ref_formatting_state *prev;
Upon initial read-through of this patch, I found the name 'prev'
confusing since it seems you sometimes treat this as a linked-list
and, for a linked-list, this member is customarily named 'next'.
However, you also sometimes treat it as a stack, in which case 'prev'
makes a certain amount of sense semantically, although so does 'next'.
I'd probably have named it 'next', however, attr.c:struct attr_stack
names its member 'prev', so there is some precedence for the current
choice.
s/precedence/precedent/
--
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 v11 06/13] ref-filter: add option to filter out tags, branches and remotes
On Mon, Aug 17, 2015 at 12:42 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Aug 15, 2015 at 2:00 PM, Karthik Nayak karthik@gmail.com wrote:
- if (type (FILTER_REFS_ALL | FILTER_REFS_INCLUDE_BROKEN))
- ret = for_each_rawref(ref_filter_handler, ref_cbdata);
- else if (type FILTER_REFS_ALL)
- ret = for_each_ref(ref_filter_handler, ref_cbdata);
- else if (type)
+ if (type FILTER_REFS_INCLUDE_BROKEN) {
+ type -= FILTER_REFS_INCLUDE_BROKEN;
The above is a somewhat unusual way to say the more idiomatic:
type = ~FILTER_REFS_INCLUDE_BROKEN;
when dealing with bit flags. Is there precedence elsewhere in the
project for choosing '-' over '~'?
s/precedence/precedent/
--
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 v3] po/README: Update directions for l10n contributors
From: Jiang Xin worldhello@gmail.com From: Philip Oakley philipoak...@iee.org Some Linux distributions (such as Ubuntu) have their own l10n workflows, and their translations may be different. Add notes for this case for l10n translators. Signed-off-by: Philip Oakley philipoak...@iee.org Signed-off-by: Jiang Xin worldhello@gmail.com --- po/README | 19 +++ 1 file changed, 19 insertions(+) diff --git a/po/README b/po/README index d8c9111..fef4c0f 100644 --- a/po/README +++ b/po/README @@ -10,10 +10,26 @@ coordinates our localization effort in the l10 coordinator repository: https://github.com/git-l10n/git-po/ +The two character language translation codes are defined by ISO_639-1, as +stated in the gettext(1) full manual, appendix A.1, Usual Language Codes. + + +Contributing to an existing translation +--- As a contributor for a language XX, you should first check TEAMS file in this directory to see whether a dedicated repository for your language XX exists. Fork the dedicated repository and start to work if it exists. +Sometime, contributors may find that the translations of their Git +distributions are quite different with the translations of the +corresponding version from Git official. This is because some Git +distributions (such as from Ubuntu, etc.) have their own l10n workflow. +For this case, wrong translations should be reported and fixed through +their workflows. + OK. That's a reasonable summary of what the reader should do. + +Creating a new language translation +--- If you are the first contributor for the language XX, please fork this repository, prepare and/or update the translated message file po/XX.po (described later), and ask the l10n coordinator to pull your work. @@ -23,6 +39,9 @@ coordinate among yourselves and nominate the team leader for your language, so that the l10n coordinator only needs to interact with one person per language. + +Translation Process Flow + The overall data-flow looks like this: +---++--+ -- Confirmed-by: Philip Oakley philipoak...@iee.org -- -- 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 am --abort screwing up index?
So I just noticed while applying a patch with git am when I had a dirty tree, and I ended up getting a failure and starting over: [torvalds@i7 linux]$ git am --abort [torvalds@i7 linux]$ git reset --hard Checking out files: 100% (50794/50794), done.0794) HEAD is now at 1efdb5f0a924 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi and the thing I reacted to is that the git reset --hard re-checked out all the files. That implies that git am --abort ended up leaving the index in a bad state, presumably it re-did the index entirely from HEAD, without filling it in with the stat() details from the old index. Maybe it has always done this, and I just haven't noticed (I usually _just_ do the git reset --hard thing, don't ask me why I wanted to be doubly sure this time). But maybe it's an effect of the new built-in am. I'm about to go out and don't have time to debug this any further right now, but I'll try to get back to it later. I thought I'd send out this email in case it makes Paul goes ahh, yes.. obvious Not a big deal - things *work* fine. But forcing checking out every file obviously also means that subsequent builds end up being slowed down etc.,. Linus -- 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 0/1] handling mistranslation reports
From: Jiang Xin worldhello@gmail.com 2015-08-04 6:29 GMT+08:00 Philip Oakley philipoak...@iee.org: Hi Jiang, This is my updated patch based on your feedback at $gmane/275141 and $gmane/275142. I've used most of your wording, though have retained a comment on considering if the translation could be held here. My original commentary is below, along with the inter-diff between versions. - Recently, on the 'Git for human beings' list, a user reported a mistranslation and asked if/what could be done, with a suggested alternate text [1]. I pointed the user at the po/README for general guidance. Unfortunately the user was noting a Spanish (es) translation error which is not held in your tree, but the README does include how to start a new translation. This led to a misunderstanding with regard to which aspect of the README was being referred to (private discussion with Junio). This patch separates out the three different aspects that caused confusion and explicitly brings out what to do for translations not currently held here. I hope my suggested patch will fit with your approach and ask for comments (or Ack / Nack). regards Philip [1] https://groups.google.com/forum/#!topic/git-users/rK5oU6k8Tzw Interdiff: The subject is [PATCH v2 0/1] and I wonder where is the real patch file (v2 1/1) aside of this cover letter. Yes 0/1 was the cover letter and 1/1 was the actual patch. I have not found a way of sending, via my 'git send-email' (*), a single patch with its integrated cover-letter at the beginning. I can easily add short notes after a 3-dashes in the commit, but it is not the same as a cover-letter ... Hopefully, you got the 1/1. Unfortunately, the Git list is rejecting my patches (and just my patches), as sent via send-email, and at the moment I have no way of debugging and diagnosing that issue. But today I have time to read it carefully, and I know this is a fixup commit. I squash this reroll to last commit for this series, and simplify both the commit and the commit log. See patch v3 in the next email. Thanks. Will review. -- Jiang Xin -- (*) https://groups.google.com/forum/#!topic/msysgit/U85cSXd-Uv0 -- 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
