Re: libgit2 status
I know julio notes about libgit2. Anyway the rpm5 mantainer had decided to integrate libgit2 recently. Jfi. Regards 2012/8/25, Nicolas Sebrecht : > The 25/08/12, Vicent Marti wrote: > >> The development of libgit2 happens 100% in the open. I don't know what >> "commercial entity" are you talking about, but there are several >> companies and independent contributors working on the Library at the >> moment. > > Right but as far as I'm aware of Junio had reserves about libgit2 > integration into git due to issues making repositories broken. Though, > having libgit2 as git core would make libgit2 the the-facto standard > which would a *very* big plus. > > Also, I guess that integration into git would mean more developers > contibuting for libgit2. Currently, issues seems to be a blocker for > integration. So, libgit2 might appear to be a marginal/risky alternative > for a long time which is sad. > > [ I'm somewhat in the same situation of OP. ] > > -- > Nicolas Sebrecht > -- > 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 > -- Inviato dal mio dispositivo mobile -- 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 checkout -t -B
Dear Sir, I want to make current branch abcde a remote tracking branch with origin/abcde. Since I am working on current branch abcde, I have to use the force option. So I run git checkout -t -B origin/abcde works but git checkout -B -t origin/abcde does not. Could you document the order of parameters or fix the behaviour? Thanks, ch3cooli -- 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: git no longer prompting for password
On 25/08/12 21:39, Jeff King wrote: > I think your regex is the culprit. The first request comes in with: > >>> GET /git/test.git/info/refs?service=git-receive-pack HTTP/1.1 > > The odd URL is because we are probing to see if the server even supports > smart-http. But note that it does not match your regex above, which > requires "/git-receive-pack". It looks like that is pulled straight from > the git-http-backend manpage. I think the change in v1.7.8 broke people > using that configuration. Yes, it was lifted straight out of the manpage, albeit a couple of years ago now and there have been additions to the manpage since then. I did check, and the basic config is identical in the current manpage. I can't be the only one using a config that's based on the example in the manpage surely ? So I'm surprised this hasn't come up previously. > I tend to think the right thing is to fix the configuration (both on > your system and in the documentation), but we should probably also fix > git to handle this situation more gracefully, since it used to work and > has been advertised in the documentation for a long time. So after some head scratching trying to work out how to do the equivalent of LocationMatch but on the query string I came up with the following: ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ Require ip 10.44.0.0/16 AuthType Basic AuthUserFile /data/git/htpasswd AuthGroupfile /data/git/groups AuthName "Git Access" Require group committers and I've removed the LocationMatch section completely. So for accesses to git-http-backend I require auth if anything in the request includes git-receive-pack and that causes a prompt for the username/password as required, while at the same time it still allows anonymous pull. It appears that the clone operation uses GET /git/test.git/info/refs?service=git-upload-pack HTTP/1.1 to probe for smart-http ? So this would be ok ? I'm not sure this is ideal, I don't really know enough about the protocol to know if I'll see git-receive-pack elsewhere. Possibly if someone includes it in the name of a repo it'll blow up in my face. I can always change it to match only on QUERY_STRING and put the LocationMatch back in if that happens. If that's all that's required, I'm fine with an easy change to httpd.conf Thanks for the help Jeff. -- 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: git no longer prompting for password
On Sun, Aug 26, 2012 at 10:57:59AM +0100, Iain Paton wrote: > > The odd URL is because we are probing to see if the server even supports > > smart-http. But note that it does not match your regex above, which > > requires "/git-receive-pack". It looks like that is pulled straight from > > the git-http-backend manpage. I think the change in v1.7.8 broke people > > using that configuration. > > Yes, it was lifted straight out of the manpage, albeit a couple of years > ago now and there have been additions to the manpage since then. > I did check, and the basic config is identical in the current manpage. > > I can't be the only one using a config that's based on the example in > the manpage surely ? So I'm surprised this hasn't come up previously. Yeah, I'm surprised it took this long to come up, too. Perhaps most people just do anonymous http, and then rely on ssh for pushing to achieve the same effect. Or maybe my analysis of the problem is wrong. :) I'm preparing some patches to the test suite that will demonstrate the problem (we test dumb-http auth, but we don't do any smart-http auth at all in the test suite), and then a fix on top to let us prompt for the password in this instance. I think we should also update the documentation, but the existing advice has been given long enough that people are going to use it for some time, and I consider your issue to be a regression in v1.7.8 that should be fixed. > So after some head scratching trying to work out how to do the equivalent of > LocationMatch but on the query string I came up with the following: > > ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ > > > Require ip 10.44.0.0/16 > > AuthType Basic > AuthUserFile /data/git/htpasswd > AuthGroupfile /data/git/groups > AuthName "Git Access" > > Require group committers > > > > and I've removed the LocationMatch section completely. Yeah, I think that will work. It feels a little weird and hacky. E.g., what if you had a repo named git-receive-pack? Unlikely, of course, but I'd want the config we advertise in the manpage to be as robust as possible. I don't know enough about Apache to know off-hand if there is a cleaner way. I'll investigate a bit more before doing my documentation patch. > So for accesses to git-http-backend I require auth if anything in the request > includes git-receive-pack and that causes a prompt for the username/password > as required, while at the same time it still allows anonymous pull. > > It appears that the clone operation uses > > GET /git/test.git/info/refs?service=git-upload-pack HTTP/1.1 > > to probe for smart-http ? So this would be ok ? Right. Anything invoking receive-pack is always a push. > I'm not sure this is ideal, I don't really know enough about the protocol to > know > if I'll see git-receive-pack elsewhere. Possibly if someone includes it in > the > name of a repo it'll blow up in my face. Yep, exactly. That should be the only place, though, I think (branch names, for example, are never part of the URL). > I can always change it to match only on QUERY_STRING and put the > LocationMatch > back in if that happens. I think that would be cleaner. It would be even nicer if you could really just match "service=" as a query parameter, but I don't know that apache parses that at all. I also don't know if Apache does any canonicalization of the QUERY_STRING. When matching, you'd want to make sure there is no way of a client sneaking in a parameter that git would understand to mean a push, but that your pattern would not notice (so, e.g., just matching "git-receive-pack$" would not be sufficient, as I could request "?service=git-receive-pack&fooled_you=true". I don't recall whether git rejects nonsense like that itself. > If that's all that's required, I'm fine with an easy change to httpd.conf > > Thanks for the help Jeff. No problem. I'll probably be a day or two on the patches, as the http tests are in need of some refactoring before adding more tests. But in the meantime, I think your config change is a sane work-around. -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: misleading diff-hunk header
On 08/25/2012 02:56 PM, Tim Chase wrote:
> On 08/24/12 23:29, Junio C Hamano wrote:
>> Tim Chase writes:
>>> If the documented purpose of "diff -p" (and by proxy
>>> diff.{type}.xfuncname) is to show the name of the *function*
>>> containing the changed lines,
>>
>> Yeah, the documentation is misleading, but I do not offhand think of
>> a better phrasing. Perhaps you could send in a patch to improve it.
>>
>> How does GNU manual explain the option?
>
> Tersely. :-)
>
>-p --show-c-function
> Show which C function each change is in.
>
That's in the manpage, which is basically just a copy of the output from
"diff --help". In the texinfo manual (which is the real documentation),
there are additional explanations, saying, among other things:
To show in which functions differences occur for C and similar languages,
you can use the --show-c-function (-p) option. This option automatically
defaults to the context output format (see Context Format), with the
default number of lines of context. You can override that number with
-C lines elsewhere in the command line. You can override both the format
and the number with -U lines elsewhere in the command line.
The -p option is equivalent to -F '^[[:alpha:]$_]' if the unified format
is specified, otherwise -c -F '^[[:alpha:]$_]' (see Specified Headings).
GNU diff provides this option for the sake of convenience.
...
The --show-function-line (-F) option finds the nearest unchanged line
that precedes each hunk of differences and matches the given regular
expression.
You can find more information in the on-line documentation:
HTH,
Stefano
--
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: git no longer prompting for password
On 26/08/12 11:13, Jeff King wrote: > Yeah, I'm surprised it took this long to come up, too. Perhaps most > people just do anonymous http, and then rely on ssh for pushing to > achieve the same effect. Or maybe my analysis of the problem is wrong. > :) I'd be using ssh to push too, but the simple fact is that the http way works through a proxy and so essentially works from anywhere. The same isn't true for ssh or git protocols. Well that's my reason anyway :) > Yeah, I think that will work. It feels a little weird and hacky. E.g., Yeah, it does. I couldn't find a simple way though, most stuff like LocationMatch specifically excludes the query string which makes it rather more difficult. > I don't know enough about Apache to know off-hand if there is a cleaner > way. I'll investigate a bit more before doing my documentation patch. I'm not an apache expert either. What I could find was using mod_rewrite to set an env var based on something in the query string, but not actually do any rewrite. Then looking at how to check the env var and do something based on that got me the example of simply using If with an expression to match directly on the query string. > I think that would be cleaner. It would be even nicer if you could > really just match "service=" as a query parameter, but I don't know that > apache parses that at all. I also don't know if Apache does any > canonicalization of the QUERY_STRING. When matching, you'd want to make >From what I can tell apache really doesn't care much about the query string at all, it seems to just pass it through unless you start messing with it using mod_rewrite, but even then you're still regex based. I couldn't find anything that parsed out individual parameters. Of course I could just be looking in all the wrong places :) > sure there is no way of a client sneaking in a parameter that git would > understand to mean a push, but that your pattern would not notice (so, > e.g., just matching "git-receive-pack$" would not be sufficient, as I yep, and matching on THE_REQUEST gets you the whole string, including the HTTP/1.1 on the end. I tried putting the $ on the end of the regex and it didn't work. It should be possible to combine the original regex from the LocationMatch example and something like /[?&]service=git-receive-pack/ though, which should make it somewhat safer. > No problem. I'll probably be a day or two on the patches, as the http > tests are in need of some refactoring before adding more tests. But in > the meantime, I think your config change is a sane work-around. Works-For-Me is all I need right now :) I'll be interested if you come up with something better though. Iain -- 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 00/17] Clean up how fetch_pack() handles the heads list
mhag...@alum.mit.edu writes: > Re-roll, incorporating Jeff's suggestions. Some commit messages have > also been improved, but the only interdiff is that match_pos is > renamed to head_pos in filter_refs(). > > This patch series applies to the merge between master and > jc/maint-push-refs-all, though the dependency on the latter is only > textual. I've read this twice and saw nothing questionable in the series (other than that the titles of a few weren't clear enough when placed in a short-log like below). Very nicely done. Thanks. Will queue. > Michael Haggerty (17): > t5500: add tests of error output for missing refs > Rename static function fetch_pack() to http_fetch_pack() > Fix formatting. > Name local variables more consistently > Do not check the same head_pos twice > Let fetch_pack() inform caller about number of unique heads > Pass nr_heads to do_pack_ref() by reference > Pass nr_heads to everything_local() by reference > Pass nr_heads to filter_refs() by reference > Remove ineffective optimization > filter_refs(): do not leave gaps in return_refs > filter_refs(): compress unmatched refs in heads array > cmd_fetch_pack: return early if finish_connect() returns an error > Report missing refs even if no existing refs were received > cmd_fetch_pack(): simplify computation of return value > fetch_pack(): free matching heads > filter_refs(): simplify logic > > builtin/fetch-pack.c | 128 > -- > fetch-pack.h | 19 +--- > http-walker.c | 4 +- > t/t5500-fetch-pack.sh | 32 - > transport.c | 8 ++-- > 5 files changed, 101 insertions(+), 90 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] remote-testsvn.c: Avoid the getline() GNU extension function
Erik Faye-Lund writes: > On Sat, Aug 25, 2012 at 7:13 PM, Ramsay Jones > wrote: >> >> The getline() function is a GNU extension (you need to define >> _GNU_SOURCE before including stdio.h) and is, therefore, not >> portable. In particular, getline() is not available on MinGW. > > Actually, getline is a POSIX-2008 feature, so it's not (simply) a GNU > extension: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/getline.html True, thanks for pointing it out. Justify the change with something like this instead, perhaps? The getline() function, even though is in POSIX.1-2008, is not available on some platforms. Use strbuf_getline() for portability. By the way, the remainder of the proposed log message talks about the difference between getline() that keeps the terminating LF vs strbuf_getline() that drops it. Would strbuf_getwholeline() be a better alternative? -- 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 04/17] Name local variables more consistently
Jeff King writes:
> On Thu, Aug 23, 2012 at 10:10:29AM +0200, mhag...@alum.mit.edu wrote:
>
>> From: Michael Haggerty
>>
>> Use the names (nr_heads, heads) consistently across functions, instead
>> of sometimes naming the same values (nr_match, match).
>
> I think this is fine, although:
>
>> --- a/builtin/fetch-pack.c
>> +++ b/builtin/fetch-pack.c
>> @@ -521,7 +521,7 @@ static void mark_recent_complete_commits(unsigned long
>> cutoff)
>> }
>> }
>>
>> -static void filter_refs(struct ref **refs, int nr_match, char **match)
>> +static void filter_refs(struct ref **refs, int nr_heads, char **heads)
>> {
>> struct ref **return_refs;
>> struct ref *newlist = NULL;
>> @@ -530,12 +530,12 @@ static void filter_refs(struct ref **refs, int
>> nr_match, char **match)
>> struct ref *fastarray[32];
>> int match_pos;
>
> This match_pos is an index into the "match" array, which becomes "head".
> Should it become head_pos?
>
> And then bits like this:
>
>> -while (match_pos < nr_match) {
>> -cmp = strcmp(ref->name, match[match_pos]);
>> +while (match_pos < nr_heads) {
>> +cmp = strcmp(ref->name, heads[match_pos]);
>
> Would be:
>
> while (head_pos < nr_heads)
>
> which makes more sense to me.
Using one name is better, but I wonder "heads" is the better one
between the two.
After all, this codepath is not limited to branches these days as
the word "head" implies. Rather, has what we
asked for, and has what the other sides have, and we are
trying to make sure we haven't asked what they do not have in this
function.
And the way we do so is to match the "thing"s with what are in
"refs" to find unmatched ones.
So between the two, I would have chosen "match" instead of "heads"
to call the "thing".
--
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] contrib: GnomeKeyring support + generic helper implementation
Junio C Hamano writes: > Jeff King writes: > >> However, the shared bits are simple enough that maybe that is not a >> concern. An interesting test would be to add a 5/4 porting Erik's win32 >> credential helper, since that is the platform least like our other ones. > > Very true. > >> So I am OK with this series, but I am also OK with leaving it at patch >> 1, and just keeping the implementations separate. > > Amen. Just to make sure we do not leave loose ends, could somebody try to see if the new "generic helper" infrastructure is useful to shrink Erik's win32 credential helper implementation? If we see much code reduction and improved clarity, this refactoring may worth keeping. Otherwise it may be sufficient to drop the later ones in the series. Without knowing which, it is hard to decide. 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 v2] branch -v: align even when branch names are in UTF-8
Nguyễn Thái Ngọc Duy writes:
> Branch names are usually in ASCII so they are not the problem. The
> problem most likely comes from "(no branch)" translation, which is in
> UTF-8 and makes length calculation just wrong.
>
> Update document to mention the fact that we may want ref names in
> UTF-8. Encodings that produce invalid UTF-8 are safe as utf8_strwidth()
> falls back to strlen(). The ones that incidentally produce valid UTF-8
> sequences will cause misalignment.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> ...
> @@ -533,7 +535,7 @@ static void show_detached(struct ref_list *ref_list)
> if (head_commit && is_descendant_of(head_commit,
> ref_list->with_commit)) {
> struct ref_item item;
> item.name = xstrdup(_("(no branch)"));
> - item.len = strlen(item.name);
> + item.len = utf8_strwidth(item.name);
> item.kind = REF_LOCAL_BRANCH;
> item.dest = NULL;
> item.commit = head_commit;
We should probably rename the "len" field, as it is no longer about
the length (i.e. that which strlen() returns); it is the display
width, and is better called "cols", "width" or somesuch.
I'll squash-in the following.
Thanks.
builtin/branch.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git c/builtin/branch.c w/builtin/branch.c
index 73ff7e7..4ec556f 100644
--- c/builtin/branch.c
+++ w/builtin/branch.c
@@ -250,7 +250,7 @@ static int delete_branches(int argc, const char **argv, int
force, int kinds,
struct ref_item {
char *name;
char *dest;
- unsigned int kind, len;
+ unsigned int kind, width;
struct commit *commit;
};
@@ -355,14 +355,14 @@ static int append_ref(const char *refname, const unsigned
char *sha1, int flags,
newitem->name = xstrdup(refname);
newitem->kind = kind;
newitem->commit = commit;
- newitem->len = utf8_strwidth(refname);
+ newitem->width = utf8_strwidth(refname);
newitem->dest = resolve_symref(orig_refname, prefix);
/* adjust for "remotes/" */
if (newitem->kind == REF_REMOTE_BRANCH &&
ref_list->kinds != REF_REMOTE_BRANCH)
- newitem->len += 8;
- if (newitem->len > ref_list->maxwidth)
- ref_list->maxwidth = newitem->len;
+ newitem->width += 8;
+ if (newitem->width > ref_list->maxwidth)
+ ref_list->maxwidth = newitem->width;
return 0;
}
@@ -521,8 +521,8 @@ static int calc_maxwidth(struct ref_list *refs)
for (i = 0; i < refs->index; i++) {
if (!matches_merge_filter(refs->list[i].commit))
continue;
- if (refs->list[i].len > w)
- w = refs->list[i].len;
+ if (refs->list[i].width > w)
+ w = refs->list[i].width;
}
return w;
}
@@ -535,12 +535,12 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit && is_descendant_of(head_commit,
ref_list->with_commit)) {
struct ref_item item;
item.name = xstrdup(_("(no branch)"));
- item.len = utf8_strwidth(item.name);
+ item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
item.commit = head_commit;
- if (item.len > ref_list->maxwidth)
- ref_list->maxwidth = item.len;
+ if (item.width > ref_list->maxwidth)
+ ref_list->maxwidth = item.width;
print_ref_item(&item, ref_list->maxwidth, ref_list->verbose,
ref_list->abbrev, 1, "");
free(item.name);
}
--
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] contrib: GnomeKeyring support + generic helper implementation
n 26/08/12 19:46, Junio C Hamano wrote: > Junio C Hamano writes: > >> Jeff King writes: >> >>> However, the shared bits are simple enough that maybe that is not a >>> concern. An interesting test would be to add a 5/4 porting Erik's win32 >>> credential helper, since that is the platform least like our other ones. >> >> Very true. In principle, I agree that with the current set of helper implementations, the generic infrastructure may not yet pay off. >>> So I am OK with this series, but I am also OK with leaving it at patch >>> 1, and just keeping the implementations separate. >> >> Amen. > > Just to make sure we do not leave loose ends, could somebody try to > see if the new "generic helper" infrastructure is useful to shrink > Erik's win32 credential helper implementation? I'll try to give it a shot now, although I won't be able to test it. I'll send the results as a single 5/4 addition to the previous series. > If we see much code reduction and improved clarity, this refactoring > may worth keeping. Otherwise it may be sufficient to drop the later > ones in the series. Without knowing which, it is hard to decide. If we decide that the generic implementation is useful, I'll then resend the reordered series adding the generic helper first, then refactoring the existing ones and adding the new one for GnomeKeyring last. Thanks, Philipp -- 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: libgit2 status
Andreas Ericsson writes: > Politically, I'm not sure how keen the git community is on handing > over control to the core stuff of git to a commercial entity, but it > doesn't seem to be a dying project, so I'd say go ahead and do it. I do not think commercial-ness of any entity comes into the picture. The only three things that matter are license compatibility (I think libgit2 licensed under GPLv2 + linkage exception is doing just fine in that department), maturity and quality of it (it is in early development phase), and the openness of the development process (it could do better by finding ways to better interact with the mainstream git development discussion that happens here in the longer term). And the last one should really be a "longer term" item. It is more important for its codebase to get mature and robust, and that can only happen by various projects and products (e.g. GitHub for Mac) using it to improve it. I do not think "subtree" (or anything in contrib/ for that matter) is part of "the core stuff of git", and do not see a problem; such a move may help both subtree and libgit2. Over a much longer timeperiod, I wouldn't be surprised if some "core stuff" gets reimplemented on top of libgit2 and distributed as part of the git-core. There will be substantial integration and logistics hassles ahead of us before that can happen, though. E.g. we could point at libgit2 as our submodule, but that is not the only way to make git depend on libgit2; it could just be a Build-Depends like we depend on libz. Looking at the build dependency of libgit2 itself, I do not think tighter integration of the libgit2 itself into the git-core is not likely to happen very soon, and also is not necessarily a good thing to do. -- 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] branch -v: align even when the first column is in UTF-8
Erik Faye-Lund writes: > On Fri, Aug 24, 2012 at 4:17 PM, Nguyễn Thái Ngọc Duy > wrote: >> 1 tập tin đã bị thay đổi, 5 được thêm vào(+), 3 bị xóa(-) > > Huh? Perhaps format-patch should always use C locale. -- 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: git checkout -t -B
乙酸鋰 writes: > git checkout -t -B origin/abcde > works > > but > git checkout -B -t origin/abcde > does not. > > Could you document the order of parameters or fix the behaviour? It is crystal clear that -b/-B/--orphan must be followed by the name of the branch you are creating from the SYNOPSIS section of the documentation. NAME git-checkout - Checkout a branch or paths to the working tree SYNOPSIS [verse] ... 'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] ] [ and start it at ; see linkgit:git-branch[1] for details. as if it and are freestanding arguments. I think we should describe the option like this: -b :: Create a new branch named and start it at ; see linkgit:git-branch[1] for details. The description for "-B" and "--orphan" options share the same issue. I suspect that documentation for other commands may share this issue. It would be good if somebody can check the option description section and make sure there is no discrepancy like this by comparing it to the SYNOPSIS section (or "git cmd -h") for all manual pages. I'll patch only "git-checkout.txt" myself for now; hint, hint. 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: Re*: mergetool: support --tool-help option like difftool does
Am 24.08.2012 10:31, schrieb David Aguilar: > On Thu, Aug 23, 2012 at 10:39 AM, Junio C Hamano wrote: >> David Aguilar writes: >>> Would the ability to resolve the various merge situations using >>> the command-line be a wanted addition? >>> >>> This would let a submodule or deleted/modified encountering >>> user do something like: >>> >>> $ git mergetool --theirs -- submodule >>> >>> ...and not have to remember the various git commands that it runs. >> >> Does it have to run various git commands? For a normal path, all it >> needs to do is "git checkout --theirs $path", no? >> >> What does it mean to resolve a conflicted merge of a gitlink to take >> "theirs"? We obviously would want to point the resolved gitlink at >> the submodule commit their side wants in the resulting index but what, >> if any, should we do to the submodule itself? >> >> Stepping back a bit, if there is no conflict, and as a result of a >> clean merge (this applies to the case where you check out another >> branch that has different commit at the submodule path), if gitlink >> changed to point at a different commit in the submodule, what should >> happen? >> >> If you start from a clean working tree, with your gitlink pointing >> at the commit that matches HEAD in the submodule, and if the working >> tree of the submodule does not have any local modification, it may >> be ideal to check out the new commit in the submodule (are there >> cases where "git checkout other_branch" in the superproject does not >> want to touch the submodule working tree?). >> >> There are cases where it is not possible; checking out the new >> commit in the submodule working tree may not succeed due to local >> modifications. But is that kind of complication limited to the >> merge resolution case? Isn't it shared with normal "switching >> branches" case as well? >> >> If so, it could be that your "git mergetool --theirs -- submodule" >> is working around a wrong problem, and the right solution may be to >> make "git checkout --theirs -- $path" to always do an appropriate >> thing regardless of what kind of object $path is, no? > > True. I agree. > Admittedly, I'm not a heavy submodule user myself so I > tried crafting the directory vs submodule conflict to see > what the usability is like. > > checkout --theirs and --ours could learn a few tricks. Me thinks that after I successfully taught checkout to properly recurse into submodule work trees too it should know all those tricks. In my current version it can handle directory/submodule conversions in both directions, this should be sufficient to make "checkout --theirs/--ours" work properly. Note to self: add tests for that. > When trying to choose the directory in that situation > I had to had to "git rm --cached" the submodule path > so that git would recognize that there was no longer a conflict. > > That makes sense to me because I was following along by > reading the mergetool code, but I don't think most users > would know to "git rm" a path which they intend to keep. True. But a submodule recursing checkout would do the right thing here too. > Afterwards, the .git file is left behind, which could cause > problems elsewhere since we really don't want a .git file > in that situation. Hmm, either you remove all the files tracked in the submodule together with the gitfile or you'll possibly have former submodule files lying around there too. Recursive checkout will do all that for you. > I'm not even sure what to do about the > .gitmodules file either. Maybe we should issue a warning when the .gitmodules file is not consistent with the [non]existence of a submodule in the work tree? > That said, this really isn't an issue, per say. > I first poked at it because I noticed that mergetool > still needed stdin for some things. > > It's certainly an edge case, and perhaps this just shows > that mergetool really is the right porcelain for the job > when a user runs into these types of conflicts > (the stdin thing really isn't an issue). It looks to me as if the submodule/directory conflict can be handled by a recursive checkout without having to add something to mergetool. -- 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] doc: "git checkout -b/-B/--orphan" always takes a branch name
While the synopsis section makes it clear that the new branch name
is the parameter to these flags, the option description did not.
Signed-off-by: Junio C Hamano
---
Documentation/git-checkout.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..e3270cd 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -84,11 +84,11 @@ entries; instead, unmerged entries are ignored.
When checking out paths from the index, check out stage #2
('ours') or #3 ('theirs') for unmerged paths.
--b::
+-b ::
Create a new branch named and start it at
; see linkgit:git-branch[1] for details.
--B::
+-B ::
Creates the branch and start it at ;
if it already exists, then reset it to . This is
equivalent to running "git branch" with "-f"; see
@@ -124,7 +124,7 @@ explicitly give a name with '-b' in such a case.
is not a branch name. See the "DETACHED HEAD" section
below for details.
---orphan::
+--orphan ::
Create a new 'orphan' branch, named , started from
and switch to it. The first commit made on this
new branch will have no parents and it will be the root of a new
--
1.7.12.252.gef4e272
--
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: misleading diff-hunk header
Stefano Lattarini writes:
> On 08/25/2012 02:56 PM, Tim Chase wrote:
>> On 08/24/12 23:29, Junio C Hamano wrote:
>>> Tim Chase writes:
If the documented purpose of "diff -p" (and by proxy
diff.{type}.xfuncname) is to show the name of the *function*
containing the changed lines,
>>>
>>> Yeah, the documentation is misleading, but I do not offhand think of
>>> a better phrasing. Perhaps you could send in a patch to improve it.
>>>
>>> How does GNU manual explain the option?
>>
>> Tersely. :-)
>>
>>-p --show-c-function
>> Show which C function each change is in.
>>
> That's in the manpage, which is basically just a copy of the output from
> "diff --help". In the texinfo manual (which is the real documentation),
> there are additional explanations, saying, among other things:
>
> To show in which functions differences occur for C and similar languages,
> you can use the --show-c-function (-p) option. This option automatically
> defaults to the context output format (see Context Format), with the
> default number of lines of context. You can override that number with
> -C lines elsewhere in the command line. You can override both the format
> and the number with -U lines elsewhere in the command line.
> The -p option is equivalent to -F '^[[:alpha:]$_]' if the unified format
> is specified, otherwise -c -F '^[[:alpha:]$_]' (see Specified Headings).
> GNU diff provides this option for the sake of convenience.
> ...
> The --show-function-line (-F) option finds the nearest unchanged line
> that precedes each hunk of differences and matches the given regular
> expression.
So in short, if we say "Show which function each change is in" in
the documentation, that is consistent with what GNU does and that is
described consistently with what GNU says, modulo that we obviously
do more than "C" via the diff..xfuncname mechanism.
We already document diff..xfuncname as determining "the hunk
header", and the documentation that is referred to (i.e. gitattributes)
shows the shape of a hunk in the "diff" output:
@@ -k,l +n,m @@ TEXT
This is called a 'hunk header'. The "TEXT" portion is by default a line
that begins with an alphabet, an underscore or a dollar sign; this
matches what GNU 'diff -p' output uses.
and then later says:
Then, you would define a "diff.tex.xfuncname" configuration to
specify a regular expression that matches a line that you would
want to appear as the hunk header "TEXT".
Honestly, I do not offhand see an obvious and possible room for vast
improvement over what we already have, so my RFH to Tim that appears
at the beginning of what you quoted from my previous message still
stands ;-).
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: libgit2 status
Junio C Hamano writes: > Looking at the build dependency of libgit2 itself, I do not think > tighter integration of the libgit2 itself into the git-core is not > likely to happen very soon, and also is not necessarily a good thing > to do. Obviously I meant "I think it is not likely to happen and is not necessaryly a good thing". Dumb double-negatives. -- 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: t9020 broken on pu ?
> The reason is that contrib/svn-fe, where remote-svn is in, is not yet built > automatically by the toplevel makefile, so the remote helper can't be found. > If you build it manually it should work. > Working on it .. Hi Florian, the compilation as such is started, but gives problems on Mac OS X: CC remote-testsvn.o remote-testsvn.c: In function ‘check_or_regenerate_marks’: remote-testsvn.c:142: warning: implicit declaration of function ‘getline’ CC vcs-svn/line_buffer.o CC vcs-svn/sliding_window.o CC vcs-svn/fast_export.o CC vcs-svn/svndiff.o CC vcs-svn/svndump.o AR vcs-svn/lib.a LINK git-remote-testsvn Undefined symbols: "_getline", referenced from: _cmd_import in remote-testsvn.o (maybe you meant: _strbuf_getline) ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [git-remote-testsvn] Error 1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9020 broken on pu ?
On Sunday 26 August 2012 21:32:58 Torsten Bögershausen wrote: > > The reason is that contrib/svn-fe, where remote-svn is in, is not yet > > built automatically by the toplevel makefile, so the remote helper can't > > be found. If you build it manually it should work. > > Working on it .. > > Hi Florian, > > the compilation as such is started, but gives problems on Mac OS X: > > CC remote-testsvn.o > remote-testsvn.c: In function ‘check_or_regenerate_marks’: > remote-testsvn.c:142: warning: implicit declaration of function ‘getline’ > CC vcs-svn/line_buffer.o > CC vcs-svn/sliding_window.o > CC vcs-svn/fast_export.o > CC vcs-svn/svndiff.o > CC vcs-svn/svndump.o > AR vcs-svn/lib.a > LINK git-remote-testsvn > Undefined symbols: > "_getline", referenced from: > _cmd_import in remote-testsvn.o > (maybe you meant: _strbuf_getline) > ld: symbol(s) not found > collect2: ld returned 1 exit status > make: *** [git-remote-testsvn] Error 1 Seems you also don't have getline on Mac OS X. Others already reported that this function may not be available on some platforms. Will be replaced in the next reroll. Thanks for your reviews! I'm still hesitating to send a new version out, as long as new fixups come in continuously. -- Florian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/4] wincred: port to generic credential helper (UNTESTED)
From: "Philipp A. Hartmann"
This patch is an experiment to port the wincred helper
to the generic implementation. As of know, it is
completely untested.
In addition to porting the helper to the generic API,
this patch clears up all passwords from memory, which
reduces the total amount to saved lines.
Signed-off-by: Philipp A. Hartmann
---
The porting was fairly easy, but due to the lack of a testing
platform, it is completely untested.
Erik: Can you try to have look?
The patch is against the current 'next' with my series applied.
A github repository with all the helpers can also be found at
git://github.com/pah/git-credential-helper.git
In order to keep things simple, I decided to add the setup of
the binary pipes in the generic helper's main() already. This
was the only platform-specific change needed in the helper.
Other changes to the generic helper were
- the addition of an URI field in the credential struct
(can be reused in the GNOME implementation)
- the early stop in case of incomplete credentials
(simplifies handling this case in all three helpers)
The overall code reduction could be increased (also in
the osxkeychain helper), if we add init/cleanup functions
to the generic helper. I skipped this for now.
Some additions to the wincred code were needed (or at least
motivated) to clean up the memory correctly. Especially for
the password strings, this seems to be a sane thing to do.
Since the wincred helper duplicates parts of these buffers to
comply with the wchar_t-based Windows API, this required more
manual free's than in the other helpers.
In summary, although the platform and API looked fairly different
from the other platforms, the generic code could be used without
too much pain.
Thanks,
Philipp
contrib/credential/helper/credential_helper.c | 41 ++-
contrib/credential/helper/credential_helper.h |3 +-
contrib/credential/wincred/.gitignore |1 +
contrib/credential/wincred/Makefile| 19 +-
.../credential/wincred/git-credential-wincred.c| 310 +---
5 files changed, 199 insertions(+), 175 deletions(-)
create mode 100644 contrib/credential/wincred/.gitignore
diff --git a/contrib/credential/helper/credential_helper.c
b/contrib/credential/helper/credential_helper.c
index e99c2ec..5ddf5a5 100644
--- a/contrib/credential/helper/credential_helper.c
+++ b/contrib/credential/helper/credential_helper.c
@@ -11,6 +11,11 @@
#include
+#ifdef WIN32
+#include
+#include
+#endif
+
void credential_init(struct credential *c)
{
memset(c, 0, sizeof(*c));
@@ -23,6 +28,7 @@ void credential_clear(struct credential *c)
free(c->path);
free(c->username);
free_password(c->password);
+ free(c->uri);
credential_init(c);
}
@@ -79,6 +85,29 @@ int credential_read(struct credential *c)
* learn new lines, and the helpers are updated to match.
*/
}
+
+ /* Rebuild URI from parts */
+ *buf = '\0';
+ if (c->protocol) {
+ strncat(buf, c->protocol, sizeof(buf));
+ strncat(buf, "://", sizeof(buf));
+ }
+ if (c->username) {
+ strncat(buf, c->username, sizeof(buf));
+ strncat(buf, "@", sizeof(buf));
+ }
+ if (c->host)
+ strncat(buf, c->host, sizeof(buf));
+ if (c->port) {
+ value = buf + strlen(buf);
+ snprintf(value, sizeof(buf)-(value-buf), ":%hd", c->port);
+ }
+ if (c->path) {
+ strncat(buf, "/", sizeof(buf));
+ strncat(buf, c->path, sizeof(buf));
+ }
+ c->uri = xstrdup(buf);
+
return 0;
}
@@ -126,6 +155,12 @@ int main(int argc, char *argv[])
goto out;
}
+#ifdef WIN32
+ /* git on Windows uses binary pipes to avoid CRLF-issues */
+ _setmode(_fileno(stdin), _O_BINARY);
+ _setmode(_fileno(stdout), _O_BINARY);
+#endif
+
/* lookup operation callback */
while(try_op->name && strcmp(argv[1], try_op->name))
try_op++;
@@ -138,11 +173,15 @@ int main(int argc, char *argv[])
if(ret)
goto out;
+ if (!cred.protocol || !(cred.host || cred.path)) {
+ ret = EXIT_FAILURE;
+ goto out;
+ }
+
/* perform credential operation */
ret = (*try_op->op)(&cred);
credential_write(&cred);
-
out:
credential_clear(&cred);
return ret;
diff --git a/contrib/credential/helper/credential_helper.h
b/contrib/credential/helper/credential_helper.h
index 76b6e50..822b471 100644
--- a/contrib/credential/helper/credential_helper.h
+++ b/contrib/credential/helper/credential_helper.h
@@ -25,10 +25,11 @@ struct credential
char *path;
char *username;
char *password;
+ char *uri; /* ://[username@][host[:port]][/path]
*/
Inverting the --committer option to git-log with v1.7.5.4
I wanted to search a repository for all commits that were *not* committed by a particular person. While I eventually managed to build a regular expression that worked for my limited use case, it seems like there ought to be a more sensible way to find the data I'm looking for. As an example, this didn't work: git log --format=fuller --not --committer="Foo Bar" Apparently, the --not flag doesn't invert the grep for committer; it only inverts the revision specifiers. It seems like there should be something that works like grep's --invert-match option, but I couldn't find it. On the other hand, this will work, but is painful and error-prone to build if you have a lot of committers: # Assuming the address is foo@example.com git log --format=fuller --committer='[^r]@' Is there currently a better way to request logs for "everyone but committer x" in Git? If not, is this a feature that someone who understands the Git source might find useful enough to add in? -- 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: Inverting the --committer option to git-log with v1.7.5.4
"Todd A. Jacobs" writes: > Is there currently a better way to request logs for "everyone but > committer x" in Git? If not, is this a feature that someone who > understands the Git source might find useful enough to add in? No, there is not. I wouldn't comment on the potential usefulness of such a feature, but I do not think there is anything fundamentally wrong to enhance the limited form of "--grep/--author/--committer" the "log" family of commands currently support to a full "grep boolean expressions" that is supported by "git grep" command to let you say something like: git log --author=rezrov --grep=nitfol \ --and \( --committer=xyzzy --or --committer=frotz \) \ --all --not master to grab commits from all topics that are not yet merged to 'master', authored by rezrov and talks about nitfol, that are committed either by xyzzy or frotz. The command line syntax to integrate the "grep boolean expressions" needs to be carefully thought out, as "--not" on the "log" family of commands is already used to mean something entirely different (it is a revision range operator), though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/4 v2] wincred: port to generic credential helper (UNTESTED)
From: "Philipp A. Hartmann"
This patch is an experiment to port the wincred helper
to the generic implementation. As of know, it is
completely untested.
In addition to porting the helper to the generic API,
this patch clears up all passwords from memory, which
reduces the total amount to saved lines.
This version adds the missing xmalloc() implementation.
Signed-off-by: Philipp A. Hartmann
---
The previous version of the patch somehow lacked the xmalloc
implementation moved to credential_helper.h. Sorry for the
inconvenience.
Apart from being still untested, this version at least matches
my tree at git://github.com/pah/git-credential-helper.git.
contrib/credential/helper/credential_helper.c | 41 ++-
contrib/credential/helper/credential_helper.h | 14 +-
contrib/credential/wincred/.gitignore |1 +
contrib/credential/wincred/Makefile| 19 +-
.../credential/wincred/git-credential-wincred.c| 310 +---
5 files changed, 210 insertions(+), 175 deletions(-)
create mode 100644 contrib/credential/wincred/.gitignore
diff --git a/contrib/credential/helper/credential_helper.c
b/contrib/credential/helper/credential_helper.c
index e99c2ec..5ddf5a5 100644
--- a/contrib/credential/helper/credential_helper.c
+++ b/contrib/credential/helper/credential_helper.c
@@ -11,6 +11,11 @@
#include
+#ifdef WIN32
+#include
+#include
+#endif
+
void credential_init(struct credential *c)
{
memset(c, 0, sizeof(*c));
@@ -23,6 +28,7 @@ void credential_clear(struct credential *c)
free(c->path);
free(c->username);
free_password(c->password);
+ free(c->uri);
credential_init(c);
}
@@ -79,6 +85,29 @@ int credential_read(struct credential *c)
* learn new lines, and the helpers are updated to match.
*/
}
+
+ /* Rebuild URI from parts */
+ *buf = '\0';
+ if (c->protocol) {
+ strncat(buf, c->protocol, sizeof(buf));
+ strncat(buf, "://", sizeof(buf));
+ }
+ if (c->username) {
+ strncat(buf, c->username, sizeof(buf));
+ strncat(buf, "@", sizeof(buf));
+ }
+ if (c->host)
+ strncat(buf, c->host, sizeof(buf));
+ if (c->port) {
+ value = buf + strlen(buf);
+ snprintf(value, sizeof(buf)-(value-buf), ":%hd", c->port);
+ }
+ if (c->path) {
+ strncat(buf, "/", sizeof(buf));
+ strncat(buf, c->path, sizeof(buf));
+ }
+ c->uri = xstrdup(buf);
+
return 0;
}
@@ -126,6 +155,12 @@ int main(int argc, char *argv[])
goto out;
}
+#ifdef WIN32
+ /* git on Windows uses binary pipes to avoid CRLF-issues */
+ _setmode(_fileno(stdin), _O_BINARY);
+ _setmode(_fileno(stdout), _O_BINARY);
+#endif
+
/* lookup operation callback */
while(try_op->name && strcmp(argv[1], try_op->name))
try_op++;
@@ -138,11 +173,15 @@ int main(int argc, char *argv[])
if(ret)
goto out;
+ if (!cred.protocol || !(cred.host || cred.path)) {
+ ret = EXIT_FAILURE;
+ goto out;
+ }
+
/* perform credential operation */
ret = (*try_op->op)(&cred);
credential_write(&cred);
-
out:
credential_clear(&cred);
return ret;
diff --git a/contrib/credential/helper/credential_helper.h
b/contrib/credential/helper/credential_helper.h
index 76b6e50..7e73fc6 100644
--- a/contrib/credential/helper/credential_helper.h
+++ b/contrib/credential/helper/credential_helper.h
@@ -25,10 +25,11 @@ struct credential
char *path;
char *username;
char *password;
+ char *uri; /* ://[username@][host[:port]][/path]
*/
};
#define CREDENTIAL_INIT \
- { NULL,NULL,0,NULL,NULL,NULL }
+ { NULL,NULL,0,NULL,NULL,NULL,NULL }
void credential_init(struct credential *c);
void credential_clear(struct credential *c);
@@ -104,6 +105,17 @@ static inline void die_errno(int err)
exit(EXIT_FAILURE);
}
+static inline void *xmalloc(size_t size)
+{
+ void *ret = malloc(size);
+ if (!ret && !size)
+ ret = malloc(1);
+ if (!ret)
+die_errno(errno);
+
+ return ret;
+}
+
static inline char *xstrdup(const char *str)
{
char *ret = strdup(str);
diff --git a/contrib/credential/wincred/.gitignore
b/contrib/credential/wincred/.gitignore
new file mode 100644
index 000..4780e4e
--- /dev/null
+++ b/contrib/credential/wincred/.gitignore
@@ -0,0 +1 @@
+git-credential-wincred.exe
diff --git a/contrib/credential/wincred/Makefile
b/contrib/credential/wincred/Makefile
index bad45ca..ee7a8ef 100644
--- a/contrib/credential/wincred/Makefile
+++ b/contrib/credential/wincred/Makefile
@@ -1,4 +1,5 @@
-all: git-credential-wincred.exe
+MAIN:=git-credential-wincred
+al
[PATCH v2] test: set the realpath of CWD as TRASH_DIRECTORY
Some testcases will fail if current work directory is on a symlink.
symlink$ sh ./t4035-diff-quiet.sh
$ sh ./t4035-diff-quiet.sh --root=/symlink
$ TEST_OUTPUT_DIRECTORY=/symlink sh ./t4035-diff-quiet.sh
This is because the realpath of ".git" directory will be returned when
running the command 'git rev-parse --git-dir' in a subdir of the work
tree, and the realpath may not equal to "$TRASH_DIRECTORY".
In this fix, "$TRASH_DIRECTORY" is determined right after the realpath
of CWD is resolved.
Signed-off-by: Jiang Xin
Reported-by: Michael Haggerty
Signed-off-by: Jiang Xin
---
t/test-lib.sh | 9 +
1 个文件被修改，插入 5 行(+)，删除 4 行(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c42..9a59ca8 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -531,17 +531,17 @@ fi
test="trash directory.$(basename "$0" .sh)"
test -n "$root" && test="$root/$test"
case "$test" in
-/*) TRASH_DIRECTORY="$test" ;;
- *) TRASH_DIRECTORY="$TEST_OUTPUT_DIRECTORY/$test" ;;
+/*) ;;
+ *) test="$TEST_OUTPUT_DIRECTORY/$test" ;;
esac
-test ! -z "$debug" || remove_trash=$TRASH_DIRECTORY
+test ! -z "$debug" || remove_trash=$test
rm -fr "$test" || {
GIT_EXIT_OK=t
echo >&5 "FATAL: Cannot prepare test area"
exit 1
}
-HOME="$TRASH_DIRECTORY"
+HOME="$test"
export HOME
if test -z "$TEST_NO_CREATE_REPO"; then
@@ -552,6 +552,7 @@ fi
# Use -P to resolve symlinks in our working directory so that the cwd
# in subprocesses like git equals our $PWD (for pathname comparisons).
cd -P "$test" || exit 1
+TRASH_DIRECTORY="$(pwd)"
this_test=${0##*/}
this_test=${this_test%%-*}
--
1.7.12.92.gaa91cb5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Gettext poison fixes
Update patch 5/7 (Fix tests under GETTEXT_POISON on pack-object) and patch 6/7 (Fix tests under GETTEXT_POISON on git-remote) in this new series of patches. Not much to say. With this series, the test suite should pass again with gettext poison on. It's independent with the parseopt-i18n series I sent yesterday as the test suite was broken even before. Jiang Xin (7): Fix tests under GETTEXT_POISON on relative dates Fix tests under GETTEXT_POISON on git-stash Fix tests under GETTEXT_POISON on diffstat Fix tests under GETTEXT_POISON on git-apply Fix tests under GETTEXT_POISON on pack-object Fix tests under GETTEXT_POISON on git-remote Fix tests under GETTEXT_POISON on parseopt t/t0006-date.sh | 2 +- t/t0040-parse-options.sh| 34 +- t/t1300-repo-config.sh | 2 +- t/t1502-rev-parse-parseopt.sh | 2 +- t/t2006-checkout-index-basic.sh | 4 ++-- t/t2107-update-index-basic.sh | 4 ++-- t/t3004-ls-files-basic.sh | 4 ++-- t/t3200-branch.sh | 4 ++-- t/t3501-revert-cherry-pick.sh | 4 ++-- t/t3903-stash.sh| 2 +- t/t4006-diff-mode.sh| 8 t/t4012-diff-binary.sh | 4 ++-- t/t4120-apply-popt.sh | 4 ++-- t/t4133-apply-filenames.sh | 4 ++-- t/t4200-rerere.sh | 4 ++-- t/t4202-log.sh | 2 +- t/t4205-log-pretty-formats.sh | 4 ++-- t/t5300-pack-object.sh | 4 ++-- t/t5505-remote.sh | 28 +--- t/t5530-upload-pack-error.sh| 4 ++-- t/t6500-gc.sh | 4 ++-- t/t7508-status.sh | 2 +- t/t7600-merge.sh| 2 +- 23 files changed, 83 insertions(+), 53 deletions(-) -- 1.7.12.92.gaa91cb5 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] Fix tests under GETTEXT_POISON on relative dates
Use a i18n-specific test_i18ncmp in t/t0006-data.sh for relative dates
tests. This issue was was introduced in v1.7.10-230-g7d29a:
7d29a i18n: mark relative dates for translation
and been broken under GETTEXT_POISON=YesPlease since.
Signed-off-by: Jiang Xin
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t0006-date.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index 1d29..e53cf 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -11,7 +11,7 @@ check_show() {
echo "$t -> $2" >expect
test_expect_${3:-success} "relative date ($2)" "
test-date show $t >actual &&
- test_cmp expect actual
+ test_i18ncmp expect actual
"
}
--
1.7.12.92.gaa91cb5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] Fix tests under GETTEXT_POISON on git-stash
Use i18n-specific test functions in test scripts for git-stash. This issue was was introduced in v1.7.4.1-119-g355ec: 355ec i18n: git-status basic messages and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t3903-stash.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh index cd0426..5dfbd 100755 --- a/t/t3903-stash.sh +++ b/t/t3903-stash.sh @@ -610,7 +610,7 @@ test_expect_success 'stash apply shows status same as git status (relative to cu git stash apply ) | sed -e 1,2d >actual && # drop "Saved..." and "HEAD is now..." - test_cmp expect actual + test_i18ncmp expect actual ' cat > expect << EOF -- 1.7.12.92.gaa91cb5 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] Fix tests under GETTEXT_POISON on diffstat
Use i18n-specific test functions in test scripts for diffstat.
This issue was was introduced in v1.7.9-1-g7f814:
7f814 Use correct grammar in diffstat summary line
and been broken under GETTEXT_POISON=YesPlease since.
Signed-off-by: Jiang Xin
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t4006-diff-mode.sh | 8
t/t4202-log.sh| 2 +-
t/t4205-log-pretty-formats.sh | 4 ++--
t/t7508-status.sh | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t4006-diff-mode.sh b/t/t4006-diff-mode.sh
index 7a3e1..3d4b1 100755
--- a/t/t4006-diff-mode.sh
+++ b/t/t4006-diff-mode.sh
@@ -36,24 +36,24 @@ test_expect_success '--stat output after text chmod' '
test_chmod -x rezrov &&
echo " 0 files changed" >expect &&
git diff HEAD --stat >actual &&
- test_cmp expect actual
+ test_i18ncmp expect actual
'
test_expect_success '--shortstat output after text chmod' '
git diff HEAD --shortstat >actual &&
- test_cmp expect actual
+ test_i18ncmp expect actual
'
test_expect_success '--stat output after binary chmod' '
test_chmod +x binbin &&
echo " 0 files changed" >expect &&
git diff HEAD --stat >actual &&
- test_cmp expect actual
+ test_i18ncmp expect actual
'
test_expect_success '--shortstat output after binary chmod' '
git diff HEAD --shortstat >actual &&
- test_cmp expect actual
+ test_i18ncmp expect actual
'
test_done
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 71be5..31869 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -803,7 +803,7 @@ sanitize_output () {
test_expect_success 'log --graph with diff and stats' '
git log --graph --pretty=short --stat -p >actual &&
sanitize_output >actual.sanitized expected &&
git log -z --stat --pretty="format:%s" >actual &&
- test_cmp expected actual
+ test_i18ncmp expected actual
'
test_expect_failure 'NUL termination with --stat' '
@@ -96,7 +96,7 @@ test_expect_failure 'NUL termination with --stat' '
stat1_part=$(git diff --stat --root HEAD^) &&
printf "add bar\n$stat0_part\n\0initial\n$stat1_part\n\0" >expected &&
git log -z --stat --pretty="tformat:%s" >actual &&
- test_cmp expected actual
+ test_i18ncmp expected actual
'
test_done
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index c206f..e313e 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -80,7 +80,7 @@ test_expect_success 'status --column' '
# dir1/untracked dir2/untracked untracked
# dir2/modified output
EOF
- test_cmp expect output
+ test_i18ncmp expect output
'
cat >expect <<\EOF
--
1.7.12.92.gaa91cb5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/7] Fix tests under GETTEXT_POISON on git-apply
Use i18n-specific test functions in test scripts for git-apply. This issue was was introduced in the following commits: de373 i18n: apply: mark parseopt strings for translation 3638e i18n: apply: mark strings for translation and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t4012-diff-binary.sh | 4 ++-- t/t4120-apply-popt.sh | 4 ++-- t/t4133-apply-filenames.sh | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t4012-diff-binary.sh b/t/t4012-diff-binary.sh index ec4de..1215a 100755 --- a/t/t4012-diff-binary.sh +++ b/t/t4012-diff-binary.sh @@ -63,7 +63,7 @@ test_expect_success 'apply --numstat understands diff --binary format' ' # apply needs to be able to skip the binary material correctly # in order to report the line number of a corrupt patch. -test_expect_success 'apply detecting corrupt patch correctly' ' +test_expect_success C_LOCALE_OUTPUT 'apply detecting corrupt patch correctly' ' git diff >output && sed -e "s/-CIT/xCIT/" broken && test_must_fail git apply --stat --summary broken 2>detected && @@ -73,7 +73,7 @@ test_expect_success 'apply detecting corrupt patch correctly' ' test "$detected" = xCIT ' -test_expect_success 'apply detecting corrupt patch correctly' ' +test_expect_success C_LOCALE_OUTPUT 'apply detecting corrupt patch correctly' ' git diff --binary | sed -e "s/-CIT/xCIT/" >broken && test_must_fail git apply --stat --summary broken 2>detected && detected=`cat detected` && diff --git a/t/t4120-apply-popt.sh b/t/t4120-apply-popt.sh index a33d5..c5fec 100755 --- a/t/t4120-apply-popt.sh +++ b/t/t4120-apply-popt.sh @@ -32,7 +32,7 @@ test_expect_success 'apply git diff with -p2' ' test_expect_success 'apply with too large -p' ' cp file1.saved file1 && test_must_fail git apply --stat -p3 patch.file 2>err && - grep "removing 3 leading" err + test_i18ngrep "removing 3 leading" err ' test_expect_success 'apply (-p2) traditional diff with funny filenames' ' @@ -54,7 +54,7 @@ test_expect_success 'apply (-p2) traditional diff with funny filenames' ' test_expect_success 'apply with too large -p and fancy filename' ' cp file1.saved file1 && test_must_fail git apply --stat -p3 patch.escaped 2>err && - grep "removing 3 leading" err + test_i18ngrep "removing 3 leading" err ' test_expect_success 'apply (-p2) diff, mode change only' ' diff --git a/t/t4133-apply-filenames.sh b/t/t4133-apply-filenames.sh index 94da9..2ecb4 100755 --- a/t/t4133-apply-filenames.sh +++ b/t/t4133-apply-filenames.sh @@ -30,9 +30,9 @@ EOF test_expect_success 'apply diff with inconsistent filenames in headers' ' test_must_fail git apply bad1.patch 2>err && - grep "inconsistent new filename" err && + test_i18ngrep "inconsistent new filename" err && test_must_fail git apply bad2.patch 2>err && - grep "inconsistent old filename" err + test_i18ngrep "inconsistent old filename" err ' test_done -- 1.7.12.92.gaa91cb5 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] Fix tests under GETTEXT_POISON on pack-object
Use i18n-specific test functions in test scripts for pack-object. This issue was was introduced in v1.7.10.2-556-g46140: 46140 index-pack: use streaming interface for collision test on large blobs cf2ba pack-objects: use streaming interface for reading large loose blobs and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t5300-pack-object.sh | 4 ++-- t/t5530-upload-pack-error.sh | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh index 2e52..a07c8 100755 --- a/t/t5300-pack-object.sh +++ b/t/t5300-pack-object.sh @@ -416,11 +416,11 @@ test_expect_success \ test_expect_success \ 'make sure index-pack detects the SHA1 collision' \ 'test_must_fail git index-pack -o bad.idx test-3.pack 2>msg && - grep "SHA1 COLLISION FOUND" msg' + test_i18ngrep "SHA1 COLLISION FOUND" msg' test_expect_success \ 'make sure index-pack detects the SHA1 collision (large blobs)' \ 'test_must_fail git -c core.bigfilethreshold=1 index-pack -o bad.idx test-3.pack 2>msg && - grep "SHA1 COLLISION FOUND" msg' + test_i18ngrep "SHA1 COLLISION FOUND" msg' test_done diff --git a/t/t5530-upload-pack-error.sh b/t/t5530-upload-pack-error.sh index 6b2a5f..c983d 100755 --- a/t/t5530-upload-pack-error.sh +++ b/t/t5530-upload-pack-error.sh @@ -35,8 +35,8 @@ test_expect_success 'upload-pack fails due to error in pack-objects packing' ' printf "0032want %s\n0009done\n" \ $(git rev-parse HEAD) >input && test_must_fail git upload-pack . /dev/null 2>output.err && - grep "unable to read" output.err && - grep "pack-objects died" output.err + test_i18ngrep "unable to read" output.err && + test_i18ngrep "pack-objects died" output.err ' test_expect_success 'corrupt repo differently' ' -- 1.7.12.92.gaa91cb5 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] Fix tests under GETTEXT_POISON on git-remote
Use i18n-specific test functions in test scripts for git-remote. This issue was was introduced in v1.7.10-233-gbb16d5: bb16d5 i18n: remote: mark strings for translation and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t5505-remote.sh | 28 +--- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index e8af6..7f0cb 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -52,7 +52,7 @@ test_expect_success setup ' ' -test_expect_success 'remote information for the origin' ' +test_expect_success C_LOCALE_OUTPUT 'remote information for the origin' ' ( cd test && tokens_match origin "$(git remote)" && @@ -66,8 +66,6 @@ test_expect_success 'add another remote' ' cd test && git remote add -f second ../two && tokens_match "origin second" "$(git remote)" && - check_remote_track origin master side && - check_remote_track second master side another && check_tracking_branch second master side another && git for-each-ref "--format=%(refname)" refs/remotes | sed -e "/^refs\/remotes\/origin\//d" \ @@ -77,6 +75,14 @@ test_expect_success 'add another remote' ' ) ' +test_expect_success C_LOCALE_OUTPUT 'add another remote' ' +( + cd test && + check_remote_track origin master side && + check_remote_track second master side another && +) +' + test_expect_success 'remote forces tracking branches' ' ( cd test && @@ -95,7 +101,7 @@ test_expect_success 'remove remote' ' ) ' -test_expect_success 'remove remote' ' +test_expect_success C_LOCALE_OUTPUT 'remove remote' ' ( cd test && tokens_match origin "$(git remote)" && @@ -131,8 +137,8 @@ EOF git remote rm oops 2>actual2 && git branch -d foobranch && git tag -d footag && - test_cmp expect1 actual1 && - test_cmp expect2 actual2 + test_i18ncmp expect1 actual1 && + test_i18ncmp expect2 actual2 ) ' @@ -192,7 +198,7 @@ test_expect_success 'show' ' git config --add remote.two.push refs/heads/master:refs/heads/another && git remote show origin two > output && git branch -d rebase octopus && -test_cmp expect output) +test_i18ncmp expect output) ' cat > test/expect << EOF @@ -217,7 +223,7 @@ test_expect_success 'show -n' ' cd test && git remote show -n origin > output && mv ../one.unreachable ../one && -test_cmp expect output) +test_i18ncmp expect output) ' test_expect_success 'prune' ' @@ -255,7 +261,7 @@ EOF test_expect_success 'set-head --auto fails w/multiple HEADs' ' (cd test && test_must_fail git remote set-head --auto two >output 2>&1 && - test_cmp expect output) + test_i18ncmp expect output) ' cat >test/expect&1 && - grep "has become dangling" err && + test_i18ngrep "has become dangling" err && : And the dangling symref will not cause other annoying errors && ( -- 1.7.12.92.gaa91cb5 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] Fix tests under GETTEXT_POISON on parseopt
Use i18n-specific test functions in test scripts for parseopt tests.
This issue was was introduced in v1.7.10.1-488-g54e6d:
54e6d i18n: parseopt: lookup help and argument translations when showing
usage
and been broken under GETTEXT_POISON=YesPlease since.
Signed-off-by: Jiang Xin
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t0040-parse-options.sh| 34 +-
t/t1300-repo-config.sh | 2 +-
t/t1502-rev-parse-parseopt.sh | 2 +-
t/t2006-checkout-index-basic.sh | 4 ++--
t/t2107-update-index-basic.sh | 4 ++--
t/t3004-ls-files-basic.sh | 4 ++--
t/t3200-branch.sh | 4 ++--
t/t3501-revert-cherry-pick.sh | 4 ++--
t/t4200-rerere.sh | 4 ++--
t/t6500-gc.sh | 4 ++--
t/t7600-merge.sh| 2 +-
11 files changed, 46 insertions(+), 22 deletions(-)
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index e3f35..244a4 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -51,7 +51,7 @@ EOF
test_expect_success 'test help' '
test_must_fail test-parse-options -h > output 2> output.err &&
test ! -s output.err &&
- test_cmp expect output
+ test_i18ncmp expect output
'
mv expect expect.err
@@ -79,6 +79,17 @@ check() {
test_cmp expect output
}
+check_i18n() {
+ what="$1" &&
+ shift &&
+ expect="$1" &&
+ shift &&
+ sed "s/^$what .*/$what $expect/" expect &&
+ test-parse-options $* >output 2>output.err &&
+ test ! -s output.err &&
+ test_i18ncmp expect output
+}
+
check_unknown() {
case "$1" in
--*)
@@ -92,6 +103,19 @@ check_unknown() {
test_cmp expect output.err
}
+check_unknown_i18n() {
+ case "$1" in
+ --*)
+ echo error: unknown option \`${1#--}\' >expect ;;
+ -*)
+ echo error: unknown switch \`${1#-}\' >expect ;;
+ esac &&
+ cat expect.err >>expect &&
+ test_must_fail test-parse-options $* >output 2>output.err &&
+ test ! -s output &&
+ test_i18ncmp expect output.err
+}
+
test_expect_success 'OPT_BOOL() #1' 'check boolean: 1 --yes'
test_expect_success 'OPT_BOOL() #2' 'check boolean: 1 --no-doubt'
test_expect_success 'OPT_BOOL() #3' 'check boolean: 1 -D'
@@ -104,8 +128,8 @@ test_expect_success 'OPT_BOOL() is idempotent #2' 'check
boolean: 1 -DB'
test_expect_success 'OPT_BOOL() negation #1' 'check boolean: 0 -D --no-yes'
test_expect_success 'OPT_BOOL() negation #2' 'check boolean: 0 -D
--no-no-doubt'
-test_expect_success 'OPT_BOOL() no negation #1' 'check_unknown --fear'
-test_expect_success 'OPT_BOOL() no negation #2' 'check_unknown --no-no-fear'
+test_expect_success 'OPT_BOOL() no negation #1' 'check_unknown_i18n --fear'
+test_expect_success 'OPT_BOOL() no negation #2' 'check_unknown_i18n
--no-no-fear'
test_expect_success 'OPT_BOOL() positivation' 'check boolean: 0 -D --doubt'
@@ -310,8 +334,8 @@ EOF
test_expect_success 'OPT_CALLBACK() and callback errors work' '
test_must_fail test-parse-options --no-length > output 2> output.err &&
- test_cmp expect output &&
- test_cmp expect.err output.err
+ test_i18ncmp expect output &&
+ test_i18ncmp expect.err output.err
'
cat > expect
