* Re: [feature request] git add completion should exclude staged content
From: Junio C Hamano @ 2013-01-28 17:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Manlio Perillo, wookietreiber, git
In-Reply-To: <5106A5CE.3000800@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
>> Please, test it and report any behaviour you think is incorrect.
>
> OK, that seems to work and to be quite helpful.
>
> Minor nit: "git add -u" could use the same fileset as "git commit". But
> I don't know whether completion can act upon the presence of options.
> Currently, it also includes untracked files (just like without -u) but
> omits unmodified and ignored ones, which is already quite an improvement.
>
> I won't be able to review the completion code but may contribute a few
> lines to t/t9902-completion.sh, possibly.
Thanks both for commenting. I'll find time to read it over again
and perhaps we can merge it to 'next' and advertise it in the next
issue of "What's cooking" report to ask for wider testing to move it
forward.
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 17:45 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Lars Hjemli, git
In-Reply-To: <20130128081006.GA2434@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Tracing backwards: it would be really nice to be able to do
>
> git for-each-repo git grep -e foo -- '*.c'
This is a very good example that shows the command that is run in
the repositories found may want pathspecs passed, but at the same
time, makes me realize that these repositories have to be fairly
uniform for this command to be useful. For example, 'src/*.c' or
'inc/*.h' pathspecs wouldn't be useful unless majority if not all
projects the loop finds follow that layout convention. This is not
necessarily limited to pathspecs, of course. Unless they all have
the 'next' branch "git for-each-repo checkout next" would not work,
etc. etc.
As to the pathspec limiting to affect the loop itself, not the
argument given to the command that is run, I don't think it is
absolutely needed; I am perfectly fine with declaring that
for-each-repo goes to repositories in all subdirectories without
limit, especially if doing so will make the UI issues we have to
deal with simpler.
As to the "option to the command, not to the subcommand, -a option",
I have been assuming that it was a joke patch, but if "git -a grep"
turns out to be really useful, "submodule foreach" that iterates
over the submodules may also want to have such a short and sweet
mechanism. Between "for-each-repo" and "submodule foreach", I do
not yet have a strong opinion on which one deserves it more.
Come to think of it, is there a reason why "for-each-repo" should
not be an extention to "submodule foreach"? We can view this as
visiting repositories that _could_ be registered as a submodule, in
addition to iterating over the registered submodules, no?
If these two are unified, then we do not have to even worry about
which one deserves "git -a" more.
^ permalink raw reply
* Bug, feature, or pilot error: format-patch
From: Gene Czarcinski @ 2013-01-28 17:03 UTC (permalink / raw)
To: Git
I am not on the mailing list so please CC me. I am running git 1.8.1 on
Fedora 18.
I aam having what appears to be a problem. Here is the sequence which
generally describes what I did and what happened:
git checkout -b test1 master
git am 0001-simple-1.patch
git checkout -b test2 master
git am 0001-simple-2.patch ### this is known to conflict
with 0001-simple-1.patch
git checkout test1
git merge test2
[here git-merge detects a conflict]
git mergetool ###to resolve the conflict
[conflict resolved]
git commit -a -s
git log
[shows two commits -- one for simple-2 and one for the merge]
git format-patch master..HEAD
[two patch files created: 0001-simple-1.patch and 0002-simple-2.patch]
[0002-simple-2.patch and 0001-simple-2.patch are exactly equal and do
not reflect the resolved conflict]
If you do git-diff between <commit-patch-1> and HEAD, you get something
different that you got from format-patch.
1. Bug ... format-patch is broken
2. Feature ... that is the way it works
3. Pilot error ... ??
I can create a good version of patch-2 manually but should I have to?
Color me foolish but I assumed I could do git-format-patch in one branch
and then use git-am to recreate that branch elsewhere.
Gene
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 17:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git
In-Reply-To: <20130128081006.GA2434@elie.Belkin>
On Mon, Jan 28, 2013 at 9:10 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Lars Hjemli wrote:
>
>> [1] The 'git -a' rewrite patch shows how I think about this command -
>> it's just an option to the 'git' command, modifying the way any
>> subcommand is invoked (btw: I don't expect that patch to be applied
>> since 'git-all' was deemed to generic, so I'll just carry the patch in
>> my own tree).
>
> As one data point, 'git all' also seems too generic to me but 'git -a'
> doesn't. Intuition can be weird.
>
> So if I ran the world, then having commands
>
> git -a diff
>
> and
>
> git for-each-repo git diff
>
> do the same thing would be fine. Of course I don't run the world. ;-)
This would make me very happy. Junio?
--
larsh
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Joachim Schmitz @ 2013-01-28 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <1359353699-3987-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow wrote:
> Translate 11 new messages came from git.pot update
> in 46bc403 (l10n: Update git.pot (11 new, 7 removed
> messages)).
>
> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> ---
> po/de.po | 37 ++++++++++++++++++-------------------
> 1 file changed, 18 insertions(+), 19 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index 3779f4c..ed8330a 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -5,7 +5,7 @@
> #
> msgid ""
> msgstr ""
> -"Project-Id-Version: git 1.8.1\n"
> +"Project-Id-Version: git 1.8.2\n"
Not "Projekt-Id-Version ..."?
> #: builtin/reset.c:33
> msgid "mixed"
> @@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes"
> msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale
> Änderungen"
Not "reset -> setze" and "keep" -> halte (imperativ)?
Or is the enlish text wrong and should be "resets" and "keeps"
Bye, Jojo
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Michael J Gruber @ 2013-01-28 16:22 UTC (permalink / raw)
To: Manlio Perillo; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <510684FB.80104@gmail.com>
Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
> Il 28/01/2013 13:52, Michael J Gruber ha scritto:
>> Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
>>> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>>>> wookietreiber <kizkizzbangbang@googlemail.com> writes:
>>>
>>>>> I have a feature request for `git add` auto completion:
>>>>>
>> [...]
>>> For the OP: the last patch can be found in the mailing list archive,
>>> with the subject:
>>> [PATCH v5] git-completion.bash: add support for path completion
>>> and date:
>>> Fri, 11 Jan 2013 19:48:43 +0100
>>>
>>> Can you please test it?
>>>
>
>> I haven't looked at the patch, but in the example above, untracked
>> files) could be added as well (unless you use -u), so maybe the scope
>> should depend on the option? If the new completion code kept me from
>> adding untracked files easily it wouldn't be an improvement.
>
>
> The patch will suggest (for git add command), all the files that are
> candidate to be added to the index file.
>
> Please, test it and report any behaviour you think is incorrect.
OK, that seems to work and to be quite helpful.
Minor nit: "git add -u" could use the same fileset as "git commit". But
I don't know whether completion can act upon the presence of options.
Currently, it also includes untracked files (just like without -u) but
omits unmodified and ignored ones, which is already quite an improvement.
I won't be able to review the completion code but may contribute a few
lines to t/t9902-completion.sh, possibly.
Michael
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 14:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <51067487.9050505@drmicha.warpmail.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 13:52, Michael J Gruber ha scritto:
> Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
>> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>>> wookietreiber <kizkizzbangbang@googlemail.com> writes:
>>
>>>> I have a feature request for `git add` auto completion:
>>>>
> [...]
>> For the OP: the last patch can be found in the mailing list archive,
>> with the subject:
>> [PATCH v5] git-completion.bash: add support for path completion
>> and date:
>> Fri, 11 Jan 2013 19:48:43 +0100
>>
>> Can you please test it?
>>
>
> I haven't looked at the patch, but in the example above, untracked
> files) could be added as well (unless you use -u), so maybe the scope
> should depend on the option? If the new completion code kept me from
> adding untracked files easily it wouldn't be an improvement.
>
The patch will suggest (for git add command), all the files that are
candidate to be added to the index file.
Please, test it and report any behaviour you think is incorrect.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEGhPsACgkQscQJ24LbaUTYOwCdFagTRkHzUHoFwy3U+Vz6tAzE
tVIAnj8fAbyGrlNUoUgI4ZshwOtlEH8v
=jy8R
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Michael J Gruber @ 2013-01-28 12:52 UTC (permalink / raw)
To: Manlio Perillo; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <5106444F.2040007@gmail.com>
Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>> wookietreiber <kizkizzbangbang@googlemail.com> writes:
>
>>> I have a feature request for `git add` auto completion:
>>>
>>> `git add` auto completion suggests all files / directories,
>>> filtered by nothing. I guess it would be much nicer (as in
>>> increasing productivity) if it would only suggest unstaged
>>> content, as reported by `git status`, because that would be the
>>> only content one would be able to add.
>
>> I think that is what Manlio Perillo tried to do with the stalled
>> mp/complete-paths topic that is queued in 'pu'.
>
>> Manlio, any progress?
>
> Well, I assumed that the patch was stalled due to missing review from
> git completion experts...
>
> For this reason I have not updated it with your latest suggestions,
> waiting for the review (also, because now I'm busy with other projects).
>
> For the OP: the last patch can be found in the mailing list archive,
> with the subject:
> [PATCH v5] git-completion.bash: add support for path completion
> and date:
> Fri, 11 Jan 2013 19:48:43 +0100
>
> Can you please test it?
>
>
>
>
> Regards Manlio
>
I haven't looked at the patch, but in the example above, untracked
files) could be added as well (unless you use -u), so maybe the scope
should depend on the option? If the new completion code kept me from
adding untracked files easily it wouldn't be an improvement.
Michael
^ permalink raw reply
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Michael J Gruber @ 2013-01-28 12:47 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, gitster, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <1359364593-10933-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:
> Most git commands that can be used with our without a filepattern are
> tree-wide by default, the filepattern being used to restrict their scope.
> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
Since I didn't follow this thread, my first reaction was: "Huh? Aren't
they treewide?" (for the relative tree)
So, for someone reading just the commit message, it would be helpful to
say what the others do, i.e. default to the relative tree at pwd (rather
than defaulting to an empty tree, or all files whether tracked or not,
or...).
Otherwise, I'd rather switch sooner than later; it's so easy to take
"git add -u && git commit == git commit -a" for granted and to miss
staging some hunks. But 2.0 is around the corner anyway, isn't it ;)
> The inconsistency of 'git add -u' and 'git add -A' are particularly
> problematic since other 'git add' subcommands (namely 'git add -p' and
> 'git add -e') are tree-wide by default.
>
> Flipping the default now is unacceptable, so this patch starts training
> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
> for the next steps:
>
> * forbid 'git add -u|-A' without filepattern (like 'git add' without
> option)
>
> * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
> tree-wide scope.
>
> A nice side effect of this patch is that it makes the :/ special
> filepattern easier to discover for users.
>
> When the command is called from the root of the tree, there is no
> ambiguity and no need to change the behavior, hence no need to warn.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> Changes since v2:
>
> * Typo consistant -> consistent
>
> * Mention both short and long option names (Thanks Junio). I went for
> a two-lines display which I find a bit nicer to read than Junio's
> version, but I'm fine with both.
>
> Documentation/git-add.txt | 7 ++++---
> builtin/add.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index fd9e36b..5333559 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
> from the index if the corresponding files in the working tree
> have been removed.
> +
> -If no <filepattern> is given, default to "."; in other words,
> -update all tracked files in the current directory and its
> -subdirectories.
> +If no <filepattern> is given, the current version of Git defaults to
> +"."; in other words, update all tracked files in the current directory
> +and its subdirectories. This default will change in a future version
> +of Git, hence the form without <filepattern> should not be used.
>
> -A::
> --all::
> diff --git a/builtin/add.c b/builtin/add.c
> index 7cb6cca..7738025 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)
> return exit_status;
> }
>
> +static void warn_pathless_add(const char *option_name, const char *short_name) {
> + /*
> + * To be consistent with "git add -p" and most Git
> + * commands, we should default to being tree-wide, but
> + * this is not the original behavior and can't be
> + * changed until users trained themselves not to type
> + * "git add -u" or "git add -A". For now, we warn and
> + * keep the old behavior. Later, this warning can be
> + * turned into a die(...), and eventually we may
> + * reallow the command with a new behavior.
> + */
> + warning(_("The behavior of 'git add %s (or %s)' with no path argument from a\n"
> + "subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n"
> + "To add content for the whole tree, run:\n"
> + "\n"
> + " git add %s :/\n"
> + " (or git add %s :/)\n"
> + "\n"
> + "To restrict the command to the current directory, run:\n"
> + "\n"
> + " git add %s .\n"
> + " (or git add %s .)\n"
> + "\n"
> + "With the current Git version, the command is restricted to the current directory."),
> + option_name, short_name,
> + option_name, short_name,
> + option_name, short_name);
> +}
> +
> int cmd_add(int argc, const char **argv, const char *prefix)
> {
> int exit_status = 0;
> @@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> int add_new_files;
> int require_pathspec;
> char *seen = NULL;
> + const char *option_with_implicit_dot = NULL;
> + const char *short_option_with_implicit_dot = NULL;
>
> git_config(add_config, NULL);
>
> @@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> die(_("-A and -u are mutually incompatible"));
> if (!show_only && ignore_missing)
> die(_("Option --ignore-missing can only be used together with --dry-run"));
> - if ((addremove || take_worktree_changes) && !argc) {
> + if (addremove) {
> + option_with_implicit_dot = "--all";
> + short_option_with_implicit_dot = "-A";
> + }
> + if (take_worktree_changes) {
> + option_with_implicit_dot = "--update";
> + short_option_with_implicit_dot = "-u";
> + }
> + if (option_with_implicit_dot && !argc) {
> static const char *here[2] = { ".", NULL };
> + if (prefix)
> + warn_pathless_add(option_with_implicit_dot,
> + short_option_with_implicit_dot);
> argc = 1;
> argv = here;
> }
>
^ permalink raw reply
* [PATCH] fixup! git-remote-testpy: fix path hashing on Python 3
From: John Keeping @ 2013-01-28 11:20 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Sverre Rabbelier
In-Reply-To: <51065692.9000708@alum.mit.edu>
---
On Mon, Jan 28, 2013 at 11:44:34AM +0100, Michael Haggerty wrote:
> NAK. It is still not right. If the locale is not utf-8 based, then it
> is incorrect to re-encode the string using utf-8. I think you really
> have to use sys.getfilesystemencoding() as I suggested.
If you'd asked me what the patch contained I would have said it did use
getfilesystemencoding(), but I can't disbelieve my own eyes :-(
Junio, please can you squash this in?
git-remote-testpy.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index 6098bdd..ca67899 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -49,7 +49,7 @@ def encode_filepath(path):
"""
if sys.hexversion < 0x03000000:
return path
- return path.encode('utf-8', 'surrogateescape')
+ return path.encode(sys.getfilesystemencoding(), 'surrogateescape')
def get_repo(alias, url):
--
1.8.1.1
^ permalink raw reply related
* [CLOSED FIXED] Bug: file named - on git commit
From: Rene Moser @ 2013-01-28 11:19 UTC (permalink / raw)
To: git
In-Reply-To: <87txq11sbk.fsf@pctrast.inf.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 289 bytes --]
On 01/28/2013 12:05 PM, Thomas Rast wrote:
> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
> need to read blob from the standard input, 2012-06-27), which is
> included starting with v1.7.12 and the v1.7.11.3 maint release. Please
> upgrade.
Thanks.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Thomas Rast @ 2013-01-28 11:05 UTC (permalink / raw)
To: Rene Moser; +Cc: git
In-Reply-To: <51065540.1090007@renemoser.net>
Rene Moser <mail@renemoser.net> writes:
>
> Found a little issue in git version 1.7.9.5 if a file named "-", causing
> "git commit" to read from stdin.
>
> (So you must hit ctrl-d or ctrl-c to finish the commit.)
>
> Everything looks ok to me after the commit. Other users reported to be
> fixed in 1.8.1.1 but haven't it tested myself.
>
> This does not work:
>
> mkdir tmp && cd tmp;
> echo foo >./-;
> git init; git add .;
> git commit -m "is this a bug?"
This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
need to read blob from the standard input, 2012-06-27), which is
included starting with v1.7.12 and the v1.7.11.3 maint release. Please
upgrade.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Duy Nguyen @ 2013-01-28 10:58 UTC (permalink / raw)
To: Rene Moser; +Cc: git
In-Reply-To: <51065540.1090007@renemoser.net>
On Mon, Jan 28, 2013 at 5:38 PM, Rene Moser <mail@renemoser.net> wrote:
> Hi
>
> Found a little issue in git version 1.7.9.5 if a file named "-", causing
> "git commit" to read from stdin.
>
> (So you must hit ctrl-d or ctrl-c to finish the commit.)
>
> Everything looks ok to me after the commit. Other users reported to be
> fixed in 1.8.1.1 but haven't it tested myself.
Yes, it's fixed in 4682d85 (diff-index.c: "git diff" has no need to
read blob from the standard input - 2012-06-27) since v1.7.11.3.
> This does not work:
>
> mkdir tmp && cd tmp;
> echo foo >./-;
> git init; git add .;
> git commit -m "is this a bug?"
>
> Kind regards
>
> René
>
>
>
>
>
>
--
Duy
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Matthieu Moy @ 2013-01-28 10:56 UTC (permalink / raw)
To: Rene Moser; +Cc: git
In-Reply-To: <51065540.1090007@renemoser.net>
Rene Moser <mail@renemoser.net> writes:
> Hi
>
> Found a little issue in git version 1.7.9.5 if a file named "-", causing
> "git commit" to read from stdin.
Can't reproduce with Git version 1.8.1.1.440.g1d329bd, this probably has
been fixed already.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Bug: file named - on git commit
From: Rene Moser @ 2013-01-28 10:38 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
Hi
Found a little issue in git version 1.7.9.5 if a file named "-", causing
"git commit" to read from stdin.
(So you must hit ctrl-d or ctrl-c to finish the commit.)
Everything looks ok to me after the commit. Other users reported to be
fixed in 1.8.1.1 but haven't it tested myself.
This does not work:
mkdir tmp && cd tmp;
echo foo >./-;
git init; git add .;
git commit -m "is this a bug?"
Kind regards
René
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH] git-remote-testpy: fix patch hashing on Python 3
From: Michael Haggerty @ 2013-01-28 10:44 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, git, Sverre Rabbelier
In-Reply-To: <20130127145056.GP7498@serenity.lan>
[-- Attachment #1: Type: text/plain, Size: 4681 bytes --]
On 01/27/2013 03:50 PM, John Keeping wrote:
> When this change was originally made (0846b0c - git-remote-testpy: hash
> bytes explicitly , I didn't realised that the "hex" encoding we chose is
> a "bytes to bytes" encoding so it just fails with an error on Python 3
> in the same way as the original code.
>
> It is not possible to provide a single code path that works on Python 2
> and Python 3 since Python 2.x will attempt to decode the string before
> encoding it, which fails for strings that are not valid in the default
> encoding. Python 3.1 introduced the "surrogateescape" error handler
> which handles this correctly and permits a bytes -> unicode -> bytes
> round-trip to be lossless.
>
> At this point Python 3.0 is unsupported so we don't go out of our way to
> try to support it.
>
> Helped-by: Michael Haggerty <mhagger@alum.mit.edu>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> On Sun, Jan 27, 2013 at 02:13:29PM +0000, John Keeping wrote:
>> On Sun, Jan 27, 2013 at 05:44:37AM +0100, Michael Haggerty wrote:
>>> So to handle all of the cases across Python versions as closely as
>>> possible to the old 2.x code, it might be necessary to make the code
>>> explicitly depend on the Python version number, like:
>>>
>>> hasher = _digest()
>>> if sys.hexversion < 0x03000000:
>>> pathbytes = repo.path
>>> elif sys.hexversion < 0x03010000:
>>> # If support for Python 3.0.x is desired (note: result can
>>> # be different in this case than under 2.x or 3.1+):
>>> pathbytes = repo.path.encode(sys.getfilesystemencoding(),
>>> 'backslashreplace')
>>> else
>>> pathbytes = repo.path.encode(sys.getfilesystemencoding(),
>>> 'surrogateescape')
>>> hasher.update(pathbytes)
>>> repo.hash = hasher.hexdigest()
>
> How about this?
>
> git-remote-testpy.py | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/git-remote-testpy.py b/git-remote-testpy.py
> index c7a04ec..16b0c52 100644
> --- a/git-remote-testpy.py
> +++ b/git-remote-testpy.py
> @@ -36,6 +36,22 @@ if sys.hexversion < 0x02000000:
> sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
> sys.exit(1)
>
> +
> +def _encode_filepath(path):
> + """Encodes a Unicode file path to a byte string.
> +
> + On Python 2 this is a no-op; on Python 3 we encode the string as
> + suggested by [1] which allows an exact round-trip from the command line
> + to the filesystem.
> +
> + [1] http://docs.python.org/3/c-api/unicode.html#file-system-encoding
> +
> + """
> + if sys.hexversion < 0x03000000:
> + return path
> + return path.encode('utf-8', 'surrogateescape')
> +
> +
> def get_repo(alias, url):
> """Returns a git repository object initialized for usage.
> """
> @@ -45,7 +61,7 @@ def get_repo(alias, url):
> repo.get_head()
>
> hasher = _digest()
> - hasher.update(repo.path.encode('hex'))
> + hasher.update(_encode_filepath(repo.path))
> repo.hash = hasher.hexdigest()
>
> repo.get_base_path = lambda base: os.path.join(
>
NAK. It is still not right. If the locale is not utf-8 based, then it
is incorrect to re-encode the string using utf-8. I think you really
have to use sys.getfilesystemencoding() as I suggested.
The attached program demonstrates the problem: the output of re-encoding
using UTF-8 depends on the locale, whereas that of re-encoding using the
filesystemencoding is independent of locale (as we want). The output,
using Python 3.2.3:
# This is 0xb6 0xc3:
$ ARG="ö"
$ LANG='C' /usr/bin/python3 chaos3.py "$ARG"
LANG = 'C'
fse = 'ascii'
sys.argv[1] = u"U+DCC3 U+DCB6"
re-encoded using UTF-8: b"C3 B6"
re-encoded using fse: b"C3 B6"
$ LANG='C.UTF-8' /usr/bin/python3 chaos3.py "$ARG"
LANG = 'C.UTF-8'
fse = 'utf-8'
sys.argv[1] = u"U+00F6"
re-encoded using UTF-8: b"C3 B6"
re-encoded using fse: b"C3 B6"
$ LANG='en_US.iso88591' /usr/bin/python3 chaos3.py "$ARG"
LANG = 'en_US.iso88591'
fse = 'iso8859-1'
sys.argv[1] = u"U+00C3 U+00B6"
re-encoded using UTF-8: b"C3 83 C2 B6"
re-encoded using fse: b"C3 B6"
Even though the Unicode intermediate representation is different for
UTF-8 and ASCII, re-encoding using the correct encoding gives back the
original bytes (which is what we want). But when using the ios8859-1
locale, the original bytes look like a valid latin1 string so they are
not surrogated going in, giving the incorrect Unicode string u"U+00C3
U+00B6". When this is re-encoded using UTF-8, the code points U+00C3
and U+00B6 are each encoded as two bytes.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
[-- Attachment #2: chaos3.py --]
[-- Type: text/x-python, Size: 664 bytes --]
#! /usr/bin/python3
import sys
import os
def explicit(s):
"""Convert a string or bytestring into an unambiguous human-readable string."""
if isinstance(s, str):
return 'u"%s"' % (' '.join('U+%04X' % (ord(c),) for c in s))
else:
return 'b"%s"' % (' '.join('%02X' % (c,) for c in s))
fse = sys.getfilesystemencoding()
print('LANG = %r' % (os.getenv('LANG'),))
print('fse = %r' % (fse,))
print('sys.argv[1] = %s' % explicit(sys.argv[1]))
print('re-encoded using UTF-8: %s' % explicit(sys.argv[1].encode('utf-8', 'surrogateescape')))
print('re-encoded using fse: %s' % explicit(sys.argv[1].encode(fse, 'surrogateescape')))
print()
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Thomas Rast @ 2013-01-28 10:33 UTC (permalink / raw)
To: Ralf Thielow; +Cc: jk, stimming, git
In-Reply-To: <1359353699-3987-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow <ralf.thielow@gmail.com> writes:
> Translate 11 new messages came from git.pot update
> in 46bc403 (l10n: Update git.pot (11 new, 7 removed
> messages)).
> #: builtin/log.c:104
> msgid "Use mail map file"
> -msgstr ""
> +msgstr "verwendet \"mailmap\"-Datei"
Note that case differs here, but it's the English one that doesn't fit
the pattern -- option descriptions usually start with lowercase.
> #: builtin/reset.c:275
> -#, fuzzy, c-format
> +#, c-format
> msgid "Failed to resolve '%s' as a valid revision."
> -msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
> +msgstr "Konnte '%s' nicht als gültige Revision auflösen."
You don't have "revision" in the glossary[1] yet. Wouldn't it be
appropriate to treat it as "commit", and translate as "Version" to avoid
introducing yet another term?
Or am I missing some subtle distinction between commit and revision?
Since it's only a single nit, feel free to add my ack when you reroll:
Acked-by: Thomas Rast <trast@inf.ethz.ch>
[1] https://github.com/ralfth/git-po-de/wiki/Glossary
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 9:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: wookietreiber, git
In-Reply-To: <7vip6iteod.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 00:00, Junio C Hamano ha scritto:
> wookietreiber <kizkizzbangbang@googlemail.com> writes:
>
>> I have a feature request for `git add` auto completion:
>>
>> `git add` auto completion suggests all files / directories,
>> filtered by nothing. I guess it would be much nicer (as in
>> increasing productivity) if it would only suggest unstaged
>> content, as reported by `git status`, because that would be the
>> only content one would be able to add.
>
> I think that is what Manlio Perillo tried to do with the stalled
> mp/complete-paths topic that is queued in 'pu'.
>
> Manlio, any progress?
Well, I assumed that the patch was stalled due to missing review from
git completion experts...
For this reason I have not updated it with your latest suggestions,
waiting for the review (also, because now I'm busy with other projects).
For the OP: the last patch can be found in the mailing list archive,
with the subject:
[PATCH v5] git-completion.bash: add support for path completion
and date:
Fri, 11 Jan 2013 19:48:43 +0100
Can you please test it?
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEGRE8ACgkQscQJ24LbaUSX9ACfUMBH/X6lVH4V7FUaB2wlqj8C
eYQAnAzuYwhYhDvkW3d29IeqHsDFyWBT
=BpRi
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Jonathan Nieder @ 2013-01-28 9:20 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, gitster, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <1359364593-10933-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy wrote:
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Looks good to me.
At some point we'll want to have tests for this case, but that's not
particularly urgent until it's time for the warning() to turn into a
die().
Thanks.
Jonathan
^ permalink raw reply
* Re: Port 22
From: Michael J Gruber @ 2013-01-28 9:20 UTC (permalink / raw)
To: Kevin; +Cc: Craig Christensen, git
In-Reply-To: <CAO54GHBFo94Pes1cJ9MVvVJGD5ZMK4yMv9+_shtT8iPP-DVtsg@mail.gmail.com>
Kevin venit, vidit, dixit 28.01.2013 09:06:
> This is not really a git problem, but more of an ssh problem.
>
> Are you in the position to change the port where the SSH daemon
> listens on? Then you could use a different port which isn't blocked
> (443 perhaps?).
>
> On Sat, Jan 26, 2013 at 7:56 PM, Craig Christensen <cwcraigo@gmail.com> wrote:
>> I am currently a student at Brigham Young University - Idaho and we are use Pagoda Box and Git for our Mobile Apps class. However, the school's network has blocked incoming trafic on port 22. I have been searching through all the tutorials and documents provided by Pagoda Box and Git but have not been able to find a solution to solve this problem. We can use sftp but we then have to manually deploy the latest using the admin panel. Can you help provide a simple solution?
So how is your setup:
- Pagoda Box instance at BYU
- sftp uploads allowed, but not ssh
- drive Git on the box using the admin interface
Or do you use a Pagoda server? Do you have read access to the git repo
on the box?
ssh allows to restrict commands to only a subset, such as ssh only. If
the port were blocked for incoming traffic you wouldn't be able to use
(ssh at all thus) sftp either.
Michael
^ permalink raw reply
* [PATCH v3] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-28 9:16 UTC (permalink / raw)
To: git, gitster
Cc: Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky, Matthieu Moy
In-Reply-To: <vpqobg966cv.fsf@grenoble-inp.fr>
Most git commands that can be used with our without a filepattern are
tree-wide by default, the filepattern being used to restrict their scope.
A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
The inconsistency of 'git add -u' and 'git add -A' are particularly
problematic since other 'git add' subcommands (namely 'git add -p' and
'git add -e') are tree-wide by default.
Flipping the default now is unacceptable, so this patch starts training
users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
for the next steps:
* forbid 'git add -u|-A' without filepattern (like 'git add' without
option)
* much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
tree-wide scope.
A nice side effect of this patch is that it makes the :/ special
filepattern easier to discover for users.
When the command is called from the root of the tree, there is no
ambiguity and no need to change the behavior, hence no need to warn.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Changes since v2:
* Typo consistant -> consistent
* Mention both short and long option names (Thanks Junio). I went for
a two-lines display which I find a bit nicer to read than Junio's
version, but I'm fine with both.
Documentation/git-add.txt | 7 ++++---
builtin/add.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index fd9e36b..5333559 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
from the index if the corresponding files in the working tree
have been removed.
+
-If no <filepattern> is given, default to "."; in other words,
-update all tracked files in the current directory and its
-subdirectories.
+If no <filepattern> is given, the current version of Git defaults to
+"."; in other words, update all tracked files in the current directory
+and its subdirectories. This default will change in a future version
+of Git, hence the form without <filepattern> should not be used.
-A::
--all::
diff --git a/builtin/add.c b/builtin/add.c
index 7cb6cca..7738025 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)
return exit_status;
}
+static void warn_pathless_add(const char *option_name, const char *short_name) {
+ /*
+ * To be consistent with "git add -p" and most Git
+ * commands, we should default to being tree-wide, but
+ * this is not the original behavior and can't be
+ * changed until users trained themselves not to type
+ * "git add -u" or "git add -A". For now, we warn and
+ * keep the old behavior. Later, this warning can be
+ * turned into a die(...), and eventually we may
+ * reallow the command with a new behavior.
+ */
+ warning(_("The behavior of 'git add %s (or %s)' with no path argument from a\n"
+ "subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n"
+ "To add content for the whole tree, run:\n"
+ "\n"
+ " git add %s :/\n"
+ " (or git add %s :/)\n"
+ "\n"
+ "To restrict the command to the current directory, run:\n"
+ "\n"
+ " git add %s .\n"
+ " (or git add %s .)\n"
+ "\n"
+ "With the current Git version, the command is restricted to the current directory."),
+ option_name, short_name,
+ option_name, short_name,
+ option_name, short_name);
+}
+
int cmd_add(int argc, const char **argv, const char *prefix)
{
int exit_status = 0;
@@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int add_new_files;
int require_pathspec;
char *seen = NULL;
+ const char *option_with_implicit_dot = NULL;
+ const char *short_option_with_implicit_dot = NULL;
git_config(add_config, NULL);
@@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
die(_("-A and -u are mutually incompatible"));
if (!show_only && ignore_missing)
die(_("Option --ignore-missing can only be used together with --dry-run"));
- if ((addremove || take_worktree_changes) && !argc) {
+ if (addremove) {
+ option_with_implicit_dot = "--all";
+ short_option_with_implicit_dot = "-A";
+ }
+ if (take_worktree_changes) {
+ option_with_implicit_dot = "--update";
+ short_option_with_implicit_dot = "-u";
+ }
+ if (option_with_implicit_dot && !argc) {
static const char *here[2] = { ".", NULL };
+ if (prefix)
+ warn_pathless_add(option_with_implicit_dot,
+ short_option_with_implicit_dot);
argc = 1;
argv = here;
}
--
1.8.1.1.440.g1d329bd.dirty
^ permalink raw reply related
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: David Aguilar @ 2013-01-28 9:16 UTC (permalink / raw)
To: Philip Oakley; +Cc: Junio C Hamano, git, John Keeping
In-Reply-To: <5F78436DB1994B6DA686EC1BFA96B54E@PhilipOakley>
On Mon, Jan 28, 2013 at 12:20 AM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "David Aguilar" <davvid@gmail.com>
> Sent: Monday, January 28, 2013 12:52 AM
>
>> This is round two of this series.
>> I think this touched on everything brought up in the code review.
>> 4/4 could use a review as I'm not completely familiar with the
>> makefile dependencies, though it seems to work correctly.
>
>
> Does this 4/4 have any effect on the Msysgit / Git for Windows documentation
> which simply refers [IIRC] to HTML documenation made by Junio?
>
> That is, how easy is it to create a 'default' set of docs, rather than
> personalised documenation. Or have I misunderstood how it is working?
It doesn't have any effect on Msysgit. The resulting documentation
lists all available tools, on all platforms.
--
David
^ permalink raw reply
* Re: [PATCH v2] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-28 8:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <7vehh6v01v.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Plus, option_with_implicit_dot is used in cut-and-paste ready commands
>> below.
>
> I do not think we should aim for easy cut-and-paste, especially when
> the real purpose of the change is to train people's fingers; the
> message should discouraging cut-and-paste in a case like this, if
> anything.
cut-and-paste readyness is also a way to avoid being ambiguous. If you
tell users to run "git add -u (--update)", you'll always find someone to
type the command as-is and complain about it not working (sadly, the
teacher living inside me is speaking of experience ;-) ).
> But we could obviously do this, if you really want to cut-and-paste.
I was going to do something like this, you've been too quick ;-).
Resend comming soon.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: Philip Oakley @ 2013-01-28 8:20 UTC (permalink / raw)
To: David Aguilar, Junio C Hamano; +Cc: git, John Keeping
In-Reply-To: <1359334346-5879-1-git-send-email-davvid@gmail.com>
From: "David Aguilar" <davvid@gmail.com>
Sent: Monday, January 28, 2013 12:52 AM
> This is round two of this series.
> I think this touched on everything brought up in the code review.
> 4/4 could use a review as I'm not completely familiar with the
> makefile dependencies, though it seems to work correctly.
Does this 4/4 have any effect on the Msysgit / Git for Windows
documentation which simply refers [IIRC] to HTML documenation made by
Junio?
That is, how easy is it to create a 'default' set of docs, rather than
personalised documenation. Or have I misunderstood how it is working?
>
> David Aguilar (4):
> mergetool--lib: Simplify command expressions
> mergetool--lib: Improve the help text in guess_merge_tool()
> mergetool--lib: Add functions for finding available tools
> doc: Generate a list of valid merge tools
>
> Documentation/.gitignore | 1 +
> Documentation/Makefile | 22 +++++++-
> Documentation/diff-config.txt | 13 ++---
> Documentation/merge-config.txt | 12 ++---
> git-mergetool--lib.sh | 116
> ++++++++++++++++++++++-------------------
> 5 files changed, 96 insertions(+), 68 deletions(-)
>
> --
> 1.8.0.13.g3ff16bb
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2890 / Virus Database: 2639/6061 - Release Date:
> 01/27/13
>
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Jonathan Nieder @ 2013-01-28 8:10 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <CAFXTnz6GTVgY4DK-FLELGF-Cb1=iNYyWcUsUiaUytGRx9Tr4Ow@mail.gmail.com>
Hi,
Lars Hjemli wrote:
> [1] The 'git -a' rewrite patch shows how I think about this command -
> it's just an option to the 'git' command, modifying the way any
> subcommand is invoked (btw: I don't expect that patch to be applied
> since 'git-all' was deemed to generic, so I'll just carry the patch in
> my own tree).
As one data point, 'git all' also seems too generic to me but 'git -a'
doesn't. Intuition can be weird.
So if I ran the world, then having commands
git -a diff
and
git for-each-repo git diff
do the same thing would be fine. Of course I don't run the world. ;-)
[...]
>> One more thing that nobody brought up during the previous reviews is
>> if we want to support subset of repositories by allowing the
>> standard pathspec match mechanism. For example,
>>
>> git for-each-repo -d git diff --name-only -- foo/ bar/b\*z
>>
>> might be a way to ask "please find repositories match the given
>> pathspecs (i.e. foo/ bar/b\*z) and run the command in the ones that
>> are dirty". We would need to think about how to mark the end of the
>> command though---we could borrow \; from find(1), even though find
>> is not the best example of the UI design.
In most non-git commands, "--" represents an end-of-options marker,
allowing arbitrary options afterward without having to worry about
escaping minus signs. So in that spirit, if this weren't a git
command, I'd expect to be able to do
for-each-repo -- git diff -- '*.c'
and have the second '--' passed verbatim to "git diff".
Unfortunately in git (imitating commands like "grep", I suppose), "--"
means "paths start here". That means that with the git convention,
there is only one place to pass paths to a given command.
Tracing backwards: it would be really nice to be able to do
git for-each-repo git grep -e foo -- '*.c'
or
git -a grep -e foo -- '*.c'
For this practical reason, it seems that paths listed after the '--'
should go to the command being run. On the other hand, if I wanted to
limit my for-each-repo run to repositories in two subdirectories of
the cwd, I'd be tempted to try
git for-each-repo git grep -e foo -- src/ doc/
And if I wanted to limit to different file types in the repositories
under each directory, it would be tempting to use
git for-each-repo git grep -e foo -- 'src/*.c' 'doc/*.txt'
Is there a convention that would be usable today that is roughly
forward-compatible with that? (To throw an example out, requiring
that each pathspec passed to for-each-repo either starts with '*' or
contains no wildcards.)
Thanks,
Jonathan
^ 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