Re: [PATCH] l10n: de.po: translate 11 new messages
2013/1/28 Philip Oakley : > From: "Ralf Thielow" > Sent: Monday, January 28, 2013 5:55 PM > >> On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote: >>> >>> Ralf Thielow writes: >>> >>> > #: builtin/reset.c:275 >>> > -#, fuzzy, c-format >>> > +#, c-format >>> > msgid "Failed to resolve '%s' as a valid revision." >>> > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen." >>> > +msgstr "Konnte '%s' nicht als gültige Revision auflösen." >>> >>> You don't have "revision" in the glossary[1] yet. Wouldn't it be >>> appropriate to treat it as "commit", and translate as "Version" to >>> avoid >>> introducing yet another term? >>> >>> Or am I missing some subtle distinction between commit and revision? >>> >> >> I don't think there's a distinction. > > > It was a problem I had http://stackoverflow.com/a/11792712/717355 > answered as: > > See "SPECIFYING REVISIONS" of git rev-parse: > > A revision parameter typically, but not necessarily, names a commit > object. > It uses what is called an extended SHA1 syntax, [and includes] various ways > to spell object names. > > It had me confused for a while. > Thanks. So it would be a mistake to translate "revision" and "commit" with the same word. This would hide the special meaning of revision and the user wouldn't see that there's a difference. I'll amend the commit which unifys the translation of "revision" and "commit" in the way that "revision" will be translated as "Revision" in the whole file. I'll also update the glossary. >> Since we've already translated >> "revision" as "Revision" in a couple of other messages, I'll make a >> new "s/Revision/Version" commit on top. >> >>> Since it's only a single nit, feel free to add my ack when you >>> reroll: >>> >>> Acked-by: Thomas Rast >>> >>> >>> [1] https://github.com/ralfth/git-po-de/wiki/Glossary >>> >>> -- >>> Thomas Rast >>> trast@{inf,student}.ethz.ch >> >> -- > > Philip Oakley -- 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] The design of new pathspec features
Duy Nguyen writes: >> prefixq=$(git rev-parse --show-prefix-glob-quoted) >> pathspec="$prefixq$1" >> >> but magic that applies only to a substring may have other uses. > > Yeah, that simplifies things. Supporting applying magic over just > parts of the pathspec pattern sounds complex. Just a small > modification. That rev-parse needs to look at "$1" as well. Makes sense. More like prefix=$(git rev-parse --show-prefix) test -z "$prefix" || cd $(git rev-parse --show-cdup) ... pathspec=$(git rev-parse --prefix-pathspec "$prefix" "$1") git ls-files "$pathspec" which may take prefix="D*cumentati*n" (from the previous example), and the user may have given ":(icase)hell*.txt" to "$1". Ideally the scriptors shouldn't have to worry about how to add the prefix to the user supplied pathspec. -- 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] The design of new pathspec features
On Tue, Jan 29, 2013 at 12:33 PM, Junio C Hamano wrote: > Have you considered if it may be helpful to have a :(literal) magic > (or any magic in general) that applies only to the first N > characters of the pathspec pattern? Not user-driven. But the prefix part is :(literal)-applied. :(glob) is currently implemented this way, using nowildcard_len as you mentioned. :(icase) is more complicated and does not follow yet. > I personally think we do not need to support something like this: > > prefix=$(git rev-parse --show-prefix) > n=${#prefix} > pathspec=":(literal-$n)$prefix$1" > > but other aspiring Porcelain script writers may disagree and would > want to have it. We can always solve it by giving them an easy and > uniform way to get the glob-quoted version of prefix to solve this > particular issue, i.e. > > prefixq=$(git rev-parse --show-prefix-glob-quoted) > pathspec="$prefixq$1" > > but magic that applies only to a substring may have other uses. Yeah, that simplifies things. Supporting applying magic over just parts of the pathspec pattern sounds complex. Just a small modification. That rev-parse needs to look at "$1" as well. If :(literal) is already specified, glob quoting will backfire. The user script can deal with that, but it's harder (e.g. parsing magic from scripts and deal with magic combination) than letting rev-parse does it. I've done some form of this already, for supporting add--interactive. git-add prefixes the pathspec but keeps all the magic in place, before passing pathspec to add--interactive. But I missed the quoting point you mentioned above. I probably need de-quoting the prefix as well. Many optimizations stop short at the sign of any glob symbols, including backslash. This could be a new task for wildmatch. -- 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
Cloning remote HTTP repository: Can only see 'master' branch
Hello! I've a readonly git repository that I'm hosting via HTTP (a bare git repository located within the appropriate directory on the server). I push to it via my own SSH account (local repository with a remote pointing to the ssh:// URL). This has all worked fine so far - I push via ssh, and others can clone and pull via the HTTP URL. I've recently added a branch - "beta" - which pushed just fine, but now cloning via the HTTP URL doesn't seem to show the new branch - just master: $ git clone http://server.tld/path/to/repository.git repository Cloning into 'repository'... $ cd repository $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master Cloning via the readwrite ssh URL works fine though: $ git clone ssh://u...@server.tld:www/path/to/repository.git repository Cloning into 'repository'... stdin: is not a tty remote: Counting objects: 225, done. remote: Compressing objects: 100% (196/196), done. remote: Total 225 (delta 109), reused 77 (delta 25) Receiving objects: 100% (225/225), 9.55 MiB | 295 KiB/s, done. Resolving deltas: 100% (109/109), done. $ cd repository $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/beta remotes/origin/master I've tried 'git clone --mirror' just in case, but this just resulted in a bare repository with only the 'master' branch, still. Anyone have any ideas about what I'm doing wrong? Cheers, Michael -- 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] The design of new pathspec features
Duy Nguyen writes: > :(literal) magic > > > This magic is for people who want simple no-globbing pathspec (*). It > can be used in combination with other magic such as case-insensitive > matching. Incompatible with :(glob) magic below. > > Global option --noglob-pathspecs is added to add :(literal) to > all. This is very similar to --literal-pathspecs. It just does not > disable pathspec magic. :(glob) magic overrides this global option. > > (*) you can always disable wildcards by quoting them using backslash, > but that's inconvenient Have you considered if it may be helpful to have a :(literal) magic (or any magic in general) that applies only to the first N characters of the pathspec pattern? When you are in subdirectory and do a pathspec limited operation, e.g. cd Documentation && git ls-files "*.txt" we internaly do an equivalent of this: (1) first find out the "prefix", e.g. "Documentation/" in this case; (2) prepend the prefix to user-supplied pathspecs, e.g. yielding "Documentation/*.txt" in this case; and (3) use the resulting pathspecs to match against full pathnames relative to the root of the working tree. If the prefix had globbing character in it (e.g. we started in a directory "D*cumentati*n" instead), we still should make sure that that part matches literally, while allowing the globbing in user-supplied part of the pathspec (e.g. "*.txt"). In the built in code, you can work with the struct pathspec directly and mark the entire prefix part with nowildcard_len field to match literally, but if the above three-step logic needs to be implemented by a Porcelain script like old days, they would need to quote glob specials in the prefix part before appending user-supplied part to form the full pathspec string. I personally think we do not need to support something like this: prefix=$(git rev-parse --show-prefix) n=${#prefix} pathspec=":(literal-$n)$prefix$1" but other aspiring Porcelain script writers may disagree and would want to have it. We can always solve it by giving them an easy and uniform way to get the glob-quoted version of prefix to solve this particular issue, i.e. prefixq=$(git rev-parse --show-prefix-glob-quoted) pathspec="$prefixq$1" but magic that applies only to a substring may have other uses. If you do not immediately think of any, let's not overengineer this. 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: [RFC] The design of new pathspec features
On Tue, Jan 29, 2013 at 12:05 PM, Junio C Hamano wrote: >> New way to specify long pathspec magic >> == >> >> While testing the pathspec magic code, I grow tired of quoting :(glob) >> every time because '(' is the start of a new shell. Which is one of >> the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to >> specify long pathspec magic without quoting. > > Is this a real issue, though? Often interesting pathspecs do have > shell globs in them and we have to quote them anyway. :(icase) often won't (unless you combine with :(glob)). If we turn grep's --max-depth feature into pathspec magic (feasible, just not sure if it's actually useful), it won't need quoting either. Even with :(glob), because of the complexity of the pathspec, it's less likely to match anything and be expanded by bash, so no quoting required. >> How about making ":q/xxx/" an equivalence of ":(xxx)"? > > A moderately strong no from 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 0/3] transfer.hiderefs
Please take this as just a preview of early WIP. I think I may end up doing moderate amount of refactoring as a preparatory step before these patches, so nitpick-reviews are likely to become waste of reviewer's time at this point. -- 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] The design of new pathspec features
Duy Nguyen writes: > For those who haven't followed closely, some coming changes allow us > to extend current pathspec syntax. We should soon be able to do > case-insenstive matching for example, or introduce "**" wildcard that > is currently used by gitignore. I just want to discuss about the new > syntax and behavior. > > Many of these are already implemented in [1]. But I don't want you to > bother with buggy code yet. I'll resend it soon after 1.8.2. I think I agree with everything up to the "fnmatch(~FNM_PATHNAME)" part, from a quick read. Thanks for writing this up. -- 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] The design of new pathspec features
Duy Nguyen writes: > Pathspec mnemonic > = > > Are :(literal) and :(glob) used often enough to deserve a short > mnemonic (like :/ is equivalent to :(top))? Which symbols should be > used? I do not think we should discuss this before letting people gain experience with various forms of magic; otherwise we would at best end up with a concensus guess among uninformed. > New way to specify long pathspec magic > == > > While testing the pathspec magic code, I grow tired of quoting :(glob) > every time because '(' is the start of a new shell. Which is one of > the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to > specify long pathspec magic without quoting. Is this a real issue, though? Often interesting pathspecs do have shell globs in them and we have to quote them anyway. > How about making ":q/xxx/" an equivalence of ":(xxx)"? A moderately strong no from here. -- 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
[RFC] The design of new pathspec features
For those who haven't followed closely, some coming changes allow us to extend current pathspec syntax. We should soon be able to do case-insenstive matching for example, or introduce "**" wildcard that is currently used by gitignore. I just want to discuss about the new syntax and behavior. Many of these are already implemented in [1]. But I don't want you to bother with buggy code yet. I'll resend it soon after 1.8.2. --literal-pathspecs === This feature is added by Jeff to disable globbing for all pathspecs. I want to push it a bit further: disable all pathspec magic. This means even ":/" is treated literally when --literal-pathspecs is set. Because the intent behind this, as I understand, is for scripting, it makes sense to keep it as literal as possible. :(literal) magic This magic is for people who want simple no-globbing pathspec (*). It can be used in combination with other magic such as case-insensitive matching. Incompatible with :(glob) magic below. Global option --noglob-pathspecs is added to add :(literal) to all. This is very similar to --literal-pathspecs. It just does not disable pathspec magic. :(glob) magic overrides this global option. (*) you can always disable wildcards by quoting them using backslash, but that's inconvenient :(glob) magic = This magic is for people who want globbing. However, it does _not_ use the same matching mechanism the non-magic pathspec does today. It uses wildmatch(WM_PATHNAME), which basically means '*' does not match slashes and "**" does. Global option --glob-pathspecs is added to add :(glob) to all pathspec. :(literal) magic overrides this global option. fnmatch without FNM_PATHNAME is deprecated == With the two magic above, people can switch between literal and new globbing. There is no way to regain current matching behavior once --[no]glob-pathspecs is used. And I think that's a good thing. New globbing is more powerful than the current one. At some point, I'd like to switch the matching behavior when neither literal nor magic pathspec is specified. Either: - make it literal by default - make it new globbing by default Which is more often used should be come the default. The question is which. Pathspec mnemonic = Are :(literal) and :(glob) used often enough to deserve a short mnemonic (like :/ is equivalent to :(top))? Which symbols should be used? We can only use non-alphanumeric here, and '(', ')', ':' and '/' are taken. It should be friendly to UNIX shell, no quoting is preferred. Another magic will come soon: case-insensitive matching. We may want to reserve a mnemonic symbol for it as well. We may also want to reserve option shortcuts for --noglob-pathspecs and --glob-pathspecs. I suspect they'll be used more often. New way to specify long pathspec magic == While testing the pathspec magic code, I grow tired of quoting :(glob) every time because '(' is the start of a new shell. Which is one of the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to specify long pathspec magic without quoting. How about making ":q/xxx/" an equivalence of ":(xxx)"? Any character (except ',') following 'q' is used as separator (similar to s/// from sed). This violates the guidelines set in glossary-content.txt (only use non-alphanumeric). Another step futher is remove support for ":(xxx)" in favor of ":q(xxx)". We can do it today because I don't think anybody is using ":(top)" (the only supported magic) yet. [1] https://github.com/pclouds/git/tree/parse-pathspec -- 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] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
Interesting. I wonder if they've changed it recently. I only pointed it out because a software product I'm working on had a bug because it was building the URLs with "https://www..."; and the resulting images were showing as X's instead of avatars. We had to change the implementation to use "https://secure..."; to get the avatars to load correctly. That's been ~8 months ago now, though, so maybe it's no longer the case. It seems like it would be much more convenient if they just changed the scheme. Bryan On 29 January 2013 15:12, Jonathan Nieder wrote: > Hi Bryan, > > Bryan Turner wrote: > >> This won't work correctly as-is. The secure URL for Gravatar is >> "https://secure.gravatar.com"[1], not "https://www.gravatar.com";. > > Odd. "https://www.gravatar.com/"; also seems to work. I've put in a > technical support query to find out what the Gravatar admins prefer. > > Thanks, > Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
Hi Bryan, Bryan Turner wrote: > This won't work correctly as-is. The secure URL for Gravatar is > "https://secure.gravatar.com"[1], not "https://www.gravatar.com";. Odd. "https://www.gravatar.com/"; also seems to work. I've put in a technical support query to find out what the Gravatar admins prefer. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
This won't work correctly as-is. The secure URL for Gravatar is "https://secure.gravatar.com"[1], not "https://www.gravatar.com";. [1] See the "Secure Requests" section on: https://en.gravatar.com/site/implement/images/ On 29 January 2013 14:03, Junio C Hamano wrote: > > Thanks; will queue. > > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
Thanks; will queue. -- 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] fixup! mergetools: simplify how we handle "vim" and "defaults"
David Aguilar writes: > On Mon, Jan 28, 2013 at 11:28 AM, John Keeping wrote: >> --- >> Junio, please can you squash this into f9924e5 on jk/mergetool, >> providing that David is OK with that? > > This looks good to me. Thanks for a quick response. Will squash this in and rebuild the two affected branches. -- 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] fixup! mergetools: simplify how we handle "vim" and "defaults"
On Mon, Jan 28, 2013 at 11:28 AM, John Keeping wrote: > --- > Junio, please can you squash this into f9924e5 on jk/mergetool, > providing that David is OK with that? This looks good to me. > The original change breaks custom mergetool by making changing the logic > around default functions so that they are now only defined when the tool > file exists in $MERGE_TOOLS_DIR but we need the default implementations > when a custom tool is in use, which by definition means that the file > doesn't exist in $MERGE_TOOLS_DIR. > > git-mergetool--lib.sh | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh > index 1d0fb12..211ffe5 100644 > --- a/git-mergetool--lib.sh > +++ b/git-mergetool--lib.sh > @@ -48,15 +48,6 @@ valid_tool () { > setup_tool () { > tool="$1" > > - if ! test -f "$MERGE_TOOLS_DIR/$tool" > - then > - # Use a special return code for this case since we want to > - # source "defaults" even when an explicit tool path is > - # configured since the user can use that to override the > - # default path in the scriptlet. > - return 2 > - fi > - > # Fallback definitions, to be overriden by tools. > can_merge () { > return 0 > @@ -80,6 +71,15 @@ setup_tool () { > echo "$1" > } > > + if ! test -f "$MERGE_TOOLS_DIR/$tool" > + then > + # Use a special return code for this case since we want to > + # source "defaults" even when an explicit tool path is > + # configured since the user can use that to override the > + # default path in the scriptlet. > + return 2 > + fi > + > # Load the redefined functions > . "$MERGE_TOOLS_DIR/$tool" > > -- > 1.8.1.1 -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] receive-pack: reject an attempt to update/delete a hidden ref
An attempt to update or delete a ref that is hidden from "git push" is rejected. With this the server side can implement refs that are only available for its own use, e.g. refs/pull/11/head used to hold an incoming pull request at GitHub. Signed-off-by: Junio C Hamano --- Documentation/config.txt | 3 ++- builtin/receive-pack.c | 16 t/t5516-fetch-push.sh| 24 3 files changed, 42 insertions(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 8e2853e..b7b407b 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2063,7 +2063,8 @@ transfer.hiderefs:: more than one transfer.hiderefs configuration variables to specify multiple prefix strings. A ref that has one of these strings as its prefix is excluded, and is hidden from - `git clone --mirror` and `git push :`. + `git clone --mirror` and `git push :`. An attempt to update + or delete a hidden ref by `git push` is rejected. transfer.unpackLimit:: When `fetch.unpackLimit` or `receive.unpackLimit` are diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index 5ed40be..a8248d9 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -696,6 +696,20 @@ static int iterate_receive_command_list(void *cb_data, unsigned char sha1[20]) return -1; /* end of list */ } +static void reject_updates_to_hidden(struct command *commands) +{ + struct command *cmd; + + for (cmd = commands; cmd; cmd = cmd->next) { + if (cmd->error_string || !ref_is_hidden(cmd->ref_name)) + continue; + if (is_null_sha1(cmd->new_sha1)) + cmd->error_string = "deny deleting a hidden ref"; + else + cmd->error_string = "deny updating a hidden ref"; + } +} + static void execute_commands(struct command *commands, const char *unpacker_error) { struct command *cmd; @@ -712,6 +726,8 @@ static void execute_commands(struct command *commands, const char *unpacker_erro 0, &cmd)) set_connectivity_errors(commands); + reject_updates_to_hidden(commands); + if (run_receive_hook(commands, pre_receive_hook, 0)) { for (cmd = commands; cmd; cmd = cmd->next) { if (!cmd->error_string) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 6009372..8e8287a 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -1037,4 +1037,28 @@ test_expect_success 'push --prune refspec' ' ! check_push_result $the_first_commit tmp/foo tmp/bar ' +test_expect_success 'push to update a hidden ref' ' + mk_test heads/master hidden/one hidden/two hidden/three && + ( + cd testrepo && + git config transfer.hiderefs refs/hidden + ) && + + # push to unhidden ref succeeds normally + git push testrepo master:refs/heads/master && + check_push_result $the_commit heads/master && + + # push to update a hidden ref should fail + test_must_fail git push testrepo master:refs/hidden/one && + check_push_result $the_first_commit hidden/one && + + # push to delete a hidden ref should fail + test_must_fail git push testrepo master:refs/hidden/two && + check_push_result $the_first_commit hidden/two && + + # idempotent push to update a hidden ref should fail + test_must_fail git push testrepo $the_first_commit:refs/hidden/three && + check_push_result $the_first_commit hidden/three +' + test_done -- 1.8.1.2.548.g0e4986f -- 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/3] upload-pack: share more code
We mark the objects pointed at our refs with "OUR_REF" flag in two functions (mark_our_ref() and send_ref()), but we can just use the former as a helper for the latter. Update the way mark_our_ref() prepares in-core object to use lookup_unknown_object() to delay reading the actual object data, just like we did in 435c833 (upload-pack: use peel_ref for ref advertisements, 2012-10-04). Signed-off-by: Junio C Hamano --- upload-pack.c | 31 ++- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index 95d8313..3dd220d 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -722,15 +722,28 @@ static void receive_needs(void) free(shallows.objects); } +static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data) +{ + struct object *o = lookup_unknown_object(sha1); + if (!o) + die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1)); + if (!(o->flags & OUR_REF)) { + o->flags |= OUR_REF; + nr_our_refs++; + } + return 0; +} + static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data) { static const char *capabilities = "multi_ack thin-pack side-band" " side-band-64k ofs-delta shallow no-progress" " include-tag multi_ack_detailed"; - struct object *o = lookup_unknown_object(sha1); const char *refname_nons = strip_namespace(refname); unsigned char peeled[20]; + mark_our_ref(refname, sha1, flag, cb_data); + if (capabilities) packet_write(1, "%s %s%c%s%s agent=%s\n", sha1_to_hex(sha1), refname_nons, @@ -740,27 +753,11 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo else packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons); capabilities = NULL; - if (!(o->flags & OUR_REF)) { - o->flags |= OUR_REF; - nr_our_refs++; - } if (!peel_ref(refname, peeled)) packet_write(1, "%s %s^{}\n", sha1_to_hex(peeled), refname_nons); return 0; } -static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data) -{ - struct object *o = parse_object(sha1); - if (!o) - die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1)); - if (!(o->flags & OUR_REF)) { - o->flags |= OUR_REF; - nr_our_refs++; - } - return 0; -} - static void upload_pack(void) { if (advertise_refs || !stateless_rpc) { -- 1.8.1.2.548.g0e4986f -- 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/3] upload-pack: allow hiding ref hiearchies
Teach upload-pack to omit some refs from the initial advertisement by introducing the uploadPack.hiderefs multivalued configuration variable. Any ref that is under the hierarchies listed on the value of this variable is excluded from responses to "ls-remote", "fetch" or "clone" requests. One typical use case may be [uploadPack] hiderefs = refs/changes Note that the underlying protocol still allows a request to fetch objects at the tip of any ref, including the hidden ones, but on the client side (e.g. fetch-pack), the requests are checked against the ls-remote response, so it cannot ask for refs/changes/14/432432, or for the object name (which is what eventually goes over the wire on "want" line) the user may obtain out of band (e.g. Gerrit dashboard). A new capability "allow-tip-sha1-in-want" is returned by upload-pack to signal updated clients that it may be OK to ask for objects that were not advertised. Signed-off-by: Junio C Hamano --- Documentation/config.txt | 8 builtin/receive-pack.c | 8 refs.c | 41 + refs.h | 3 +++ t/t5512-ls-remote.sh | 9 + upload-pack.c| 25 +++-- 6 files changed, 92 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index ef45c99..8e2853e 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2057,6 +2057,14 @@ transfer.fsckObjects:: not set, the value of this variable is used instead. Defaults to false. +transfer.hiderefs:: + String(s) `upload-pack` and `receive-pack` use to decide + which refs to omit from their initial advertisement. Use + more than one transfer.hiderefs configuration variables to + specify multiple prefix strings. A ref that has one of these + strings as its prefix is excluded, and is hidden from + `git clone --mirror` and `git push :`. + transfer.unpackLimit:: When `fetch.unpackLimit` or `receive.unpackLimit` are not set, the value of this variable is used instead. diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index ff781fe..5ed40be 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -59,6 +59,11 @@ static enum deny_action parse_deny_action(const char *var, const char *value) static int receive_pack_config(const char *var, const char *value, void *cb) { + int status = parse_hide_refs_config(var, value, cb); + + if (status) + return status; + if (strcmp(var, "receive.denydeletes") == 0) { deny_deletes = git_config_bool(var, value); return 0; @@ -119,6 +124,9 @@ static int receive_pack_config(const char *var, const char *value, void *cb) static void show_ref(const char *path, const unsigned char *sha1) { + if (ref_is_hidden(path)) + return; + if (sent_capabilities) packet_write(1, "%s %s\n", sha1_to_hex(sha1), path); else diff --git a/refs.c b/refs.c index 541fec2..e3574ca 100644 --- a/refs.c +++ b/refs.c @@ -3,6 +3,7 @@ #include "object.h" #include "tag.h" #include "dir.h" +#include "string-list.h" /* * Make sure "ref" is something reasonable to have under ".git/refs/"; @@ -2556,3 +2557,43 @@ char *shorten_unambiguous_ref(const char *refname, int strict) free(short_name); return xstrdup(refname); } + +static struct string_list *hide_refs; + +int parse_hide_refs_config(const char *var, const char *value, void *unused) +{ + if (!strcmp("transfer.hiderefs", var)) { + char *ref; + int len; + + if (!value) + return config_error_nonbool(var); + ref = xstrdup(value); + len = strlen(ref); + while (len && ref[len - 1] == '/') + ref[--len] = '\0'; + if (!hide_refs) { + hide_refs = xcalloc(1, sizeof(*hide_refs)); + hide_refs->strdup_strings = 1; + } + string_list_append(hide_refs, ref); + } + return 0; +} + +int ref_is_hidden(const char *refname) +{ + struct string_list_item *item; + + if (!hide_refs) + return 0; + for_each_string_list_item(item, hide_refs) { + int len; + if (prefixcmp(refname, item->string)) + continue; + len = strlen(item->string); + if (!refname[len] || refname[len] == '/') + return 1; + } + return 0; +} diff --git a/refs.h b/refs.h index d6c2fe2..50b233f 100644 --- a/refs.h +++ b/refs.h @@ -147,4 +147,7 @@ int update_ref(const char *action, const char *refname, const unsigned char *sha1, const unsigned char *oldval, int flags, enum action_on_err onerr); +
[PATCH v2 0/3] transfer.hiderefs
So this is the second round, unifying the handling of "hidden refs" a hosting site administrator may want to handle differently from normal refs available to upload-pack and receive-pack. Big thanks to Peff for making me realize that what is shown to "git push" should match what is shown to "git fetch/clone". The configuration variable has been changed to "transfer.hiderefs" in this round. I picked refs.[ch] as the shared location to place the machinery that deals with this configuration, but I am not proud of the choice---there may be a more suitable place. The third patch is new; it prevents a hidden ref to be deleted or updated via "git push" to ensure that its contents are controlled only from the server side using some side channel (e.g. pull-request UI on the Web). There is no "git fetch $there $exact_sha1_obtained_out_of_band" yet; that must come next, together with a mechanism to control the availability of it on the server side. For those who missed it, the first round starts at http://thread.gmane.org/gmane.comp.version-control.git/213951 Junio C Hamano (3): upload-pack: share more code upload-pack: allow hiding ref hiearchies receive-pack: reject an attempt to update/delete a hidden ref Documentation/config.txt | 9 + builtin/receive-pack.c | 24 +++ refs.c | 41 +++ refs.h | 3 +++ t/t5512-ls-remote.sh | 9 + t/t5516-fetch-push.sh| 24 +++ upload-pack.c| 50 7 files changed, 144 insertions(+), 16 deletions(-) -- 1.8.1.2.548.g0e4986f -- 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] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
re sended. Very big thanks for example :D 2013/1/29 Junio C Hamano : > Андрей Баранов writes: > >> Or maybe option like: >> /etc/gitweb.conf: >> $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none']; >> >> but it's hard for me :) i don't know perl > > The effect is the same and your original patch is shorter and > cleaner to see what is going on; as far as the patch text is > concerned, the original one is just fine. > > Except that we wanted a bit more stuff before "---" line. How about > something like this? > > Subject: [PATCH] gitweb: refer to picon/gravatar images over the same > scheme > > The images from picon and gravatar are always used over > http://, and browsers give mixed contents warning when > gitweb is served over https://. > > Just drop the scheme: part from the URL, so that these > external sites are accessed over https:// in such a case. > > Signed-off-by: Your Name > --- > gitweb/gitweb.perl | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl > ... > -- 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] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
Just drop the scheme: part from the URL, so that these external sites are accessed over https:// in such a case. Signed-off-by: Andrej E Baranov --- gitweb/gitweb.perl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index c6bafe6..1309196 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -2068,7 +2068,7 @@ sub picon_url { if (!$avatar_cache{$email}) { my ($user, $domain) = split('@', $email); $avatar_cache{$email} = - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; . + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" . "$domain/$user/" . "users+domains+unknown/up/single"; } @@ -2083,7 +2083,7 @@ sub gravatar_url { my $email = lc shift; my $size = shift; $avatar_cache{$email} ||= - "http://www.gravatar.com/avatar/"; . + "//www.gravatar.com/avatar/" . Digest::MD5::md5_hex($email) . "?s="; return $avatar_cache{$email} . $size; } -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
Андрей Баранов writes: > Or maybe option like: > /etc/gitweb.conf: > $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none']; > > but it's hard for me :) i don't know perl The effect is the same and your original patch is shorter and cleaner to see what is going on; as far as the patch text is concerned, the original one is just fine. Except that we wanted a bit more stuff before "---" line. How about something like this? Subject: [PATCH] gitweb: refer to picon/gravatar images over the same scheme The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://. Just drop the scheme: part from the URL, so that these external sites are accessed over https:// in such a case. Signed-off-by: Your Name --- gitweb/gitweb.perl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl ... -- 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] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
Junio C Hamano wrote: > I am sure mixed content warning was the primary motivation of the > patch. Sure, but that's not enough motivation for me to like it. ;-) The privacy aspect is enough to motivate it for me. > Do we know these external sites actually server what we want > over https://? Yep. cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi and www.gravatar.com/avatar both support https and return the expected responses for queries over https. -- 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] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
Or maybe option like: /etc/gitweb.conf: $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none']; but it's hard for me :) i don't know perl 2013/1/29 Junio C Hamano : > Jonathan Nieder writes: > >> Junio C Hamano wrote: Andrej Andb wrote: >> > --- a/gitweb/gitweb.perl > +++ b/gitweb/gitweb.perl > @@ -2068,7 +2068,7 @@ sub picon_url { >if (!$avatar_cache{$email}) { >my ($user, $domain) = split('@', $email); >$avatar_cache{$email} = > - > "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; . > + > "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" . >> [...] >>> Intuitively it feels strange that the above lets the site that gave >>> you the base URL dictate over what scheme sites unrelated to it has >>> to serve their resources. >> >> The main effect is to slightly improve privacy. A man in the middle >> can still see the size of avatars and when you fetched them, but at >> least this way when you are using HTTPS they do not see the names of >> authors of commits you are looking at. >> >> It also avoids a mixed content warning. >> >> On the other hand, it hurts caching by proxies. > > I am sure mixed content warning was the primary motivation of the > patch. Do we know these external sites actually server what we want > over https://? > -- 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] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
Jonathan Nieder writes: > Junio C Hamano wrote: >>> Andrej Andb wrote: > --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -2068,7 +2068,7 @@ sub picon_url { if (!$avatar_cache{$email}) { my ($user, $domain) = split('@', $email); $avatar_cache{$email} = - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; . + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" . > [...] >> Intuitively it feels strange that the above lets the site that gave >> you the base URL dictate over what scheme sites unrelated to it has >> to serve their resources. > > The main effect is to slightly improve privacy. A man in the middle > can still see the size of avatars and when you fetched them, but at > least this way when you are using HTTPS they do not see the names of > authors of commits you are looking at. > > It also avoids a mixed content warning. > > On the other hand, it hurts caching by proxies. I am sure mixed content warning was the primary motivation of the patch. Do we know these external sites actually server what we want over https://? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Auto-generate mergetool lists
On Mon, Jan 28, 2013 at 01:50:19PM -0800, Junio C Hamano wrote: > What are the situations where a valid user-defined tools is > unavailable, by the way? The same as a built-in tool: the command isn't available. Currently I'm extracting the command word using: cmd=$(eval -- "set -- $(git config mergetool.$tool.cmd); echo \"$1\"") (it's slightly more complicated due to handling difftool.$tool.cmd as well, but that's essentially it). Then it just uses the same "type $cmd" test as for built-in tools. I don't know if there's a better way to extract the first word, but that's the best I've come up with so far. John -- 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] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
Junio C Hamano wrote: >> Andrej Andb wrote: >>> --- a/gitweb/gitweb.perl >>> +++ b/gitweb/gitweb.perl >>> @@ -2068,7 +2068,7 @@ sub picon_url { >>> if (!$avatar_cache{$email}) { >>> my ($user, $domain) = split('@', $email); >>> $avatar_cache{$email} = >>> - >>> "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; . >>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" >>> . [...] > Intuitively it feels strange that the above lets the site that gave > you the base URL dictate over what scheme sites unrelated to it has > to serve their resources. The main effect is to slightly improve privacy. A man in the middle can still see the size of avatars and when you fetched them, but at least this way when you are using HTTPS they do not see the names of authors of commits you are looking at. It also avoids a mixed content warning. On the other hand, it hurts caching by proxies. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
Junio C Hamano writes: >>> - >>> "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; . >>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" >>> . > > Hrmph. Is that even a valid URL to refer to that external site from > a https://my.site/some/where/ base URL? I wouldn't be surprised if > browsers allowed it, but I do not recall seeing such a use in RFCs. ah, nevermind. That's net_path in 1808. -- 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] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
Jonathan Nieder writes: > (cc-ing some area experts) > Hi Andrej, > > Andrej Andb wrote: > >> [Subject: remove protocol from gravatar and picon links for clear if >> Gitweb is being called through a secure server] > > Sounds good to me. May we have your signoff? (See > Documentation/SubmittingPatches for what this means.) > > Thanks, > Jonathan > (patch left unsnipped for reference) > >> --- >> gitweb/gitweb.perl | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl >> index c6bafe6..1309196 100755 >> --- a/gitweb/gitweb.perl >> +++ b/gitweb/gitweb.perl >> @@ -2068,7 +2068,7 @@ sub picon_url { >> if (!$avatar_cache{$email}) { >> my ($user, $domain) = split('@', $email); >> $avatar_cache{$email} = >> - >> "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; . >> +"//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" >> . Hrmph. Is that even a valid URL to refer to that external site from a https://my.site/some/where/ base URL? I wouldn't be surprised if browsers allowed it, but I do not recall seeing such a use in RFCs. Intuitively it feels strange that the above lets the site that gave you the base URL dictate over what scheme sites unrelated to it has to serve their resources. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Auto-generate mergetool lists
John Keeping writes: > I've had a quick look and it's quite straightforward to build on top of > this to get an output format like this: > > 'git mergetool --tool-' may be set to one of the following: > araxis >... > vimdiff2 > > user-defined: > mytool > > The following tools are valid, but not currently available: > bc3 >... > xxdiff > > user-defined: > mybrokentool > > Some of the tools listed above only work in a windowed > environment. If run in a terminal-only session, they will fail. > > I don't think the suffix form would be too hard either - it just > requires moving an explicit sort into the top-level shot_tool_help > function. I tend to think that one-tool-per-line format like the above looks nicer. What are the situations where a valid user-defined tools is unavailable, by the way? -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
Am 28.01.2013 21:34, schrieb Junio C Hamano: > Jens Lehmann writes: > >> Am 28.01.2013 19:51, schrieb Junio C Hamano: >>> Lars Hjemli writes: >>> > Come to think of it, is there a reason why "for-each-repo" should > not be an extention to "submodule foreach"? We can view this as > visiting repositories that _could_ be registered as a submodule, in > addition to iterating over the registered submodules, no? Yes, but I see some possible problems with that approach: -'git for-each-repo' does not need to be started from within a git worktree >>> >>> True, but "git submodule foreach --untracked" can be told that it is >>> OK not (yet) to be in any superproject, no? >> >> Hmm, I'm not sure how that would work as it looks for gitlinks >> in the index which point to work tree paths. > > I was imagining that "foreach --untracked" could go something like this: > > * If you are inside an existing git repository, read its index to >learn the gitlinks in the directory and its subdirectories. > > * Start from the current directory and recursively apply the >procedure in this step: > >* Scan the directory and iterate over the ones that has ".git" in > it: > > * If it is a gitlinked one, show it, but do not descend into it >unless --recursive is given (e.g. you start from /home/jens, >find /home/jens/proj/ directory that has /home/jens/proj/.git >in it. /home/jens/.git/index knows that it is a submodule of >the top-level superproject. "proj" is handled, and it is up >to the --recursive option if its submodules are handled). > > * If it is _not_ a gitlinked one, show it and descend into it >(e.g. /home/jens/ is not a repository or /home/jens/proj is >not a tracked submodule) to apply this procedure recursively. > > Of course, without --untracked, we have no need to iterate over the > readdir() return values; instead we just scan the index of the > top-level superproject. Thanks for explaining, that makes tons of sense. -'git for-each-repo' and 'git submodule foreach' have different semantics for --dirty and --clean >> >> I'm confused, what semantics of --dirty and --clean does current >> 'git submodule foreach' have? I can't find any sign of it in the >> current code ... did I miss something while skimming through this >> thread? Or are you talking about status and diff here? > > I think Lars is hinting that "submodule foreach" could restrict its > operation to a similar --dirty/--clean/--both option he has. Of > course, the command given to foreach can decide to become no-op by > inspecting the submodule itself, so in that sense, --dirty/--clean > can be done without, but I think it would make sense to have it in > "submodule foreach" even without the "--untracked" option. Nice idea. E.g. that would help submodule users to easily script a workflow which descends only into modified submodules to create branches and push them there. Or to remove branches which were created everywhere only in those submodules that weren't changed. >> But I think the current for-each-repo >> proposal doesn't allow to traverse repos which contain untracked >> content (and it would be nice if the user could somehow combine >> that with the current --dirty flag to have both in one go). > > Perhaps. I personally felt it was really strange that submodule > diff and status consider that it is a sin to have untracked and > unignored cruft in the submodule working tree, though. The VCS we used at work before Git didn't show us any untracked files, which caused trouble on a regular basis as people were breaking builds for others because they forgot to check in new files. That didn't happen with Git anymore, which was very cool. But the problem reappeared as we started using submodules. Since I taught status and diff to show that we're happy again. So for us it was everything but strange ;-) But for for-each-repo I would rather propose that modifications of tracked files can optionally and/or solely be used to pick the repos. Maybe: --dirty=modified, --dirty=untracked and --dirty=both with --dirty defaulting to modified? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: "David Aguilar" Sent: Monday, January 28, 2013 9:16 AM On Mon, Jan 28, 2013 at 12:20 AM, Philip Oakley wrote: From: "David Aguilar" Sent: Monday, January 28, 2013 12:52 AM This is round two of this series. I think this touched on everything brought up in the code review. 4/4 could use a review as I'm not completely familiar with the makefile dependencies, though it seems to work correctly. Does this 4/4 have any effect on the Msysgit / Git for Windows documentation which simply refers [IIRC] to HTML documenation made by Junio? That is, how easy is it to create a 'default' set of docs, rather than personalised documenation. Or have I misunderstood how it is working? It doesn't have any effect on Msysgit. The resulting documentation lists all available tools, on all platforms. That's useful to know. I must have misunderstood one of the earlier messages suggesting it would also list all the users other (non typical) installed mergetools and hence add them into the documentation. Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Auto-generate mergetool lists
On Sun, Jan 27, 2013 at 06:41:04PM -0800, David Aguilar wrote: > John, I didn't completely address your question about keeping > the sort and prefix in show_tool_help() but I can stop poking at > it now in case you want to start looking at what it would take > to get custom tools listed in the --tool-help output. I've had a quick look and it's quite straightforward to build on top of this to get an output format like this: 'git mergetool --tool-' may be set to one of the following: araxis gvimdiff gvimdiff2 vimdiff vimdiff2 user-defined: mytool The following tools are valid, but not currently available: bc3 codecompare deltawalker diffuse ecmerge emerge kdiff3 meld opendiff p4merge tkdiff tortoisemerge xxdiff user-defined: mybrokentool Some of the tools listed above only work in a windowed environment. If run in a terminal-only session, they will fail. I don't think the suffix form would be too hard either - it just requires moving an explicit sort into the top-level shot_tool_help function. I'm going to hold off doing any more on this until da/mergetool-docs has graduated to next since I think it will be easier to just build on that rather than trying to put all the necessary pieces into place now. John -- 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: Bug: file named - on git commit
Jonathan Nieder writes: > Thomas Rast wrote: >> Rene Moser writes: > >>> Found a little issue in git version 1.7.9.5 if a file named "-", causing >>> "git commit" to read from stdin. >>> >>> (So you must hit ctrl-d or ctrl-c to finish the commit.) > [...] >> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no >> need to read blob from the standard input, 2012-06-27), which is >> included starting with v1.7.12 and the v1.7.11.3 maint release. Please >> upgrade. > > Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which > is currently in the release candidate stage) take this fix? Do you > happen to know of any other fixes such people would want? There are files with four dotted decimal numbers in their names in the Documentation/RelNotes/ directory to help distro maintainers like you to figure it want. This is a tangent, but even with a project like git that is managed with a good use of topic branch workflow, we may want to have a way to reliably identify the tip of an ancient fix like this. People may be able to bisect down to 4682d85, and in this particular case, I happen to know that there wasn't any side-effect breakage introduced by that commit, but there needs to be an easy way (it can be expensive to compute) to make sure there is no follow-up fix to that particular commit. I can read "git rev-list --parents | grep -C3 $(git rev-parse 4682d85)" and then figure out what the children commits of that fix are, of course, but I suspect most people will view it as primitive ;-) -- 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] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
(cc-ing some area experts) Hi Andrej, Andrej Andb wrote: > [Subject: remove protocol from gravatar and picon links for clear if > Gitweb is being called through a secure server] Sounds good to me. May we have your signoff? (See Documentation/SubmittingPatches for what this means.) Thanks, Jonathan (patch left unsnipped for reference) > --- > gitweb/gitweb.perl | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl > index c6bafe6..1309196 100755 > --- a/gitweb/gitweb.perl > +++ b/gitweb/gitweb.perl > @@ -2068,7 +2068,7 @@ sub picon_url { > if (!$avatar_cache{$email}) { > my ($user, $domain) = split('@', $email); > $avatar_cache{$email} = > - > "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; . > + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" > . > "$domain/$user/" . > "users+domains+unknown/up/single"; > } > @@ -2083,7 +2083,7 @@ sub gravatar_url { > my $email = lc shift; > my $size = shift; > $avatar_cache{$email} ||= > - "http://www.gravatar.com/avatar/"; . > + "//www.gravatar.com/avatar/" . > Digest::MD5::md5_hex($email) . "?s="; > return $avatar_cache{$email} . $size; > } -- 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] l10n: de.po: translate 11 new messages
From: "Ralf Thielow" Sent: Monday, January 28, 2013 6:13 PM On Mon, Jan 28, 2013 at 05:39:27PM +0100, Joachim Schmitz wrote: Ralf Thielow wrote: >Translate 11 new messages came from git.pot update >in 46bc403 (l10n: Update git.pot (11 new, 7 removed >messages)). > >Signed-off-by: Ralf Thielow >--- > po/de.po | 37 ++--- > 1 file changed, 18 insertions(+), 19 deletions(-) > >diff --git a/po/de.po b/po/de.po >index 3779f4c..ed8330a 100644 >--- a/po/de.po >+++ b/po/de.po >@@ -5,7 +5,7 @@ > # > msgid "" > msgstr "" >-"Project-Id-Version: git 1.8.1\n" >+"Project-Id-Version: git 1.8.2\n" Just noticing. Should this be s/git/Git/ to match the * ta/doc-no-small-caps (2013-01-22) 10 commits which is cooking? Not "Projekt-Id-Version ..."? I don't think that we need to translate this. > #: builtin/reset.c:33 > msgid "mixed" >@@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes" > msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale >Änderungen" Not "reset -> setze" and "keep" -> halte (imperativ)? Or is the enlish text wrong and should be "resets" and "keeps" All translations which describe an option shown by "git -h" are (or should be) like this. The reading is like "This option..." followed by such a messages. That's at least how it's done. I don't think it sounds bad. According to the glossary, the translation here is wrong because "reset" is not "*zurück* setzen" but "neu setzen". I'll fix this (and perhaps other messages) on a commit on top. Bye, Jojo Philip Oakley -- 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: Bug: file named - on git commit
Jonathan Nieder writes: > Thomas Rast wrote: >> Rene Moser writes: > >>> Found a little issue in git version 1.7.9.5 if a file named "-", causing >>> "git commit" to read from stdin. >>> >>> (So you must hit ctrl-d or ctrl-c to finish the commit.) > [...] >> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no >> need to read blob from the standard input, 2012-06-27), which is >> included starting with v1.7.12 and the v1.7.11.3 maint release. Please >> upgrade. > > Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which > is currently in the release candidate stage) take this fix? Do you > happen to know of any other fixes such people would want? FYI, the fix referred to in this thread are three-patch series that forked from 1.7.6.6, so it should be trivial to merge it even to such an old version. The topic-branch workflow shines ;-) -- 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
A note from the maintainer
Welcome to the Git development community. This message is written by the maintainer and talks about how Git project is managed, and how you can work with it. * Mailing list and the community The development is primarily done on the Git mailing list. Help requests, feature proposals, bug reports and patches should be sent to the list address . You don't have to be subscribed to send messages. The convention on the list is to keep everybody involved on Cc:, so it is unnecessary to say "Please Cc: me, I am not subscribed". Before sending patches, please read Documentation/SubmittingPatches and Documentation/CodingGuidelines to familiarize yourself with the project convention. If you sent a patch and you did not hear any response from anybody for several days, it could be that your patch was totally uninteresting, but it also is possible that it was simply lost in the noise. Please do not hesitate to send a reminder message in such a case. Messages getting lost in the noise is a sign that people involved don't have enough mental/time bandwidth to process them right at the moment, and it often helps to wait until the list traffic becomes calmer before sending such a reminder. The list archive is available at a few public sites: http://news.gmane.org/gmane.comp.version-control.git/ http://marc.theaimsgroup.com/?l=git http://www.spinics.net/lists/git/ For those who prefer to read it over NNTP (including the maintainer): nntp://news.gmane.org/gmane.comp.version-control.git When you point at a message in a mailing list archive, using gmane is often the easiest to follow by readers, like this: http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217 as it also allows people who subscribe to the mailing list as gmane newsgroup to "jump to" the article. Some members of the development community can sometimes also be found on the #git IRC channel on Freenode. Its log is available at: http://colabti.org/irclogger/irclogger_log/git * Reporting bugs When you think git does not behave as you expect, please do not stop your bug report with just "git does not work". "I used git in this way, but it did not work" is not much better, neither is "I used git in this way, and X happend, which is broken". It often is that git is correct to cause X happen in such a case, and it is your expectation that is broken. People would not know what other result Y you expected to see instead of X, if you left it unsaid. Please remember to always state - what you wanted to achieve; - what you did (the version of git and the command sequence to reproduce the behavior); - what you saw happen (X above); - what you expected to see (Y above); and - how the last two are different. See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further hints. * Repositories, branches and documentation. My public git.git repositories are at: git://git.kernel.org/pub/scm/git/git.git/ git://repo.or.cz/alt-git.git/ https://github.com/git/git/ https://code.google.com/p/git-core/ git://git.sourceforge.jp/gitroot/git-core/git.git/ git://git-core.git.sourceforge.net/gitroot/git-core/git-core/ A few gitweb interfaces are found at: http://git.kernel.org/?p=git/git.git http://repo.or.cz/w/alt-git.git Preformatted documentation from the tip of the "master" branch can be found in: git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/ git://repo.or.cz/git-{htmldocs,manpages}.git/ https://code.google.com/p/git-{htmldocs,manpages}.git/ https://github.com/gitster/git-{htmldocs,manpages}.git/ You can browse the HTML manual pages at: http://git-htmldocs.googlecode.com/git/git.html There are four branches in git.git repository that track the source tree of git: "master", "maint", "next", and "pu". The "master" branch is meant to contain what are very well tested and ready to be used in a production setting. Every now and then, a "feature release" is cut from the tip of this branch and they typically are named with three dotted decimal digits. The last such release was 1.8.1 done on Dec 31, 2012 (or Jan 1, 2013, depending on where you were when it happened). You can expect that the tip of the "master" branch is always more stable than any of the released versions. Whenever a feature release is made, "maint" branch is forked off from "master" at that point. Obvious, safe and urgent fixes after a feature release are applied to this branch and maintenance releases are cut from it. The maintenance releases are named with four dotted decimal, named after the feature release they are updates to; the last such release was 1.8.1.2. New features never go to this branch. This branch is also merged into "master" to propagate the fixes forward as needed. A new development does not usually happen on "master". When you send a series of patches, after review on th
Re: Bug: file named - on git commit
Hi, Thomas Rast wrote: > Rene Moser writes: >> Found a little issue in git version 1.7.9.5 if a file named "-", causing >> "git commit" to read from stdin. >> >> (So you must hit ctrl-d or ctrl-c to finish the commit.) [...] > This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no > need to read blob from the standard input, 2012-06-27), which is > included starting with v1.7.12 and the v1.7.11.3 maint release. Please > upgrade. Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which is currently in the release candidate stage) take this fix? Do you happen to know of any other fixes such people would want? Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.8.1.2
The latest maintenance release Git v1.8.1.2 is now available at the usual places. This contains a handful of fixes that will also appear in the next feature release. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 29a2dee568b1f86e9d3d8f9dcc376f24439b6a0c git-1.8.1.2.tar.gz 3df491003d026b8f4b2de378e57b930a98f0a595 git-htmldocs-1.8.1.2.tar.gz 14a27dfec52256831f2d0e2ee655f75c1077 git-manpages-1.8.1.2.tar.gz Also the following public repositories all have a copy of the v1.8.1.2 tag and the maint branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git 1.8.1.2 Release Notes = Fixes since v1.8.1.1 * An element on GIT_CEILING_DIRECTORIES list that does not name the real path to a directory (i.e. a symbolic link) could have caused the GIT_DIR discovery logic to escape the ceiling. * Command line completion for "tcsh" emitted an unwanted space after completing a single directory name. * Command line completion leaked an unnecessary error message while looking for possible matches with paths in . * "git archive" did not record uncompressed size in the header when streaming a zip archive, which confused some implementations of unzip. * When users spelled "cc:" in lowercase in the fake "header" in the trailer part, "git send-email" failed to pick up the addresses from there. As e-mail headers field names are case insensitive, this script should follow suit and treat "cc:" and "Cc:" the same way. Also contains various documentation fixes. Changes since v1.8.1.1 are as follows: Antoine Pelisse (3): dir.c: Make git-status --ignored more consistent git-status: Test --ignored behavior status: always report ignored tracked directories Dylan Smith (1): git-completion.bash: silence "not a valid object" errors Eric S. Raymond (1): Remove the suggestion to use parsecvs, which is currently broken. John Keeping (1): git-for-each-ref.txt: 'raw' is a supported date format Jonathan Nieder (1): contrib/vim: simplify instructions for old vim support Junio C Hamano (2): Start preparing for 1.8.1.2 Git 1.8.1.2 Marc Khouzam (1): Prevent space after directories in tcsh completion Michael Haggerty (8): Introduce new static function real_path_internal() real_path_internal(): add comment explaining use of cwd Introduce new function real_path_if_valid() longest_ancestor_length(): use string_list_split() longest_ancestor_length(): take a string_list argument for prefixes longest_ancestor_length(): require prefix list entries to be normalized setup_git_directory_gently_1(): resolve symlinks in ceiling paths string_list_longest_prefix(): remove function Nguyễn Thái Ngọc Duy (1): attr: make it build with DEBUG_ATTR again Nickolai Zeldovich (1): git-send-email: treat field names as case-insensitively Peter Eisentraut (1): git-commit-tree(1): correct description of defaults René Scharfe (5): archive-zip: write uncompressed size into header even with streaming t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead t0024, t5000: use test_lazy_prereq for UNZIP t5000, t5003: move ZIP tests into their own script t5003: check if unzip supports symlinks Sebastian Staudt (1): config.txt: Document help.htmlpath config parameter -- 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 3/4] mergetool--lib: Add functions for finding available tools
John Keeping writes: >> +printf "%s%s\n" "$per_line_prefix" "$tool" > > This needs to be: > > printf "$per_line_prefix%s\n" "$tool" > > since $per_line_prefix is usually '\t\t' which isn't expanded if we > format it with %s - an alternative would be to change the value passed > in to '$TAB$TAB' with literal tabs. I would prefer the latter, actually. I do understand the convenience of being able to write backslash-t, but I do not think it outweighs the potential risk of mistakingly passing a string with per-cent in it. -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
Jens Lehmann writes: > Am 28.01.2013 19:51, schrieb Junio C Hamano: >> Lars Hjemli writes: >> Come to think of it, is there a reason why "for-each-repo" should not be an extention to "submodule foreach"? We can view this as visiting repositories that _could_ be registered as a submodule, in addition to iterating over the registered submodules, no? >>> >>> Yes, but I see some possible problems with that approach: >>> -'git for-each-repo' does not need to be started from within a git worktree >> >> True, but "git submodule foreach --untracked" can be told that it is >> OK not (yet) to be in any superproject, no? > > Hmm, I'm not sure how that would work as it looks for gitlinks > in the index which point to work tree paths. I was imagining that "foreach --untracked" could go something like this: * If you are inside an existing git repository, read its index to learn the gitlinks in the directory and its subdirectories. * Start from the current directory and recursively apply the procedure in this step: * Scan the directory and iterate over the ones that has ".git" in it: * If it is a gitlinked one, show it, but do not descend into it unless --recursive is given (e.g. you start from /home/jens, find /home/jens/proj/ directory that has /home/jens/proj/.git in it. /home/jens/.git/index knows that it is a submodule of the top-level superproject. "proj" is handled, and it is up to the --recursive option if its submodules are handled). * If it is _not_ a gitlinked one, show it and descend into it (e.g. /home/jens/ is not a repository or /home/jens/proj is not a tracked submodule) to apply this procedure recursively. Of course, without --untracked, we have no need to iterate over the readdir() return values; instead we just scan the index of the top-level superproject. >>> -'git for-each-repo' and 'git submodule foreach' have different >>> semantics for --dirty and --clean > > I'm confused, what semantics of --dirty and --clean does current > 'git submodule foreach' have? I can't find any sign of it in the > current code ... did I miss something while skimming through this > thread? Or are you talking about status and diff here? I think Lars is hinting that "submodule foreach" could restrict its operation to a similar --dirty/--clean/--both option he has. Of course, the command given to foreach can decide to become no-op by inspecting the submodule itself, so in that sense, --dirty/--clean can be done without, but I think it would make sense to have it in "submodule foreach" even without the "--untracked" option. > But I think the current for-each-repo > proposal doesn't allow to traverse repos which contain untracked > content (and it would be nice if the user could somehow combine > that with the current --dirty flag to have both in one go). Perhaps. I personally felt it was really strange that submodule diff and status consider that it is a sin to have untracked and unignored cruft in the submodule working tree, 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
Re: [PATCH] l10n: de.po: translate 11 new messages
From: "Ralf Thielow" Sent: Monday, January 28, 2013 5:55 PM On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote: Ralf Thielow writes: > #: builtin/reset.c:275 > -#, fuzzy, c-format > +#, c-format > msgid "Failed to resolve '%s' as a valid revision." > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen." > +msgstr "Konnte '%s' nicht als gültige Revision auflösen." You don't have "revision" in the glossary[1] yet. Wouldn't it be appropriate to treat it as "commit", and translate as "Version" to avoid introducing yet another term? Or am I missing some subtle distinction between commit and revision? I don't think there's a distinction. It was a problem I had http://stackoverflow.com/a/11792712/717355 answered as: See "SPECIFYING REVISIONS" of git rev-parse: A revision parameter typically, but not necessarily, names a commit object. It uses what is called an extended SHA1 syntax, [and includes] various ways to spell object names. It had me confused for a while. Since we've already translated "revision" as "Revision" in a couple of other messages, I'll make a new "s/Revision/Version" commit on top. Since it's only a single nit, feel free to add my ack when you reroll: Acked-by: Thomas Rast [1] https://github.com/ralfth/git-po-de/wiki/Glossary -- Thomas Rast trast@{inf,student}.ethz.ch -- Philip Oakley -- 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: [feature request] git add completion should exclude staged content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 28/01/2013 18:52, Junio C Hamano ha scritto: > [...] > > Thanks both for commenting. I'll find time to read it over again > and perhaps we can merge it to 'next' and advertise it in the next > issue of "What's cooking" report to ask for wider testing to move it > forward. Thanks. I will try to update the patch, with your latest suggestions (avoid tricky POSIX shell syntax, and CDPATH issue - if I remember correctly), and with an update for the t/t9902-completion.sh test (that I completely missed). Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEG3IcACgkQscQJ24LbaUTR/wCfSC/kHxseKAQ9rnK2ba/WwND1 cmsAn2CuHpRs2VjippTwkT5O3ul9cQKb =5Way -END PGP SIGNATURE- -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
Am 28.01.2013 19:51, schrieb Junio C Hamano: > Lars Hjemli writes: > >>> Come to think of it, is there a reason why "for-each-repo" should >>> not be an extention to "submodule foreach"? We can view this as >>> visiting repositories that _could_ be registered as a submodule, in >>> addition to iterating over the registered submodules, no? >> >> Yes, but I see some possible problems with that approach: >> -'git for-each-repo' does not need to be started from within a git worktree > > True, but "git submodule foreach --untracked" can be told that it is > OK not (yet) to be in any superproject, no? Hmm, I'm not sure how that would work as it looks for gitlinks in the index which point to work tree paths. >> -'git for-each-repo' and 'git submodule foreach' have different >> semantics for --dirty and --clean I'm confused, what semantics of --dirty and --clean does current 'git submodule foreach' have? I can't find any sign of it in the current code ... did I miss something while skimming through this thread? Or are you talking about status and diff here? > That could be a problem. Is there a good reason why they should use > different definitions of dirtyness? I don't see any (except of course for comparing a gitlink with the HEAD of the submodule, which is an additional condition that only applies to submodules). But I think the current for-each-repo proposal doesn't allow to traverse repos which contain untracked content (and it would be nice if the user could somehow combine that with the current --dirty flag to have both in one go). >> -'git for-each-repo' is in C because my 'git-all' shell script was >> horribly slow on large directory trees (especially on windows) > > Your for-each-repo could be a good basis to build a new builtin > "submodule--foreach" that is a pure helper hidden from the end users > that does both; cmd_foreach() in git-submodule.sh can simply delegate > to it. I like that approach, because the operations are very similar from the user's point of view. But please remember that internally they would work differently, as submodule foreach walks the index and only descends into those submodules that are populated (and contain a .git directory or file) while for-each-repo scans the whole work tree, which makes it a more expensive operation. >> All of these problems are probably solvable, but it would require >> quite some reworking of git-submodule.sh > > Of course some work is needed, but we do not have to convert all the > cmd_foo in git-submodule.sh in one step. For the purpose of > unifying for-each-repo and submodule foreach to deliver the > functionality sooner to the end users, we can go the route to add > only the submodule--foreach builtin, out of which we will get > reusable implementation of module_list and other helper functions we > can leverage later to do other cmd_foo functions. I really like that idea! -- 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: [feature request] git add completion should exclude staged content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 28/01/2013 17:22, Michael J Gruber ha scritto: > [...] >> The patch will suggest (for git add command), all the files that are >> candidate to be added to the index file. >> >> Please, test it and report any behaviour you think is incorrect. > > OK, that seems to work and to be quite helpful. > > Minor nit: "git add -u" could use the same fileset as "git commit". But > I don't know whether completion can act upon the presence of options. It is possible, but I have not implemented since I was not sure about it and I wanted to avoid to make the patch more hard to review. I will work on it after the patch is approved. > Currently, it also includes untracked files (just like without -u) but > omits unmodified and ignored ones, which is already quite an improvement. > > I won't be able to review the completion code but may contribute a few > lines to t/t9902-completion.sh, possibly. > Ah, I missed this test; thanks. The proposed patch must update it. Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEG2+UACgkQscQJ24LbaURstACfdNxuFvaokBSTls20bSQ7jPHA 8I0An3fX6oRKuc2lzAgPVBLjsbjbw91V =igwr -END PGP SIGNATURE- -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
On Mon, Jan 28, 2013 at 7:51 PM, Junio C Hamano wrote: > Lars Hjemli writes: > >>> Come to think of it, is there a reason why "for-each-repo" should >>> not be an extention to "submodule foreach"? We can view this as >>> visiting repositories that _could_ be registered as a submodule, in >>> addition to iterating over the registered submodules, no? >> >> Yes, but I see some possible problems with that approach: >> -'git for-each-repo' does not need to be started from within a git worktree > > True, but "git submodule foreach --untracked" can be told that it is > OK not (yet) to be in any superproject, no? Yes. > >> -'git for-each-repo' and 'git submodule foreach' have different >> semantics for --dirty and --clean > > That could be a problem. Is there a good reason why they should use > different definitions of dirtyness? I suspected that 'submodule foreach --dirty' might want to compare the HEAD sha1 in the submodule against the one recorded in the superproject (similar to what 'git submodule status' does), but such a check could be triggered by a different flag (e.g. --behind/--ahead or something similar). >> -'git for-each-repo' is in C because my 'git-all' shell script was >> horribly slow on large directory trees (especially on windows) > > Your for-each-repo could be a good basis to build a new builtin > "submodule--foreach" that is a pure helper hidden from the end users > that does both; cmd_foreach() in git-submodule.sh can simply delegate > to it. Ok, I'll rework my patches in this direction. Thanks. -- larsh -- 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 3/4] mergetool--lib: Add functions for finding available tools
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote: > Refactor show_tool_help() so that the tool-finding logic is broken out > into a separate show_tool_names() function. > > Signed-off-by: David Aguilar > --- > filter_tools renamed to show_tool_names() and simplfied > to use ls -1. show_tool_names() now has a preamble as discussed. > > git-mergetool--lib.sh | 68 > +-- > 1 file changed, 39 insertions(+), 29 deletions(-) > > diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh > index db3eb58..fe068f6 100644 > --- a/git-mergetool--lib.sh > +++ b/git-mergetool--lib.sh > @@ -2,6 +2,35 @@ > # git-mergetool--lib is a library for common merge tool functions > MERGE_TOOLS_DIR=$(git --exec-path)/mergetools > > +mode_ok () { > + diff_mode && can_diff || > + merge_mode && can_merge > +} > + > +is_available () { > + merge_tool_path=$(translate_merge_tool_path "$1") && > + type "$merge_tool_path" >/dev/null 2>&1 > +} > + Can we move show_tool_names() to be above show_tool_help()? It's a very minor nit but I prefer having related functionality grouped together. > +show_tool_names () { > + condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-} Would this be better with one value on each line? Also perhaps per_line_prefix -> line_prefix. > + > + ( cd "$MERGE_TOOLS_DIR" && ls -1 * ) | > + while read toolname > + do > + if setup_tool "$toolname" 2>/dev/null && > + (eval "$condition" "$toolname") > + then > + if test -n "$preamble" > + then > + echo "$preamble" > + preamble= > + fi > + printf "%s%s\n" "$per_line_prefix" "$tool" This needs to be: printf "$per_line_prefix%s\n" "$tool" since $per_line_prefix is usually '\t\t' which isn't expanded if we format it with %s - an alternative would be to change the value passed in to '$TAB$TAB' with literal tabs. > + fi > + done > +} > + > diff_mode() { > test "$TOOL_MODE" = diff > } -- 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] fixup! mergetools: simplify how we handle "vim" and "defaults"
--- Junio, please can you squash this into f9924e5 on jk/mergetool, providing that David is OK with that? The original change breaks custom mergetool by making changing the logic around default functions so that they are now only defined when the tool file exists in $MERGE_TOOLS_DIR but we need the default implementations when a custom tool is in use, which by definition means that the file doesn't exist in $MERGE_TOOLS_DIR. git-mergetool--lib.sh | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh index 1d0fb12..211ffe5 100644 --- a/git-mergetool--lib.sh +++ b/git-mergetool--lib.sh @@ -48,15 +48,6 @@ valid_tool () { setup_tool () { tool="$1" - if ! test -f "$MERGE_TOOLS_DIR/$tool" - then - # Use a special return code for this case since we want to - # source "defaults" even when an explicit tool path is - # configured since the user can use that to override the - # default path in the scriptlet. - return 2 - fi - # Fallback definitions, to be overriden by tools. can_merge () { return 0 @@ -80,6 +71,15 @@ setup_tool () { echo "$1" } + if ! test -f "$MERGE_TOOLS_DIR/$tool" + then + # Use a special return code for this case since we want to + # source "defaults" even when an explicit tool path is + # configured since the user can use that to override the + # default path in the scriptlet. + return 2 + fi + # Load the redefined functions . "$MERGE_TOOLS_DIR/$tool" -- 1.8.1.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
[PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
--- gitweb/gitweb.perl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index c6bafe6..1309196 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -2068,7 +2068,7 @@ sub picon_url { if (!$avatar_cache{$email}) { my ($user, $domain) = split('@', $email); $avatar_cache{$email} = - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; . + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" . "$domain/$user/" . "users+domains+unknown/up/single"; } @@ -2083,7 +2083,7 @@ sub gravatar_url { my $email = lc shift; my $size = shift; $avatar_cache{$email} ||= - "http://www.gravatar.com/avatar/"; . + "//www.gravatar.com/avatar/" . Digest::MD5::md5_hex($email) . "?s="; return $avatar_cache{$email} . $size; } -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
Lars Hjemli writes: >> Come to think of it, is there a reason why "for-each-repo" should >> not be an extention to "submodule foreach"? We can view this as >> visiting repositories that _could_ be registered as a submodule, in >> addition to iterating over the registered submodules, no? > > Yes, but I see some possible problems with that approach: > -'git for-each-repo' does not need to be started from within a git worktree True, but "git submodule foreach --untracked" can be told that it is OK not (yet) to be in any superproject, no? > -'git for-each-repo' and 'git submodule foreach' have different > semantics for --dirty and --clean That could be a problem. Is there a good reason why they should use different definitions of dirtyness? > -'git for-each-repo' is in C because my 'git-all' shell script was > horribly slow on large directory trees (especially on windows) Your for-each-repo could be a good basis to build a new builtin "submodule--foreach" that is a pure helper hidden from the end users that does both; cmd_foreach() in git-submodule.sh can simply delegate to it. > All of these problems are probably solvable, but it would require > quite some reworking of git-submodule.sh Of course some work is needed, but we do not have to convert all the cmd_foo in git-submodule.sh in one step. For the purpose of unifying for-each-repo and submodule foreach to deliver the functionality sooner to the end users, we can go the route to add only the submodule--foreach builtin, out of which we will get reusable implementation of module_list and other helper functions we can leverage later to do other cmd_foo functions. -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
On Mon, Jan 28, 2013 at 6:45 PM, Junio C Hamano wrote: > As to the pathspec limiting to affect the loop itself, not the > argument given to the command that is run, I don't think it is > absolutely needed; I am perfectly fine with declaring that > for-each-repo goes to repositories in all subdirectories without > limit, especially if doing so will make the UI issues we have to > deal with simpler. Good (since the relative path of each repo will be exported to the child process, that process can perform path limiting when needed). > As to the "option to the command, not to the subcommand, -a option", > I have been assuming that it was a joke patch, but if "git -a grep" > turns out to be really useful, "submodule foreach" that iterates > over the submodules may also want to have such a short and sweet > mechanism. Between "for-each-repo" and "submodule foreach", I do > not yet have a strong opinion on which one deserves it more. > > Come to think of it, is there a reason why "for-each-repo" should > not be an extention to "submodule foreach"? We can view this as > visiting repositories that _could_ be registered as a submodule, in > addition to iterating over the registered submodules, no? Yes, but I see some possible problems with that approach: -'git for-each-repo' does not need to be started from within a git worktree -'git for-each-repo' and 'git submodule foreach' have different semantics for --dirty and --clean -'git for-each-repo' is in C because my 'git-all' shell script was horribly slow on large directory trees (especially on windows) All of these problems are probably solvable, but it would require quite some reworking of git-submodule.sh -- larsh -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
Lars Hjemli writes: > On Mon, Jan 28, 2013 at 9:10 AM, Jonathan Nieder wrote: >> ... >> So if I ran the world, then having commands >> >> git -a diff >> >> and >> >> git for-each-repo git diff >> >> do the same thing would be fine. Of course I don't run the world. ;-) > > This would make me very happy. Junio? Ahh, our mails crossed (rather, I responded to the other message I saw before I saw this one). I am not completely sold on "git -a" yet, but another worry I have is which one between "submodule foreach" and "for-each-repo" should use "git -a", if we decide that it is useful to the users to add it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] l10n: de.po: translate "revision" consistently as "Version"
In the German translation, we have translated "revision" as both "Revision" and "Version". In the context of version control, revision has the same meaning as commit, so we don't need to use both terms. "revision" is now consistently translated as "Version". Signed-off-by: Ralf Thielow --- po/de.po | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/po/de.po b/po/de.po index ed8330a..6c7384b 100644 --- a/po/de.po +++ b/po/de.po @@ -156,7 +156,7 @@ msgstr "Dem Projektarchiv fehlen folgende vorausgesetzte Versionen:" #: builtin/log.c:751 builtin/log.c:1358 builtin/log.c:1574 builtin/merge.c:347 #: builtin/shortlog.c:157 msgid "revision walk setup failed" -msgstr "Einrichtung des Revisionsgangs fehlgeschlagen" +msgstr "Einrichtung des Versionsgangs fehlgeschlagen" #: bundle.c:186 #, c-format @@ -2201,7 +2201,7 @@ msgstr "arbeite länger, um bessere Übereinstimmungen zu finden" #: builtin/blame.c:2380 msgid "Use revisions from instead of calling git-rev-list" -msgstr "Benutzt Revisionen von anstatt \"git-rev-list\" aufzurufen" +msgstr "Benutzt Versionen von anstatt \"git-rev-list\" aufzurufen" #: builtin/blame.c:2381 msgid "Use 's contents as the final image" @@ -2832,7 +2832,7 @@ msgstr "" #: builtin/checkout.c:730 msgid "internal error in revision walk" -msgstr "interner Fehler im Revisionsgang" +msgstr "interner Fehler im Versionsgang" #: builtin/checkout.c:734 msgid "Previous HEAD position was" @@ -6193,7 +6193,7 @@ msgstr "findet Vorfahren für eine einzelne n-Wege-Zusammenführung" #: builtin/merge-base.c:100 msgid "list revs not reachable from others" -msgstr "listet Revisionen auf, die nicht durch Andere erreichbar sind" +msgstr "listet Versionen auf, die nicht durch Andere erreichbar sind" #: builtin/merge-base.c:102 msgid "is the first one ancestor of the other?" @@ -6831,7 +6831,7 @@ msgstr "erzeugt keine leeren Pakete" #: builtin/pack-objects.c:2481 msgid "read revision arguments from standard input" -msgstr "liest Argumente bezüglich Revisionen von der Standard-Eingabe" +msgstr "liest Argumente bezüglich Versionen von der Standard-Eingabe" #: builtin/pack-objects.c:2483 msgid "limit the objects to those that are not yet packed" @@ -7917,7 +7917,7 @@ msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen" #: builtin/reset.c:275 #, c-format msgid "Failed to resolve '%s' as a valid revision." -msgstr "Konnte '%s' nicht als gültige Revision auflösen." +msgstr "Konnte '%s' nicht als gültige Version auflösen." #: builtin/reset.c:278 builtin/reset.c:286 #, c-format @@ -8193,7 +8193,7 @@ msgstr "" "git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order] [--" "current] [--color[=] | --no-color] [--sparse] [--more= | --list | --" "independent | --merge-base] [--no-name | --sha1-name] [--topics] " -"[( | )...]" +"[( | )...]" #: builtin/show-branch.c:10 msgid "git show-branch (-g|--reflog)[=[,]] [--list] []" @@ -9440,7 +9440,7 @@ msgstr "Kein \"stash\" gefunden." #: git-stash.sh:359 #, sh-format msgid "Too many revisions specified: $REV" -msgstr "Zu viele Revisionen angegeben: $REV" +msgstr "Zu viele Versionen angegeben: $REV" #: git-stash.sh:365 #, sh-format -- 1.8.1.1.439.g50a6b54 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] l10n: de.po: translate "reset" as "neu setzen"
According to the glossary, "reset" should be translated as "neu setzen" but in a couple of messages we've translated it as "zurücksetzen". This fixes that. Signed-off-by: Ralf Thielow --- Note that the part "neu" is not used in any places because I think sometimes it sounds better without them. po/de.po | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/po/de.po b/po/de.po index 6c7384b..9b1f589 100644 --- a/po/de.po +++ b/po/de.po @@ -2764,7 +2764,7 @@ msgstr "Zweigspitze (HEAD) ist jetzt bei" #: builtin/checkout.c:609 #, c-format msgid "Reset branch '%s'\n" -msgstr "Setze Zweig '%s' zurück\n" +msgstr "Setze Zweig '%s' neu\n" #: builtin/checkout.c:612 #, c-format @@ -2774,7 +2774,7 @@ msgstr "Bereits auf '%s'\n" #: builtin/checkout.c:616 #, c-format msgid "Switched to and reset branch '%s'\n" -msgstr "Gewechselt zu zurückgesetztem Zweig '%s'\n" +msgstr "Gewechselt zu neu gesetztem Zweig '%s'\n" #: builtin/checkout.c:618 builtin/checkout.c:955 #, c-format @@ -7900,19 +7900,19 @@ msgstr "weniger Ausgaben, meldet nur Fehler" #: builtin/reset.c:250 msgid "reset HEAD and index" -msgstr "setzt Zweigspitze (HEAD) und Bereitstellung zurück" +msgstr "setzt Zweigspitze (HEAD) und Bereitstellung neu" #: builtin/reset.c:251 msgid "reset only HEAD" -msgstr "setzt nur Zweigspitze (HEAD) zurück" +msgstr "setzt nur Zweigspitze (HEAD) neu" #: builtin/reset.c:253 builtin/reset.c:255 msgid "reset HEAD, index and working tree" -msgstr "setzt Zweigspitze (HEAD), Bereitstellung und Arbeitsbaum zurück" +msgstr "setzt Zweigspitze (HEAD), Bereitstellung und Arbeitsbaum neu" #: builtin/reset.c:257 msgid "reset HEAD but keep local changes" -msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen" +msgstr "setzt Zweigspitze (HEAD) neu, behält aber lokale Änderungen" #: builtin/reset.c:275 #, c-format @@ -7952,7 +7952,7 @@ msgstr "'%s' Zurücksetzung ist in einem bloßen Projektarchiv nicht erlaubt" #: builtin/reset.c:333 #, c-format msgid "Could not reset index file to revision '%s'." -msgstr "Konnte Bereitstellungsdatei nicht zu Version '%s' zurücksetzen." +msgstr "Konnte Bereitstellungsdatei nicht zu Version '%s' setzen." #: builtin/reset.c:339 msgid "Unstaged changes after reset:" @@ -8833,7 +8833,7 @@ msgstr "Baut lokale Versionen auf einem aktuellerem externen Zweig neu auf" #: common-cmds.h:24 msgid "Reset current HEAD to the specified state" msgstr "" -"Setzt die aktuelle Zweigspitze (HEAD) zu einem spezifizierten Zustand zurück" +"Setzt die aktuelle Zweigspitze (HEAD) zu einem spezifizierten Zustand" #: common-cmds.h:25 msgid "Remove files from the working tree and from the index" -- 1.8.1.1.439.g50a6b54 -- 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
[PATCHv2] l10n: de.po: translate 11 new messages
Translate 11 new messages came from git.pot update in 46bc403 (l10n: Update git.pot (11 new, 7 removed messages)). Signed-off-by: Ralf Thielow Acked-by: Thomas Rast --- po/de.po | 37 ++--- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/po/de.po b/po/de.po index 3779f4c..ed8330a 100644 --- a/po/de.po +++ b/po/de.po @@ -5,7 +5,7 @@ # msgid "" msgstr "" -"Project-Id-Version: git 1.8.1\n" +"Project-Id-Version: git 1.8.2\n" "Report-Msgid-Bugs-To: Git Mailing List \n" "POT-Creation-Date: 2013-01-25 12:33+0800\n" "PO-Revision-Date: 2012-10-02 19:35+0200\n" @@ -1033,9 +1033,9 @@ msgid "unable to access '%s': %s" msgstr "konnte nicht auf '%s' zugreifen: %s" #: wrapper.c:423 -#, fuzzy, c-format +#, c-format msgid "unable to access '%s'" -msgstr "konnte nicht auf '%s' zugreifen: %s" +msgstr "konnte nicht auf '%s' zugreifen" #: wrapper.c:434 #, c-format @@ -2997,14 +2997,14 @@ msgid "Would remove %s\n" msgstr "Würde %s löschen\n" #: builtin/clean.c:26 -#, fuzzy, c-format +#, c-format msgid "Skipping repository %s\n" -msgstr "ungültiges Projektarchiv '%s'" +msgstr "Überspringe Projektarchiv %s\n" #: builtin/clean.c:27 -#, fuzzy, c-format +#, c-format msgid "Would skip repository %s\n" -msgstr "ungültiges Projektarchiv '%s'" +msgstr "Würde Projektarchiv %s überspringen\n" #: builtin/clean.c:28 #, c-format @@ -3223,9 +3223,8 @@ msgid "--bare and --origin %s options are incompatible." msgstr "Die Optionen --bare und --origin %s sind inkompatibel." #: builtin/clone.c:708 -#, fuzzy msgid "--bare and --separate-git-dir are incompatible." -msgstr "Die Optionen --bare und --origin %s sind inkompatibel." +msgstr "Die Optionen --bare und --separate-git-dir sind inkompatibel." #: builtin/clone.c:721 #, c-format @@ -5449,7 +5448,7 @@ msgstr "zeigt Quelle" #: builtin/log.c:104 msgid "Use mail map file" -msgstr "" +msgstr "verwendet \"mailmap\"-Datei" #: builtin/log.c:105 msgid "decorate options" @@ -5542,7 +5541,7 @@ msgstr "beginnt die Nummerierung der Patches bei anstatt bei 1" #: builtin/log.c:1114 msgid "mark the series as Nth re-roll" -msgstr "" +msgstr "kennzeichnet die Serie als n-te Fassung" #: builtin/log.c:1116 msgid "Use [] instead of [PATCH]" @@ -7099,6 +7098,8 @@ msgid "" "Updates were rejected because the destination reference already exists\n" "in the remote." msgstr "" +"Aktualisierungen wurden zurückgewiesen, weil die Zielreferenz bereits\n" +"im Fernarchiv existiert." #: builtin/push.c:269 #, c-format @@ -7841,14 +7842,12 @@ msgstr "" "git reset [--mixed | --soft | --hard | --merge | --keep] [-q] []" #: builtin/reset.c:26 -#, fuzzy msgid "git reset [-q] [--] ..." -msgstr "git reset [-q] [--] ..." +msgstr "git reset [-q] [--] ..." #: builtin/reset.c:27 -#, fuzzy msgid "git reset --patch [] [--] [...]" -msgstr "git reset --patch [] [--] [...]" +msgstr "git reset --patch [] [--] [...]" #: builtin/reset.c:33 msgid "mixed" @@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes" msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen" #: builtin/reset.c:275 -#, fuzzy, c-format +#, c-format msgid "Failed to resolve '%s' as a valid revision." -msgstr "Konnte '%s' nicht als gültige Referenz auflösen." +msgstr "Konnte '%s' nicht als gültige Revision auflösen." #: builtin/reset.c:278 builtin/reset.c:286 #, c-format @@ -7926,9 +7925,9 @@ msgid "Could not parse object '%s'." msgstr "Konnte Objekt '%s' nicht parsen." #: builtin/reset.c:283 -#, fuzzy, c-format +#, c-format msgid "Failed to resolve '%s' as a valid tree." -msgstr "Konnte '%s' nicht als gültige Referenz auflösen." +msgstr "Konnte '%s' nicht als gültigen Baum auflösen." #: builtin/reset.c:292 msgid "--patch is incompatible with --{hard,mixed,soft}" -- 1.8.1.1.439.g50a6b54 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] add: warn when -u or -A is used without filepattern
Matthieu Moy writes: > Junio C Hamano writes: > >> I think "add -u && commit" vs "commit -a" you brought up is a good >> thing to mention, so let's do this. > > I'm OK with your proposal. Let me know if you want me to resend. Thanks for a quick response. As you may have guessed, I am sending these after running "commit --amend", so ... >> The inconsistency of 'git add -u' and 'git add -A' are particularly > > Nitpick: this should be "inconsistencies" (or "is particularly"). ... it is much easier for me to fix these locally instead of getting a reroll. Will amend with s/are particularly/is particularly/; 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/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
Jonathan Nieder wrote: > Throughout git, it is assumed that the WIN32 preprocessor symbol is > defined on native Windows setups (mingw and msvc) and not on Cygwin. > On Cygwin, most of the time git can pretend this is just another Unix > machine, and Windows-specific magic is generally counterproductive. > > Unfortunately Cygwin *does* define the WIN32 symbol in some headers. > Best to rely on a new git-specific symbol NATIVE_WINDOWS instead, > defined as follows: > > #if defined(WIN32) && !defined(__CYGWIN__) > # define NATIVE_WINDOWS > #endif > > After this change, it should be possible to drop the > CYGWIN_V15_WIN32API setting without any negative effect. > > Signed-off-by: Jonathan Nieder If we go with this approach, could we prefix the symbol name with GIT_ in order to reduce the global namespace pollution? eg GIT_NATIVE_WINDOWS, or GIT_NATIVE_WIN32 or just GIT_WIN32. (Yeah, I'm not good at choosing names!) ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] add: warn when -u or -A is used without filepattern
Junio C Hamano writes: > I think "add -u && commit" vs "commit -a" you brought up is a good > thing to mention, so let's do this. I'm OK with your proposal. Let me know if you want me to resend. > The inconsistency of 'git add -u' and 'git add -A' are particularly Nitpick: this should be "inconsistencies" (or "is particularly"). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] l10n: de.po: translate 11 new messages
On Mon, Jan 28, 2013 at 05:39:27PM +0100, Joachim Schmitz wrote: > Ralf Thielow wrote: > >Translate 11 new messages came from git.pot update > >in 46bc403 (l10n: Update git.pot (11 new, 7 removed > >messages)). > > > >Signed-off-by: Ralf Thielow > >--- > > po/de.po | 37 ++--- > > 1 file changed, 18 insertions(+), 19 deletions(-) > > > >diff --git a/po/de.po b/po/de.po > >index 3779f4c..ed8330a 100644 > >--- a/po/de.po > >+++ b/po/de.po > >@@ -5,7 +5,7 @@ > > # > > msgid "" > > msgstr "" > >-"Project-Id-Version: git 1.8.1\n" > >+"Project-Id-Version: git 1.8.2\n" > > Not "Projekt-Id-Version ..."? > I don't think that we need to translate this. > > #: builtin/reset.c:33 > > msgid "mixed" > >@@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes" > > msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale > >Änderungen" > > Not "reset -> setze" and "keep" -> halte (imperativ)? > Or is the enlish text wrong and should be "resets" and "keeps" > All translations which describe an option shown by "git -h" are (or should be) like this. The reading is like "This option..." followed by such a messages. That's at least how it's done. I don't think it sounds bad. According to the glossary, the translation here is wrong because "reset" is not "*zurück* setzen" but "neu setzen". I'll fix this (and perhaps other messages) on a commit on top. > Bye, Jojo > > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] add: warn when -u or -A is used without filepattern
Michael J Gruber writes: > Matthieu Moy venit, vidit, dixit 28.01.2013 10:16: >> Most git commands that can be used with our without a filepattern are >> tree-wide by default, the filepattern being used to restrict their scope. >> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. > > Since I didn't follow this thread, my first reaction was: "Huh? Aren't > they treewide?" (for the relative tree) > > So, for someone reading just the commit message, it would be helpful to > say what the others do, i.e. default to the relative tree at pwd (rather > than defaulting to an empty tree, or all files whether tracked or not, > or...). I think "add -u && commit" vs "commit -a" you brought up is a good thing to mention, so let's do this. Another tweak is that I did s/filepattern/pathspec/ here. I know that both the documentation and the help text for "git add" say filepattern, but we say pathspec starting from glossary fairly consistently everywhere in the rest of the system. We should probably update the documentation/help for "git add", but that is entirely a separate topic. add: warn when -u or -A is used without pathspec Most Git commands that can be used with or without pathspec operate tree-wide by default, the pathspec being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. When run in a subdirectory without pathspec, they operate only on paths in the current directory. The inconsistency of 'git add -u' and 'git add -A' are particularly problematic since other 'git add' subcommands (namely 'git add -p' and 'git add -e') are tree-wide by default. It also means that "git add -u && git commit" will record a state that is different from what is recorded with "git commit -a". Flipping the default now is unacceptable, so let's start training users to type 'git add -u|-A :/' or 'git add -u|-A .' explicitly, to prepare for the next steps: * forbid 'git add -u|-A' without pathspec (like 'git add' without option) * much later, maybe, re-allow 'git add -u|-A' without pathspec, that will add all tracked and modified files, or all files, tree-wide. A nice side effect of this patch is that it makes the :/ magic pathspec easier to discover for users. When the command is called from the root of the tree, there is no ambiguity and no need to change the behavior, hence no need to warn. Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano -- 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] l10n: de.po: translate 11 new messages
On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote: > Ralf Thielow writes: > > > #: builtin/reset.c:275 > > -#, fuzzy, c-format > > +#, c-format > > msgid "Failed to resolve '%s' as a valid revision." > > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen." > > +msgstr "Konnte '%s' nicht als gültige Revision auflösen." > > You don't have "revision" in the glossary[1] yet. Wouldn't it be > appropriate to treat it as "commit", and translate as "Version" to avoid > introducing yet another term? > > Or am I missing some subtle distinction between commit and revision? > I don't think there's a distinction. Since we've already translated "revision" as "Revision" in a couple of other messages, I'll make a new "s/Revision/Version" commit on top. > Since it's only a single nit, feel free to add my ack when you reroll: > > Acked-by: Thomas Rast > > > [1] https://github.com/ralfth/git-po-de/wiki/Glossary > > -- > Thomas Rast > trast@{inf,student}.ethz.ch -- 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] fixup! git-remote-testpy: fix path hashing on Python 3
John Keeping writes: > --- > On Mon, Jan 28, 2013 at 11:44:34AM +0100, Michael Haggerty wrote: >> NAK. It is still not right. If the locale is not utf-8 based, then it >> is incorrect to re-encode the string using utf-8. I think you really >> have to use sys.getfilesystemencoding() as I suggested. > > If you'd asked me what the patch contained I would have said it did use > getfilesystemencoding(), but I can't disbelieve my own eyes :-( > > Junio, please can you squash this in? Sure. Thanks for double-checking, Michael. I knew there was something missing but I didn't spot the difference myself. > git-remote-testpy.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/git-remote-testpy.py b/git-remote-testpy.py > index 6098bdd..ca67899 100644 > --- a/git-remote-testpy.py > +++ b/git-remote-testpy.py > @@ -49,7 +49,7 @@ def encode_filepath(path): > """ > if sys.hexversion < 0x0300: > return path > -return path.encode('utf-8', 'surrogateescape') > +return path.encode(sys.getfilesystemencoding(), 'surrogateescape') > > > def get_repo(alias, url): -- 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: [feature request] git add completion should exclude staged content
Michael J Gruber writes: > Manlio Perillo venit, vidit, dixit 28.01.2013 15:02: >> Please, test it and report any behaviour you think is incorrect. > > OK, that seems to work and to be quite helpful. > > Minor nit: "git add -u" could use the same fileset as "git commit". But > I don't know whether completion can act upon the presence of options. > Currently, it also includes untracked files (just like without -u) but > omits unmodified and ignored ones, which is already quite an improvement. > > I won't be able to review the completion code but may contribute a few > lines to t/t9902-completion.sh, possibly. Thanks both for commenting. I'll find time to read it over again and perhaps we can merge it to 'next' and advertise it in the next issue of "What's cooking" report to ask for wider testing to move it forward. -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
Jonathan Nieder writes: > Tracing backwards: it would be really nice to be able to do > > git for-each-repo git grep -e foo -- '*.c' This is a very good example that shows the command that is run in the repositories found may want pathspecs passed, but at the same time, makes me realize that these repositories have to be fairly uniform for this command to be useful. For example, 'src/*.c' or 'inc/*.h' pathspecs wouldn't be useful unless majority if not all projects the loop finds follow that layout convention. This is not necessarily limited to pathspecs, of course. Unless they all have the 'next' branch "git for-each-repo checkout next" would not work, etc. etc. As to the pathspec limiting to affect the loop itself, not the argument given to the command that is run, I don't think it is absolutely needed; I am perfectly fine with declaring that for-each-repo goes to repositories in all subdirectories without limit, especially if doing so will make the UI issues we have to deal with simpler. As to the "option to the command, not to the subcommand, -a option", I have been assuming that it was a joke patch, but if "git -a grep" turns out to be really useful, "submodule foreach" that iterates over the submodules may also want to have such a short and sweet mechanism. Between "for-each-repo" and "submodule foreach", I do not yet have a strong opinion on which one deserves it more. Come to think of it, is there a reason why "for-each-repo" should not be an extention to "submodule foreach"? We can view this as visiting repositories that _could_ be registered as a submodule, in addition to iterating over the registered submodules, no? If these two are unified, then we do not have to even worry about which one deserves "git -a" more. -- 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
Bug, feature, or pilot error: format-patch
I am not on the mailing list so please CC me. I am running git 1.8.1 on Fedora 18. I aam having what appears to be a problem. Here is the sequence which generally describes what I did and what happened: git checkout -b test1 master git am 0001-simple-1.patch git checkout -b test2 master git am 0001-simple-2.patch### this is known to conflict with 0001-simple-1.patch git checkout test1 git merge test2 [here git-merge detects a conflict] git mergetool ###to resolve the conflict [conflict resolved] git commit -a -s git log [shows two commits -- one for simple-2 and one for the merge] git format-patch master..HEAD [two patch files created: 0001-simple-1.patch and 0002-simple-2.patch] [0002-simple-2.patch and 0001-simple-2.patch are exactly equal and do not reflect the resolved conflict] If you do git-diff between and HEAD, you get something different that you got from format-patch. 1. Bug ... format-patch is broken 2. Feature ... that is the way it works 3. Pilot error ... ?? I can create a good version of patch-2 manually but should I have to? Color me foolish but I assumed I could do git-format-patch in one branch and then use git-am to recreate that branch elsewhere. Gene -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
On Mon, Jan 28, 2013 at 9:10 AM, Jonathan Nieder wrote: > > Lars Hjemli wrote: > >> [1] The 'git -a' rewrite patch shows how I think about this command - >> it's just an option to the 'git' command, modifying the way any >> subcommand is invoked (btw: I don't expect that patch to be applied >> since 'git-all' was deemed to generic, so I'll just carry the patch in >> my own tree). > > As one data point, 'git all' also seems too generic to me but 'git -a' > doesn't. Intuition can be weird. > > So if I ran the world, then having commands > > git -a diff > > and > > git for-each-repo git diff > > do the same thing would be fine. Of course I don't run the world. ;-) This would make me very happy. Junio? -- larsh -- 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] l10n: de.po: translate 11 new messages
Ralf Thielow wrote: Translate 11 new messages came from git.pot update in 46bc403 (l10n: Update git.pot (11 new, 7 removed messages)). Signed-off-by: Ralf Thielow --- po/de.po | 37 ++--- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/po/de.po b/po/de.po index 3779f4c..ed8330a 100644 --- a/po/de.po +++ b/po/de.po @@ -5,7 +5,7 @@ # msgid "" msgstr "" -"Project-Id-Version: git 1.8.1\n" +"Project-Id-Version: git 1.8.2\n" Not "Projekt-Id-Version ..."? #: builtin/reset.c:33 msgid "mixed" @@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes" msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen" Not "reset -> setze" and "keep" -> halte (imperativ)? Or is the enlish text wrong and should be "resets" and "keeps" Bye, Jojo -- 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: [feature request] git add completion should exclude staged content
Manlio Perillo venit, vidit, dixit 28.01.2013 15:02: > Il 28/01/2013 13:52, Michael J Gruber ha scritto: >> Manlio Perillo venit, vidit, dixit 28.01.2013 10:26: >>> Il 28/01/2013 00:00, Junio C Hamano ha scritto: wookietreiber writes: >>> > I have a feature request for `git add` auto completion: > >> [...] >>> For the OP: the last patch can be found in the mailing list archive, >>> with the subject: >>> [PATCH v5] git-completion.bash: add support for path completion >>> and date: >>> Fri, 11 Jan 2013 19:48:43 +0100 >>> >>> Can you please test it? >>> > >> I haven't looked at the patch, but in the example above, untracked >> files) could be added as well (unless you use -u), so maybe the scope >> should depend on the option? If the new completion code kept me from >> adding untracked files easily it wouldn't be an improvement. > > > The patch will suggest (for git add command), all the files that are > candidate to be added to the index file. > > Please, test it and report any behaviour you think is incorrect. OK, that seems to work and to be quite helpful. Minor nit: "git add -u" could use the same fileset as "git commit". But I don't know whether completion can act upon the presence of options. Currently, it also includes untracked files (just like without -u) but omits unmodified and ignored ones, which is already quite an improvement. I won't be able to review the completion code but may contribute a few lines to t/t9902-completion.sh, possibly. Michael -- 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: [feature request] git add completion should exclude staged content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 28/01/2013 13:52, Michael J Gruber ha scritto: > Manlio Perillo venit, vidit, dixit 28.01.2013 10:26: >> Il 28/01/2013 00:00, Junio C Hamano ha scritto: >>> wookietreiber writes: >> I have a feature request for `git add` auto completion: > [...] >> For the OP: the last patch can be found in the mailing list archive, >> with the subject: >> [PATCH v5] git-completion.bash: add support for path completion >> and date: >> Fri, 11 Jan 2013 19:48:43 +0100 >> >> Can you please test it? >> > > I haven't looked at the patch, but in the example above, untracked > files) could be added as well (unless you use -u), so maybe the scope > should depend on the option? If the new completion code kept me from > adding untracked files easily it wouldn't be an improvement. > The patch will suggest (for git add command), all the files that are candidate to be added to the index file. Please, test it and report any behaviour you think is incorrect. Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEGhPsACgkQscQJ24LbaUTYOwCdFagTRkHzUHoFwy3U+Vz6tAzE tVIAnj8fAbyGrlNUoUgI4ZshwOtlEH8v =jy8R -END PGP SIGNATURE- -- 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: [feature request] git add completion should exclude staged content
Manlio Perillo venit, vidit, dixit 28.01.2013 10:26: > Il 28/01/2013 00:00, Junio C Hamano ha scritto: >> wookietreiber writes: > >>> I have a feature request for `git add` auto completion: >>> >>> `git add` auto completion suggests all files / directories, >>> filtered by nothing. I guess it would be much nicer (as in >>> increasing productivity) if it would only suggest unstaged >>> content, as reported by `git status`, because that would be the >>> only content one would be able to add. > >> I think that is what Manlio Perillo tried to do with the stalled >> mp/complete-paths topic that is queued in 'pu'. > >> Manlio, any progress? > > Well, I assumed that the patch was stalled due to missing review from > git completion experts... > > For this reason I have not updated it with your latest suggestions, > waiting for the review (also, because now I'm busy with other projects). > > For the OP: the last patch can be found in the mailing list archive, > with the subject: > [PATCH v5] git-completion.bash: add support for path completion > and date: > Fri, 11 Jan 2013 19:48:43 +0100 > > Can you please test it? > > > > > Regards Manlio > I haven't looked at the patch, but in the example above, untracked files) could be added as well (unless you use -u), so maybe the scope should depend on the option? If the new completion code kept me from adding untracked files easily it wouldn't be an improvement. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] add: warn when -u or -A is used without filepattern
Matthieu Moy venit, vidit, dixit 28.01.2013 10:16: > Most git commands that can be used with our without a filepattern are > tree-wide by default, the filepattern being used to restrict their scope. > A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. Since I didn't follow this thread, my first reaction was: "Huh? Aren't they treewide?" (for the relative tree) So, for someone reading just the commit message, it would be helpful to say what the others do, i.e. default to the relative tree at pwd (rather than defaulting to an empty tree, or all files whether tracked or not, or...). Otherwise, I'd rather switch sooner than later; it's so easy to take "git add -u && git commit == git commit -a" for granted and to miss staging some hunks. But 2.0 is around the corner anyway, isn't it ;) > The inconsistency of 'git add -u' and 'git add -A' are particularly > problematic since other 'git add' subcommands (namely 'git add -p' and > 'git add -e') are tree-wide by default. > > Flipping the default now is unacceptable, so this patch starts training > users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare > for the next steps: > > * forbid 'git add -u|-A' without filepattern (like 'git add' without > option) > > * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a > tree-wide scope. > > A nice side effect of this patch is that it makes the :/ special > filepattern easier to discover for users. > > When the command is called from the root of the tree, there is no > ambiguity and no need to change the behavior, hence no need to warn. > > Signed-off-by: Matthieu Moy > --- > Changes since v2: > > * Typo consistant -> consistent > > * Mention both short and long option names (Thanks Junio). I went for > a two-lines display which I find a bit nicer to read than Junio's > version, but I'm fine with both. > > Documentation/git-add.txt | 7 --- > builtin/add.c | 44 +++- > 2 files changed, 47 insertions(+), 4 deletions(-) > > diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt > index fd9e36b..5333559 100644 > --- a/Documentation/git-add.txt > +++ b/Documentation/git-add.txt > @@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below. > from the index if the corresponding files in the working tree > have been removed. > + > -If no is given, default to "."; in other words, > -update all tracked files in the current directory and its > -subdirectories. > +If no is given, the current version of Git defaults to > +"."; in other words, update all tracked files in the current directory > +and its subdirectories. This default will change in a future version > +of Git, hence the form without should not be used. > > -A:: > --all:: > diff --git a/builtin/add.c b/builtin/add.c > index 7cb6cca..7738025 100644 > --- a/builtin/add.c > +++ b/builtin/add.c > @@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags) > return exit_status; > } > > +static void warn_pathless_add(const char *option_name, const char > *short_name) { > + /* > + * To be consistent with "git add -p" and most Git > + * commands, we should default to being tree-wide, but > + * this is not the original behavior and can't be > + * changed until users trained themselves not to type > + * "git add -u" or "git add -A". For now, we warn and > + * keep the old behavior. Later, this warning can be > + * turned into a die(...), and eventually we may > + * reallow the command with a new behavior. > + */ > + warning(_("The behavior of 'git add %s (or %s)' with no path argument > from a\n" > + "subdirectory of the tree will change in Git 2.0 and should > not be used anymore.\n" > + "To add content for the whole tree, run:\n" > + "\n" > + " git add %s :/\n" > + " (or git add %s :/)\n" > + "\n" > + "To restrict the command to the current directory, run:\n" > + "\n" > + " git add %s .\n" > + " (or git add %s .)\n" > + "\n" > + "With the current Git version, the command is restricted to > the current directory."), > + option_name, short_name, > + option_name, short_name, > + option_name, short_name); > +} > + > int cmd_add(int argc, const char **argv, const char *prefix) > { > int exit_status = 0; > @@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char > *prefix) > int add_new_files; > int require_pathspec; > char *seen = NULL; > + const char *option_with_implicit_dot = NULL; > + const char *short_option_with_implicit_dot = NULL; > > git_config(add_config, NULL); > > @@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char > *p
[PATCH] fixup! git-remote-testpy: fix path hashing on Python 3
--- On Mon, Jan 28, 2013 at 11:44:34AM +0100, Michael Haggerty wrote: > NAK. It is still not right. If the locale is not utf-8 based, then it > is incorrect to re-encode the string using utf-8. I think you really > have to use sys.getfilesystemencoding() as I suggested. If you'd asked me what the patch contained I would have said it did use getfilesystemencoding(), but I can't disbelieve my own eyes :-( Junio, please can you squash this in? git-remote-testpy.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-remote-testpy.py b/git-remote-testpy.py index 6098bdd..ca67899 100644 --- a/git-remote-testpy.py +++ b/git-remote-testpy.py @@ -49,7 +49,7 @@ def encode_filepath(path): """ if sys.hexversion < 0x0300: return path -return path.encode('utf-8', 'surrogateescape') +return path.encode(sys.getfilesystemencoding(), 'surrogateescape') def get_repo(alias, url): -- 1.8.1.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
[CLOSED FIXED] Bug: file named - on git commit
On 01/28/2013 12:05 PM, Thomas Rast wrote: > This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no > need to read blob from the standard input, 2012-06-27), which is > included starting with v1.7.12 and the v1.7.11.3 maint release. Please > upgrade. Thanks. signature.asc Description: OpenPGP digital signature
Re: Bug: file named - on git commit
Rene Moser writes: > > Found a little issue in git version 1.7.9.5 if a file named "-", causing > "git commit" to read from stdin. > > (So you must hit ctrl-d or ctrl-c to finish the commit.) > > Everything looks ok to me after the commit. Other users reported to be > fixed in 1.8.1.1 but haven't it tested myself. > > This does not work: > > mkdir tmp && cd tmp; > echo foo >./-; > git init; git add .; > git commit -m "is this a bug?" This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no need to read blob from the standard input, 2012-06-27), which is included starting with v1.7.12 and the v1.7.11.3 maint release. Please upgrade. -- Thomas Rast trast@{inf,student}.ethz.ch -- 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: Bug: file named - on git commit
On Mon, Jan 28, 2013 at 5:38 PM, Rene Moser wrote: > Hi > > Found a little issue in git version 1.7.9.5 if a file named "-", causing > "git commit" to read from stdin. > > (So you must hit ctrl-d or ctrl-c to finish the commit.) > > Everything looks ok to me after the commit. Other users reported to be > fixed in 1.8.1.1 but haven't it tested myself. Yes, it's fixed in 4682d85 (diff-index.c: "git diff" has no need to read blob from the standard input - 2012-06-27) since v1.7.11.3. > This does not work: > > mkdir tmp && cd tmp; > echo foo >./-; > git init; git add .; > git commit -m "is this a bug?" > > Kind regards > > René > > > > > > -- 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: Bug: file named - on git commit
Rene Moser writes: > Hi > > Found a little issue in git version 1.7.9.5 if a file named "-", causing > "git commit" to read from stdin. Can't reproduce with Git version 1.8.1.1.440.g1d329bd, this probably has been fixed already. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Bug: file named - on git commit
Hi Found a little issue in git version 1.7.9.5 if a file named "-", causing "git commit" to read from stdin. (So you must hit ctrl-d or ctrl-c to finish the commit.) Everything looks ok to me after the commit. Other users reported to be fixed in 1.8.1.1 but haven't it tested myself. This does not work: mkdir tmp && cd tmp; echo foo >./-; git init; git add .; git commit -m "is this a bug?" Kind regards René signature.asc Description: OpenPGP digital signature
Re: [PATCH] git-remote-testpy: fix patch hashing on Python 3
On 01/27/2013 03:50 PM, John Keeping wrote: > When this change was originally made (0846b0c - git-remote-testpy: hash > bytes explicitly , I didn't realised that the "hex" encoding we chose is > a "bytes to bytes" encoding so it just fails with an error on Python 3 > in the same way as the original code. > > It is not possible to provide a single code path that works on Python 2 > and Python 3 since Python 2.x will attempt to decode the string before > encoding it, which fails for strings that are not valid in the default > encoding. Python 3.1 introduced the "surrogateescape" error handler > which handles this correctly and permits a bytes -> unicode -> bytes > round-trip to be lossless. > > At this point Python 3.0 is unsupported so we don't go out of our way to > try to support it. > > Helped-by: Michael Haggerty > Signed-off-by: John Keeping > --- > On Sun, Jan 27, 2013 at 02:13:29PM +, John Keeping wrote: >> On Sun, Jan 27, 2013 at 05:44:37AM +0100, Michael Haggerty wrote: >>> So to handle all of the cases across Python versions as closely as >>> possible to the old 2.x code, it might be necessary to make the code >>> explicitly depend on the Python version number, like: >>> >>> hasher = _digest() >>> if sys.hexversion < 0x0300: >>> pathbytes = repo.path >>> elif sys.hexversion < 0x0301: >>> # If support for Python 3.0.x is desired (note: result can >>> # be different in this case than under 2.x or 3.1+): >>> pathbytes = repo.path.encode(sys.getfilesystemencoding(), >>> 'backslashreplace') >>> else >>> pathbytes = repo.path.encode(sys.getfilesystemencoding(), >>> 'surrogateescape') >>> hasher.update(pathbytes) >>> repo.hash = hasher.hexdigest() > > How about this? > > git-remote-testpy.py | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/git-remote-testpy.py b/git-remote-testpy.py > index c7a04ec..16b0c52 100644 > --- a/git-remote-testpy.py > +++ b/git-remote-testpy.py > @@ -36,6 +36,22 @@ if sys.hexversion < 0x0200: > sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n") > sys.exit(1) > > + > +def _encode_filepath(path): > +"""Encodes a Unicode file path to a byte string. > + > +On Python 2 this is a no-op; on Python 3 we encode the string as > +suggested by [1] which allows an exact round-trip from the command line > +to the filesystem. > + > +[1] http://docs.python.org/3/c-api/unicode.html#file-system-encoding > + > +""" > +if sys.hexversion < 0x0300: > +return path > +return path.encode('utf-8', 'surrogateescape') > + > + > def get_repo(alias, url): > """Returns a git repository object initialized for usage. > """ > @@ -45,7 +61,7 @@ def get_repo(alias, url): > repo.get_head() > > hasher = _digest() > -hasher.update(repo.path.encode('hex')) > +hasher.update(_encode_filepath(repo.path)) > repo.hash = hasher.hexdigest() > > repo.get_base_path = lambda base: os.path.join( > NAK. It is still not right. If the locale is not utf-8 based, then it is incorrect to re-encode the string using utf-8. I think you really have to use sys.getfilesystemencoding() as I suggested. The attached program demonstrates the problem: the output of re-encoding using UTF-8 depends on the locale, whereas that of re-encoding using the filesystemencoding is independent of locale (as we want). The output, using Python 3.2.3: # This is 0xb6 0xc3: $ ARG="ö" $ LANG='C' /usr/bin/python3 chaos3.py "$ARG" LANG = 'C' fse = 'ascii' sys.argv[1] = u"U+DCC3 U+DCB6" re-encoded using UTF-8: b"C3 B6" re-encoded using fse: b"C3 B6" $ LANG='C.UTF-8' /usr/bin/python3 chaos3.py "$ARG" LANG = 'C.UTF-8' fse = 'utf-8' sys.argv[1] = u"U+00F6" re-encoded using UTF-8: b"C3 B6" re-encoded using fse: b"C3 B6" $ LANG='en_US.iso88591' /usr/bin/python3 chaos3.py "$ARG" LANG = 'en_US.iso88591' fse = 'iso8859-1' sys.argv[1] = u"U+00C3 U+00B6" re-encoded using UTF-8: b"C3 83 C2 B6" re-encoded using fse: b"C3 B6" Even though the Unicode intermediate representation is different for UTF-8 and ASCII, re-encoding using the correct encoding gives back the original bytes (which is what we want). But when using the ios8859-1 locale, the original bytes look like a valid latin1 string so they are not surrogated going in, giving the incorrect Unicode string u"U+00C3 U+00B6". When this is re-encoded using UTF-8, the code points U+00C3 and U+00B6 are each encoded as two bytes. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ #! /usr/bin/python3 import sys import os def explicit(s): """Convert a string or bytestring into an unambiguous human-readable string.""" if isinstance(s, str): return 'u"%s"' % (' '.join('U+%04X' % (ord(c),) for c in s)) else: return 'b"%s"' % (' '.join('%02X' % (c,) for c in s)) fse = sys.getfilesystemencoding() print('LA
Re: [PATCH] l10n: de.po: translate 11 new messages
Ralf Thielow writes: > Translate 11 new messages came from git.pot update > in 46bc403 (l10n: Update git.pot (11 new, 7 removed > messages)). > #: builtin/log.c:104 > msgid "Use mail map file" > -msgstr "" > +msgstr "verwendet \"mailmap\"-Datei" Note that case differs here, but it's the English one that doesn't fit the pattern -- option descriptions usually start with lowercase. > #: builtin/reset.c:275 > -#, fuzzy, c-format > +#, c-format > msgid "Failed to resolve '%s' as a valid revision." > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen." > +msgstr "Konnte '%s' nicht als gültige Revision auflösen." You don't have "revision" in the glossary[1] yet. Wouldn't it be appropriate to treat it as "commit", and translate as "Version" to avoid introducing yet another term? Or am I missing some subtle distinction between commit and revision? Since it's only a single nit, feel free to add my ack when you reroll: Acked-by: Thomas Rast [1] https://github.com/ralfth/git-po-de/wiki/Glossary -- Thomas Rast trast@{inf,student}.ethz.ch -- 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: [feature request] git add completion should exclude staged content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 28/01/2013 00:00, Junio C Hamano ha scritto: > wookietreiber writes: > >> I have a feature request for `git add` auto completion: >> >> `git add` auto completion suggests all files / directories, >> filtered by nothing. I guess it would be much nicer (as in >> increasing productivity) if it would only suggest unstaged >> content, as reported by `git status`, because that would be the >> only content one would be able to add. > > I think that is what Manlio Perillo tried to do with the stalled > mp/complete-paths topic that is queued in 'pu'. > > Manlio, any progress? Well, I assumed that the patch was stalled due to missing review from git completion experts... For this reason I have not updated it with your latest suggestions, waiting for the review (also, because now I'm busy with other projects). For the OP: the last patch can be found in the mailing list archive, with the subject: [PATCH v5] git-completion.bash: add support for path completion and date: Fri, 11 Jan 2013 19:48:43 +0100 Can you please test it? Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEGRE8ACgkQscQJ24LbaUSX9ACfUMBH/X6lVH4V7FUaB2wlqj8C eYQAnAzuYwhYhDvkW3d29IeqHsDFyWBT =BpRi -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] add: warn when -u or -A is used without filepattern
Matthieu Moy wrote: > Signed-off-by: Matthieu Moy Looks good to me. At some point we'll want to have tests for this case, but that's not particularly urgent until it's time for the warning() to turn into a die(). Thanks. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Port 22
Kevin venit, vidit, dixit 28.01.2013 09:06: > This is not really a git problem, but more of an ssh problem. > > Are you in the position to change the port where the SSH daemon > listens on? Then you could use a different port which isn't blocked > (443 perhaps?). > > On Sat, Jan 26, 2013 at 7:56 PM, Craig Christensen wrote: >> I am currently a student at Brigham Young University - Idaho and we are use >> Pagoda Box and Git for our Mobile Apps class. However, the school's network >> has blocked incoming trafic on port 22. I have been searching through all >> the tutorials and documents provided by Pagoda Box and Git but have not been >> able to find a solution to solve this problem. We can use sftp but we then >> have to manually deploy the latest using the admin panel. Can you help >> provide a simple solution? So how is your setup: - Pagoda Box instance at BYU - sftp uploads allowed, but not ssh - drive Git on the box using the admin interface Or do you use a Pagoda server? Do you have read access to the git repo on the box? ssh allows to restrict commands to only a subset, such as ssh only. If the port were blocked for incoming traffic you wouldn't be able to use (ssh at all thus) sftp either. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] add: warn when -u or -A is used without filepattern
Most git commands that can be used with our without a filepattern are tree-wide by default, the filepattern being used to restrict their scope. A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'. The inconsistency of 'git add -u' and 'git add -A' are particularly problematic since other 'git add' subcommands (namely 'git add -p' and 'git add -e') are tree-wide by default. Flipping the default now is unacceptable, so this patch starts training users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare for the next steps: * forbid 'git add -u|-A' without filepattern (like 'git add' without option) * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a tree-wide scope. A nice side effect of this patch is that it makes the :/ special filepattern easier to discover for users. When the command is called from the root of the tree, there is no ambiguity and no need to change the behavior, hence no need to warn. Signed-off-by: Matthieu Moy --- Changes since v2: * Typo consistant -> consistent * Mention both short and long option names (Thanks Junio). I went for a two-lines display which I find a bit nicer to read than Junio's version, but I'm fine with both. Documentation/git-add.txt | 7 --- builtin/add.c | 44 +++- 2 files changed, 47 insertions(+), 4 deletions(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index fd9e36b..5333559 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below. from the index if the corresponding files in the working tree have been removed. + -If no is given, default to "."; in other words, -update all tracked files in the current directory and its -subdirectories. +If no is given, the current version of Git defaults to +"."; in other words, update all tracked files in the current directory +and its subdirectories. This default will change in a future version +of Git, hence the form without should not be used. -A:: --all:: diff --git a/builtin/add.c b/builtin/add.c index 7cb6cca..7738025 100644 --- a/builtin/add.c +++ b/builtin/add.c @@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags) return exit_status; } +static void warn_pathless_add(const char *option_name, const char *short_name) { + /* +* To be consistent with "git add -p" and most Git +* commands, we should default to being tree-wide, but +* this is not the original behavior and can't be +* changed until users trained themselves not to type +* "git add -u" or "git add -A". For now, we warn and +* keep the old behavior. Later, this warning can be +* turned into a die(...), and eventually we may +* reallow the command with a new behavior. +*/ + warning(_("The behavior of 'git add %s (or %s)' with no path argument from a\n" + "subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n" + "To add content for the whole tree, run:\n" + "\n" + " git add %s :/\n" + " (or git add %s :/)\n" + "\n" + "To restrict the command to the current directory, run:\n" + "\n" + " git add %s .\n" + " (or git add %s .)\n" + "\n" + "With the current Git version, the command is restricted to the current directory."), + option_name, short_name, + option_name, short_name, + option_name, short_name); +} + int cmd_add(int argc, const char **argv, const char *prefix) { int exit_status = 0; @@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix) int add_new_files; int require_pathspec; char *seen = NULL; + const char *option_with_implicit_dot = NULL; + const char *short_option_with_implicit_dot = NULL; git_config(add_config, NULL); @@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix) die(_("-A and -u are mutually incompatible")); if (!show_only && ignore_missing) die(_("Option --ignore-missing can only be used together with --dry-run")); - if ((addremove || take_worktree_changes) && !argc) { + if (addremove) { + option_with_implicit_dot = "--all"; + short_option_with_implicit_dot = "-A"; + } + if (take_worktree_changes) { + option_with_implicit_dot = "--update"; + short_option_with_implicit_dot = "-u"; + } + if (option_with_implicit_dot && !argc) { static const char *here[2] = { ".", NULL }; + if (prefix) + warn_pathless_add(op
Re: [PATCH v2 0/4] Auto-generate mergetool lists
On Mon, Jan 28, 2013 at 12:20 AM, Philip Oakley wrote: > From: "David Aguilar" > Sent: Monday, January 28, 2013 12:52 AM > >> This is round two of this series. >> I think this touched on everything brought up in the code review. >> 4/4 could use a review as I'm not completely familiar with the >> makefile dependencies, though it seems to work correctly. > > > Does this 4/4 have any effect on the Msysgit / Git for Windows documentation > which simply refers [IIRC] to HTML documenation made by Junio? > > That is, how easy is it to create a 'default' set of docs, rather than > personalised documenation. Or have I misunderstood how it is working? It doesn't have any effect on Msysgit. The resulting documentation lists all available tools, on all platforms. -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] add: warn when -u or -A is used without filepattern
Junio C Hamano writes: > Matthieu Moy writes: > >> Plus, option_with_implicit_dot is used in cut-and-paste ready commands >> below. > > I do not think we should aim for easy cut-and-paste, especially when > the real purpose of the change is to train people's fingers; the > message should discouraging cut-and-paste in a case like this, if > anything. cut-and-paste readyness is also a way to avoid being ambiguous. If you tell users to run "git add -u (--update)", you'll always find someone to type the command as-is and complain about it not working (sadly, the teacher living inside me is speaking of experience ;-) ). > But we could obviously do this, if you really want to cut-and-paste. I was going to do something like this, you've been too quick ;-). Resend comming soon. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: "David Aguilar" Sent: Monday, January 28, 2013 12:52 AM This is round two of this series. I think this touched on everything brought up in the code review. 4/4 could use a review as I'm not completely familiar with the makefile dependencies, though it seems to work correctly. Does this 4/4 have any effect on the Msysgit / Git for Windows documentation which simply refers [IIRC] to HTML documenation made by Junio? That is, how easy is it to create a 'default' set of docs, rather than personalised documenation. Or have I misunderstood how it is working? David Aguilar (4): mergetool--lib: Simplify command expressions mergetool--lib: Improve the help text in guess_merge_tool() mergetool--lib: Add functions for finding available tools doc: Generate a list of valid merge tools Documentation/.gitignore | 1 + Documentation/Makefile | 22 +++- Documentation/diff-config.txt | 13 ++--- Documentation/merge-config.txt | 12 ++--- git-mergetool--lib.sh | 116 ++--- 5 files changed, 96 insertions(+), 68 deletions(-) -- 1.8.0.13.g3ff16bb -- 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6061 - Release Date: 01/27/13 -- 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 v4 1/2] for-each-repo: new command used for multi-repo operations
Hi, Lars Hjemli wrote: > [1] The 'git -a' rewrite patch shows how I think about this command - > it's just an option to the 'git' command, modifying the way any > subcommand is invoked (btw: I don't expect that patch to be applied > since 'git-all' was deemed to generic, so I'll just carry the patch in > my own tree). As one data point, 'git all' also seems too generic to me but 'git -a' doesn't. Intuition can be weird. So if I ran the world, then having commands git -a diff and git for-each-repo git diff do the same thing would be fine. Of course I don't run the world. ;-) [...] >> One more thing that nobody brought up during the previous reviews is >> if we want to support subset of repositories by allowing the >> standard pathspec match mechanism. For example, >> >> git for-each-repo -d git diff --name-only -- foo/ bar/b\*z >> >> might be a way to ask "please find repositories match the given >> pathspecs (i.e. foo/ bar/b\*z) and run the command in the ones that >> are dirty". We would need to think about how to mark the end of the >> command though---we could borrow \; from find(1), even though find >> is not the best example of the UI design. In most non-git commands, "--" represents an end-of-options marker, allowing arbitrary options afterward without having to worry about escaping minus signs. So in that spirit, if this weren't a git command, I'd expect to be able to do for-each-repo -- git diff -- '*.c' and have the second '--' passed verbatim to "git diff". Unfortunately in git (imitating commands like "grep", I suppose), "--" means "paths start here". That means that with the git convention, there is only one place to pass paths to a given command. Tracing backwards: it would be really nice to be able to do git for-each-repo git grep -e foo -- '*.c' or git -a grep -e foo -- '*.c' For this practical reason, it seems that paths listed after the '--' should go to the command being run. On the other hand, if I wanted to limit my for-each-repo run to repositories in two subdirectories of the cwd, I'd be tempted to try git for-each-repo git grep -e foo -- src/ doc/ And if I wanted to limit to different file types in the repositories under each directory, it would be tempting to use git for-each-repo git grep -e foo -- 'src/*.c' 'doc/*.txt' Is there a convention that would be usable today that is roughly forward-compatible with that? (To throw an example out, requiring that each pathspec passed to for-each-repo either starts with '*' or contains no wildcards.) Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Port 22
This is not really a git problem, but more of an ssh problem. Are you in the position to change the port where the SSH daemon listens on? Then you could use a different port which isn't blocked (443 perhaps?). On Sat, Jan 26, 2013 at 7:56 PM, Craig Christensen wrote: > I am currently a student at Brigham Young University - Idaho and we are use > Pagoda Box and Git for our Mobile Apps class. However, the school's network > has blocked incoming trafic on port 22. I have been searching through all > the tutorials and documents provided by Pagoda Box and Git but have not been > able to find a solution to solve this problem. We can use sftp but we then > have to manually deploy the latest using the admin panel. Can you help > provide a simple solution? > > Thanks, > > Craig W Christensen > cwcra...@gmail.com > chr07...@byui.edu-- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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