* Re: [RFC/PATCH] i18n of multi-line messages
From: Thomas Rast @ 2011-12-22 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <7vmxale9so.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I think the easiest way to tackle that sort of thing is to just do:
>>
>> _("hint: %.*s\n")
>>
>> And have a TRANSLATORS comment indicating that the format string
>> should be kept, but that translators can move around the "hint", GNU
>> gettext also has a msgcheck feature to check that format strings are
>> compatible in the translations.
>
> Good point. Thanks.
Note that your commit message in pu still says
- append each line in the result to localization of the "hint: " prefix.
even though you now fixed that to be more general.
(It also has a very weird case of mixed indentation when I view it with
'git show':
advise(_("Please rename %s to something else"), gostak);
advise(_("so that we can avoid distimming %s unnecessarily."), doshes);
Apparently the first line is indented with a tab, and the second with 8
spaces.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Martin von Zweigbergk @ 2011-12-22 17:09 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Git Mailing List
In-Reply-To: <4EF3517A.8030108@dirk.my1.cc>
2011/12/22 Dirk Süsserott <newsletter@dirk.my1.cc>:
> Does anybody know about a shortcut in gitk to "jump to the yellow spot"?
Not sure it's fast enough for you, but you can always enter "HEAD" in
the "SHA1 ID" box (and press Enter).
^ permalink raw reply
* Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Dirk Süsserott @ 2011-12-22 17:23 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Git Mailing List
In-Reply-To: <CAOeW2eGFw0RfU0FHL4CEMVPwSNvrRLv9_iG7Gy_qCheY3GxWxw@mail.gmail.com>
Am 22.12.2011 18:09 schrieb Martin von Zweigbergk:
> 2011/12/22 Dirk Süsserott <newsletter@dirk.my1.cc>:
>> Does anybody know about a shortcut in gitk to "jump to the yellow spot"?
>
> Not sure it's fast enough for you, but you can always enter "HEAD" in
> the "SHA1 ID" box (and press Enter).
Martin, that's fast enough for me. Works great! Thank you.
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Junio C Hamano @ 2011-12-22 18:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <4EF2E824.7020509@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 12/22/2011 8:38, schrieb Junio C Hamano:
>> +static void v_format(const char *prefix, const char *fmt, va_list params,
>> + emit_fn emit, void *cb_data)
>> +{
>> + struct strbuf buf = STRBUF_INIT;
>> + struct strbuf line = STRBUF_INIT;
>> + const char *cp, *np;
>> +
>> + strbuf_vaddf(&buf, fmt, params);
> ...
>> void vreportf(const char *prefix, const char *err, va_list params)
>> {
>> - char msg[4096];
>> - vsnprintf(msg, sizeof(msg), err, params);
>> - fprintf(stderr, "%s%s\n", prefix, msg);
>> + v_format(prefix, err, params, emit_report, NULL);
>> }
>
> Using strbuf (or xmalloc for that matter) from a function that can be
> called from die() is a big no-no. You should keep the fixed-sized buffer.
I _think_ I liked the simplicity of having the logic to
- format localized message to a multi-line buffer; and
- split the contents of that buffer into lines and add prefix in an
i18n friendly way
in vreportf(), but there are many problems in this approach, it seems. We
may need to limit the message length for error()/die() codepath, but we do
not want to be limited in others, definitely not from advise().
Also some calls to error() are meant to produce plumbing error message and
should never be localized. The approach to localize the prefix in vreportf()
will not work for this reason.
I think we should start from the original "advise-only" way. In the longer
term (if somebody cares about it deeply), things can be fixed up and the
mechanism can then be unified in the following order:
(1) figure out a way to allow error() and die() tell if they are called
to produce a plumbing message that should not be translated (multiple
approaches are possible, ranging from adding error_plumb() function
to marking the message format string specially);
(2) update the existing error()/die() calls that are used to produce
plumbing message and mark them as such, using the mechanism decided
in (1);
(3) Take the v_format/vreport code from my patch I am discarding with
this message, enhance them to turn the "prefix" i18n part
consitional, and use that to reimplement the mechanism (1).
But that is not for this year.
^ permalink raw reply
* Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Pat Thoyts @ 2011-12-22 18:26 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Git Mailing List
In-Reply-To: <4EF3517A.8030108@dirk.my1.cc>
Dirk Süsserott <newsletter@dirk.my1.cc> writes:
>Hi!
>
>Does anybody know about a shortcut in gitk to "jump to the yellow spot"?
>
>I often use cmdline and gitk at the same time, switch branches, stash,
>rebase and so on from bash. When hitting [Ctrl-]F5 in gitk, the last
>highlighted commit is focused again and my HEAD is far off the screen.
>
>Is there a way to jump to the HEAD (the yellow bubble in gitk) with a
>fingertip?
>
>TIA
> Dirk
Hit the Home key. The binding for that takes you to the first commit.
End to the last (oldest) commit.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: Warning from AV software about kill.exe
From: Pat Thoyts @ 2011-12-22 18:19 UTC (permalink / raw)
To: Thomas Rast; +Cc: Erik Blake, git
In-Reply-To: <87mxalkn9q.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
>Erik Blake <erik@icefield.yk.ca> writes:
>
>> I'm running git under Win7 64. As I selected "Repository|Visualize all
>> branch history" in the git gui, my AV software (Trustport) trapped the
>> bin\kill.exe program for "trying to modify system global settings
>> (time, timezone, registry quota, etc.)"
>>
>> Does anyone know the details of this process and what it's function
>> is? First time I've seen it, though I'm a relatively new user.
>
>'kill' is a standard unix utility that sends signals to processes, in
>particular signals that cause the processes to exit or be killed
>forcibly by the kernel, hence the name. (I don't know how the windows
>equivalent works under the hood, but presumably it's something similar.)
>
>git-gui and gitk use kill to terminate background worker processes that
>are no longer needed because you closed the window their output would
>have been displayed in, etc.
You might try replacing the command in the tcl scripts with 'exec
taskkill /f /pid $pid' and see if that avoids the error. taskkill is
present on XP and above as part of the OS distribution so shouldn't
suffer any AV complaints.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* "Nested quantifiers" error in gitweb with "++" in the filename
From: Jehan Bing @ 2011-12-22 20:37 UTC (permalink / raw)
To: git
Hi,
I'm getting an error when trying to look at a blob when the filename has
"++" in it:
http://.../blob/13ec1624fefc23d20d0407aac3337b35844a2ceb:/foo-++.txt
And I get the following error page:
gitprojects /
500 - Internal Server Error
Nested quantifiers in regex; marked by <-- HERE in
m//test.git/blob/13ec1624fefc23d20d0407aac3337b35844a2ceb:/foo-++ <--
HERE .txt$/ at (eval 10) line 7.
OPML TXT
The Apache log show the same thing:
gitweb.cgi: Nested quantifiers in regex; marked by <-- HERE in
m//test.git/blob/13ec1624fefc23d20d0407aac3337b35844a2ceb:/foo-++ <--
HERE .txt$/ at (eval 10) line 7.
It works fine if the filename has a single '+' sign (tried "foo-+.txt").
There is a same error when browsing a tree and clicking a directory with
the "++"
We notice the error when looking at the Qt source code. They have a
bunch of "*g++*" files and directories.
We use git-1.7.6 but updating to gitweb.cgi from 1.7.8.1 didn't fix it.
Regards,
Jehan
^ permalink raw reply
* What's cooking in git.git (Dec 2011, #08; Thu, 22)
From: Junio C Hamano @ 2011-12-22 20:59 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
The tip of 'master' is now feature complete for 1.7.9 so I could tag it as
the -rc0, but I'll let it simmer for several days to give people chance to
test over the holidays.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are 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/
--------------------------------------------------
[New Topics]
* tr/doc-sh-setup (2011-12-20) 1 commit
(merged to 'next' on 2011-12-21 at bd73695)
+ git-sh-setup: make require_clean_work_tree part of the interface
* ab/sun-studio-portability (2011-12-21) 3 commits
(merged to 'next' on 2011-12-21 at 0cc5a63)
+ Appease Sun Studio by renaming "tmpfile"
+ Fix a bitwise negation assignment issue spotted by Sun Studio
+ Fix an enum assignment issue spotted by Sun Studio
* tr/bash-read-unescaped (2011-12-21) 1 commit
(merged to 'next' on 2011-12-21 at de865c1)
+ bash completion: use read -r everywhere
* jc/advise-i18n (2011-12-22) 1 commit
- i18n of multi-line advice messages
Allow localization of advice messages that tend to be longer and
multi-line formatted. For now this is deliberately limited to advise()
interface and not vreportf() in general as touching the latter has
interactions with error() that has plumbing callers whose prefix "error: "
should never be translated.
--------------------------------------------------
[Graduated to "master"]
* cn/maint-lf-to-crlf-filter (2011-12-16) 1 commit
(merged to 'next' on 2011-12-20 at 83d6f7c)
+ lf_to_crlf_filter(): tell the caller we added "\n" when draining
(this branch is used by jc/maint-lf-to-crlf-keep-crlf.)
A recent fix to the codepath was not quite correct.
* ef/setenv-putenv (2011-12-14) 2 commits
(merged to 'next' on 2011-12-20 at 4845020)
+ compat/setenv.c: error if name contains '='
+ compat/setenv.c: update errno when erroring out
(this branch is used by ef/x-setenv-putenv.)
* jc/advice-doc (2011-12-18) 1 commit
(merged to 'next' on 2011-12-19 at 0b410e5)
+ advice: Document that they all default to true
(this branch is used by jc/advise-push-default.)
* jc/maint-lf-to-crlf-keep-crlf (2011-12-18) 1 commit
(merged to 'next' on 2011-12-20 at eee6eb3)
+ lf_to_crlf_filter(): resurrect CRLF->CRLF hack
The lf-to-crlf filter in the streaming checkout codepath forgot that we
try not to convert LF to CRLF if the repository data already has CRLF.
* jc/request-pull-show-head-4 (2011-12-19) 2 commits
(merged to 'next' on 2011-12-19 at 771939b)
+ request-pull: do not emit "tag" before the tagname
(merged to 'next' on 2011-12-16 at bea51ac)
+ request-pull: update the "pull" command generation logic
* jk/doc-fsck (2011-12-16) 1 commit
(merged to 'next' on 2011-12-20 at 70df8a4)
+ docs: brush up obsolete bits of git-fsck manpage
* jk/follow-rename-score (2011-12-16) 1 commit
(merged to 'next' on 2011-12-20 at 74db2a9)
+ use custom rename score during --follow
* jk/git-prompt (2011-12-12) 10 commits
(merged to 'next' on 2011-12-20 at 24aff90)
+ contrib: add credential helper for OS X Keychain
+ Makefile: OS X has /dev/tty
+ Makefile: linux has /dev/tty
+ credential: use git_prompt instead of git_getpass
+ prompt: use git_terminal_prompt
+ add generic terminal prompt function
+ refactor git_getpass into generic prompt function
+ move git_getpass to its own source file
+ imap-send: don't check return value of git_getpass
+ imap-send: avoid buffer overflow
* jk/http-push-to-empty (2011-12-19) 1 commit
(merged to 'next' on 2011-12-19 at 845e2a1)
+ remote-curl: don't pass back fake refs
* jk/maint-do-not-feed-stdin-to-tests (2011-12-15) 1 commit
(merged to 'next' on 2011-12-20 at 43e83c5)
+ test-lib: redirect stdin of tests
* jk/maint-push-v-is-verbose (2011-12-17) 1 commit
(merged to 'next' on 2011-12-20 at b79f101)
+ make "git push -v" actually verbose
* jk/maint-strbuf-missing-init (2011-12-18) 2 commits
(merged to 'next' on 2011-12-20 at 72fa8ae)
+ Update jk/maint-strbuf-missing-init to builtin/ rename
+ commit, merge: initialize static strbuf
* jk/pretty-reglog-ent (2011-12-16) 1 commit
(merged to 'next' on 2011-12-20 at 949b010)
+ pretty: give placeholders to reflog identity
* jn/test-cleanup-7006 (2011-12-14) 1 commit
(merged to 'next' on 2011-12-20 at 952f48f)
+ test: errors preparing for a test are not special
* mh/ref-api (2011-12-12) 16 commits
(merged to 'next' on 2011-12-15 at d65a830)
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ repack_without_ref(): remove temporary
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
(this branch is used by mh/ref-api-rest.)
Later part split out to expedite moving the earlier good bits forward.
* nd/war-on-nul-in-commit (2011-12-15) 3 commits
(merged to 'next' on 2011-12-20 at d441111)
+ commit_tree(): refuse commit messages that contain NULs
+ Convert commit_tree() to take strbuf as message
+ merge: abort if fails to commit
* rs/diff-tree-combined-clean-up (2011-12-17) 3 commits
(merged to 'next' on 2011-12-20 at 265e049)
+ submodule: use diff_tree_combined_merge() instead of diff_tree_combined()
+ pass struct commit to diff_tree_combined_merge()
+ use struct sha1_array in diff_tree_combined()
* tr/grep-threading (2011-12-16) 3 commits
(merged to 'next' on 2011-12-20 at 1a852ef)
+ grep: disable threading in non-worktree case
+ grep: enable threading with -p and -W using lazy attribute lookup
+ grep: load funcname patterns for -W
--------------------------------------------------
[Stalled]
* pw/p4-docs-and-tests (2011-12-18) 11 commits
- git-p4: document and test submit options
- git-p4: test and document --use-client-spec
- git-p4: test --keep-path
- git-p4: test --max-changes
- git-p4: document and test --import-local
- git-p4: honor --changesfile option and test
- git-p4: document and test clone --branch
- git-p4: test cloning with two dirs, clarify doc
- git-p4: clone does not use --git-dir
- git-p4: test debug macro
- git-p4: introduce asciidoc documentation
Waiting for a reroll.
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
Waiting for a reroll.
* mh/ref-api-rest (2011-12-12) 35 commits
- repack_without_ref(): call clear_packed_ref_cache()
- read_packed_refs(): keep track of the directory being worked in
- is_refname_available(): query only possibly-conflicting references
- refs: read loose references lazily
- read_loose_refs(): take a (ref_entry *) as argument
- struct ref_dir: store a reference to the enclosing ref_cache
- sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
- add_entry(): take (ref_entry *) instead of (ref_dir *)
- search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
- add_ref(): take (ref_entry *) instead of (ref_dir *)
- read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
- find_ref(): take (ref_entry *) instead of (ref_dir *)
- is_refname_available(): take (ref_entry *) instead of (ref_dir *)
- get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
- get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
- refs: wrap top-level ref_dirs in ref_entries
- get_ref_dir(): keep track of the current ref_dir
- do_for_each_ref(): only iterate over the subtree that was requested
- refs: sort ref_dirs lazily
- sort_ref_dir(): do not sort if already sorted
- refs: store references hierarchically
- refs.c: rename ref_array -> ref_dir
- struct ref_entry: nest the value part in a union
- check_refname_component(): return 0 for zero-length components
- free_ref_entry(): new function
- refs.c: reorder definitions more logically
- is_refname_available(): reimplement using do_for_each_ref_in_array()
- names_conflict(): simplify implementation
- names_conflict(): new function, extracted from is_refname_available()
- repack_without_ref(): reimplement using do_for_each_ref_in_array()
- do_for_each_ref_in_arrays(): new function
- do_for_each_ref_in_array(): new function
- do_for_each_ref(): correctly terminate while processesing extra_refs
The API for extra anchoring points may require rethought first; that would
hopefully make the "ref" part a lot simpler.
Waiting for a reroll.
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
At least pack-objects and fsck need to learn the new encoding for the
series to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.
--------------------------------------------------
[Cooking]
* jn/maint-gitweb-utf8-fix (2011-12-19) 4 commits
(merged to 'next' on 2011-12-20 at b816812)
+ gitweb: Fix fallback mode of to_utf8 subroutine
+ gitweb: Output valid utf8 in git_blame_common('data')
+ gitweb: esc_html() site name for title in OPML
+ gitweb: Call to_utf8() on input string in chop_and_escape_str()
* tr/pty-all (2011-12-19) 1 commit
(merged to 'next' on 2011-12-20 at 9b637d3)
+ test-terminal: set output terminals to raw mode
Kept only the second one from the original.
* rr/revert-cherry-pick (2011-12-15) 6 commits
(merged to 'next' on 2011-12-21 at d0428dc)
+ t3502, t3510: clarify cherry-pick -m failure
+ t3510 (cherry-pick-sequencer): use exit status
+ revert: simplify getting commit subject in format_todo()
+ revert: tolerate extra spaces, tabs in insn sheet
+ revert: make commit subjects in insn sheet optional
+ revert: free msg in format_todo()
* jc/signed-commit (2011-11-29) 5 commits
(merged to 'next' on 2011-12-21 at 8fcbf00)
+ gpg-interface: allow use of a custom GPG binary
+ pretty: %G[?GS] placeholders
+ test "commit -S" and "log --show-signature"
+ log: --show-signature
+ commit: teach --gpg-sign option
* jc/push-ignore-stale (2011-12-14) 2 commits
- push: --ignore-stale option
- set_ref_status_for_push(): use transport-flags abstraction
Probably solving a wrong problem and encouraging a wrong workflow while at
it. jc/advise-push-default might be a better approach.
Will drop.
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Ævar Arnfjörð Bjarmason @ 2011-12-22 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vaa6ldpk6.fsf@alter.siamese.dyndns.org>
On Thu, Dec 22, 2011 at 08:38, Junio C Hamano <gitster@pobox.com> wrote:
[Re-formatted for clarity]
> - vreportf("hint: ", advice, params);
> + vreportf("hint", advice, params);
> - vreportf("fatal: ", err, params);
> + vreportf("fatal", err, params);
> - vwritef(child_err, "fatal: ", err, params);
> + vwritef(child_err, "fatal", err, params);
> - vreportf("usage: ", err, params);
> + vreportf("usage", err, params);
> - vreportf("fatal: ", err, params);
> + vreportf("fatal", err, params);
> - vreportf("error: ", err, params);
> + vreportf("error", err, params);
> - vreportf("warning: ", warn, params);
> + vreportf("warning", warn, params);
If we do it like this these would have to have something like:
vreportf(N_("warning"), warn, params);
Followed by...:
> + strbuf_vaddf(&buf, fmt, params);
> + for (cp = buf.buf; *cp; cp = np) {
> + np = strchrnul(cp, '\n');
> + /*
> + * TRANSLATORS: the format is designed so that in RTL
> + * languages you could reorder and put the "prefix" at
> + * the end instead of the beginning of a line if you
> + * wanted to.
> + */
> + strbuf_addf(&line,
> + _("%s: %.*s\n"),
> + prefix,
Changing this to _(prefix).
> + (int)(np - cp), cp);
> + emit(&line, cb_data);
> + strbuf_reset(&line);
> + if (*np)
> + np++;
> + }
> + strbuf_release(&buf);
> + strbuf_release(&line);
But ideally to make things clear to the translators it's better to
give them something like this to translate:
error: %s
message
Instead of just, as two separate things:
error
message
Because:
1. We might use "error", "warning", "usage" etc. somewhere else, and
unless we start using the msgctxt feature of gettext we can't
distinguish between these.
2. If you present them as two separate things the translator is
likely to get the case wrong (e.g. translate "error" in the
nominative case instead of say accusative).
But it's not a big deal, the patch looks good to me as-is with those
N_() and _() changes. Just something to keep in mind.
We can always fixed issues like the one I'm raising later as they crop up.
^ permalink raw reply
* Re: Patch to support proxy authentication through NTLM?
From: Ævar Arnfjörð Bjarmason @ 2011-12-23 1:43 UTC (permalink / raw)
To: Schmidt, Marco; +Cc: git
In-Reply-To: <4CDEC141B5583D408E79F2931DB7708301691B80@GSX300A.mxchg.m.corp>
On Thu, Dec 22, 2011 at 09:45, Schmidt, Marco
<Marco.Schmidt@cassidian.com> wrote:
> After debugging git proxy authentication and creating my own fix to
> support git+https over an NTLM proxy I found a set of patches inside of
> the mailing list archives [1]. What is the state of this patch set? The
> essence of the patch would be to allow NTLM authentification by giving
> the correct options to libcurl.
~Weekly Junio sends out a "What's cooking in Git" E-Mail. Things that
aren't listed there aren't being actively considered for inclusion.
Which means that if you're interested in it the best thing you can do
is to take that patch, rebase it on top of master, make sure it works,
and re-submit it.
See Documentation/SubmittingPatches and one of those E-Mails Junios
sends out for more info.
^ permalink raw reply
* Re: Patch to support proxy authentication through NTLM?
From: Junio C Hamano @ 2011-12-23 2:34 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Schmidt, Marco, git
In-Reply-To: <CACBZZX4FS37zqY3eUKHK+FGMjXB4D1DEi17hQSPsmQBS9E8jUA@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Which means that if you're interested in it the best thing you can do
> is to take that patch, rebase it on top of master, make sure it works,
> and re-submit it.
In the case of that particular patch, it appears to take more than that,
unless you meant "make it work" by "make sure it works". The discussion
following patch seems to indicate that it was very broken and not working
at all, and then the patch submitter disappeared.
^ permalink raw reply
* Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Jeff King @ 2011-12-23 5:47 UTC (permalink / raw)
To: Philip Oakley; +Cc: Junio C Hamano, git, Brandon Casey
In-Reply-To: <22866D05066E43DEA0A0EBDF9B7686ED@PhilipOakley>
On Thu, Dec 22, 2011 at 12:05:39AM -0000, Philip Oakley wrote:
> The "*.m=matlab" does give better (proper) hunk headers as it picks
> out the "^%%" comment line which starts a code block . For option 3
> (ObjC) they are empty (which is poor). The plain vanila (default)
> hunk headers are so-so.
Thanks for all of the detail. I think it comes down to the part I
quoted, though: it is indeed a disservice to matlab people to map "*.m"
to objc. So let's be conservative and not do that (projects can always
add their own gitattributes).
(Even before seeing your answer, I dropped it from the re-roll of my
patch that I sent, but this confirms to me that it was the right thing
to do).
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Johannes Sixt @ 2011-12-23 6:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <7v39cceay0.fsf@alter.siamese.dyndns.org>
Am 12/22/2011 19:08, schrieb Junio C Hamano:
> I _think_ I liked the simplicity of having the logic to
>
> - format localized message to a multi-line buffer; and
> - split the contents of that buffer into lines and add prefix in an
> i18n friendly way
>
> in vreportf(), but there are many problems in this approach, it seems. We
> may need to limit the message length for error()/die() codepath, but we do
> not want to be limited in others, definitely not from advise().
>
> Also some calls to error() are meant to produce plumbing error message and
> should never be localized. The approach to localize the prefix in vreportf()
> will not work for this reason.
IMO the solution to not translate plumbing messages is to omit the
initialization of the gettext machinery.
Anyway, here is a patch that modifies vreportf() in an i18n friendly way
(I think). It is not necessarily meant for inclusion. Notably, the
changes to the test suite indicate one problem in a class of error()
messages: A list of file names is produced that are indented by a tab.
But with the "error: " prefix, the visible indentation shrinks to two
spaces (the minimum possible). We may want to do something about it.
--- >8 ---
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] Put a prefix on all lines of multi-line hint, warning,
error messages
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
advice.c | 2 +-
git-compat-util.h | 2 +-
http-backend.c | 2 +-
run-command.c | 2 +-
t/t1011-read-tree-sparse-checkout.sh | 6 ++--
t/t1506-rev-parse-diagnosis.sh | 2 +-
t/t7607-merge-overwrite.sh | 6 ++--
t/t7609-merge-co-error-msgs.sh | 40 +++++++++++++++++-----------------
usage.c | 19 +++++++++++-----
9 files changed, 44 insertions(+), 37 deletions(-)
diff --git a/advice.c b/advice.c
index e02e632..38b55b6 100644
--- a/advice.c
+++ b/advice.c
@@ -24,7 +24,7 @@ void advise(const char *advice, ...)
va_list params;
va_start(params, advice);
- vreportf("hint: ", advice, params);
+ vreportf("hint: %s\n", advice, params);
va_end(params);
}
diff --git a/git-compat-util.h b/git-compat-util.h
index 8f3972c..26b7d19 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -239,7 +239,7 @@ extern char *gitbasename(char *);
#include "compat/bswap.h"
/* General helper functions */
-extern void vreportf(const char *prefix, const char *err, va_list params);
+extern void vreportf(const char *line_fmt, const char *err, va_list params);
extern void vwritef(int fd, const char *prefix, const char *err, va_list params);
extern NORETURN void usage(const char *err);
extern NORETURN void usagef(const char *err, ...) __attribute__((format (printf, 1, 2)));
diff --git a/http-backend.c b/http-backend.c
index 869d515..fb91742 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -490,7 +490,7 @@ static NORETURN void die_webcgi(const char *err, va_list params)
hdr_nocache();
end_headers();
- vreportf("fatal: ", err, params);
+ vreportf("fatal: %s\n", err, params);
}
exit(0); /* we successfully reported a failure ;-) */
}
diff --git a/run-command.c b/run-command.c
index 1c51043..664c215 100644
--- a/run-command.c
+++ b/run-command.c
@@ -466,7 +466,7 @@ static void *run_thread(void *data)
static NORETURN void die_async(const char *err, va_list params)
{
- vreportf("fatal: ", err, params);
+ vreportf("fatal: %s\n", err, params);
if (!pthread_equal(main_thread, pthread_self())) {
struct async *async = pthread_getspecific(async_key);
diff --git a/t/t1011-read-tree-sparse-checkout.sh b/t/t1011-read-tree-sparse-checkout.sh
index 5c0053a..22b6a20 100755
--- a/t/t1011-read-tree-sparse-checkout.sh
+++ b/t/t1011-read-tree-sparse-checkout.sh
@@ -242,9 +242,9 @@ test_expect_success 'print errors when failed to update worktree' '
test_must_fail git checkout top 2>actual &&
cat >expected <<\EOF &&
error: The following untracked working tree files would be overwritten by checkout:
- sub/added
- sub/addedtoo
-Please move or remove them before you can switch branches.
+error: sub/added
+error: sub/addedtoo
+error: Please move or remove them before you can switch branches.
Aborting
EOF
test_cmp expected actual
diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh
index 0843a1c..292f2fb 100755
--- a/t/t1506-rev-parse-diagnosis.sh
+++ b/t/t1506-rev-parse-diagnosis.sh
@@ -11,7 +11,7 @@ test_did_you_mean ()
sq="'" &&
cat >expected <<-EOF &&
fatal: Path '$2$3' $4, but not ${5:-$sq$3$sq}.
- Did you mean '$1:$2$3'${2:+ aka $sq$1:./$3$sq}?
+ fatal: Did you mean '$1:$2$3'${2:+ aka $sq$1:./$3$sq}?
EOF
test_cmp expected error
}
diff --git a/t/t7607-merge-overwrite.sh b/t/t7607-merge-overwrite.sh
index aa74184..7d6498d 100755
--- a/t/t7607-merge-overwrite.sh
+++ b/t/t7607-merge-overwrite.sh
@@ -104,9 +104,9 @@ test_expect_success 'will not overwrite untracked subtree' '
cat >expect <<\EOF
error: The following untracked working tree files would be overwritten by merge:
- sub
- sub2
-Please move or remove them before you can merge.
+error: sub
+error: sub2
+error: Please move or remove them before you can merge.
Aborting
EOF
diff --git a/t/t7609-merge-co-error-msgs.sh b/t/t7609-merge-co-error-msgs.sh
index 0e4a682..653eb7e 100755
--- a/t/t7609-merge-co-error-msgs.sh
+++ b/t/t7609-merge-co-error-msgs.sh
@@ -27,11 +27,11 @@ test_expect_success 'setup' '
cat >expect <<\EOF
error: The following untracked working tree files would be overwritten by merge:
- five
- four
- three
- two
-Please move or remove them before you can merge.
+error: five
+error: four
+error: three
+error: two
+error: Please move or remove them before you can merge.
Aborting
EOF
@@ -50,13 +50,13 @@ test_expect_success 'untracked files overwritten by merge (fast and non-fast for
cat >expect <<\EOF
error: Your local changes to the following files would be overwritten by merge:
- four
- three
- two
-Please, commit your changes or stash them before you can merge.
+error: four
+error: three
+error: two
+error: Please, commit your changes or stash them before you can merge.
error: The following untracked working tree files would be overwritten by merge:
- five
-Please move or remove them before you can merge.
+error: five
+error: Please move or remove them before you can merge.
Aborting
EOF
@@ -70,9 +70,9 @@ test_expect_success 'untracked files or local changes ovewritten by merge' '
cat >expect <<\EOF
error: Your local changes to the following files would be overwritten by checkout:
- rep/one
- rep/two
-Please, commit your changes or stash them before you can switch branches.
+error: rep/one
+error: rep/two
+error: Please, commit your changes or stash them before you can switch branches.
Aborting
EOF
@@ -92,9 +92,9 @@ test_expect_success 'cannot switch branches because of local changes' '
cat >expect <<\EOF
error: Your local changes to the following files would be overwritten by checkout:
- rep/one
- rep/two
-Please, commit your changes or stash them before you can switch branches.
+error: rep/one
+error: rep/two
+error: Please, commit your changes or stash them before you can switch branches.
Aborting
EOF
@@ -106,9 +106,9 @@ test_expect_success 'not uptodate file porcelain checkout error' '
cat >expect <<\EOF
error: Updating the following directories would lose untracked files in it:
- rep
- rep2
-
+error: rep
+error: rep2
+error:
Aborting
EOF
diff --git a/usage.c b/usage.c
index a2a6678..1b55afd 100644
--- a/usage.c
+++ b/usage.c
@@ -6,11 +6,18 @@
#include "git-compat-util.h"
#include "cache.h"
-void vreportf(const char *prefix, const char *err, va_list params)
+void vreportf(const char *line_fmt, const char *err, va_list params)
{
char msg[4096];
+ char *line, *end;
+
vsnprintf(msg, sizeof(msg), err, params);
- fprintf(stderr, "%s%s\n", prefix, msg);
+
+ for (line = msg; (end = strchr(line, '\n')); line = end) {
+ *end++ = 0;
+ fprintf(stderr, line_fmt, line);
+ }
+ fprintf(stderr, line_fmt, line);
}
void vwritef(int fd, const char *prefix, const char *err, va_list params)
@@ -27,24 +34,24 @@ void vwritef(int fd, const char *prefix, const char *err, va_list params)
static NORETURN void usage_builtin(const char *err, va_list params)
{
- vreportf("usage: ", err, params);
+ vreportf("usage: %s\n", err, params);
exit(129);
}
static NORETURN void die_builtin(const char *err, va_list params)
{
- vreportf("fatal: ", err, params);
+ vreportf("fatal: %s\n", err, params);
exit(128);
}
static void error_builtin(const char *err, va_list params)
{
- vreportf("error: ", err, params);
+ vreportf("error: %s\n", err, params);
}
static void warn_builtin(const char *warn, va_list params)
{
- vreportf("warning: ", warn, params);
+ vreportf("warning: %s\n", warn, params);
}
/* If we are in a dlopen()ed .so write to a global variable would segfault
--
1.7.8.rc0.126.gd15506
^ permalink raw reply related
* Re: [PATCH] Specify a precision for the length of a subject string
From: Miles Bader @ 2011-12-23 9:41 UTC (permalink / raw)
To: nathan.panike; +Cc: Andreas Schwab, git
In-Reply-To: <20111221145352.GB13097@llunet.cs.wisc.edu>
Nathan Panike <nwp@cs.wisc.edu> writes:
>> > $ git log --pretty='%h %30s' d165204 -1
>>
>> In C's formatted output this syntax denotes a minimum field width, not a
>> precision, so it will probably be surprising to many people.
>
> C semantics are already broken because (from git-log(1))
>
> "If you add a - (minus sign) after % of a placeholder, line-feeds that
> immediately precede the expansion are deleted if and only if the placeholder
> expands to an empty string."
>
> rather than indicating justification of the field.
There's no reason to make it _worse_ though...
For your desired feature, why not just use the C printf syntax for this
functionality, a leading dot before the max length? E.g. "%.30s".
-miles
--
Youth, n. The Period of Possibility, when Archimedes finds a fulcrum,
Cassandra has a following and seven cities compete for the honor of endowing a
living Homer.
^ permalink raw reply
* Re: [PATCH] Specify a precision for the length of a subject string
From: Jeff King @ 2011-12-23 10:09 UTC (permalink / raw)
To: nathan.panike; +Cc: git
In-Reply-To: <20111221145112.GA13097@llunet.cs.wisc.edu>
On Wed, Dec 21, 2011 at 08:51:13AM -0600, Nathan Panike wrote:
> > Hmm. I think the idea of limiting is OK (though personally, I would just
> > pipe through a filter that truncates long lines). But I'm a bit negative
> > on adding a tweak like this that only affects the subject. Is there a
> > reason I couldn't do %30gs, or %30f, or even some other placeholder?
>
> The ones that make sense to limit are all those that depend on the subject, as the
> above; it does not make sense to limit other fields that don't depend on the
> subject, as they are fixed width, or have small variance. And it does not make
> sense to me to limit the length of the body.
I agree the subject is the most likely place. I was thinking one might
want to do it with the body, too. But whether it would be "I want N
bytes of the body" or "truncate each body line at N bytes without
wrapping", I don't know.
-Peff
^ permalink raw reply
* Re: [PATCH] Specify a precision for the length of a subject string
From: Jeff King @ 2011-12-23 10:35 UTC (permalink / raw)
To: nathan.panike; +Cc: git
In-Reply-To: <20111223100957.GA1247@sigill.intra.peff.net>
On Fri, Dec 23, 2011 at 05:09:58AM -0500, Jeff King wrote:
> > The ones that make sense to limit are all those that depend on the subject, as the
> > above; it does not make sense to limit other fields that don't depend on the
> > subject, as they are fixed width, or have small variance. And it does not make
> > sense to me to limit the length of the body.
>
> I agree the subject is the most likely place. I was thinking one might
> want to do it with the body, too. But whether it would be "I want N
> bytes of the body" or "truncate each body line at N bytes without
> wrapping", I don't know.
Another place that might want it is %N (commit notes).
Here's how I would have done it. Not involving %w at all, but applying
equally to all placeholders.
[1/2]: pretty: refactor --format "magic" placeholders
[2/2]: pretty: allow "max-size" magic for all placeholders
I'm not personally interested in this topic, so I won't be pushing for
this to be included in git. But if it feels like the right direction for
you, feel free to be build on it and post it as part of your series (or
just take it as inspiration and make your own commits). Off the top of
my head, it needs:
- documentation updates
- tests
- userformat_want_item should also respect the same magic (it already
duplicates some of the "-/+/ " magic. It might be nice to factor
that part out).
-Peff
^ permalink raw reply
* [PATCH 1/2] pretty: refactor --format "magic" placeholders
From: Jeff King @ 2011-12-23 10:35 UTC (permalink / raw)
To: nathan.panike; +Cc: git
In-Reply-To: <20111223100957.GA1247@sigill.intra.peff.net>
Instead of assuming each magic token is a single character,
let's handle arbitrary-sized magic.
Signed-off-by: Jeff King <peff@peff.net>
---
pretty.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/pretty.c b/pretty.c
index 230fe1c..7b4d098 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1018,6 +1018,7 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void *context)
{
int consumed;
+ int magic_len = 0;
size_t orig_len;
enum {
NO_MAGIC,
@@ -1039,13 +1040,13 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
default:
break;
}
- if (magic != NO_MAGIC)
+ if (magic != NO_MAGIC) {
+ magic_len++;
placeholder++;
+ }
orig_len = sb->len;
consumed = format_commit_one(sb, placeholder, context);
- if (magic == NO_MAGIC)
- return consumed;
if ((orig_len == sb->len) && magic == DEL_LF_BEFORE_EMPTY) {
while (sb->len && sb->buf[sb->len - 1] == '\n')
@@ -1056,7 +1057,7 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
else if (magic == ADD_SP_BEFORE_NON_EMPTY)
strbuf_insert(sb, orig_len, " ", 1);
}
- return consumed + 1;
+ return consumed + magic_len;
}
static size_t userformat_want_item(struct strbuf *sb, const char *placeholder,
--
1.7.8.1.3.gba11d
^ permalink raw reply related
* [PATCH 2/2] pretty: allow "max-size" magic for all placeholders
From: Jeff King @ 2011-12-23 10:36 UTC (permalink / raw)
To: nathan.panike; +Cc: git
In-Reply-To: <20111223100957.GA1247@sigill.intra.peff.net>
You can now truncate a given placeholder to no more than a
certain number of characters with something like "%30s".
Signed-off-by: Jeff King <peff@peff.net>
---
This just uses the made-up "%30s" syntax, but you could easily tweak it
to handle "%.30s" or whatever.
pretty.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 7b4d098..06d96a7 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1019,6 +1019,7 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
{
int consumed;
int magic_len = 0;
+ int max_len = 0;
size_t orig_len;
enum {
NO_MAGIC,
@@ -1045,9 +1046,22 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
placeholder++;
}
+ if (isdigit(placeholder[0])) {
+ char *end;
+ max_len = strtoul(placeholder, &end, 10);
+ magic_len += (end - placeholder);
+ placeholder = end;
+ }
+
orig_len = sb->len;
consumed = format_commit_one(sb, placeholder, context);
+ if (max_len) {
+ size_t end = orig_len + max_len;
+ if (end < sb->len)
+ strbuf_setlen(sb, end);
+ }
+
if ((orig_len == sb->len) && magic == DEL_LF_BEFORE_EMPTY) {
while (sb->len && sb->buf[sb->len - 1] == '\n')
strbuf_setlen(sb, sb->len - 1);
--
1.7.8.1.3.gba11d
^ permalink raw reply related
* I can never finish a push
From: Martin L Resnick @ 2011-12-23 13:11 UTC (permalink / raw)
To: git
I'm working remotely over a VERY slow line.
When I do a push it starts out fine
but after the 15 seconds it takes to push
it fails with non-fast-forward merge.
So I pull (no merge needed, its fast-forward)
and try push again. Fails again.
I can keep this up for hours on end;
pushing, pulling, pushing, pulling.
Apparently there is fast and furious development
on the branch I'm on that during my 15 seconds
of pushing someone else on-site pushes and adds
new commits before mine can finish.
Is there anyway to lock the repository while
my push is going on ?
Please don't ask why I have a slow line
or why the volume of changes that I am pushing.
Suffice it to say its military work.
^ permalink raw reply
* Re: I can never finish a push
From: Thomas Rast @ 2011-12-23 14:18 UTC (permalink / raw)
To: Martin L Resnick; +Cc: git
In-Reply-To: <4EF47DF3.9080809@bbn.com>
Martin L Resnick <mresnick@bbn.com> writes:
> I'm working remotely over a VERY slow line.
>
> When I do a push it starts out fine
> but after the 15 seconds it takes to push
> it fails with non-fast-forward merge.
>
> So I pull (no merge needed, its fast-forward)
> and try push again. Fails again.
>
> I can keep this up for hours on end;
> pushing, pulling, pushing, pulling.
> Apparently there is fast and furious development
> on the branch I'm on that during my 15 seconds
> of pushing someone else on-site pushes and adds
> new commits before mine can finish.
>
> Is there anyway to lock the repository while
> my push is going on ?
Git doesn't have any locking features.
Your best bet is probably to have someone with faster access merge your
branch, e.g., by pushing your work elsewhere (to another repo or just
a different branch) and then sending them an email asking for your work
to be merged.
If you have this issue a lot, the admins of your repo server could
probably arrange for a feature where you push to a special "please merge
this" branch namespace (such as incoming/martin-resnick), and the server
then does the merge for you using locking (and of course refusing if
there was any conflict).
However, it somewhat eludes me how you can generate churn on the order
of 2000 commits (8*3600/15) per workday *to the same repository*.
Perhaps the repository should be split into subprojects? Or at the very
least, the subprojects should be handled in different repositories, from
which an integrator pulls together the daily latest-and-greatest across
all subprojects?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: I can never finish a push
From: demerphq @ 2011-12-23 14:19 UTC (permalink / raw)
To: Martin L Resnick; +Cc: git
In-Reply-To: <4EF47DF3.9080809@bbn.com>
On 23 December 2011 14:11, Martin L Resnick <mresnick@bbn.com> wrote:
> I'm working remotely over a VERY slow line.
>
> When I do a push it starts out fine
> but after the 15 seconds it takes to push
> it fails with non-fast-forward merge.
>
> So I pull (no merge needed, its fast-forward)
> and try push again. Fails again.
>
> I can keep this up for hours on end;
> pushing, pulling, pushing, pulling.
> Apparently there is fast and furious development
> on the branch I'm on that during my 15 seconds
> of pushing someone else on-site pushes and adds
> new commits before mine can finish.
>
> Is there anyway to lock the repository while
> my push is going on ?
>
> Please don't ask why I have a slow line
> or why the volume of changes that I am pushing.
> Suffice it to say its military work.
Maybe try pushing a branch and then having a colleague with a faster
connection do the merge for you.
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: I can never finish a push
From: Johannes Sixt @ 2011-12-23 14:39 UTC (permalink / raw)
To: Martin L Resnick; +Cc: git
In-Reply-To: <4EF47DF3.9080809@bbn.com>
Am 12/23/2011 14:11, schrieb Martin L Resnick:
> I'm working remotely over a VERY slow line.
>
> When I do a push it starts out fine
> but after the 15 seconds it takes to push
> it fails with non-fast-forward merge.
>
> So I pull (no merge needed, its fast-forward)
> and try push again. Fails again.
>
> I can keep this up for hours on end;
> pushing, pulling, pushing, pulling.
Your statements can only make sense if the pushed branch generates a
"non-fast-forward" is not the same branch that you pull. Show a transcript
of your commands, and in particular also tell your setting of push.default.
-- Hannes
^ permalink raw reply
* Re: I can never finish a push
From: Andreas Schwab @ 2011-12-23 14:39 UTC (permalink / raw)
To: Martin L Resnick; +Cc: git
In-Reply-To: <4EF47DF3.9080809@bbn.com>
Martin L Resnick <mresnick@bbn.com> writes:
> So I pull (no merge needed, its fast-forward)
If the merge is fast-forward then you aren't really having anything to
push, are you? Are you sure you are pushing the right branch?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: "Nested quantifiers" error in gitweb with "++" in the filename
From: demerphq @ 2011-12-23 16:02 UTC (permalink / raw)
To: Jehan Bing; +Cc: git
In-Reply-To: <jd04eq$9m0$1@dough.gmane.org>
On 22 December 2011 21:37, Jehan Bing <jehan@orb.com> wrote:
> Hi,
>
> I'm getting an error when trying to look at a blob when the filename has
> "++" in it:
>
> http://.../blob/13ec1624fefc23d20d0407aac3337b35844a2ceb:/foo-++.txt
This error comes because the filename is being used a pattern without
being protected by a quotemeta.
Interestingly, a later version of perl would not have this problem as
++ is a legal quantifier as of 5.10, nevertheless it probably wouldnt
do what you expected.
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] fix shell command line in example
From: Joey Hess @ 2011-12-23 16:41 UTC (permalink / raw)
To: git
The comma was probably intended to be a semicolon so that the
two commands can be run by cut-n-paste.
Signed-off-by: Joey Hess <joey@kitenet.net>
---
Documentation/git-pull.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 0f18ec8..628695d 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -194,7 +194,7 @@ EXAMPLES
current branch:
+
------------------------------------------------
-$ git pull, git pull origin
+$ git pull; git pull origin
------------------------------------------------
+
Normally the branch merged in is the HEAD of the remote repository,
--
1.7.7.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox