* Re: filtering out mode-change-only changes
From: Junio C Hamano @ 2012-02-29 3:52 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <7vmx82wbmr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Neal Kreitzinger" <neal@rsss.com> writes:
>
>> What is the best way to filter out the "mode change only" entries from a
>> "name-status diff result" listing of changed files?
>> ...
> I do not know about random scripts people write, but there is nothing
> built-in.
Having said that, if we _were_ to do this built-in, an obvious logical
place to do so is to define a new DIFF_OPT_IGNORE_EXECUTABLE_BIT, teach
"--ignore-executable-bit" command line option to diff_opt_parse(), and
then teach diff_resolve_rename_copy() to consider this bit when the code
originally set DIFF_STATUS_MODIFIED. Instead, the updated code that is
working under --ignore-executable-bit option would drop such a filepair
from diff_queued_diff.
I do not know if such a change is worth doing, though. It depends on the
real reason why do you have so many "mode change only" changes that would
make rebasing or cherry-picking too troublesome.
^ permalink raw reply
* Re: [RFC/PATCH] Make git-{pull,rebase} no-tracking message friendlier
From: Carlos Martín Nieto @ 2012-02-29 3:57 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq399wc4ns.fsf@bauges.imag.fr>
On Mon, 2012-02-27 at 23:06 +0100, Matthieu Moy wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > - echo "You asked me to $cmd without telling me which branch you
> > -want to $op_type $op_prep, and 'branch.${branch_name#refs/heads/}.merge' in
> > -your configuration file does not tell me, either. Please
> > -specify which branch you want to use on the command line and
> > + echo "You asked me to $cmd without telling me which branch you want to
> > +$op_type $op_prep, and there is no tracking information for the current branch.
> > +Please specify which branch you want to use on the command line and
> > try again (e.g. '$example').
>
> At this point, it may be better to actually give the full command
> instead of just this "(e.g. '$example')", i.e. stg like
>
> git $op_type <remote> $example
>
> I also saw users confused by the message (indeed without reading it,
> but ...). Giving them something as close as possible to
> cut-and-paste-able command should help.
$example is a caller-given string which already contains the whole
command (i.e. it's already 'git rebase <upstream branch>' or 'git pull
<repository> <branch>'). In this patch I've moved that command to its
own paragraph so the usage part of the output gets more visibility.
Another version of the patch, this one somewhat more intrusive,
hopefully easier to digest.
---8<---
Subject: [PATCH] Make git-{pull,rebase} message without tracking information
friendlier
The current message is too long and at too low a level for anybody to
understand it if they don't know about the configuration format
already.
Reformat it to show the commands a user would be expected to use,
instead of the contents of the configuration file. Use <branch>
instead of <refspec> or <upstream branch> as they're bound to consfuse
new users more than help them. Use <remote> instead of <repository> in
the pull message.
---
git-parse-remote.sh | 26 ++++++++++----------------
git-pull.sh | 2 +-
git-rebase.sh | 2 +-
3 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index b24119d..bcb75a0 100644
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -66,25 +66,19 @@ line and try again (e.g. '$example').
See git-${cmd}(1) for details."
else
echo "You asked me to $cmd without telling me which branch you
-want to $op_type $op_prep, and 'branch.${branch_name#refs/heads/}.merge' in
-your configuration file does not tell me, either. Please
-specify which branch you want to use on the command line and
-try again (e.g. '$example').
-See git-${cmd}(1) for details.
+want to $op_type $op_prep, and the current branch doesn't have
+tracking information. Please specify which branch you want to
+use on the command line and try again. See git-${cmd}(1) for details.
+
+ $example
If you often $op_type $op_prep the same branch, you may want to
-use something like the following in your configuration file:
- [branch \"${branch_name#refs/heads/}\"]
- remote = <nickname>
- merge = <remote-ref>"
- test rebase = "$op_type" &&
- echo " rebase = true"
- echo "
- [remote \"<nickname>\"]
- url = <url>
- fetch = <refspec>
+run something like:
-See git-config(1) for details."
+ git remote add <remote> <url>
+ git branch --set-upstream ${branch_name#refs/heads/} <remote>/<branch>"
+ test rebase = "$op_type" &&
+ echo " git config branch.${branch_name#refs/heads/}.rebase true"
fi
exit 1
}
diff --git a/git-pull.sh b/git-pull.sh
index d8b64d7..309c7db 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -176,7 +176,7 @@ error_on_no_merge_candidates () {
elif [ -z "$curr_branch" -o -z "$upstream" ]; then
. git-parse-remote
error_on_missing_default_upstream "pull" $op_type $op_prep \
- "git pull <repository> <refspec>"
+ "git pull <remote> <branch>"
else
echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
echo "from the remote, but no such ref was fetched."
diff --git a/git-rebase.sh b/git-rebase.sh
index 00ca7b9..69c1374 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -380,7 +380,7 @@ then
then
. git-parse-remote
error_on_missing_default_upstream "rebase" "rebase" \
- "against" "git rebase <upstream branch>"
+ "against" "git rebase <branch>"
fi
;;
*) upstream_name="$1"
--
1.7.9.2.3.g4346f
^ permalink raw reply related
* Re: [PATCH v7 02/10] Stop starting pager recursively
From: Junio C Hamano @ 2012-02-29 4:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Ramsay Jones
In-Reply-To: <CACsJy8BfBP9m8rdEY3mk6g4G7n5LyFPvvNgNK2bkwC6L7qTDCg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Wed, Feb 29, 2012 at 10:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>
>>> It does improve that situation, or at least it stops git from forking
>>> frantically.
>>
>> That "at least" sounds suspicious ;-) Do you mean that there is other
>> breakages in that mode of operation?
>
> Well, "shortlog -p" did not run $PAGER (i.e. less). I haven't had time
> to dig further.
Ok. for that matter,
$ GIT_PAGER="git -p column" git tag --list
does not seem to use pager, either, so that may not be limited to
shortlog, but in any case, I can see how the current code without your
patch can fall into a fork loop, and your patch is an improvement, even if
it may not yet be the whole solution.
^ permalink raw reply
* Re: l10n: the maintaince of git-po repo
From: Junio C Hamano @ 2012-02-29 5:34 UTC (permalink / raw)
To: Git List; +Cc: Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <CANYiYbGS_cFTHT1Pkafi9dmzedqezTq8k1tPkYur0b2St_c43Q@mail.gmail.com>
Jiang Xin <worldhello.net@gmail.com> writes:
> I'm looking forward to the next git release with Chinese l10n, so that
> I can start to rewrite my book on Git. ;-)
For people who don't know, Jiang kindly sent me an autographed copy of his
book https://plus.google.com/u/0/108182106411180467879/posts/XX2CewgxSAb I
can only read the command examples, but the book seems to have a good
coverage of modern Git, judging from the table of contents.
> The maintaince of the git-po and git-po-zh_CN repositories so far:
>
> git-po repository
> -----------------
> Location : https://github.com/gotgit/git-po
> Fork from : https://github.com/git/git
> Description: This is the Git l10n master repo, and is used to coordinate
> works of l10n teams. L10n team leaders send pull requests
> to this repo, while other l10n contributors should wok on
> the language specified repository created by the l10n team
> leader.
Thanks. I took a look.
I'll comment on the changes as if they came in the patch form here, to ask
for sanity checks from the list members.
> Makefile | 1 -
> po/.gitignore | 1 -
> po/git.pot | 3494 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> po/zh_CN.po | 3671 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 7165 insertions(+), 2 deletions(-)
> create mode 100644 po/git.pot
> create mode 100644 po/zh_CN.po
>
>
> diff --git a/Makefile b/Makefile
> index cf2c40b..be1957a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2635,7 +2635,6 @@ dist-doc:
>
> distclean: clean
> $(RM) configure
> - $(RM) po/git.pot
>
> profile-clean:
> $(RM) $(addsuffix *.gcda,$(addprefix $(PROFILE_DIR)/, $(object_dirs)))
The file is no longer a generated file but is tracked, and should not be
removed upon distclean. Good.
> diff --git a/po/.gitignore b/po/.gitignore
> index 4caa631..796b96d 100644
> --- a/po/.gitignore
> +++ b/po/.gitignore
> @@ -1,2 +1 @@
> -/git.pot
> /build
Likewise, it is not ignored anymore. Good.
> diff --git a/po/git.pot b/po/git.pot
> new file mode 100644
> index 0000000..efcda39
> --- /dev/null
> +++ b/po/git.pot
> @@ -0,0 +1,3494 @@
> +# SOME DESCRIPTIVE TITLE.
> +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
> +# This file is distributed under the same license as the PACKAGE package.
Should the above placeholder lines left as they are, or should they be
updated to name "Git" as the "PACKAGE" with "SOME DESCRIPTIVE TITLE"?
If the answer is "latter", I think we would need to apply a similar update
to po/git-gui.pot for git-gui package.
On the other hand, I think the placeholder lines below should stay as they
are.
> +# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
> +#
> +#, fuzzy
> +msgid ""
> +msgstr ""
> +"Project-Id-Version: PACKAGE VERSION\n"
> +"Report-Msgid-Bugs-To: Git Mailing List <git@vger.kernel.org>\n"
> +"POT-Creation-Date: 2012-02-28 09:17+0800\n"
> +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
> +"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
> +"Language-Team: LANGUAGE <LL@li.org>\n"
> +"Language: \n"
> +"MIME-Version: 1.0\n"
> +"Content-Type: text/plain; charset=CHARSET\n"
> +"Content-Transfer-Encoding: 8bit\n"
> +"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"
> +
> +#: advice.c:34
> +#, c-format
> +msgid "hint: %.*s\n"
> +msgstr ""
> ...
^ permalink raw reply
* Re: [PATCH 1/2] am -3: allow nonstandard -p<num> option
From: Jeff King @ 2012-02-29 7:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcmqwbto.fsf@alter.siamese.dyndns.org>
On Tue, Feb 28, 2012 at 07:36:03PM -0800, Junio C Hamano wrote:
> > $git_apply_opt can have other stuff in it, too (from my cursory reading,
> > it looks like --whitespace, --directory, --exclude, -C, --reject,
> > --ignore-whitespace, and --ignore-space-change). Those options are now
> > passed, too.
> >
> > Naively, I don't think it should be a problem. Many of them will do
> > nothing (because the patch _should_ apply cleanly to the blobs it
> > mentions). Some seem like an obvious improvement (e.g., "--directory"
> > should be just as necessary as "-p", I would think). For something like
> > "--whitespace=error", I would think we would have errored out already
> > when we first tried to apply the patch. Or maybe not. I didn't test.
>
> An honest answer is that I didn't think deeply if they matter ;-).
I figured. But once in a while it is good to hold you to the same
standard that we do of other contributors. :)
> Certainly we would want to honor the original settings for whitespace
> errors by propagating the option, so that we would reject or adjust when
> synthesizing the fake ancestor tree the same way as we deal with them when
> apply the patch for real.
I did a quick test, and yes, your patch is an improvement for the other
options, too. Though it's still not perfect. My test was:
# make a repo with a simple file
git init -q repo && cd repo &&
perl -le 'print for(1..10)' >foo && git add foo && git commit -qm base &&
# now make a whitespace-damaged patch
sed -i 's/3/trailing whitespace /' foo && git commit -qam ws &&
git format-patch -1 --stdout >patch &&
git reset -q --hard HEAD^ &&
# now make a change that needs a 3-way merge
sed -i 's/5/conflicting context/' foo && git commit -qam conflict &&
# and then apply our patch with 3-way fallback, erroring out on
# whitespace
git am --whitespace=error -3 patch
which does indeed apply the patch with the wrong whitespace settings.
With your patch, it correctly refuses to apply. Though the output is:
Applying: ws
/home/peff/foo/am/repo/.git/rebase-apply/patch:13: trailing whitespace.
trailing whitespace
fatal: 1 line adds whitespace errors.
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 ws
which is misleading. We do not lack the necessary blobs, but rather
git-apply failed for a different reason. However, git-apply doesn't
differentiate the situations by exit code, so git-am is left to guess.
So I think the unintended side effects of your patch are likely to be a
good thing and fix bugs. Possibly the commit message should explain
that, but as it is already in next, I'm content to leave this thread in
the list archive as a footnote.
We could assign a special exit code to git-apply to allow git-am to
produce a better error message. I don't know if it's worth the effort.
-Peff
^ permalink raw reply
* Re: Tilde spec - befuzzled
From: Jeff King @ 2012-02-29 7:34 UTC (permalink / raw)
To: Andrew Ardill
Cc: Junio C Hamano, Thomas Rast, Andreas Ericsson, Luke Diamand,
Git List
In-Reply-To: <CAH5451m=6XhRj1osN_Dw7zKvAW-jtru+EbCkRvo8aNRMbJS6bA@mail.gmail.com>
On Wed, Feb 29, 2012 at 12:18:07PM +1100, Andrew Ardill wrote:
> >>>> '<rev>{tilde}<n>', e.g. 'master{tilde}3'::
> >>>> A suffix '{tilde}<n>' to a revision parameter means the commit
> >>>> object that is the <n>th generation grand-parent of the named
> >>>> commit object, following only the first parents.
> >>>>
> >>>> Hang on, *grand*-parents?
> >>>> ...
> >>
> >> Perhaps we should reword it as "n-th first-parent ancestor"? Barring
> >> confusion about the position of the dashes, that leaves little room for
> >> error.
> >
> > I think we could either go "easier to read but not precise"
> >
> > ... that is the <n>th generation (grand-)parent of ...
> >
> > or "may sound scary but correct"
> >
> > the ancestor reached by walking the first-parent chain <n> times
> >
> > I am not sure which bucket "n-th first-parent ancestor" falls into.
>
> The terms might be too technical, however my understanding was that
> HEAD^n takes <n> steps along a breadth-first traversal of the commit
> tree rooted at HEAD, while HEAD~n uses a depth-first traversal.
The term breadth-first has me confused, as it implies that we will
traverse the breadth of the tree before descending to the next level of
depth. As if foo^3 would mean "well, foo only has two parents, so go on
to the next level of the tree". It is really a breadth-only traversal,
and the tilde is a depth-only traversal.
Anyway, it seems to me the OP's confusion can be cleared up with
s/grand-parent/ancestor/. Of course, while we are here, it might be
worth expanding or improving the text if there are other confusing
aspects (which I'm not sure there are).
-Peff
^ permalink raw reply
* Re: Incremental updates to What's cooking
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-29 7:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vy5rn1mar.fsf@alter.siamese.dyndns.org>
On 02/28/2012 07:53 AM, Junio C Hamano wrote:
> * zj/diff-stat-dyncol (2012-02-27) 11 commits
> - diff --stat: add config option to limit graph width
> - diff --stat: enable limiting of the graph part
> - diff --stat: add a test for output with COLUMNS=40
> - diff --stat: use a maximum of 5/8 for the filename part
> - merge --stat: use the full terminal width
> - log --stat: use the full terminal width
> - show --stat: use the full terminal width
> - diff --stat: use the full terminal width
> - diff --stat: tests for long filenames and big change counts
> - t4014: addtional format-patch test vectors
> - Merge branches zj/decimal-width, zj/term-columns and jc/diff-stat-scaler
>
> I resurrected the additional tests for format-patch from an earlier round,
> as it illustrates the behaviour change brought by "5/8 split" very well.
Hi,
the resurrected tests are partly duplicated in 4052-stat-output.sh:
t4014:
ok 75 - small change with long name gives more space to the name
ok 76 - a long name is given more room when the bar is short
ok 77 - format patch --stat-width=width works with long name *
ok 78 - format patch --stat=...,name-width with long name *
ok 79 - format patch --stat-name-width with long name *
ok 81 - format patch graph part width *
ok 82 - format patch ignores COLUMNS *
ok 83 - format patch --stat=width with big change *
ok 84 - format patch --stat-width=width with big change *
ok 85 - partition between long name and big change is more balanced
t4052:
ok 3 - format-patch graph width defaults to 80 columns
ok 4 - format-patch --stat=width with long name
ok 5 - format-patch --stat-width=width with long name
ok 6 - format-patch --stat=...,name-width with long name
ok 7 - format-patch --stat-name-width with long name
ok 24 - format-patch ignores too many COLUMNS (big change)
ok 28 - format-patch ignores not enough COLUMNS (big change)
ok 29 - format-patch ignores statGraphWidth config
ok 36 - format-patch --stat=width with big change
ok 37 - format-patch --stat-width=width with big change
ok 38 - format-patch --stat-graph--width with big change
ok 49 - format-patch --stat=width with big change and long name
ok 53 - format-patch ignores COLUMNS (long filename)
The ones with * are duplicated exactly. They tests run very fast, but
maybe the duplicated ones should be culled.
Zbyszek
^ permalink raw reply
* git archive invocation using sha1 to specify commit
From: Zdenek Crha @ 2012-02-29 7:45 UTC (permalink / raw)
To: git
CC me on answers please, since I'm not subscribed to the list
Hello,
I would like to ask a question about commit restriction added to git
archive by commit (ee27ca4a: archive: don't let remote clients get
unreachable commits, 2011-11-17) and following efforts to loosen them
a bit.
In out company we are using git together with source indexing. We
store a git command for retrieval of source code file that was used
for building into pdb file(s). Currently, we are using an invocation
of git archive with --remote parameter and commit sha1 to export
exactly the source code that was used for build.
The above mentioned commit removed possibility to do that. I have read
about efforts to loosen the restrictions,
but I'm not sure whenever ability to export arbitrary sha1 will be
allowed too. Can anybody clarify that for me please?
Regards,
Zdenek Crha
^ permalink raw reply
* Re: [RFC/PATCH] Make git-{pull,rebase} no-tracking message friendlier
From: Matthieu Moy @ 2012-02-29 8:09 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1330487854.691.24.camel@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> $example is a caller-given string which already contains the whole
> command (i.e. it's already 'git rebase <upstream branch>' or 'git pull
> <repository> <branch>').
OK, I didn't remember the exact message.
> In this patch I've moved that command to its own paragraph so the
> usage part of the output gets more visibility.
I prefer this, yes.
Perhaps we could go further and try to guess a remote and a branch name
to give in the example. "git push" already does that to some extend:
$ git -c push.default=tracking push
fatal: The current branch my-branch has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin my-branch
i.e. if there's a remote configured, then using it in the example makes
sense. I'm not sure if using the current branch name in the example
would also be a good thing (it usually is for "push" because most users
would push to a branch with the same name on the remote end).
It may also make sense not to suggest "git remote add" if there's
already a remote configured. Otherwise, the case, which is probably the
most common, of:
git clone http://example.com/repo
cd repo
git checkout -b new-branch
git pull
is made far more complex than it should for the newcommer.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Update l10n guide
From: Junio C Hamano @ 2012-02-29 8:23 UTC (permalink / raw)
To: Git List; +Cc: Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <7v1upew6d0.fsf@alter.siamese.dyndns.org>
Describe the high-level overview of the localization workflow, and update
the description on po/git.pot file, which no longer is an untracked file.
Clarify the roles and responsibilities among:
- the core developers (responsible for marking the translatable strings
and restructuring the code to avoid message-lego);
- the l10n coordinator (maintaining po/git.pot, interfacing with language
teams and feeding updated translations back to the core); and
- the language teams (updating po/*.po for their language and feeding
their work back to the l10n coordinator).
This is largely based on an earlier message $gmane/189584 from me.
Date: Wed, 01 Feb 2012 20:56:18 -0800
Message-ID: <7vmx91ygst.fsf@alter.siamese.dyndns.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I would like to see something like this before we start getting the
second language team. Comments are very much appreciated.
I am not sure if the existing instruction to update the new XX.po
file copied from git.pot is correct, but I left it as-is.
@@ -1,6 +1,6 @@
-# Icelandic translations for PACKAGE package.
-# Copyright (C) 2010 THE PACKAGE'S COPYRIGHT HOLDER
-# This file is distributed under the same license as the PACKAGE package.
+# Icelandic translations for Git.
+# Copyright (C) 2010 Ævar Arnfjörð Bjarmason <avarab@gmail.com>
+# This file is distributed under the same license as the Git package.
# Ævar Arnfjörð Bjarmason <avarab@gmail.com>, 2010.
The second line of the template tells us to name the copyright holder
of the package, not of the translation, but the above example makes it
appear as if we are assigning the copyright to the translator.
po/README | 106 ++++++++++++++++++++++++++++++++++++++++++++++++-------------
po/TEAMS | 10 ++++++
2 files changed, 94 insertions(+), 22 deletions(-)
create mode 100644 po/TEAMS
diff --git a/po/README b/po/README
index 10b0ad2..6480882 100644
--- a/po/README
+++ b/po/README
@@ -1,33 +1,78 @@
Core GIT Translations
=====================
-This directory holds the translations for the core of Git. This
-document describes how to add to and maintain these translations, and
-how to mark source strings for translation.
-
+This directory holds the translations for the core of Git. This document
+describes how you can contribute to the effort of enhancing the language
+coverage and maintaining the translation.
+
+The localization (l10n) coordinator, Jiang Xin <worldhello.net@gmail.com>,
+coordinates our localization effort in his repository:
+
+ https://github.com/gotgit/git-po/
+
+As a contributor for a language XX, you would fork this repository,
+prepare and/or update the translated message file po/XX.po (described
+later), and ask the l10n coordinator to pull your work.
+
+If there are multiple contributors for the same language, please first
+coordinate among yourselves and nominate the team leader for your
+language, so that the l10n coordinator only needs to interact with one
+person per language.
+
+For the list of exiting translations and language teams, see TEAMS file in
+this directory.
+
+The overall data-flow looks like this:
+
+ +-------------------+ +------------------+
+ | Git source code | ---(1)---> | L10n coordinator |
+ | repository | <---(4)--- | repository |
+ +-------------------+ +------------------+
+ | ^
+ (2) (3)
+ V |
+ +------------------+
+ | Language Team XX |
+ +------------------+
+
+ * Translatable strings are marked in the source file.
+ * L10n coordinator pulls from the source (1)
+ * L10n coordinator updates the message template po/git.pot
+ * Language team pulls from L10n coordinator (2)
+ * Language team updates the message file po/XX.po
+ * L10n coordinator pulls from Language team (3)
+ * L10n coordinator asks the result to be pulled (4).
+
+
+Maintaining the po/git.pot file
+-------------------------------
-Generating a .pot file
-----------------------
+(This is done by the l10n coordinator).
The po/git.pot file contains a message catalog extracted from Git's
-sources. You need to generate it to add new translations with
-msginit(1), or update existing ones with msgmerge(1).
+sources. The l10n coordinator maintains it by adding new translations with
+msginit(1), or update existing ones with msgmerge(1). In order to update
+the Git sources to extract the messages from, the l10n coordinator is
+expected to pull from the main git repository at strategic point in
+history (e.g. when a major release and release candidates are tagged),
+and then run "make pot" at the top-level directory.
-Since the file can be automatically generated it's not checked into
-git.git. To generate it do, at the top-level:
+Language contributors use this file to prepare translations for their
+language, but they are not expected to modify it.
- make pot
+Initializing a XX.po file
+-------------------------
-Initializing a .po file
------------------------
+(This is done by the language teams).
-To add a new translation first generate git.pot (see above) and then
-in the po/ directory do:
+If your language XX does not have translated message file po/XX.po yet,
+you add a translation for the first time by running:
msginit --locale=XX
-Where XX is your locale, e.g. "is", "de" or "pt_BR".
+in the po/ directory, where XX is the locale, e.g. "de", "is", "pt_BR",
+"zh_CN", etc.
Then edit the automatically generated copyright info in your new XX.po
to be correct, e.g. for Icelandic:
@@ -46,21 +91,36 @@ just "Git":
perl -pi -e 's/(?<="Project-Id-Version: )PACKAGE VERSION/Git/' XX.po
+Once you are done testing the translation (see below), commit the result
+and ask the l10n coordinator to pull from you.
+
+
+Updating a XX.po file
+---------------------
-Updating a .po file
--------------------
+(This is done by the language teams).
-If there's an existing *.po file for your language but you need to
-update the translation you first need to generate git.pot (see above)
-and then in the po/ directory do:
+If you are replacing translation strings in an existing XX.po file to
+improve the translation, just edit the file.
+
+If there's an existing XX.po file for your language, but the repository
+of the l10n coordinator has newer po/git.pot file, you would need to first
+pull from the l10n coordinator (see the beginning of this document for its
+URL), and then update the existing translation by running:
msgmerge --add-location --backup=off -U XX.po git.pot
-Where XX.po is the file you want to update.
+in the po/ directory, where XX.po is the file you want to update.
+
+Once you are done testing the translation (see below), commit the result
+and ask the l10n coordinator to pull from you.
+
Testing your changes
--------------------
+(This is done by the language teams, after creating or updating XX.po file).
+
Before you submit your changes go back to the top-level and do:
make
@@ -75,6 +135,8 @@ with a newline or not.
Marking strings for translation
-------------------------------
+(This is done by the core developers).
+
Before strings can be translated they first have to be marked for
translation.
diff --git a/po/TEAMS b/po/TEAMS
new file mode 100644
index 0000000..8ee6199
--- /dev/null
+++ b/po/TEAMS
@@ -0,0 +1,10 @@
+Core Git translation language teams
+(please keep the list sorted alphabetically on language field)
+
+Language: is (Icelandic)
+Leader: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
+
+Language: zh_CN (Simplified Chinese)
+Leader: Jiang Xin <worldhello.net@gmail.com>
+Members: Yichao Yu <yyc1992@gmail.com>
+ Riku <lu.riku@gmail.com>
--
1.7.9.2.344.g3e8c86
^ permalink raw reply related
* Re: [PATCH v2 1/2] grep: use static trans-case table
From: Jeff King @ 2012-02-29 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1330474831-9030-2-git-send-email-gitster@pobox.com>
On Tue, Feb 28, 2012 at 04:20:30PM -0800, Junio C Hamano wrote:
> In order to prepare the kwset machinery for a case-insensitive search, we
> used to use a static table of 256 elements and filled it every time before
> calling kwsalloc(). Because the kwset machinery will never modify this
> table, just allocate a single instance globally and fill it at the compile
> time.
Hmm. I was going to complain that the original code used tolower() to
generate the table at run-time, and therefore respected the current
locale. But of course we have replaced tolower() with a
locale-independent version, so it should behave identically.
But that does make me wonder. Do people expect their case-insensitive
searches to work on non-ASCII characters? I would think yes, but I do
not use non-ASCII characters in the first place, so my opinion may not
mean much.
For that matter, does REG_ICASE respect locales? The glibc code appears
to consider it, but I couldn't make it work in some simple tests. But if
it does, that raises another weirdness: we fall back to kwset
transparently when a grep pattern contains no metacharacters. So you
would get different results for "-i --grep=é" versus "-i --grep=é.*".
Of course, even if we used a locale-respecting version of tolower in the
original code, I suspect that a byte table would be fundamentally
insufficient, anyway, in the face of multi-byte encodings like utf8.
So I don't think your patch is making the problem any worse. And even if
somebody wants to tackle the problem later, the solution would look so
unlike the original code that your change is not hurting their effort.
-Peff
^ permalink raw reply
* Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Jeff King @ 2012-02-29 8:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1330474831-9030-3-git-send-email-gitster@pobox.com>
On Tue, Feb 28, 2012 at 04:20:31PM -0800, Junio C Hamano wrote:
> "git log -S<string>" is a useful way to find the last commit in the
> codebase that touched the <string>. As it was designed to be used by a
> porcelain script to dig the history starting from a block of text that
> appear in the starting commit, it never had to look for anything but an
> exact match.
>
> When used by an end user who wants to look for the last commit that
> removed a string (e.g. name of a variable) that he vaguely remembers,
> however, it is useful to support case insensitive match.
>
> When given the "--regexp-ignore-case" (or "-i") option, which originally
> was designed to affect case sensitivity of the search done in the commit
> log part, e.g. "log --grep", the matches made with -S/-G pickaxe search is
> done case insensitively now.
I can't imagine anybody would want to have different case-sensitivity
options for grepping the commit message versus pickaxe. But even if they
do, and we later add options to control them individually, we would
still want the short-and-sweet "-i" to cover the common case of setting
both. So I think the approach is good.
The patch itself looks fine to me.
-Peff
^ permalink raw reply
* Re: Incremental updates to What's cooking
From: Junio C Hamano @ 2012-02-29 8:39 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek
Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <4F4DD5C1.60604@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> On 02/28/2012 07:53 AM, Junio C Hamano wrote:
>
>> * zj/diff-stat-dyncol (2012-02-27) 11 commits
>> - diff --stat: add config option to limit graph width
>> - diff --stat: enable limiting of the graph part
>> - diff --stat: add a test for output with COLUMNS=40
>> - diff --stat: use a maximum of 5/8 for the filename part
>> - merge --stat: use the full terminal width
>> - log --stat: use the full terminal width
>> - show --stat: use the full terminal width
>> - diff --stat: use the full terminal width
>> - diff --stat: tests for long filenames and big change counts
>> - t4014: addtional format-patch test vectors
>> - Merge branches zj/decimal-width, zj/term-columns and jc/diff-stat-scaler
>>
>> I resurrected the additional tests for format-patch from an earlier round,
>> as it illustrates the behaviour change brought by "5/8 split" very well.
> Hi,
> the resurrected tests are partly duplicated in 4052-stat-output.sh:
>
> t4014:
> ok 75 - small change with long name gives more space to the name
> ok 76 - a long name is given more room when the bar is short
> ok 77 - format patch --stat-width=width works with long name *
> ok 78 - format patch --stat=...,name-width with long name *
> ok 79 - format patch --stat-name-width with long name *
> ok 81 - format patch graph part width *
> ok 82 - format patch ignores COLUMNS *
> ok 83 - format patch --stat=width with big change *
> ok 84 - format patch --stat-width=width with big change *
> ok 85 - partition between long name and big change is more balanced
>
> t4052:
> ok 3 - format-patch graph width defaults to 80 columns
> ok 4 - format-patch --stat=width with long name
> ok 5 - format-patch --stat-width=width with long name
> ok 6 - format-patch --stat=...,name-width with long name
> ok 7 - format-patch --stat-name-width with long name
> ok 24 - format-patch ignores too many COLUMNS (big change)
> ok 28 - format-patch ignores not enough COLUMNS (big change)
> ok 29 - format-patch ignores statGraphWidth config
> ok 36 - format-patch --stat=width with big change
> ok 37 - format-patch --stat-width=width with big change
> ok 38 - format-patch --stat-graph--width with big change
> ok 49 - format-patch --stat=width with big change and long name
> ok 53 - format-patch ignores COLUMNS (long filename)
>
> The ones with * are duplicated exactly. They tests run very fast, but
> maybe the duplicated ones should be culled.
Yeah, probably we should de-dup them.
Compare the behaviour change shown for t4052 and for t4014 by 119c07bf.
Which one more obviously show the effect of the code change to allow the
reader judge if the behaviour change is going in a good direction?
The style used in t4052 only changes expect_failure to expect_success, and
the reader has to accept the judgement of the person who wrote the test
vector and declared "this is the _right_ output!". The way t4014, taken
from your earlier round, shows the behaviour change shows how the
expectation changes from the old behaviour to the new one, and the reader
can see and decide which one is giving a better output.
Actually, the whole reason I didn't notice duplicates in 4052 was because
of the above X-<.
If we remove duplicates, will 4052 become empty? It would be really nice
if we do not have to add a new test script for this series, and instead
add necessary new tests to existing scripts.
^ permalink raw reply
* Re: git archive invocation using sha1 to specify commit
From: Junio C Hamano @ 2012-02-29 8:46 UTC (permalink / raw)
To: Zdenek Crha; +Cc: git
In-Reply-To: <CA+OUE96-mLc0RJZz0g0oBWxdZKeCMQ9xJbg6DjCacN119TFY+A@mail.gmail.com>
Zdenek Crha <zdenek.crha@gmail.com> writes:
> In out company we are using git together with source indexing. We
> store a git command for retrieval of source code file that was used
> for building into pdb file(s). Currently,...
> ... I'm not sure whenever ability to export arbitrary sha1 will be
> allowed too.
No, that will be a premium feature that your company _could_ pay for with
the source of that "source indexing" system ;-)
Jokes aside, this was part of a security tightening to make sure nobody
could reach something that cannot be obtained by cloning, without incurring
large computation overhead.
Theoretically we could selectively loosen the restriction [*1*], but it is
not very high on our priority list.
[Footnote]
*1* When the given starting point is a raw SHA-1, we could run a single
merge_bases_many() to see if any of the refs can reach it, and only serve
the tree the check passes, or something.
^ permalink raw reply
* Re: [PATCH v2 1/2] grep: use static trans-case table
From: Junio C Hamano @ 2012-02-29 8:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120229082814.GB14181@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So I don't think your patch is making the problem any worse. And even if
> somebody wants to tackle the problem later, the solution would look so
> unlike the original code that your change is not hurting their effort.
Yes.
^ permalink raw reply
* Re: git archive invocation using sha1 to specify commit
From: Jeff King @ 2012-02-29 8:53 UTC (permalink / raw)
To: Zdenek Crha; +Cc: git
In-Reply-To: <CA+OUE96-mLc0RJZz0g0oBWxdZKeCMQ9xJbg6DjCacN119TFY+A@mail.gmail.com>
On Wed, Feb 29, 2012 at 08:45:55AM +0100, Zdenek Crha wrote:
> I would like to ask a question about commit restriction added to git
> archive by commit (ee27ca4a: archive: don't let remote clients get
> unreachable commits, 2011-11-17) and following efforts to loosen them
> a bit.
>
> In out company we are using git together with source indexing. We
> store a git command for retrieval of source code file that was used
> for building into pdb file(s). Currently, we are using an invocation
> of git archive with --remote parameter and commit sha1 to export
> exactly the source code that was used for build.
>
> The above mentioned commit removed possibility to do that. I have read
> about efforts to loosen the restrictions,
> but I'm not sure whenever ability to export arbitrary sha1 will be
> allowed too. Can anybody clarify that for me please?
The plans for loosening are still up in the air, as we didn't have real
data on whether people were using this feature or not. I do have patches
ready that loosen the restriction based on the details of the name
lookup, which would allow things which started a traversal from a ref,
like "foo~5". But it would explicitly not allow an arbitrary sha1.
The only way to correctly handle an arbitrary sha1 is to actually do a
reachability analysis from the refs. That's what we do with upload-pack
(which handles regular fetch and clone requests). However, handling the
general case of fetching an arbitrary tree would mean we would have to
look inside every commit to see if it contains the tree. And that can
get a bit expensive. It sounds like you are just asking for a commit
sha1, so for your case we could get away with just handling sha1s of
commits, and only allowing trees that are referenced by commit (e.g.,
"HEAD~5:subdir") or have an exact ref pointing to them (e.g., like the
linux v2.6.11-tree tag).
Yet another option would be to add a config option on the server repo to
turn off this safety check for git-archive. That is simple to do, and
sounds like it would handle your use case, as you control the repo. One
downside is that it is the server admin who must turn on the config
option, whereas it is the clients of the repo who might want to make the
bare-sha1 request. In a company, the admins (usually) have to listen to
the clients, but that is not always the case.
-Peff
^ permalink raw reply
* Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Junio C Hamano @ 2012-02-29 8:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120229083534.GC14181@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> When given the "--regexp-ignore-case" (or "-i") option, which originally
>> was designed to affect case sensitivity of the search done in the commit
>> log part, e.g. "log --grep", the matches made with -S/-G pickaxe search is
>> done case insensitively now.
>
> I can't imagine anybody would want to have different case-sensitivity
> options for grepping the commit message versus pickaxe. But even if they
> do, and we later add options to control them individually, we would
> still want the short-and-sweet "-i" to cover the common case of setting
> both. So I think the approach is good.
What you didn't read in the above is that the devilq around "-i" is not in
the case insensitivity switch between log-part grep (--grep/--author) and
patch part grep (-S/-G), but how it interacts with generating the patch
part case insensitively (i.e. "log -p --ignore-case", which is also "-i").
You can see what I decided to do in an evil merge in 'pu'.
In short,
* The short-and-sweet "-i" means both --regexp-ignore-case (grep) and
--ignore-case (diff); and
* The long-hand can be used to ask for case
insensitive grep but case sensitive patch, or vice versa.
^ permalink raw reply
* Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Jeff King @ 2012-02-29 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5rmt3w8.fsf@alter.siamese.dyndns.org>
On Wed, Feb 29, 2012 at 12:55:35AM -0800, Junio C Hamano wrote:
> > I can't imagine anybody would want to have different case-sensitivity
> > options for grepping the commit message versus pickaxe. But even if they
> > do, and we later add options to control them individually, we would
> > still want the short-and-sweet "-i" to cover the common case of setting
> > both. So I think the approach is good.
>
> What you didn't read in the above is that the devilq around "-i" is not in
> the case insensitivity switch between log-part grep (--grep/--author) and
> patch part grep (-S/-G), but how it interacts with generating the patch
> part case insensitively (i.e. "log -p --ignore-case", which is also "-i").
Hmm. So there are actually three potential options to flip. However, I
think the reasoning above is still sound. We could later split
--regexp-ignore-case into two sub-options if we wanted (but like I said,
I doubt anybody will want that; I was more concerned with making sure
that if somebody _does_ want it, we have not painted ourselves into a
corner).
> You can see what I decided to do in an evil merge in 'pu'.
>
> In short,
>
> * The short-and-sweet "-i" means both --regexp-ignore-case (grep) and
> --ignore-case (diff); and
>
> * The long-hand can be used to ask for case
> insensitive grep but case sensitive patch, or vice versa.
Yes, the evil merge looks sane, assuming both topics implement the
desired behavior.
I am a little dubious of the decision in jc/diff-ignore-case to have
"-i" imply "--ignore-case". For "git diff", it makes perfect sense. But
for "git log", it feels wrong. Ignoring case for the regexps is very
common, and ignoring case for the diffs is uncommon (it is, after all, a
feature we have gone many years without, and I don't remember anyone
bringing it up until recently).
As a user, I would be surprised that something common like "git log
--author=junio -i -p" would change diff generation between versions of
git. It's probably not a huge regression, as patches which actually
look different with --ignore-case are relatively rare, so you are
unlikely to see any difference if you trigger it accidentally. But that
just argues to me that it is a feature that one would want to turn on
explicitly, anyway.
-Peff
^ permalink raw reply
* Re: Tilde spec - befuzzled
From: Andreas Ericsson @ 2012-02-29 9:30 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Junio C Hamano, Thomas Rast, Luke Diamand, Git List
In-Reply-To: <CAH5451m=6XhRj1osN_Dw7zKvAW-jtru+EbCkRvo8aNRMbJS6bA@mail.gmail.com>
On 02/29/2012 02:18 AM, Andrew Ardill wrote:
> On 29 February 2012 06:20, Junio C Hamano<gitster@pobox.com> wrote:
>> Thomas Rast<trast@inf.ethz.ch> writes:
>>
>>>>> '<rev>{tilde}<n>', e.g. 'master{tilde}3'::
>>>>> A suffix '{tilde}<n>' to a revision parameter means the commit
>>>>> object that is the<n>th generation grand-parent of the named
>>>>> commit object, following only the first parents.
>>>>>
>>>>> Hang on, *grand*-parents?
>>>>> ...
>>>
>>> Perhaps we should reword it as "n-th first-parent ancestor"? Barring
>>> confusion about the position of the dashes, that leaves little room for
>>> error.
>>
>> I think we could either go "easier to read but not precise"
>>
>> ... that is the<n>th generation (grand-)parent of ...
>>
>> or "may sound scary but correct"
>>
>> the ancestor reached by walking the first-parent chain<n> times
>>
>> I am not sure which bucket "n-th first-parent ancestor" falls into.
>
> The terms might be too technical, however my understanding was that
> HEAD^n takes<n> steps along a breadth-first traversal of the commit
> tree rooted at HEAD, while HEAD~n uses a depth-first traversal.
>
> A better form for the description might come from that formulation of
> the process, rather than the 'generational' formulation.
>
I doubt it. Most non-programmers have no notion of the difference
between breadth-first and depth-first. You have to work with trees
or graphs in some form before breadth and depth become intuitive
to read in tech docs.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Tilde spec - befuzzled
From: Andreas Ericsson @ 2012-02-29 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Luke Diamand, Git List
In-Reply-To: <7vaa42zrw8.fsf@alter.siamese.dyndns.org>
On 02/28/2012 08:20 PM, Junio C Hamano wrote:
> Thomas Rast<trast@inf.ethz.ch> writes:
>
>>>> '<rev>{tilde}<n>', e.g. 'master{tilde}3'::
>>>> A suffix '{tilde}<n>' to a revision parameter means the commit
>>>> object that is the<n>th generation grand-parent of the named
>>>> commit object, following only the first parents.
>>>>
>>>> Hang on, *grand*-parents?
>>>> ...
>>
>> Perhaps we should reword it as "n-th first-parent ancestor"? Barring
>> confusion about the position of the dashes, that leaves little room for
>> error.
>
> I think we could either go "easier to read but not precise"
>
> ... that is the<n>th generation (grand-)parent of ...
>
(grand-)parent and ancestor are interchangeable while the parentheses
remain, although the former looks a bit clumsier in text.
> or "may sound scary but correct"
>
> the ancestor reached by walking the first-parent chain<n> times
>
> I am not sure which bucket "n-th first-parent ancestor" falls into.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Nelson Benitez Leon @ 2012-02-29 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, peff, sam.vilain, sam
In-Reply-To: <7v62eqzrqm.fsf@alter.siamese.dyndns.org>
On 02/28/2012 08:24 PM, Junio C Hamano wrote:
> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> Which raises the questions:
>>
>> * Why is this needed? Does git's use of libcurl ignore http_proxy? [1]
>> seems to indicate that libcurl respects <protocol>_proxy
>> automatically.
>>
>> * Why do you (need to?) support HTTP_PROXY when curl doesn't?
>
> Let me add a third bullet point.
>
> I've heard rumors that libcurl on some versions/installations of Mac OS X
> deliberately ignores the environment. For those who agree with Apple, it
> would be a regression if we suddenly start the environment ourselves and
> using it.
Hi Junio, what did you mean by "we start the environment and using it"?
I didn't understand what you mean there..
^ permalink raw reply
* Re: [PATCH 3/3] http: when proxy url has username but no password, ask for password
From: Nelson Benitez Leon @ 2012-02-29 10:46 UTC (permalink / raw)
To: Jeff King; +Cc: git, sam
In-Reply-To: <20120228193125.GA11725@sigill.intra.peff.net>
On 02/28/2012 08:31 PM, Jeff King wrote:
> On Tue, Feb 28, 2012 at 01:56:29PM +0100, Nelson Benitez Leon wrote:
>
>> diff --git a/http.c b/http.c
>> index 79cbe50..68e3f7d 100644
>> --- a/http.c
>> +++ b/http.c
>> @@ -306,7 +306,41 @@ static CURL *get_curl_handle(void)
>> }
>> }
>> if (curl_http_proxy) {
>> - curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>> + char *at, *colon, *proxyuser;
>> + const char *cp;
>> + cp = strstr(curl_http_proxy, "://");
>> + if (cp == NULL) {
>> + cp = curl_http_proxy;
>> + } else {
>> + cp += 3;
>> + }
>> + at = strchr(cp, '@');
>> + colon = strchr(cp, ':');
>> + if (at && (!colon || at < colon)) {
>> + /* proxy string has username but no password, ask for password */
>
> Don't parse the URL by hand. Use credential_from_url, which will do it
> for you (and will properly handle things like unquoting the various
> components).
Will do that
>> + char *ask_str, *proxyuser, *proxypass;
>
> Shouldn't these be static globals? If we have multiple curl handles, you
> would want them to share the authentication information we collect here,
> and not have to ask the user again, no?
I didn't think about multiple curl handles, will look at make those static..
>> + strbuf_addf(&pbuf, "Enter password for proxy %s...", at+1);
>> + ask_str = strbuf_detach(&pbuf, NULL);
>> + proxypass = xstrdup(git_getpass(ask_str));
>
> And this should be using credential_fill(), which will let it use
> credential helpers to save passwords, give it the same type of prompt as
> elsewhere, etc.
>
> See Documentation/technical/api-credential.txt, and see how regular http
> auth is handled for an example.
I will try the credential api, I did my patch based on the fedora 16 git
version, which didn't have the credential api (I couldn't git clone at
that moment for the proxy problem so I had to use the source rpm from
fedora).
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Nelson Benitez Leon @ 2012-02-29 10:46 UTC (permalink / raw)
To: Jeff King; +Cc: Sam Vilain, Thomas Rast, git, sam.vilain
In-Reply-To: <20120228193443.GB11725@sigill.intra.peff.net>
On 02/28/2012 08:34 PM, Jeff King wrote:
> On Tue, Feb 28, 2012 at 11:27:41AM -0800, Sam Vilain wrote:
>
>> On 2/28/12 11:15 AM, Jeff King wrote:
>>> Usually we would prefer environment variables to config. So that:
>>>
>>> $ git config http.proxy foo
>>> $ HTTP_PROXY=bar git fetch
>>>
>>> would use "bar" as the proxy, not "foo". But your code above would
>>> prefer "foo", right?
>>
>> Apparently I'm the author of the http.proxy feature, though I barely
>> [snip]
>
> Good point. We sometimes follow this order:
>
> 1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
> it existed)
> 2. git config files (i.e., http.proxy)
> 3. generic system environment (i.e., $http_proxy).
>
> So thinking about it that way, the original patch makes more sense.
So, in PATCH 2/3, apart from expanding the commit message.. do we want
to support HTTP_PROXY or only http_proxy ? HTTP_PROXY seems to not be
very used by existent programs, but support it it's only a gentenv call..
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Matthieu Moy @ 2012-02-29 9:55 UTC (permalink / raw)
To: Jeff King; +Cc: Sam Vilain, Nelson Benitez Leon, Thomas Rast, git, sam.vilain
In-Reply-To: <20120228193443.GB11725@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Good point. We sometimes follow this order:
>
> 1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
> it existed)
> 2. git config files (i.e., http.proxy)
> 3. generic system environment (i.e., $http_proxy).
Yes, just like $EDITOR << core.editor << $GIT_EDITOR.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Thomas Rast @ 2012-02-29 11:40 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20120229091855.GE14181@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I am a little dubious of the decision in jc/diff-ignore-case to have
> "-i" imply "--ignore-case". For "git diff", it makes perfect sense. But
> for "git log", it feels wrong. Ignoring case for the regexps is very
> common, and ignoring case for the diffs is uncommon (it is, after all, a
> feature we have gone many years without, and I don't remember anyone
> bringing it up until recently).
Doubly so because (to the best of my list-reading efforts) when it was
brought up recently, the interpretation as "case-insensitive diff
generation" was by mistake/misreading.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
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