$0.99/pc monopod selfie stick,on promotion
Dear
Good day $0.99/pc monopod selfie stick with cable take pole,only from us,the
arcpeaks factory
Please feel free to contact me for more details
Thanks
Best Regards
Ray
arcpeaks.en.alibaba.com
Skype:sixiwenzhi
MOBIL:+86 18924649532
We will attend Hong kong Electronics Fair(Autumn Edition) On Oct 13th to
16th,2015
Our booth located at ED-D26 at Expo Drive Hall
WelcomeN�Р骒r��yb�X�肚�v�^�)藓{.n�+丕��≤�}��财�z�&j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f
Re: Git at OSCON
On Sun, Jul 12, 2015 at 9:01 PM, Jeff King wrote: > OSCON is coming up soon (the week of the 20th) in Portland, and I want > to let people know that there's going to be a small Git table in the > exhibit hall, connected to the GitHub booth. I'll be manning the table > both days (Wednesday and Thursday the 22nd and 23rd), telling people > about how great git is and tricking^W convincing them to become git > contributors. > > If you're a git contributor and you feel like hanging out at the table > with me for a bit and preaching the gospel, please come by! If you're a > fan of git, come by and we can chat about new features. And if you're > not a fan of git, come by and throw rotten tomatoes at me! I am not sure rotten tomatoes are fine for carry luggage, so I'll see if I get some in portland. In case I cannot get some, I'll just drop by to observe how many others could bring some. > > -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 -- 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 at OSCON
OSCON is coming up soon (the week of the 20th) in Portland, and I want to let people know that there's going to be a small Git table in the exhibit hall, connected to the GitHub booth. I'll be manning the table both days (Wednesday and Thursday the 22nd and 23rd), telling people about how great git is and tricking^W convincing them to become git contributors. If you're a git contributor and you feel like hanging out at the table with me for a bit and preaching the gospel, please come by! If you're a fan of git, come by and we can chat about new features. And if you're not a fan of git, come by and throw rotten tomatoes at me! -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
Re: [PATCH] check_and_freshen_file: fix reversed success-check
On Sun, Jul 12, 2015 at 12:21:33AM +0200, X H wrote: > How are the permission handled, is it git that is asking to create a file > read only or rw on the remote or is it the environment with umask ans so on > that decides it, or Windows when the drive is mounted with noacl? Generally, git follows the umask when creating most files. However, for the object files in the object database, it does drop the "w" bit, as once written, they should never be changed (after all, the filename is a hash of the contents). We don't ever open those files for writing, but we may try to rename another file over them; that might behave differently on Unix versus Windows (or even differently on Windows between local and remote-mounted filesystems). -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
[GSOC] Update 5: Unification of tag -l, branch -l and for-each-ref
Hello All,
As part of GSoC I'm working on the Unification of 'for-each-ref', 'tag -l'
and 'branch -l'. Sorry for the lack of update since Jun 14, was a
little busy with an exam I had. Now thats over, I will be working more
on the project.
Current Progress:
1. Building ref-filter.{c,h} from for-each-ref.
This is the process of creating an initial library for the unification
by moving most of the code from for-each-ref to ref-filter.{c,h}.
Merged into next
2. Add options to ref-filter.
This includes the porting of --points-at, --contains, --merged,
--no-merged options from builtin/branch.c and builtin/tag.c, Also the
implementation of these options into for-each-ref.
Currently in pu
(https://github.com/git/git/commit/6d4c958d88e6456405b8d65a8bf469382c47f4c5)
3. Port builtin/tag.c to use ref-filter.
Here we port tag.c to use ref-filter and also port the --format,
--sort and --merged and --no-merged options to builtin/tag.c.
Version 2 can be found here
http://thread.gmane.org/gmane.comp.version-control.git/273731
A lot of input on this, Junio and Duy gave some suggestions on
how we can align items in the format option, there has been good progress
in this regard. More at
http://thread.gmane.org/gmane.comp.version-control.git/273732. A
working prototype of these suggestions have been pushed to Github,
where suggestions can be made until I send my next iteration of the
patch series.
Also a lot of changes suggested by my mentors Matthieu and Christian. Most of
which have been implemented and pushed to Github.
Next:
Have been working on branch.c and there is good progress for the same.
Code pushed to Github.
Github: https://github.com/KarthikNayak/git
Thanks to everyone who has helped :)
--
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 v2 01/10] ref-filter: add %(refname:shortalign=X) option
On Sun, Jul 12, 2015 at 7:17 AM, Duy Nguyen wrote: > > I guess if you can have multiple arguments after ':' in an atom, then > you have wiggle room for future. But it looks like you only accept one > argument after ':'.. (I only checked the version on 'pu'). Having an > "alignment atom" to augment the real one (like %< changes the behavior > of the next placeholder), could also work, but it adds dependency > between atoms, something I don't think ref-filter.c is ready for. > I was thinking of something on the lines of having a function which right before printing checks if any "align" option is given to the end of a given item and aligns it accordingly, this ensures that any item which needs to have such an option can easily do so. https://github.com/KarthikNayak/git/commit/0284320483d6442a6425fc665e740f9f975654a1 This is what I came up with, you could have a look and let me know if you have any suggestions. > Another thing, the atom value is also used for sorting. When used for > sorting, I think these padding spaces should not be generated or it > may confuse the sort algorithm. Left alignment may be ok, right or > center alignment (in future?), not so much. Perhaps we should do the > padding in a separate phase, outside populate_value(). If you go this > route, having separate atoms for alignment works better: you don't > have to parse them in populate_value() which is for actual values, and > you can handle dependency easily (I think). This was cleared out in your other reply. > > By the way, please consider adding _() back to translatable strings, > usually those die() or warn(), or "[ahead %s]"... In the last case, > because you don't really know how long the string is after > translation, avoid hard coding buffer size (to 40). Yes, sure, maybe a cleanup patch at the end to do all of cleanup any such use cases :) Thanks for all the suggestions. -- 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 v2 08/10] tag.c: use 'ref-filter' APIs
On Sun, Jul 12, 2015 at 3:15 PM, Duy Nguyen wrote:
> On Thu, Jul 9, 2015 at 5:58 PM, Karthik Nayak wrote:
>> -static int show_reference(const char *refname, const struct object_id *oid,
>> - int flag, void *cb_data)
>> -{
> ...
>> -
>> - if (match_pattern(filter->name_patterns, refname)) {
>
>> - printf("%-15s ", refname);
>> - show_tag_lines(oid, filter->lines);
>> - putchar('\n');
>> - }
>> -
>> - return 0;
>> -}
> ...
>> + if (filter->lines)
>> + format = "%(refname:shortalign=16)";
>> + else
>> + format = "%(refname:short)";
>
> I can see this is a faithful conversion, but this looks line an
> opportunity to avoid this special limit 15/16. Even on git.git "git
> tag -l -n1" already breaks alignment with *.msysgit.* tags (ok maybe
> msysgit, not purely git.git) When you get to "branch -l", it
> calculates the max-width automatically so you probably need
> "%(refname:shortalign)" any way. "shortalign" (i.e. create the "align"
> version for every modifier) does not look good because it could double
> the number of modifiers and let's not thinking about truncation
> options or right alignment..
What I was thinking of was getting rid of the whole "align" feature where
you provide a value to which it would align.
Something like: --format="%(item:modifieralign)" which would use something
on the lines of what the max-width calculator in branch -l uses, to get the max
alignment size. But the problem is that ref-filter goes through the refs using
a function which has no connections with the atoms used. So a more practical
solution would be --format="%(item:modifieralign=X)" where we could provide a
means of calculating X via ref-filter. Something like this in tag.c:
int max_width = get_max_width("");
use this max_width to then do a
--format="%(item:modifieralign=X)", where X = max_width
What do you think?
--
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 10/16] worktree: make branch creation distinct from worktree population
On Sun, Jul 12, 2015 at 04:54:02PM +0700, Duy Nguyen wrote:
> On Sun, Jul 12, 2015 at 10:27 AM, Eric Sunshine
> wrot> > In this case, it's easy enough to side-step the issue since there's no
> > need to call ref_exists() if the new branch was created successfully
> > (since we know it exists). The logic would effectively become this:
> >
> > branch = ...
> > if (create_new_branch) {
> > exec "git branch newbranch branch"
> > exec "git symbolic-ref HEAD newbranch"
> > } else if (ref_exists(branch) && !detach)
> > exec "git symbolic-ref HEAD branch"
> > else
> > exec "git update-ref HEAD $(git rev-parse branch)"
> > exec "git reset --hard"
>
> Yeah.. Another option we can take is deal with this at run-command.c
> level (and outside this series) because this could affect everywhere:
> by default, invalidate all cache after running any git commands. The
> caller can pass options to keep some cache intact if they know the
> command won't touch it.
>
> If ref_exists() is the only thing we use, right now it does not use
> cache so we should be safe. If the new ref backend introduces a cache,
> they would need to examine all callers anyway, including this one. The
> cache in refs.c seems to be for for_each_ref.. only, which we don't
> call here.
In case I don't need to re-roll the series for some other reason, here's
a squash-in making the above adjustment to patch 12/16, which Junio can
pick up if he wants to:
8<
From: Eric Sunshine
Subject: [PATCH] fixup! worktree: detect branch symref/detach and error
conditions locally
Current logic is effectively:
branch = ...
if (create_new_branch) {
run "git branch newbranch branch"
branch = newbranch
}
if (!detach && ref_exists(branch)) {
if (!force)
die_if_already_checked_out(branch)
run "git symbolic-ref HEAD branch"
} else
run "git update-ref HEAD $(git rev-parse branch)"
run "git reset --hard"
The ref_exists() call following 'run "git branch newbranch branch"'
works fine since ref_exists() hits the filesystem directly to answer the
question rather than relying upon potentially stale cached information.
However, this is potentially fragile if someone some day implements
caching. Moreover, with pluggable backends on the horizon, we may not
be able to rely upon ref_exists() in this process accurately reflecting
changes made by a subprocess.
If new branch creation was successful, then we know it's a branch, and
don't need to ask ref_exists() about it, thus we don't need to worry
about ref_exists() possibly returning an answer based upon stale
information, nor do we have to check if the new branch is already
checked out elsewhere. Therefore, rework the logic slightly to become
effectively:
branch = ...
if (create_new_branch) {
run "git branch newbranch branch"
run "git symbolic-ref HEAD newbranch"
} else if (!detach && ref_exists(branch)) {
if (!force)
die_if_already_checked_out(branch)
run "git symbolic-ref HEAD branch"
} else
run "git update-ref HEAD $(git rev-parse branch)"
run "git reset --hard"
Signed-off-by: Eric Sunshine
---
builtin/worktree.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 51c57bc..39f87a4 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -195,8 +195,10 @@ static int add_worktree(const char *path, const char
*refname,
if (file_exists(path) && !is_empty_dir(path))
die(_("'%s' already exists"), path);
- if (!opts->detach && !strbuf_check_branch_ref(&symref, refname) &&
- ref_exists(symref.buf)) {
+ if (opts->force_new_branch)
+ ;
+ else if (!opts->detach && !strbuf_check_branch_ref(&symref, refname) &&
+ref_exists(symref.buf)) {
if (!opts->force)
die_if_checked_out(symref.buf);
} else {
--
2.5.0.rc1.387.g8463c8d
--
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] rev-parse --parseopt: allow [*=?!] in argument hints
From: Sent: Sunday, July 12, 2015 10:39 AM
From: Ilya Bobyr
It is not very likely that any of the "*=?!" Characters would be
useful
in the argument short or long names. On the other hand, there are
already argument hints that contain the "=" sign. It used to be
impossible to include any of the "*=?!" signs in the arguments hints
before.
I found this difficult to parse, and had to check the man pages to
understand the proposal, which were nearly as bad (for me).
Perhaps:
"In the 'git rev-parse' parseopt mode, the the short and long options
cannot contain any of the terminating flag characters "*=?!".
This restriction does not apply to the argument name hint
which is space terminated.
Allow flag characters in the , after the arg-hint's initial
non flag character."
Would that be a correct understanding?
--
Philip
Added test case with equals sign in the argument hint and updated the
test to perform all the operations in test_expect_success matching the
t\README requirements and allowing commands like
./t1502-rev-parse-parseopt.sh --run=1-2
to stop at the test case 2 without any further modification of the
test
state area.
Signed-off-by: Ilya Bobyr
---
builtin/rev-parse.c | 36
t/t1502-rev-parse-parseopt.sh | 97
++-
2 files changed, 77 insertions(+), 56 deletions(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index b623239..205ea67 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -423,17 +423,25 @@ static int cmd_parseopt(int argc, const char
**argv, const char *prefix)
o->flags = PARSE_OPT_NOARG;
o->callback = &parseopt_dump;
- /* Possible argument name hint */
+ /* parse names, type and the hint */
end = s;
- while (s > sb.buf && strchr("*=?!", s[-1]) == NULL)
- --s;
- if (s != sb.buf && s != end)
- o->argh = xmemdupz(s, end - s);
- if (s == sb.buf)
- s = end;
+ s = sb.buf;
+
+ /* name(s) */
+ while (s < end && strchr("*=?!", *s) == NULL)
+ ++s;
+
+ if (s - sb.buf == 1) /* short option only */
+ o->short_name = *sb.buf;
+ else if (sb.buf[1] != ',') /* long option only */
+ o->long_name = xmemdupz(sb.buf, s - sb.buf);
+ else {
+ o->short_name = *sb.buf;
+ o->long_name = xmemdupz(sb.buf + 2, s - sb.buf - 2);
+ }
- while (s > sb.buf && strchr("*=?!", s[-1])) {
- switch (*--s) {
+ while (s < end && strchr("*=?!", *s)) {
+ switch (*s++) {
case '=':
o->flags &= ~PARSE_OPT_NOARG;
break;
@@ -450,14 +458,8 @@ static int cmd_parseopt(int argc, const char
**argv, const char *prefix)
}
}
- if (s - sb.buf == 1) /* short option only */
- o->short_name = *sb.buf;
- else if (sb.buf[1] != ',') /* long option only */
- o->long_name = xmemdupz(sb.buf, s - sb.buf);
- else {
- o->short_name = *sb.buf;
- o->long_name = xmemdupz(sb.buf + 2, s - sb.buf - 2);
- }
+ if (s < end)
+ o->argh = xmemdupz(s, end - s);
}
strbuf_release(&sb);
diff --git a/t/t1502-rev-parse-parseopt.sh
b/t/t1502-rev-parse-parseopt.sh
index ebe7c3b..d5e5720 100755
--- a/t/t1502-rev-parse-parseopt.sh
+++ b/t/t1502-rev-parse-parseopt.sh
@@ -3,7 +3,39 @@
test_description='test git rev-parse --parseopt'
. ./test-lib.sh
-sed -e 's/^|//' >expect <<\END_EXPECT
+test_expect_success 'setup optionspec' '
+ sed -e "s/^|//" >optionspec <<\EOF
+|some-command [options] ...
+|
+|some-command does foo and bar!
+|--
+|h,helpshow the help
+|
+|foo some nifty option --foo
+|bar= some cool option --bar with an argument
+|b,baz a short and long option
+|
+| An option group Header
+|C?option C with an optional argument
+|d,data? short and long option with an optional argument
+|
+| Argument hints
+|B=arg short option required argument
+|bar2=arg long option required argument
+|e,fuz=with-space short and long option required argument
+|s?someshort option optional argument
+|long?data long option optional argument
+|g,fluf?path short and long option optional argument
+|longest=very-long-argument-hint a very long argument hint
+|pair=key=value with an equals sign in the hint
+|
+|Extras
+|extra1line above used to cause a segfault but no longer does
+EOF
+'
+
+test_expect_success 'test --parseopt help output' '
+ sed -e "s/^|//" >expect <<\END_EXPECT &&
|cat <<\EOF
|usage: some-command [options] ...
|
@@ -28,49 +60,22 @@ sed -e 's/^|//' >expect <<\END_EXPECT
|-g, --fluf[=] short and long option optional argument
|--longest
| a very long argument hint
+|--pair with an equals sign in the hint
|
|Extras
|--extra1 line above used to cause a segfault but no
longer does
|
|EOF
END_EXPECT
-
-sed -e 's/^|//' >optionspec <<\EOF
-|some-command [options] ...
-|
-|some-command does foo and bar!
-|--
-|h,helpshow the help
-|
-|foo some nifty option --foo
-|bar= some cool option --bar with an argument
-|b,baz a short and long option
-|
-| An option group Header
-|C?option C with an optional argument
-|d,data? short
Re: [PATCH v5 00/44] Make git-am a builtin
Paul Tan writes: >> However, I am reluctant to blindly replace assert(!state->field) >> with free(state->field). Are there cases where we _must_ call a >> function that sets these fields at most once? > > I wouldn't say we are "blindly" replacing them. I said "I was", not "you and me". If there was a case where we should never call into a codepath once these fields are already initialized, then we need to keep assert(!state->field) in such a codepath. I didn't know if that were the case, hence I would have been blindly replacing, which I didn't want to do. And that is why I asked _you_ ;-) -- 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] rev-parse --parseopt: allow [*=?!] in argument hints
ilya.bo...@gmail.com writes:
> From: Ilya Bobyr
>
> It is not very likely that any of the "*=?!" Characters would be useful
> in the argument short or long names. On the other hand, there are
> already argument hints that contain the "=" sign. It used to be
> impossible to include any of the "*=?!" signs in the arguments hints
> before.
After reading this three times (without looking at the code), it is
unclear to me what the change wants to achieve. A few points that
confuse me:
- "It is not very likely..."; so what does this change do to such
an unlikely case? Does it just forbid? Or does it have escape
hatches?
- "... there are already ..."; so an unlikely case already exists?
- "It used to be impossible..."; h, it earlier said there are
already cases there---how they have been working?
Perhaps it would clarify the paragraph if you said upfront that a
parseopt option specification is (i.e. short and long
names) optionally followed by (i.e. one or more of these
"*=?!" characters) and the string to remind the readers
and reviewers, and phrase what you wrote to make the differences
between them stand out?
A line in the input to "rev-parse --parseopt" describes an
option by listing a short and/or long name, optional flags
[*=?!], argument hint, and then whitespace and help string.
The code first finds the help string and scans backwards to find
the flags, which would imply that [*=?!] is allowed in the
option names but not in argument hint string.
That is backwards; you do not want these special characters in
option names, but you may want to be able to include them
(especially '=', as in 'key=value') in the argument hint string.
Change the parsing to go from the beginning to find the first
occurrence of [*=?!] to find the flags and use the remainder as
argument hint.
or something, perhaps.
> Added test case with equals sign in the argument hint and updated the
"Add a test case with ... and update the test ...". Write your log
message as if you are giving somebody an order with your commit to
do such and such.
> test to perform all the operations in test_expect_success matching the
> t\README requirements and allowing commands like
t/README.
>
> ./t1502-rev-parse-parseopt.sh --run=1-2
>
> to stop at the test case 2 without any further modification of the test
> state area.
>
> Signed-off-by: Ilya Bobyr
> ---
> builtin/rev-parse.c | 36
> t/t1502-rev-parse-parseopt.sh | 97
> ++-
> 2 files changed, 77 insertions(+), 56 deletions(-)
>
> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
> index b623239..205ea67 100644
> --- a/builtin/rev-parse.c
> +++ b/builtin/rev-parse.c
> @@ -423,17 +423,25 @@ static int cmd_parseopt(int argc, const char **argv,
> const char *prefix)
> o->flags = PARSE_OPT_NOARG;
> o->callback = &parseopt_dump;
>
> - /* Possible argument name hint */
> + /* parse names, type and the hint */
> end = s;
> - while (s > sb.buf && strchr("*=?!", s[-1]) == NULL)
> - --s;
I must have overlooked this one long time ago when a patch added
this; it is a horrible way to parse a thing from the tail. Good to
see the code go ;-)
> - if (s != sb.buf && s != end)
> - o->argh = xmemdupz(s, end - s);
> - if (s == sb.buf)
> - s = end;
> + s = sb.buf;
> +
> + /* name(s) */
> + while (s < end && strchr("*=?!", *s) == NULL)
> + ++s;
In C, we usually pre-decrement and post-increment, unless the value
is used.
More importantly, can't we write this more concisely by using
strcspn(3)?
const char *flags_chars = "*=?!";
size_t leading = strcspn(s, flags_chars);
if (s + leading < end)
... /* s + leading is the beginning of flags */
else
... /* there was no flags before end */
> +
> + if (s - sb.buf == 1) /* short option only */
> + o->short_name = *sb.buf;
> + else if (sb.buf[1] != ',') /* long option only */
> + o->long_name = xmemdupz(sb.buf, s - sb.buf);
> + else {
> + o->short_name = *sb.buf;
> + o->long_name = xmemdupz(sb.buf + 2, s - sb.buf - 2);
> + }
>
> - while (s > sb.buf && strchr("*=?!", s[-1])) {
> - switch (*--s) {
> + while (s < end && strchr("*=?!", *s)) {
> + switch (*s++) {
> case '=':
No need for the strchr() dance, I think, because you will do
different things depending on *s inside the loop anyway. Just
while (s < end) {
switch (*s++) {
case '=':
Re: [PATCH] diff: parse ws-error-highlight option more strictly
René Scharfe writes:
> Check if a matched token is followed by a delimiter before advancing the
> pointer arg. This avoids accepting composite words like "allnew" or
> "defaultcontext".
>
> Signed-off-by: Rene Scharfe
> ---
> diff.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/diff.c b/diff.c
> index 87b16d5..0f17ec5 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3653,7 +3653,12 @@ static void enable_patch_output(int *fmt) {
>
> static int parse_one_token(const char **arg, const char *token)
> {
> - return skip_prefix(*arg, token, arg) && (!**arg || **arg == ',');
> + const char *rest;
> + if (skip_prefix(*arg, token, &rest) && (!*rest || *rest == ',')) {
> + *arg = rest;
> + return 1;
> + }
> + return 0;
> }
So the bug is, when fed "allnew", calls to this function are done
with "none" and "default" (both of which fail skip_prefix()), then
with "all", at which point skip_prefix() advance the *arg pointer to
"allnew"+3 (i.e. pointing at 'n') and the check on the "are we at
the end of token?" fails. The next call is for "new" and it
incorrectly passes.
Thanks for spotting.
An unrelated tangent, but I misnamed this function grossly, it
seems. Even if this is a file-scope static, it is selfish to claim
that this function is the only one that will ever parse any kind of
token in this file. As this is a helper that can be used to parse
any string with comma-separated tokens, I should have named it with
some word that hints that fact.
--
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: What's cooking in git.git (Jul 2015, #03; Fri, 10)
Eric Sunshine writes: > Did you want to drop the final patch[*1*] which retires > --ignore-other-worktrees in favor of --force before letting this > graduate to 'master'? Yeah, thanks for catching it. > By the way, v1 of the follow-on series which replaces "git checkout" > with "git reset --hard" to populate the new worktree is ready. I > expect to send it out shortly. 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] Documentation clarification on git-checkout regarding ours/theirs
"Simon A. Eugster" writes: >> +... As the keeper of >> +the canonical history, you need to view the history from the remote >> +as `ours` (i.e. "our shared canonical history"), while what you did >> +on your side branch as `theirs` (i.e. "one contributor's work on top >> +of it"). >> >> -b :: >> Create a new branch named and start it at > > I think there is an “s” missing in “… and treat the work done on > the branch …”, but not quite sure. Thanks, you are right. Will fix. -- 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/PATCH 4/9] ref-filter: add support to sort by version
On Sun, Jul 12, 2015 at 2:39 PM, Duy Nguyen wrote: > On Thu, Jun 25, 2015 at 6:43 PM, Karthik Nayak wrote: >> Add support to sort by version using the "v:refname" and >> "version:refname" option. This is achieved by using the >> 'version_cmp()' function as the comparing function for qsort. > > If these v:refname and version:refname are from git-tag, you may want > to see [1]. I would say "version:" or "v:" is in the same class as "-" > (for reverse sort) and they should be parsed in > parse_opt_ref_sorting() instead. They should not be treated as atom > names. By stripping "version:" before pref_ref_filter_atom() is called > in this function, you make "version:" work with all supported atoms. > > [1] http://article.gmane.org/gmane.comp.version-control.git/242446 > -- > Duy Thanks for this, what you're saying makes sense, will follow. -- 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 v2 06/10] Documentation/tag: remove double occurance of ""
On Fri, Jul 10, 2015 at 10:14 PM, Junio C Hamano wrote: > Christian Couder writes: > >> On Thu, Jul 9, 2015 at 12:27 PM, Karthik Nayak wrote: >>> Mentored-by: Christian Couder >>> Mentored-by: Matthieu Moy >>> Signed-off-by: Karthik Nayak >>> --- >>> Documentation/git-tag.txt | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt >>> index 034d10d..4b04c2b 100644 >>> --- a/Documentation/git-tag.txt >>> +++ b/Documentation/git-tag.txt >>> @@ -14,7 +14,6 @@ SYNOPSIS >>> 'git tag' -d ... >>> 'git tag' [-n[]] -l [--contains ] [--points-at ] >>> [--column[=] | --no-column] [...] >>> - [...] >>> 'git tag' -v ... >> >> As this patch could be applied directly to master and to maint maybe >> you could send it at the top of this patch series or alone outside of >> this patch series. > > Thanks. I'll pick this patch from the remainder of the series and > queue it on a separate topic. That'll be awesome :) -- 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 v5 00/44] Make git-am a builtin
Hi,
(Sorry for the late reply. Caught a nasty stomach bug that kept me in
bed for a while ><)
On Thu, Jul 9, 2015 at 2:00 PM, Junio C Hamano wrote:
> What I pushed out tonight should have SQUASH??? (or fixup!) that
> splits this into appropriate steps in your series. Please check.
Yeah they look good.
> Note that you do not have to say "if the variable h2as something,
> then free it". free(NULL) is perfectly fine and we can read
>
> free(var);
> var = compute_new_value();
>
> just fine.
OK. There are other places where I used "if (x) free(x)" though (such
as in am_state_release()), so I will fix them in a re-roll as well.
> However, I am reluctant to blindly replace assert(!state->field)
> with free(state->field). Are there cases where we _must_ call a
> function that sets these fields at most once?
I wouldn't say we are "blindly" replacing them. The purpose of the
assert(!state->field) is to ensure that we are not overwriting any
commit metadata already stored in the state directory. And in almost
all cases, this holds true. However, as you have just shown, running
"git am" again while there is a session in progress will override the
commit metadata stored in the state directory, so I believe the
replacement with free() is reasonable.
> On the other hand, assert() like this is more or less useless.
>
> assert(state->field);
> ...
> printf("%s", state->field); /* or other uses */
>
> "The caller must have filled the field" can be seen by unconditional
> use of "state->field" without such an assert().
OK. Will remove them as well.
Thanks,
Paul
--
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 10/16] worktree: make branch creation distinct from worktree population
(resend, +everybody)
On Sun, Jul 12, 2015 at 10:27 AM, Eric Sunshine wrote:
>>> So, if I understand your concern correctly, then you are worried that,
>>> following the git-branch invocation, ref_exists() could return the
>>> wrong answer with a pluggable ref-backend since it might be answering
>>> based upon stale information. Is that what you mean? If so, I can see
>>> how that it could be an issue. (As far as I can tell, the current
>>> file-based backend doesn't have a problem with this since it's hitting
>>> the filesystem directly to answer the ref_exists() question.)
>>
>> I meant for this final sentence to end like this:
>>
>> ...to answer the ref_exists() question, but it still seems
>> fragile since some future change could introduce caching.
>
> In this case, it's easy enough to side-step the issue since there's no
> need to call ref_exists() if the new branch was created successfully
> (since we know it exists). The logic would effectively become this:
>
> branch = ...
> if (create_new_branch) {
> exec "git branch newbranch branch"
> exec "git symbolic-ref HEAD newbranch"
> } else if (ref_exists(branch) && !detach)
> exec "git symbolic-ref HEAD branch"
> else
> exec "git update-ref HEAD $(git rev-parse branch)"
> exec "git reset --hard"
Yeah.. Another option we can take is deal with this at run-command.c
level (and outside this series) because this could affect everywhere:
by default, invalidate all cache after running any git commands. The
caller can pass options to keep some cache intact if they know the
command won't touch it.
If ref_exists() is the only thing we use, right now it does not use
cache so we should be safe. If the new ref backend introduces a cache,
they would need to examine all callers anyway, including this one. The
cache in refs.c seems to be for for_each_ref.. only, which we don't
call here.
--
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 v2 08/10] tag.c: use 'ref-filter' APIs
On Thu, Jul 9, 2015 at 5:58 PM, Karthik Nayak wrote:
> -static int show_reference(const char *refname, const struct object_id *oid,
> - int flag, void *cb_data)
> -{
...
> -
> - if (match_pattern(filter->name_patterns, refname)) {
> - printf("%-15s ", refname);
> - show_tag_lines(oid, filter->lines);
> - putchar('\n');
> - }
> -
> - return 0;
> -}
...
> + if (filter->lines)
> + format = "%(refname:shortalign=16)";
> + else
> + format = "%(refname:short)";
I can see this is a faithful conversion, but this looks line an
opportunity to avoid this special limit 15/16. Even on git.git "git
tag -l -n1" already breaks alignment with *.msysgit.* tags (ok maybe
msysgit, not purely git.git) When you get to "branch -l", it
calculates the max-width automatically so you probably need
"%(refname:shortalign)" any way. "shortalign" (i.e. create the "align"
version for every modifier) does not look good because it could double
the number of modifiers and let's not thinking about truncation
options or right alignment..
--
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
[PATCH] rev-parse --parseopt: allow [*=?!] in argument hints
From: Ilya Bobyr
It is not very likely that any of the "*=?!" Characters would be useful
in the argument short or long names. On the other hand, there are
already argument hints that contain the "=" sign. It used to be
impossible to include any of the "*=?!" signs in the arguments hints
before.
Added test case with equals sign in the argument hint and updated the
test to perform all the operations in test_expect_success matching the
t\README requirements and allowing commands like
./t1502-rev-parse-parseopt.sh --run=1-2
to stop at the test case 2 without any further modification of the test
state area.
Signed-off-by: Ilya Bobyr
---
builtin/rev-parse.c | 36
t/t1502-rev-parse-parseopt.sh | 97 ++-
2 files changed, 77 insertions(+), 56 deletions(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index b623239..205ea67 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -423,17 +423,25 @@ static int cmd_parseopt(int argc, const char **argv,
const char *prefix)
o->flags = PARSE_OPT_NOARG;
o->callback = &parseopt_dump;
- /* Possible argument name hint */
+ /* parse names, type and the hint */
end = s;
- while (s > sb.buf && strchr("*=?!", s[-1]) == NULL)
- --s;
- if (s != sb.buf && s != end)
- o->argh = xmemdupz(s, end - s);
- if (s == sb.buf)
- s = end;
+ s = sb.buf;
+
+ /* name(s) */
+ while (s < end && strchr("*=?!", *s) == NULL)
+ ++s;
+
+ if (s - sb.buf == 1) /* short option only */
+ o->short_name = *sb.buf;
+ else if (sb.buf[1] != ',') /* long option only */
+ o->long_name = xmemdupz(sb.buf, s - sb.buf);
+ else {
+ o->short_name = *sb.buf;
+ o->long_name = xmemdupz(sb.buf + 2, s - sb.buf - 2);
+ }
- while (s > sb.buf && strchr("*=?!", s[-1])) {
- switch (*--s) {
+ while (s < end && strchr("*=?!", *s)) {
+ switch (*s++) {
case '=':
o->flags &= ~PARSE_OPT_NOARG;
break;
@@ -450,14 +458,8 @@ static int cmd_parseopt(int argc, const char **argv, const
char *prefix)
}
}
- if (s - sb.buf == 1) /* short option only */
- o->short_name = *sb.buf;
- else if (sb.buf[1] != ',') /* long option only */
- o->long_name = xmemdupz(sb.buf, s - sb.buf);
- else {
- o->short_name = *sb.buf;
- o->long_name = xmemdupz(sb.buf + 2, s - sb.buf - 2);
- }
+ if (s < end)
+ o->argh = xmemdupz(s, end - s);
}
strbuf_release(&sb);
diff --git a/t/t1502-rev-parse-parseopt.sh b/t/t1502-rev-parse-parseopt.sh
index ebe7c3b..d5e5720 100755
--- a/t/t1502-rev-parse-parseopt.sh
+++ b/t/t1502-rev-parse-parseopt.sh
@@ -3,7 +3,39 @@
test_description='test git rev-parse --parseopt'
. ./test-lib.sh
-sed -e 's/^|//' >expect <<\END_EXPECT
+test_expect_success 'setup optionspec' '
+ sed -e "s/^|//" >optionspec <<\EOF
+|some-command [options] ...
+|
+|some-command does foo and bar!
+|--
+|h,helpshow the help
+|
+|foo some nifty option --foo
+|bar= some cool option --bar with an argument
+|b,baz a short and long option
+|
+| An option group Header
+|C?option C with an optional argument
+|d,data? short and long option with an optional argument
+|
+| Argument hints
+|B=arg short option required argument
+|bar2=arg long option required argument
+|e,fuz=with-space short and long option required argument
+|s?someshort option optional argument
+|long?data long option optional argument
+|g,fluf?path short and long option optional argument
+|longest=very-long-argument-hint a very long argument hint
+|pair=key=value with an equals sign in the hint
+|
+|Extras
+|extra1line above used to cause a segfault but no longer does
+EOF
+'
+
+test_expect_success 'test --parseopt help output' '
+ sed -e "s/^|//" >expect <<\END_EXPECT &&
|cat <<\EOF
|usage: some-command [options] ...
|
@@ -28,49 +60,22 @@ sed -e 's/^|//' >expect <<\END_EXPECT
|-g, --fluf[=] short and long option optional argument
|--longest
| a very long argument hint
+|--pair with an equals sign in the hint
|
|Extras
|--extra1 line above used to cause a segfault but no longer
does
|
|EOF
END_EXPECT
-
-sed -e 's/^|//' >optionspec <<\EOF
-|some-command [options] ...
-|
-|some-command does foo and
Re: [RFC/PATCH 4/9] ref-filter: add support to sort by version
On Thu, Jun 25, 2015 at 6:43 PM, Karthik Nayak wrote: > Add support to sort by version using the "v:refname" and > "version:refname" option. This is achieved by using the > 'version_cmp()' function as the comparing function for qsort. If these v:refname and version:refname are from git-tag, you may want to see [1]. I would say "version:" or "v:" is in the same class as "-" (for reverse sort) and they should be parsed in parse_opt_ref_sorting() instead. They should not be treated as atom names. By stripping "version:" before pref_ref_filter_atom() is called in this function, you make "version:" work with all supported atoms. [1] http://article.gmane.org/gmane.comp.version-control.git/242446 -- 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 v2 01/10] ref-filter: add %(refname:shortalign=X) option
On Sun, Jul 12, 2015 at 8:47 AM, Duy Nguyen wrote: > Another thing, the atom value is also used for sorting. When used for > sorting, I think these padding spaces should not be generated or it > may confuse the sort algorithm. Left alignment may be ok, right or > center alignment (in future?), not so much.\ Correction: I'm wrong. This is only true if the atom for sorting is in the same atom list for display. But we create new atoms for sorting in parse_opt_ref_sorting(), where we drop everything after ':', so "shortalign=" shouldn't be there when populate_atom() for sorting is called. -- 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
