2013/1/28 Philip Oakley :
> From: "Ralf Thielow"
> Sent: Monday, January 28, 2013 5:55 PM
>
>> On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote:
>>>
>>> Ralf Thielow writes:
>>>
>>> > #: builtin/reset.c:275
>>> > -#, fuzzy, c-format
>>> > +#, c-format
>>> > msgid "Failed to resolve '
Duy Nguyen writes:
>> prefixq=$(git rev-parse --show-prefix-glob-quoted)
>> pathspec="$prefixq$1"
>>
>> but magic that applies only to a substring may have other uses.
>
> Yeah, that simplifies things. Supporting applying magic over just
> parts of the pathspec pattern sounds comp
On Tue, Jan 29, 2013 at 12:33 PM, Junio C Hamano wrote:
> Have you considered if it may be helpful to have a :(literal) magic
> (or any magic in general) that applies only to the first N
> characters of the pathspec pattern?
Not user-driven. But the prefix part is :(literal)-applied. :(glob) is
c
Hello!
I've a readonly git repository that I'm hosting via HTTP (a bare git repository
located within the appropriate directory on the server). I push to it via my
own SSH account (local repository with a remote pointing to the ssh:// URL).
This has all worked fine so far - I push via ssh, and
Duy Nguyen writes:
> :(literal) magic
>
>
> This magic is for people who want simple no-globbing pathspec (*). It
> can be used in combination with other magic such as case-insensitive
> matching. Incompatible with :(glob) magic below.
>
> Global option --noglob-pathspecs is adde
On Tue, Jan 29, 2013 at 12:05 PM, Junio C Hamano wrote:
>> New way to specify long pathspec magic
>> ==
>>
>> While testing the pathspec magic code, I grow tired of quoting :(glob)
>> every time because '(' is the start of a new shell. Which is one of
>> the rea
Please take this as just a preview of early WIP. I think I may end
up doing moderate amount of refactoring as a preparatory step before
these patches, so nitpick-reviews are likely to become waste of
reviewer's time at this point.
--
To unsubscribe from this list: send the line "unsubscribe git"
Duy Nguyen writes:
> For those who haven't followed closely, some coming changes allow us
> to extend current pathspec syntax. We should soon be able to do
> case-insenstive matching for example, or introduce "**" wildcard that
> is currently used by gitignore. I just want to discuss about the ne
Duy Nguyen writes:
> Pathspec mnemonic
> =
>
> Are :(literal) and :(glob) used often enough to deserve a short
> mnemonic (like :/ is equivalent to :(top))? Which symbols should be
> used?
I do not think we should discuss this before letting people gain
experience with various fo
For those who haven't followed closely, some coming changes allow us
to extend current pathspec syntax. We should soon be able to do
case-insenstive matching for example, or introduce "**" wildcard that
is currently used by gitignore. I just want to discuss about the new
syntax and behavior.
Many
Interesting. I wonder if they've changed it recently. I only pointed
it out because a software product I'm working on had a bug because it
was building the URLs with "https://www..."; and the resulting images
were showing as X's instead of avatars. We had to change the
implementation to use "https:
Hi Bryan,
Bryan Turner wrote:
> This won't work correctly as-is. The secure URL for Gravatar is
> "https://secure.gravatar.com"[1], not "https://www.gravatar.com";.
Odd. "https://www.gravatar.com/"; also seems to work. I've put in a
technical support query to find out what the Gravatar admins
This won't work correctly as-is. The secure URL for Gravatar is
"https://secure.gravatar.com"[1], not "https://www.gravatar.com";.
[1] See the "Secure Requests" section on:
https://en.gravatar.com/site/implement/images/
On 29 January 2013 14:03, Junio C Hamano wrote:
>
> Thanks; will queue.
>
>
Thanks; will queue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Aguilar writes:
> On Mon, Jan 28, 2013 at 11:28 AM, John Keeping wrote:
>> ---
>> Junio, please can you squash this into f9924e5 on jk/mergetool,
>> providing that David is OK with that?
>
> This looks good to me.
Thanks for a quick response. Will squash this in and rebuild the
two affec
On Mon, Jan 28, 2013 at 11:28 AM, John Keeping wrote:
> ---
> Junio, please can you squash this into f9924e5 on jk/mergetool,
> providing that David is OK with that?
This looks good to me.
> The original change breaks custom mergetool by making changing the logic
> around default functions so th
An attempt to update or delete a ref that is hidden from "git push"
is rejected. With this the server side can implement refs that are
only available for its own use, e.g. refs/pull/11/head used to hold
an incoming pull request at GitHub.
Signed-off-by: Junio C Hamano
---
Documentation/config.t
We mark the objects pointed at our refs with "OUR_REF" flag in two
functions (mark_our_ref() and send_ref()), but we can just use the
former as a helper for the latter.
Update the way mark_our_ref() prepares in-core object to use
lookup_unknown_object() to delay reading the actual object data,
jus
Teach upload-pack to omit some refs from the initial advertisement
by introducing the uploadPack.hiderefs multivalued configuration
variable. Any ref that is under the hierarchies listed on the value
of this variable is excluded from responses to "ls-remote", "fetch"
or "clone" requests. One typi
So this is the second round, unifying the handling of "hidden refs"
a hosting site administrator may want to handle differently from
normal refs available to upload-pack and receive-pack. Big thanks
to Peff for making me realize that what is shown to "git push"
should match what is shown to "git f
re sended. Very big thanks for example :D
2013/1/29 Junio C Hamano :
> Андрей Баранов writes:
>
>> Or maybe option like:
>> /etc/gitweb.conf:
>> $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
>>
>> but it's hard for me :) i don't know perl
>
> The effect is the same and your origi
Just drop the scheme: part from the URL, so that these
external sites are accessed over https:// in such a case.
Signed-off-by: Andrej E Baranov
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c6bafe6..1
Андрей Баранов writes:
> Or maybe option like:
> /etc/gitweb.conf:
> $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
>
> but it's hard for me :) i don't know perl
The effect is the same and your original patch is shorter and
cleaner to see what is going on; as far as the patch tex
Junio C Hamano wrote:
> I am sure mixed content warning was the primary motivation of the
> patch.
Sure, but that's not enough motivation for me to like it. ;-)
The privacy aspect is enough to motivate it for me.
> Do we know these external sites actually server what we want
> over https
Or maybe option like:
/etc/gitweb.conf:
$feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
but it's hard for me :) i don't know perl
2013/1/29 Junio C Hamano :
> Jonathan Nieder writes:
>
>> Junio C Hamano wrote:
Andrej Andb wrote:
>>
> --- a/gitweb/gitweb.perl
> +++ b/gi
Jonathan Nieder writes:
> Junio C Hamano wrote:
>>> Andrej Andb wrote:
>
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2068,7 +2068,7 @@ sub picon_url {
if (!$avatar_cache{$email}) {
my ($user, $domain) = split('@', $email);
$avatar_c
On Mon, Jan 28, 2013 at 01:50:19PM -0800, Junio C Hamano wrote:
> What are the situations where a valid user-defined tools is
> unavailable, by the way?
The same as a built-in tool: the command isn't available.
Currently I'm extracting the command word using:
cmd=$(eval -- "set -- $(git conf
Junio C Hamano wrote:
>> Andrej Andb wrote:
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -2068,7 +2068,7 @@ sub picon_url {
>>> if (!$avatar_cache{$email}) {
>>> my ($user, $domain) = split('@', $email);
>>> $avatar_cache{$email} =
>>> -
Junio C Hamano writes:
>>> -
>>> "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"; .
>>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/"
>>> .
>
> Hrmph. Is that even a valid URL to refer to that external site from
> a https://my.site/s
Jonathan Nieder writes:
> (cc-ing some area experts)
> Hi Andrej,
>
> Andrej Andb wrote:
>
>> [Subject: remove protocol from gravatar and picon links for clear if
>> Gitweb is being called through a secure server]
>
> Sounds good to me. May we have your signoff? (See
> Documentation/SubmittingP
John Keeping writes:
> I've had a quick look and it's quite straightforward to build on top of
> this to get an output format like this:
>
> 'git mergetool --tool-' may be set to one of the following:
> araxis
>...
> vimdiff2
>
> user-defin
Am 28.01.2013 21:34, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> Am 28.01.2013 19:51, schrieb Junio C Hamano:
>>> Lars Hjemli writes:
>>>
> Come to think of it, is there a reason why "for-each-repo" should
> not be an extention to "submodule foreach"? We can view this as
> v
From: "David Aguilar"
Sent: Monday, January 28, 2013 9:16 AM
On Mon, Jan 28, 2013 at 12:20 AM, Philip Oakley
wrote:
From: "David Aguilar"
Sent: Monday, January 28, 2013 12:52 AM
This is round two of this series.
I think this touched on everything brought up in the code review.
4/4 could use
On Sun, Jan 27, 2013 at 06:41:04PM -0800, David Aguilar wrote:
> John, I didn't completely address your question about keeping
> the sort and prefix in show_tool_help() but I can stop poking at
> it now in case you want to start looking at what it would take
> to get custom tools listed in the --to
Jonathan Nieder writes:
> Thomas Rast wrote:
>> Rene Moser writes:
>
>>> Found a little issue in git version 1.7.9.5 if a file named "-", causing
>>> "git commit" to read from stdin.
>>>
>>> (So you must hit ctrl-d or ctrl-c to finish the commit.)
> [...]
>> This was fixed by Junio around 4682d8
(cc-ing some area experts)
Hi Andrej,
Andrej Andb wrote:
> [Subject: remove protocol from gravatar and picon links for clear if
> Gitweb is being called through a secure server]
Sounds good to me. May we have your signoff? (See
Documentation/SubmittingPatches for what this means.)
Thanks,
Jon
From: "Ralf Thielow"
Sent: Monday, January 28, 2013 6:13 PM
On Mon, Jan 28, 2013 at 05:39:27PM +0100, Joachim Schmitz wrote:
Ralf Thielow wrote:
>Translate 11 new messages came from git.pot update
>in 46bc403 (l10n: Update git.pot (11 new, 7 removed
>messages)).
>
>Signed-off-by: Ralf Thielow
Jonathan Nieder writes:
> Thomas Rast wrote:
>> Rene Moser writes:
>
>>> Found a little issue in git version 1.7.9.5 if a file named "-", causing
>>> "git commit" to read from stdin.
>>>
>>> (So you must hit ctrl-d or ctrl-c to finish the commit.)
> [...]
>> This was fixed by Junio around 4682d8
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
Hi,
Thomas Rast wrote:
> Rene Moser writes:
>> Found a little issue in git version 1.7.9.5 if a file named "-", causing
>> "git commit" to read from stdin.
>>
>> (So you must hit ctrl-d or ctrl-c to finish the commit.)
[...]
> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has
The latest maintenance release Git v1.8.1.2 is now available at the
usual places. This contains a handful of fixes that will also
appear in the next feature release.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
29a2dee56
John Keeping writes:
>> +printf "%s%s\n" "$per_line_prefix" "$tool"
>
> This needs to be:
>
> printf "$per_line_prefix%s\n" "$tool"
>
> since $per_line_prefix is usually '\t\t' which isn't expanded if we
> format it with %s - an alternative would be to change the value pas
Jens Lehmann writes:
> Am 28.01.2013 19:51, schrieb Junio C Hamano:
>> Lars Hjemli writes:
>>
Come to think of it, is there a reason why "for-each-repo" should
not be an extention to "submodule foreach"? We can view this as
visiting repositories that _could_ be registered as a s
From: "Ralf Thielow"
Sent: Monday, January 28, 2013 5:55 PM
On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote:
Ralf Thielow writes:
> #: builtin/reset.c:275
> -#, fuzzy, c-format
> +#, c-format
> msgid "Failed to resolve '%s' as a valid revision."
> -msgstr "Konnte '%s' nicht als
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 28/01/2013 18:52, Junio C Hamano ha scritto:
> [...]
>
> Thanks both for commenting. I'll find time to read it over again
> and perhaps we can merge it to 'next' and advertise it in the next
> issue of "What's cooking" report to ask for wider test
Am 28.01.2013 19:51, schrieb Junio C Hamano:
> Lars Hjemli writes:
>
>>> Come to think of it, is there a reason why "for-each-repo" should
>>> not be an extention to "submodule foreach"? We can view this as
>>> visiting repositories that _could_ be registered as a submodule, in
>>> addition to i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 28/01/2013 17:22, Michael J Gruber ha scritto:
> [...]
>> The patch will suggest (for git add command), all the files that are
>> candidate to be added to the index file.
>>
>> Please, test it and report any behaviour you think is incorrect.
>
> OK
On Mon, Jan 28, 2013 at 7:51 PM, Junio C Hamano wrote:
> Lars Hjemli writes:
>
>>> Come to think of it, is there a reason why "for-each-repo" should
>>> not be an extention to "submodule foreach"? We can view this as
>>> visiting repositories that _could_ be registered as a submodule, in
>>> add
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
> Refactor show_tool_help() so that the tool-finding logic is broken out
> into a separate show_tool_names() function.
>
> Signed-off-by: David Aguilar
> ---
> filter_tools renamed to show_tool_names() and simplfied
> to use ls -1. s
---
Junio, please can you squash this into f9924e5 on jk/mergetool,
providing that David is OK with that?
The original change breaks custom mergetool by making changing the logic
around default functions so that they are now only defined when the tool
file exists in $MERGE_TOOLS_DIR but we need th
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c6bafe6..1309196 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2068,7 +2068,7 @@ sub picon_url {
if (!$avatar_cache{$email}) {
Lars Hjemli writes:
>> Come to think of it, is there a reason why "for-each-repo" should
>> not be an extention to "submodule foreach"? We can view this as
>> visiting repositories that _could_ be registered as a submodule, in
>> addition to iterating over the registered submodules, no?
>
> Yes,
On Mon, Jan 28, 2013 at 6:45 PM, Junio C Hamano wrote:
> As to the pathspec limiting to affect the loop itself, not the
> argument given to the command that is run, I don't think it is
> absolutely needed; I am perfectly fine with declaring that
> for-each-repo goes to repositories in all subdirec
Lars Hjemli writes:
> On Mon, Jan 28, 2013 at 9:10 AM, Jonathan Nieder wrote:
>> ...
>> So if I ran the world, then having commands
>>
>> git -a diff
>>
>> and
>>
>> git for-each-repo git diff
>>
>> do the same thing would be fine. Of course I don't run the world. ;-)
>
> This w
In the German translation, we have translated "revision"
as both "Revision" and "Version". In the context of version
control, revision has the same meaning as commit, so we don't
need to use both terms. "revision" is now consistently translated
as "Version".
Signed-off-by: Ralf Thielow
---
po/de
According to the glossary, "reset" should be
translated as "neu setzen" but in a couple of
messages we've translated it as "zurücksetzen".
This fixes that.
Signed-off-by: Ralf Thielow
---
Note that the part "neu" is not used in any places because
I think sometimes it sounds better without them.
Translate 11 new messages came from git.pot update
in 46bc403 (l10n: Update git.pot (11 new, 7 removed
messages)).
Signed-off-by: Ralf Thielow
Acked-by: Thomas Rast
---
po/de.po | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/po/de.po
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> I think "add -u && commit" vs "commit -a" you brought up is a good
>> thing to mention, so let's do this.
>
> I'm OK with your proposal. Let me know if you want me to resend.
Thanks for a quick response. As you may have guessed, I am sending
t
Jonathan Nieder wrote:
> Throughout git, it is assumed that the WIN32 preprocessor symbol is
> defined on native Windows setups (mingw and msvc) and not on Cygwin.
> On Cygwin, most of the time git can pretend this is just another Unix
> machine, and Windows-specific magic is generally counterprodu
Junio C Hamano writes:
> I think "add -u && commit" vs "commit -a" you brought up is a good
> thing to mention, so let's do this.
I'm OK with your proposal. Let me know if you want me to resend.
> The inconsistency of 'git add -u' and 'git add -A' are particularly
Nitpick: this should be "
On Mon, Jan 28, 2013 at 05:39:27PM +0100, Joachim Schmitz wrote:
> Ralf Thielow wrote:
> >Translate 11 new messages came from git.pot update
> >in 46bc403 (l10n: Update git.pot (11 new, 7 removed
> >messages)).
> >
> >Signed-off-by: Ralf Thielow
> >---
> > po/de.po | 37 ++-
Michael J Gruber writes:
> Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:
>> Most git commands that can be used with our without a filepattern are
>> tree-wide by default, the filepattern being used to restrict their scope.
>> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'g
On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote:
> Ralf Thielow writes:
>
> > #: builtin/reset.c:275
> > -#, fuzzy, c-format
> > +#, c-format
> > msgid "Failed to resolve '%s' as a valid revision."
> > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
> > +msgstr "Konnte '%
John Keeping writes:
> ---
> On Mon, Jan 28, 2013 at 11:44:34AM +0100, Michael Haggerty wrote:
>> NAK. It is still not right. If the locale is not utf-8 based, then it
>> is incorrect to re-encode the string using utf-8. I think you really
>> have to use sys.getfilesystemencoding() as I sugges
Michael J Gruber writes:
> Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
>> Please, test it and report any behaviour you think is incorrect.
>
> OK, that seems to work and to be quite helpful.
>
> Minor nit: "git add -u" could use the same fileset as "git commit". But
> I don't know whether
Jonathan Nieder writes:
> Tracing backwards: it would be really nice to be able to do
>
> git for-each-repo git grep -e foo -- '*.c'
This is a very good example that shows the command that is run in
the repositories found may want pathspecs passed, but at the same
time, makes me realize th
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
On Mon, Jan 28, 2013 at 9:10 AM, Jonathan Nieder wrote:
>
> Lars Hjemli wrote:
>
>> [1] The 'git -a' rewrite patch shows how I think about this command -
>> it's just an option to the 'git' command, modifying the way any
>> subcommand is invoked (btw: I don't expect that patch to be applied
>> sin
Ralf Thielow wrote:
Translate 11 new messages came from git.pot update
in 46bc403 (l10n: Update git.pot (11 new, 7 removed
messages)).
Signed-off-by: Ralf Thielow
---
po/de.po | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/po/de.po b
Manlio Perillo venit, vidit, dixit 28.01.2013 15:02:
> Il 28/01/2013 13:52, Michael J Gruber ha scritto:
>> Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
>>> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
wookietreiber writes:
>>>
> I have a feature request for `git add` auto comp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 28/01/2013 13:52, Michael J Gruber ha scritto:
> Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
>> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>>> wookietreiber writes:
>>
I have a feature request for `git add` auto completion:
Manlio Perillo venit, vidit, dixit 28.01.2013 10:26:
> Il 28/01/2013 00:00, Junio C Hamano ha scritto:
>> wookietreiber writes:
>
>>> I have a feature request for `git add` auto completion:
>>>
>>> `git add` auto completion suggests all files / directories,
>>> filtered by nothing. I guess it wou
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 foll
---
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 t
On 01/28/2013 12:05 PM, Thomas Rast wrote:
> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
> need to read blob from the standard input, 2012-06-27), which is
> included starting with v1.7.12 and the v1.7.11.3 maint release. Please
> upgrade.
Thanks.
signature.asc
Des
Rene Moser writes:
>
> Found a little issue in git version 1.7.9.5 if a file named "-", causing
> "git commit" to read from stdin.
>
> (So you must hit ctrl-d or ctrl-c to finish the commit.)
>
> Everything looks ok to me after the commit. Other users reported to be
> fixed in 1.8.1.1 but haven't
On Mon, Jan 28, 2013 at 5:38 PM, Rene Moser wrote:
> Hi
>
> Found a little issue in git version 1.7.9.5 if a file named "-", causing
> "git commit" to read from stdin.
>
> (So you must hit ctrl-d or ctrl-c to finish the commit.)
>
> Everything looks ok to me after the commit. Other users reported
Rene Moser writes:
> Hi
>
> Found a little issue in git version 1.7.9.5 if a file named "-", causing
> "git commit" to read from stdin.
Can't reproduce with Git version 1.8.1.1.440.g1d329bd, this probably has
been fixed already.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscrib
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 n
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
Ralf Thielow writes:
> Translate 11 new messages came from git.pot update
> in 46bc403 (l10n: Update git.pot (11 new, 7 removed
> messages)).
> #: builtin/log.c:104
> msgid "Use mail map file"
> -msgstr ""
> +msgstr "verwendet \"mailmap\"-Datei"
Note that case differs here, but it's the Engli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 28/01/2013 00:00, Junio C Hamano ha scritto:
> wookietreiber writes:
>
>> I have a feature request for `git add` auto completion:
>>
>> `git add` auto completion suggests all files / directories,
>> filtered by nothing. I guess it would be much ni
Matthieu Moy wrote:
> Signed-off-by: Matthieu Moy
Looks good to me.
At some point we'll want to have tests for this case, but that's not
particularly urgent until it's time for the warning() to turn into a
die().
Thanks.
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git
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
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
problema
On Mon, Jan 28, 2013 at 12:20 AM, Philip Oakley wrote:
> From: "David Aguilar"
> Sent: Monday, January 28, 2013 12:52 AM
>
>> This is round two of this series.
>> I think this touched on everything brought up in the code review.
>> 4/4 could use a review as I'm not completely familiar with the
>>
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Plus, option_with_implicit_dot is used in cut-and-paste ready commands
>> below.
>
> I do not think we should aim for easy cut-and-paste, especially when
> the real purpose of the change is to train people's fingers; the
> message should discour
From: "David Aguilar"
Sent: Monday, January 28, 2013 12:52 AM
This is round two of this series.
I think this touched on everything brought up in the code review.
4/4 could use a review as I'm not completely familiar with the
makefile dependencies, though it seems to work correctly.
Does this 4
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 pa
This is not really a git problem, but more of an ssh problem.
Are you in the position to change the port where the SSH daemon
listens on? Then you could use a different port which isn't blocked
(443 perhaps?).
On Sat, Jan 26, 2013 at 7:56 PM, Craig Christensen wrote:
> I am currently a student a
90 matches
Mail list logo
