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