Access different NAMESPACE of remote repo from client side
GIT_NAMESPACE is designed to be used mainly on the server side, that the server can serve multiple git repositories while share one single repository storage using different GIT_NAMESPACE settings. Since we know that one remote repository hosts multiple namespaces, can we handle different namespaces in one local repository? Or can we access the proper namespace of the remote repository without complicated server settings? At least there are three solutions for ssh protocol: pass namespace through environment, pass namespace in URL, or pass namespace from the proper settings of remote..receivepack and remote..uploadpack. Solution 1: passing the namespace through environment. 1. Set '/etc/sshd_config' in the server side as the following, so that the ssh server can accept GIT_NAMESPACE environment. AcceptEnv LANG LC_* GIT_NAMESPACE 2. In the client side, When connect to ssh server, must send the GIT_NAMESPACE environment. This can be done with a remote-ext url: $ git remote add foo \ 'ext::ssh -o SendEnv=GIT_NAMESPACE git@server %S 'path/to/repo.git' Then the remote "foo" is GIT_NAMESPACE aware, but when operate on this remote, must provide proper "--namespace" option. $ git --namespace=foo push foo master $ git --namespace=foo fetch foo $ git --namespace=foo ls-remote foo $ git --namespace=foo remote prune foo $ git --namespace=foo archive --remote foo HEAD But provide a "--namespace" option is error-prone, but we may invent "remote..namespace" or something to set GIT_NAMESPACE automatically when push to or fetch from remote server. Solution 2: passing the namespace in URL. Again use remote-ext style URL to access remote repository: $ git remote add foo \ 'ext::ssh git@server git --namespace foo %s path/to/repo.git' $ git remote add bar \ 'ext::ssh git@server git --namespace bar %s path/to/repo.git' But if the remote server use a limit shell (such as git-shell or gitolite), the above URLs won't work. This is because these git specific shell (git-shell or gitolite) do not like options. Solution 3: use custom receivepack and uploadpack. e.g. [remote "foo"] url = ssh://git@server/path/to/repo.git receivepack = git --namespace foo receive-pack uploadpack = git --namespace foo upload-pack fetch = +refs/heads/*:refs/remotes/foo/* [remote "bar"] url = ssh://git@server/path/to/repo.git receivepack = git --namespace bar receive-pack uploadpack = git --namespace bar upload-pack fetch = +refs/heads/*:refs/remotes/foo/* Just like solution 2, these settings won't work without a patched git-shell or gitolite. I will send a patch in next email to address the latter two cases. -- Jiang Xin -- 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: Fwd: Error with git-svn pushing a rename
Hi > But today I tried to push back a rename to the subversion server, > which resulted in the following error:> > perl: subversion/libsvn_subr/dirent_uri.c:2489: > svn_fspath__skip_ancestor: Assertion > `svn_fspath__is_canonical(child_fspath)' failed. > error: git-svn died of signal 6 I also observed this issue with a rename. My workaround was to downgrade subversion to 1.7.x. That worked, but I'm searching for a real solution. > After searching the web I found a similar problem at stackoverflow: > http://stackoverflow.com/questions/17693255/git-svn-dcommit-fails-because-of-assertion-error-svn-fspath-is-canonicalchildj I'll add this one to the list: https://trac.macports.org/ticket/39986 It looks like I'm not the only one experiencing this. Regards, Andy -- 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: Add a bugzilla website
* ycollette.nos...@free.fr [2013-11-15 08:44]: > I just wanted to ask a question: why is there no bugzilla website for > git ? It's better to put bugs into such a tool to follow there > evolution than to manage bugs via a developpment mailing list ... http://thread.gmane.org/gmane.comp.version-control.git/191835/focus=192464 -- Damien Wyart -- 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: Add a bugzilla website
And the conclusion is ? No bugzilla tool installed because somebody want to build a gitbased bugzilla thing ? YC - Mail original - De: "Damien Wyart" À: "ycollette nospam" Cc: git@vger.kernel.org Envoyé: Vendredi 15 Novembre 2013 09:53:26 Objet: Re: Add a bugzilla website * ycollette.nos...@free.fr [2013-11-15 08:44]: > I just wanted to ask a question: why is there no bugzilla website for > git ? It's better to put bugs into such a tool to follow there > evolution than to manage bugs via a developpment mailing list ... http://thread.gmane.org/gmane.comp.version-control.git/191835/focus=192464 -- Damien Wyart -- 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] shell: allow git command with --namespace option
GIT_NAMESPACE is designed to be used mainly on the server side, that
the server can serve multiple git repositories while share one single
repository storage using different GIT_NAMESPACE settings.
Since we know that one remote repository hosts multiple namespaces,
can we handle different namespaces in one local repository? Or can
we access the proper namespace of the remote repository without
complicated server settings?
We can access namespace of remote repository using a proper formated
URL or with the help of settings of "remote..receivepack" and
"remote..uploadpack". E.g.
Use remote-ext style URL to access specific namespace of the remote:
$ git remote add foo \
'ext::ssh git@server git --namespace foo %s path/to/repo.git'
$ git remote add bar \
'ext::ssh git@server git --namespace bar %s path/to/repo.git'
Or set "remote..receivepack" and "remote..uploadpack".
[remote "foo"]
url = ssh://git@server/path/to/repo.git
receivepack = git --namespace foo receive-pack
uploadpack = git --namespace foo upload-pack
fetch = +refs/heads/*:refs/remotes/foo/*
[remote "bar"]
url = ssh://git@server/path/to/repo.git
receivepack = git --namespace bar receive-pack
uploadpack = git --namespace bar upload-pack
fetch = +refs/heads/*:refs/remotes/foo/*
But if the remote ssh server use a limit shell (such as git-shell
or gitolite), the above URLs won't work. This is because these git
specific shell (git-shell or gitolite) do not like options.
This patch makes git-shell aware of the "--namespace" option.
Signed-off-by: Jiang Xin
---
shell.c | 47 ++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/shell.c b/shell.c
index 66350b2..a619577 100644
--- a/shell.c
+++ b/shell.c
@@ -25,6 +25,50 @@ static int do_generic_cmd(const char *me, char *arg)
return execv_git_cmd(my_argv);
}
+static int do_git_with_opts_cmd(const char *me, char *arg)
+{
+ const char *allowed_cmds[] = {
+ "receive-pack",
+ "upload-pack",
+ "upload-archive",
+ NULL,
+ };
+ const char **user_argv, **p;
+ const char *cmd = NULL;
+ int count;
+
+ count = split_cmdline(arg, &user_argv);
+ if (count < 0) {
+ die ("Invalid command format '%s'\n", arg);
+ }
+
+ if (count == 3 && !strncmp("--namespace=", *user_argv, 12)) {
+ cmd = user_argv[1];
+ p = user_argv + 2;
+ } else if (count == 4 && !strcmp("--namespace", *user_argv)) {
+ cmd = user_argv[2];
+ p = user_argv + 3;
+ } else {
+ cmd = user_argv[0];
+ p = user_argv + 1;
+ }
+
+ if (cmd) {
+ /* last arg is path of repository */
+ if (!*p || *(p+1))
+ die("bad argument");
+
+ for (p = allowed_cmds; *p; p++) {
+ if (strcmp(*p, cmd))
+ continue;
+ setup_path();
+ return execv_git_cmd(user_argv);
+ }
+ }
+
+ die("bad command");
+}
+
static int do_cvs_cmd(const char *me, char *arg)
{
const char *cvsserver_argv[3] = {
@@ -138,6 +182,7 @@ static struct commands {
{ "git-receive-pack", do_generic_cmd },
{ "git-upload-pack", do_generic_cmd },
{ "git-upload-archive", do_generic_cmd },
+ { "git", do_git_with_opts_cmd },
{ "cvs", do_cvs_cmd },
{ NULL },
};
@@ -185,7 +230,7 @@ int main(int argc, char **argv)
}
prog = xstrdup(argv[2]);
- if (!strncmp(prog, "git", 3) && isspace(prog[3]))
+ if (!strncmp(prog, "git", 3) && isspace(prog[3]) && isalpha(prog[4]))
/* Accept "git foo" as if the caller said "git-foo". */
prog[3] = '-';
--
1.8.5.rc2.2.g0469850
--
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: Add a bugzilla website
On Fri, 15 Nov 2013 10:40:47 +0100 (CET) ycollette.nos...@free.fr wrote: > And the conclusion is ? No bugzilla tool installed because somebody > want to build a gitbased bugzilla thing ? Well, no, the real answer is that for those who actually write code and apply patches, an e-mail based workflow is simpler: Git has tools to apply patches right from Unix mailboxes, so one is able to just save a thread with the final patch series to a file and apply it. Some people also prefer discussing patches inline -- in the same e-mail thread the patch series being discussed had started. I'm aware of at least one big project sporting the same approach to handling bugs -- PostgreSQL. But there was an announcement that an experimental JIRA instance has been set up for Git [1]. I'm not sure what its current status is, but you could look at it. Also Git's mirror on github [2] supposedly provides for pull requests. Again, not sure whether/how they're handled. 1. http://git-blame.blogspot.ru/2012/02/experimental-git-bug-tracker.html 2. https://github.com/git/git/ -- 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: Add a bugzilla website
OK, thanks for these informations. >From a user perspective, having this volume of devel mails flooding all the >bugs mail is very annoying. And following the status of a bug and the history of this bug is very hard too. The bugzilla approach is really useful for the user who is reporting bugs: all the bugs are tracked, you can see if a bug has been already filled and put some additional informations if necessary. I will have a look at the JIRA thing. YC - Mail original - De: "Konstantin Khomoutov" À: "ycollette nospam" Cc: git@vger.kernel.org Envoyé: Vendredi 15 Novembre 2013 10:51:32 Objet: Re: Add a bugzilla website On Fri, 15 Nov 2013 10:40:47 +0100 (CET) ycollette.nos...@free.fr wrote: > And the conclusion is ? No bugzilla tool installed because somebody > want to build a gitbased bugzilla thing ? Well, no, the real answer is that for those who actually write code and apply patches, an e-mail based workflow is simpler: Git has tools to apply patches right from Unix mailboxes, so one is able to just save a thread with the final patch series to a file and apply it. Some people also prefer discussing patches inline -- in the same e-mail thread the patch series being discussed had started. I'm aware of at least one big project sporting the same approach to handling bugs -- PostgreSQL. But there was an announcement that an experimental JIRA instance has been set up for Git [1]. I'm not sure what its current status is, but you could look at it. Also Git's mirror on github [2] supposedly provides for pull requests. Again, not sure whether/how they're handled. 1. http://git-blame.blogspot.ru/2012/02/experimental-git-bug-tracker.html 2. https://github.com/git/git/ -- 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: Add a bugzilla website
ycollette.nos...@free.fr writes: > The bugzilla approach is really useful for the user who is reporting > bugs: all the bugs are tracked, you can see if a bug has been already > filled and put some additional informations if necessary. As a user, the most important thing is that the bug is eventually fixed. I had a lot of experiences with projects using bugtrackers, where I filed bugs, and the bugs were burried forever in the bugtracker. Not all projects are like this, but the danger of using a bugtracker to have long-standing bugs forgotten is high. It is especially high when there's no one paid to maintain the list of open bugs low. As opposed to this, most bug reports on this list are followed by a lively discussion and a patch. Sure, a bugtracker could complement this, but someone would have to volunteer to set up and maintain one, and to get developpers interested in fixing bugs reported there. There have been attempts, but AFAIK no success. -- 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
[PATCH v3 0/6] Replacement for rr/for-each-ref-decoration
Hi Junio et al, v3 contains the following changes: - [1/6] is totally unrelated; it's a "while we're there" patch. - [2/6] is required for the test modification in [4/6]. - [3/6], [4/6], [5/6] now come with tests. - [6/6] is new: implements Junio's suggestion to auto-reset color. I haven't included Junio's 78465bb (fixup! for-each-ref: introduce %(upstream:track[short]), 2013-10-31), because my compiler doesn't complain, and because it's ugly. Thanks. Ramkumar Ramachandra (6): t6300 (for-each-ref): clearly demarcate setup t6300 (for-each-ref): don't hardcode SHA-1 hexes for-each-ref: introduce %(HEAD) asterisk marker for-each-ref: introduce %(upstream:track[short]) for-each-ref: introduce %(color:...) for color for-each-ref: auto reset color after each atom Documentation/git-for-each-ref.txt | 14 ++- builtin/for-each-ref.c | 86 +- t/t6300-for-each-ref.sh| 59 -- 3 files changed, 135 insertions(+), 24 deletions(-) -- 1.8.5.rc0.6.gfd75b41 -- 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 4/6] for-each-ref: introduce %(upstream:track[short])
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%(refname:short)%(upstream:trackshort)
to display refs with terse tracking information.
Note that :track and :trackshort only work with "upstream", and error
out when used with anything else.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 6 +-
builtin/for-each-ref.c | 40 +++---
t/t6300-for-each-ref.sh| 22 +
3 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index ab3da0e..c9b192e 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -91,7 +91,11 @@ objectname::
upstream::
The name of a local ref which can be considered ``upstream''
from the displayed ref. Respects `:short` in the same way as
- `refname` above.
+ `refname` above. Additionally respects `:track` to show
+ "[ahead N, behind M]" and `:trackshort` to show the terse
+ version (like the prompt) ">", "<", "<>", or "=". Has no
+ effect if the ref does not have tracking information
+ associated with it.
HEAD::
Used to indicate the currently checked out branch. Is '*' if
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 5f1842f..ed81407 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -641,6 +641,7 @@ static void populate_value(struct refinfo *ref)
int deref = 0;
const char *refname;
const char *formatp;
+ struct branch *branch;
if (*name == '*') {
deref = 1;
@@ -652,7 +653,6 @@ static void populate_value(struct refinfo *ref)
else if (!prefixcmp(name, "symref"))
refname = ref->symref ? ref->symref : "";
else if (!prefixcmp(name, "upstream")) {
- struct branch *branch;
/* only local branches may have an upstream */
if (prefixcmp(ref->refname, "refs/heads/"))
continue;
@@ -679,6 +679,7 @@ static void populate_value(struct refinfo *ref)
} else if (!strcmp(name, "HEAD")) {
const char *head;
unsigned char sha1[20];
+
head = resolve_ref_unsafe("HEAD", sha1, 1, NULL);
if (!strcmp(ref->refname, head))
v->s = "*";
@@ -689,13 +690,46 @@ static void populate_value(struct refinfo *ref)
continue;
formatp = strchr(name, ':');
- /* look for "short" refname format */
if (formatp) {
+ int num_ours, num_theirs;
+
formatp++;
if (!strcmp(formatp, "short"))
refname = shorten_unambiguous_ref(refname,
warn_ambiguous_refs);
- else
+ else if (!strcmp(formatp, "track") &&
+ !prefixcmp(name, "upstream")) {
+ char buf[40];
+
+ stat_tracking_info(branch, &num_ours,
&num_theirs);
+ if (!num_ours && !num_theirs)
+ v->s = "";
+ else if (!num_ours) {
+ sprintf(buf, "[behind %d]", num_theirs);
+ v->s = xstrdup(buf);
+ } else if (!num_theirs) {
+ sprintf(buf, "[ahead %d]", num_ours);
+ v->s = xstrdup(buf);
+ } else {
+ sprintf(buf, "[ahead %d, behind %d]",
+ num_ours, num_theirs);
+ v->s = xstrdup(buf);
+ }
+ continue;
+ } else if (!strcmp(formatp, "trackshort") &&
+ !prefixcmp(name, "upstream")) {
+
+ stat_tracking_info(branch, &num_ours,
&num_theirs);
+ if (!num_ours && !num_theirs)
+ v->s = "=";
+ else if (!num_ours)
+ v->s = "<";
+ else if (!num_theirs)
+ v->s = ">";
+
[PATCH v3 1/6] t6300 (for-each-ref): clearly demarcate setup
Condense the two-step setup into one step, and give it an appropriate
name.
Signed-off-by: Ramkumar Ramachandra
---
t/t6300-for-each-ref.sh | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 752f5cb..72d282f 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -18,16 +18,13 @@ setdate_and_increment () {
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
}
-test_expect_success 'Create sample commit with known timestamp' '
+test_expect_success setup '
setdate_and_increment &&
echo "Using $datestamp" > one &&
git add one &&
git commit -m "Initial" &&
setdate_and_increment &&
git tag -a -m "Tagging at $datestamp" testtag
-'
-
-test_expect_success 'Create upstream config' '
git update-ref refs/remotes/origin/master master &&
git remote add origin nowhere &&
git config branch.master.remote origin &&
--
1.8.5.rc0.6.gfd75b41
--
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 3/6] for-each-ref: introduce %(HEAD) asterisk marker
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend its format with
%(HEAD) for the same effect.
Now you can use the following format in for-each-ref:
%(HEAD) %(refname:short)
to display an asterisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +++--
t/t6300-for-each-ref.sh| 2 ++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index f2e08d1..ab3da0e 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -93,6 +93,10 @@ upstream::
from the displayed ref. Respects `:short` in the same way as
`refname` above.
+HEAD::
+ Used to indicate the currently checked out branch. Is '*' if
+ HEAD points to the current ref, and ' ' otherwise.
+
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 1d4083c..5f1842f 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -75,6 +75,7 @@ static struct {
{ "upstream" },
{ "symref" },
{ "flag" },
+ { "HEAD" },
};
/*
@@ -675,8 +676,16 @@ static void populate_value(struct refinfo *ref)
v->s = xstrdup(buf + 1);
}
continue;
- }
- else
+ } else if (!strcmp(name, "HEAD")) {
+ const char *head;
+ unsigned char sha1[20];
+ head = resolve_ref_unsafe("HEAD", sha1, 1, NULL);
+ if (!strcmp(ref->refname, head))
+ v->s = "*";
+ else
+ v->s = " ";
+ continue;
+ } else
continue;
formatp = strchr(name, ':');
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index e1f71ff..5e29ffc 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -77,6 +77,7 @@ test_atom head contents:body ''
test_atom head contents:signature ''
test_atom head contents 'Initial
'
+test_atom head HEAD '*'
test_atom tag refname refs/tags/testtag
test_atom tag upstream ''
@@ -110,6 +111,7 @@ test_atom tag contents:body ''
test_atom tag contents:signature ''
test_atom tag contents 'Tagging at 1151939927
'
+test_atom tag HEAD ' '
test_expect_success 'Check invalid atoms names are errors' '
test_must_fail git for-each-ref --format="%(INVALID)" refs/heads
--
1.8.5.rc0.6.gfd75b41
--
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 2/6] t6300 (for-each-ref): don't hardcode SHA-1 hexes
Use rev-parse in its place, making it easier for future patches to
modify the test script.
Signed-off-by: Ramkumar Ramachandra
---
t/t6300-for-each-ref.sh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 72d282f..e1f71ff 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -49,8 +49,8 @@ test_atom head refname refs/heads/master
test_atom head upstream refs/remotes/origin/master
test_atom head objecttype commit
test_atom head objectsize 171
-test_atom head objectname 67a36f10722846e891fbada1ba48ed035de75581
-test_atom head tree 0e51c00fcb93dffc755546f27593d511e1bdb46f
+test_atom head objectname $(git rev-parse refs/heads/master)
+test_atom head tree $(git rev-parse refs/heads/master^{tree})
test_atom head parent ''
test_atom head numparent 0
test_atom head object ''
@@ -82,11 +82,11 @@ test_atom tag refname refs/tags/testtag
test_atom tag upstream ''
test_atom tag objecttype tag
test_atom tag objectsize 154
-test_atom tag objectname 98b46b1d36e5b07909de1b3886224e3e81e87322
+test_atom tag objectname $(git rev-parse refs/tags/testtag)
test_atom tag tree ''
test_atom tag parent ''
test_atom tag numparent ''
-test_atom tag object '67a36f10722846e891fbada1ba48ed035de75581'
+test_atom tag object $(git rev-parse refs/tags/testtag^0)
test_atom tag type 'commit'
test_atom tag author ''
test_atom tag authorname ''
@@ -302,7 +302,7 @@ test_expect_success 'Check short upstream format' '
'
cat >expected expected < refs/tags/master
+$(git rev-parse refs/tags/bogo) refs/tags/bogo
EOF
test_expect_success 'Verify sort with multiple keys' '
--
1.8.5.rc0.6.gfd75b41
--
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 5/6] for-each-ref: introduce %(color:...) for color
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%(color:green)%(refname:short)%(color:reset)
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 11 +--
t/t6300-for-each-ref.sh| 14 ++
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index c9b192e..2f3ac22 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -101,6 +101,10 @@ HEAD::
Used to indicate the currently checked out branch. Is '*' if
HEAD points to the current ref, and ' ' otherwise.
+color::
+ Used to change color of output. Followed by `:`,
+ where names are described in `color.branch.*`.
+
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index ed81407..2ff4e54 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -9,6 +9,7 @@
#include "quote.h"
#include "parse-options.h"
#include "remote.h"
+#include "color.h"
/* Quoting styles */
#define QUOTE_NONE 0
@@ -76,6 +77,7 @@ static struct {
{ "symref" },
{ "flag" },
{ "HEAD" },
+ { "color" },
};
/*
@@ -662,8 +664,13 @@ static void populate_value(struct refinfo *ref)
!branch->merge[0]->dst)
continue;
refname = branch->merge[0]->dst;
- }
- else if (!strcmp(name, "flag")) {
+ } else if (!prefixcmp(name, "color:")) {
+ char color[COLOR_MAXLEN] = "";
+
+ color_parse(name + 6, "--format", color);
+ v->s = xstrdup(color);
+ continue;
+ } else if (!strcmp(name, "flag")) {
char buf[256], *cp = buf;
if (ref->flag & REF_ISSYMREF)
cp = copy_advance(cp, ",symref");
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 9d874fd..35ca991 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -338,6 +338,20 @@ test_expect_success 'Check for invalid refname format' '
test_must_fail git for-each-ref --format="%(refname:INVALID)"
'
+get_color ()
+{
+ git config --get-color no.such.slot "$1"
+}
+
+cat >expected expected <<\EOF
heads/master
tags/master
--
1.8.5.rc0.6.gfd75b41
--
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 6/6] for-each-ref: auto reset color after each atom
It makes it easier to write a sensible format string, since you don't
have to %(color:reset) after each atom. Additionally, to make sure that
an invocation like the following doesn't leak color,
$ git for-each-ref --format='%(subject)%(color:green)'
auto-reset at the end of the format string as well.
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 22 ++
t/t6300-for-each-ref.sh | 2 +-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 2ff4e54..1050aea 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -23,6 +23,7 @@ typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
struct atom_value {
const char *s;
unsigned long ul; /* used for sorting when not FIELD_STR */
+ int color : 1;
};
struct ref_sort {
@@ -669,6 +670,7 @@ static void populate_value(struct refinfo *ref)
color_parse(name + 6, "--format", color);
v->s = xstrdup(color);
+ v->color = 1;
continue;
} else if (!strcmp(name, "flag")) {
char buf[256], *cp = buf;
@@ -914,11 +916,9 @@ static void sort_refs(struct ref_sort *sort, struct
refinfo **refs, int num_refs
qsort(refs, num_refs, sizeof(struct refinfo *), compare_refs);
}
-static void print_value(struct refinfo *ref, int atom, int quote_style)
+static void print_value(struct atom_value *v, int quote_style)
{
- struct atom_value *v;
struct strbuf sb = STRBUF_INIT;
- get_value(ref, atom, &v);
switch (quote_style) {
case QUOTE_NONE:
fputs(v->s, stdout);
@@ -983,17 +983,31 @@ static void emit(const char *cp, const char *ep)
static void show_ref(struct refinfo *info, const char *format, int quote_style)
{
const char *cp, *sp, *ep;
+ struct atom_value *atomv, resetv;
+ int reset_color = 0;
+ char color[COLOR_MAXLEN] = "";
+ color_parse("reset", "--format", color);
+ resetv.s = color;
for (cp = format; *cp && (sp = find_next(cp)); cp = ep + 1) {
ep = strchr(sp, ')');
if (cp < sp)
emit(cp, sp);
- print_value(info, parse_atom(sp + 2, ep), quote_style);
+ get_value(info, parse_atom(sp + 2, ep), &atomv);
+ print_value(atomv, quote_style);
+ if (reset_color) {
+ print_value(&resetv, quote_style);
+ reset_color = 0;
+ }
+ if (atomv->color)
+ reset_color = 1;
}
if (*cp) {
sp = cp + strlen(cp);
emit(cp, sp);
}
+ if (reset_color)
+ print_value(&resetv, quote_style);
putchar('\n');
}
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 35ca991..2bf2bea 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -348,7 +348,7 @@ $(get_color red)$(git rev-parse --short HEAD)$(get_color
reset) origin/master
EOF
test_expect_success 'Check %(color:...) ' '
- git for-each-ref
--format="%(color:red)%(objectname:short)%(color:reset) %(upstream:short)"
refs/heads >actual &&
+ git for-each-ref --format="%(color:red)%(objectname:short)
%(upstream:short)" refs/heads >actual &&
test_cmp expected actual
'
--
1.8.5.rc0.6.gfd75b41
--
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: Fwd: Error with git-svn pushing a rename
Hi Benjamin > thanks for your link. Can you give me the exact version you > downgraded svn to? svn, Version 1.7.10 (r1485443) I tried to reproduce the problem with git version 1.8.4.2 and Subversion version 1.8.4 (r1534716) with a fresh and pristine subversion repo and a git-svn clone of it: I didn't manage to reproduce the rename issue. Then I switched subversion back to 1.7.10, created both the repo and the git-svn clone, switched againt to 1.8.4.2 and then got an error. Unfortunately I didn't check if the subversion perlbindings were regenerated, so I'm not exactly sure. I'll repeat the test again, as soon I've find the time. It looks like a fresh git svn clone may fix the problem. Regards, Andy -- 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: Access different NAMESPACE of remote repo from client side
On 11/15/2013 01:49 PM, Jiang Xin wrote: > GIT_NAMESPACE is designed to be used mainly on the server side, that > the server can serve multiple git repositories while share one single > repository storage using different GIT_NAMESPACE settings. > > Since we know that one remote repository hosts multiple namespaces, > can we handle different namespaces in one local repository? Or can > we access the proper namespace of the remote repository without > complicated server settings? > > At least there are three solutions for ssh protocol: pass namespace > through environment, pass namespace in URL, or pass namespace from > the proper settings of remote..receivepack and > remote..uploadpack. > > Solution 1: passing the namespace through environment. > > 1. Set '/etc/sshd_config' in the server side as the following, > so that the ssh server can accept GIT_NAMESPACE environment. > > AcceptEnv LANG LC_* GIT_NAMESPACE > > 2. In the client side, When connect to ssh server, must send the > GIT_NAMESPACE environment. This can be done with a remote-ext > url: > > $ git remote add foo \ > 'ext::ssh -o SendEnv=GIT_NAMESPACE git@server %S 'path/to/repo.git' > > Then the remote "foo" is GIT_NAMESPACE aware, but when operate on > this remote, must provide proper "--namespace" option. > > $ git --namespace=foo push foo master > $ git --namespace=foo fetch foo > $ git --namespace=foo ls-remote foo > $ git --namespace=foo remote prune foo > $ git --namespace=foo archive --remote foo HEAD > > But provide a "--namespace" option is error-prone, but we may invent > "remote..namespace" or something to set GIT_NAMESPACE > automatically when push to or fetch from remote server. > > Solution 2: passing the namespace in URL. > > Again use remote-ext style URL to access remote repository: > > $ git remote add foo \ > 'ext::ssh git@server git --namespace foo %s path/to/repo.git' > > $ git remote add bar \ > 'ext::ssh git@server git --namespace bar %s path/to/repo.git' > > But if the remote server use a limit shell (such as git-shell or > gitolite), the above URLs won't work. This is because these git > specific shell (git-shell or gitolite) do not like options. > > Solution 3: use custom receivepack and uploadpack. e.g. > > [remote "foo"] > url = ssh://git@server/path/to/repo.git > receivepack = git --namespace foo receive-pack > uploadpack = git --namespace foo upload-pack > fetch = +refs/heads/*:refs/remotes/foo/* > > [remote "bar"] > url = ssh://git@server/path/to/repo.git > receivepack = git --namespace bar receive-pack > uploadpack = git --namespace bar upload-pack > fetch = +refs/heads/*:refs/remotes/foo/* > > Just like solution 2, these settings won't work without a patched > git-shell or gitolite. Gitolite has a namespaces branch that handles namespaces as described in http://gitolite.com/gitolite/namespaces.html Briefly, it recognises that you can have a "main" repo off of which several developer might want to hang their logical repos. It also recognises that the actual names of the logical repos will follow some pattern that may include the name of the developer also, and provides a way to derive the name of the physical repo from the logical one. There is an example or two in that link. -- 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: Access different NAMESPACE of remote repo from client side
On 11/15/2013 07:55 PM, Sitaram Chamarty wrote: > On 11/15/2013 01:49 PM, Jiang Xin wrote: >> GIT_NAMESPACE is designed to be used mainly on the server side, that >> the server can serve multiple git repositories while share one single >> repository storage using different GIT_NAMESPACE settings. >> >> Since we know that one remote repository hosts multiple namespaces, >> can we handle different namespaces in one local repository? Or can >> we access the proper namespace of the remote repository without >> complicated server settings? >> >> At least there are three solutions for ssh protocol: pass namespace >> through environment, pass namespace in URL, or pass namespace from >> the proper settings of remote..receivepack and >> remote..uploadpack. >> >> Solution 1: passing the namespace through environment. >> >> 1. Set '/etc/sshd_config' in the server side as the following, >> so that the ssh server can accept GIT_NAMESPACE environment. >> >> AcceptEnv LANG LC_* GIT_NAMESPACE >> >> 2. In the client side, When connect to ssh server, must send the >> GIT_NAMESPACE environment. This can be done with a remote-ext >> url: >> >> $ git remote add foo \ >> 'ext::ssh -o SendEnv=GIT_NAMESPACE git@server %S 'path/to/repo.git' >> >> Then the remote "foo" is GIT_NAMESPACE aware, but when operate on >> this remote, must provide proper "--namespace" option. >> >> $ git --namespace=foo push foo master >> $ git --namespace=foo fetch foo >> $ git --namespace=foo ls-remote foo >> $ git --namespace=foo remote prune foo >> $ git --namespace=foo archive --remote foo HEAD >> >> But provide a "--namespace" option is error-prone, but we may invent >> "remote..namespace" or something to set GIT_NAMESPACE >> automatically when push to or fetch from remote server. >> >> Solution 2: passing the namespace in URL. >> >> Again use remote-ext style URL to access remote repository: >> >> $ git remote add foo \ >> 'ext::ssh git@server git --namespace foo %s path/to/repo.git' >> >> $ git remote add bar \ >> 'ext::ssh git@server git --namespace bar %s path/to/repo.git' >> >> But if the remote server use a limit shell (such as git-shell or >> gitolite), the above URLs won't work. This is because these git >> specific shell (git-shell or gitolite) do not like options. >> >> Solution 3: use custom receivepack and uploadpack. e.g. >> >> [remote "foo"] >> url = ssh://git@server/path/to/repo.git >> receivepack = git --namespace foo receive-pack >> uploadpack = git --namespace foo upload-pack >> fetch = +refs/heads/*:refs/remotes/foo/* >> >> [remote "bar"] >> url = ssh://git@server/path/to/repo.git >> receivepack = git --namespace bar receive-pack >> uploadpack = git --namespace bar upload-pack >> fetch = +refs/heads/*:refs/remotes/foo/* >> >> Just like solution 2, these settings won't work without a patched >> git-shell or gitolite. > > Gitolite has a namespaces branch that handles namespaces as described in > http://gitolite.com/gitolite/namespaces.html > > Briefly, it recognises that you can have a "main" repo off of which > several developer might want to hang their logical repos. > > It also recognises that the actual names of the logical repos will > follow some pattern that may include the name of the developer also, and > provides a way to derive the name of the physical repo from the logical > one. > > There is an example or two in that link. I should add that the Gitolite model is: the user doesn't need to know about namespaces, because namespaces are just things that the server admin is setting up for his own reasons... ...typically because he anticipates several dozens of people cloning the same repo into their namespace and so he expects to save a lot of disk doing this). So in this model we don't really need anything on the client side. -- 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] RelNotes: Spelling & grammar fixes.
Oops: Signed-off-by: Marc Branchaud Sorry! (I have at long last automated s-o-b in my git repo...) M. -- 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
Fwd: Possible bug report: `git commit -ammend`
I ran `git commit -ammend` on a repo where 1 out of 3 files changed were staged for commit. I would've expected an error to be thrown due to the double typo but instead it committed all 3 files with the message 'mend'. So it looks like it interpreted it as `git commit -a -m 'mend'`. I'm running git 1.8.3.4 using iTerm 1.0.0 on OSX 10.9. -- -- This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL. Registered in England and Wales with company number 53723. -- 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: Fwd: Possible bug report: `git commit -ammend`
rhys evans writes: > I ran `git commit -ammend` on a repo where 1 out of 3 files changed > were staged for commit. > > I would've expected an error to be thrown due to the double typo but > instead it committed all 3 files with the message 'mend'. > > So it looks like it interpreted it as `git commit -a -m 'mend'`. Yes. This is a rather widespread convention (e.g. rm -fr == rm -r -f). Git does a special-case for -amend to avoid confusion: $ git commit -amend error: did you mean `--amend` (with two dashes ?) But it did not special-case the double-typo. -- 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: Add a bugzilla website
On 15 November 2013 01:51, Konstantin Khomoutov wrote: > But there was an announcement that an experimental JIRA instance has > been set up for Git [1]. I'm not sure what its current status is, but > you could look at it. So! The biggest concern has always been that any bug tracking system needs to complement the existing workflow of many developers. For bugs and feature requests, they are raised, discussed, and fixed on the list. Replacing this process is not in scope for a bug tracker. In that framework the main value a bug tracker has is keeping track of what bugs exist, what versions they affect, and when they are fixed. Unfortunately, at the moment, collecting and curating this information is entirely manual. The JIRA attempt [1] looks to pull in every conversation and thread it for us (adding replies as comments to existing tickets), but hasn't tried to anything beyond that. Automation may be possible, to do things like parse What's Cooking and the release notes, but that is a harder problem :) The tools are there, and you should be able to log in and add/update issues. Feel free! (Definite value would be derived from a dedicated curator who updated the bug tracker manually) I had a look over the set up (I hadn't in a while) and realised we were dropping some emails, so I'll try and fix that, but the bigger problem is that simply creating tickets to track conversations is not enough. We need to then identify those conversations that we care about and capture some metadata about them - did they resolve the reported issue, and when did that happen? Junio is the source of truth for this, and so ideally we would use his communications to understand it, but that just shifts the problem to linking the issues he writes about to the conversations that started them. In any case, adding value to the existing process is hard (because it works quite well!) and probably requires significantly more work to even understand what that value might look like. This, I think, is the key reason it is hard to truly get started with any bug tracking solution; the solution is not obvious, and the current (very customised) workflow is not supported directly by any tool. Regards, Andrew Ardill [1] https://git-scm.atlassian.net -- 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
Greetings From China
Hello, I want to invest 7.5MillionEuros in your Country and I need someone who will help me. For more info reply me to enable us have a concrete discussion on how I can move the funds to your Country. Best regards Mr.Chenlin Chiang -- 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: Add a bugzilla website
Hi, Andrew Ardill wrote: > On 15 November 2013 01:51, Konstantin Khomoutov > wrote: >> But there was an announcement that an experimental JIRA instance has >> been set up for Git [1]. I'm not sure what its current status is, but >> you could look at it. > > So! > > The biggest concern has always been that any bug tracking system needs > to complement the existing workflow of many developers. For bugs and > feature requests, they are raised, discussed, and fixed on the list. > Replacing this process is not in scope for a bug tracker. I always thought the biggest concern was that someone has to have a sense of what bugs are a priority to track and do the curation to keep the list of bugs useful. In the mailing list it's easy to prioritize based on what people are actually working on; on a bug tracker, which is mainly about what people are *not* working on, that's harder work. One way to address that problem is to decentralize: maybe everyone has a different idea of what bugs are important, but if each person or project makes their own idea of that public, you get most of the benefit of a bugtracker. Bonus points if different project's bugtrackers link to each other to avoid duplication of information. In this vein, there are a few active bugtrackers for git already: * the mailing list archive is the canonical source of truth * the JIRA experiment: https://git-scm.atlassian.net * the Debian project maintains http://bugs.debian.org/src:git * the Ubuntu project maintains https://bugs.launchpad.net/ubuntu/+source/git I don't think the Ubuntu bugtracker wants reports for upstream issues that were not discovered on Ubuntu. By contrast, the maintainers of the Debian bugtracker have made it clear that they are happy to receive reports for the git package even when they do not affect Debian at all (e.g., Windows-specific issues). In other words: if you report a bug by sending an email to sub...@bugs.debian.org with body text starting with Package: git Version: 1:1.8.5~rc2-1 Tags: upstream ... description of the bug here ... then I am happy to keep track of it, link to the corresponding upstream conversation, and let you know when I notice it's fixed. Of course I won't fix your bug for you, unless it's a priority to me for other reasons. :) More details on reporting bugs through the Debian BTS are at [1]. Maybe other people provide the same service as well. Thanks and hope that helps, Jonathan [1] http://www.debian.org/Bugs/Reporting -- 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 0/2] add PERLLIB_EXTRA to add to default perl path
A small pair of patches, for your enjoyment. Thoughts? Jonathan Nieder (2): Makefile: rebuild perl scripts when perl paths change Makefile: add PERLLIB_EXTRA variable that adds to default perl path Makefile | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) -- 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 1/2] Makefile: rebuild perl scripts when perl paths change
Signed-off-by: Jonathan Nieder
---
Makefile | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index af847f8..e5e7868 100644
--- a/Makefile
+++ b/Makefile
@@ -1792,7 +1792,8 @@ perl/PM.stamp: FORCE
perl/perl.mak: GIT-CFLAGS GIT-PREFIX perl/Makefile perl/Makefile.PL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)'
prefix='$(prefix_SQ)' $(@F)
-$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl GIT-VERSION-FILE
+PERL_DEFINES = $(PERL_PATH_SQ)
+$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl perl/perl.mak GIT-PERL-DEFINES
GIT-VERSION-FILE
$(QUIET_GEN)$(RM) $@ $@+ && \
INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory
instlibdir` && \
sed -e '1{' \
@@ -1807,6 +1808,13 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
GIT-VERSION-FILE
chmod +x $@+ && \
mv $@+ $@
+GIT-PERL-DEFINES: FORCE
+ @FLAGS='$(PERL_DEFINES)'; \
+ if test x"$$FLAGS" != x"`cat $@ 2>/dev/null`" ; then \
+ echo >&2 "* new perl-specific parameters"; \
+ echo "$$FLAGS" >$@; \
+ fi
+
.PHONY: gitweb
gitweb:
@@ -2494,7 +2502,8 @@ ifndef NO_TCLTK
$(MAKE) -C git-gui clean
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS
- $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES GIT-PYTHON-VARS
+ $(RM) GIT-USER-AGENT GIT-PREFIX
+ $(RM) GIT-SCRIPT-DEFINES GIT-PERL-DEFINES GIT-PYTHON-VARS
.PHONY: all install profile-clean clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
--
1.8.4.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 2/2] Makefile: add PERLLIB_EXTRA variable that adds to default perl path
Some platforms ship Perl modules used by git scripts outside the
default perl path (e.g., on Mac OS X, Subversion's perl bindings live
in a separate xcode perl path). Add an PERLLIB_EXTRA variable to hold
a colon-separated list of extra directories to add to the perl path in
git's scripts, as a convenience for packagers.
Requested-by: Dave Borowitz
Signed-off-by: Jonathan Nieder
---
Thanks for reading.
Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e5e7868..67f1754 100644
--- a/Makefile
+++ b/Makefile
@@ -1588,6 +1588,7 @@ PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
PYTHON_PATH_SQ = $(subst ','\'',$(PYTHON_PATH))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
DIFF_SQ = $(subst ','\'',$(DIFF))
+PERLLIB_EXTRA_SQ = $(subst ','\'',$(PERLLIB_EXTRA))
LIBS = $(GITLIBS) $(EXTLIBS)
@@ -1792,10 +1793,12 @@ perl/PM.stamp: FORCE
perl/perl.mak: GIT-CFLAGS GIT-PREFIX perl/Makefile perl/Makefile.PL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)'
prefix='$(prefix_SQ)' $(@F)
-PERL_DEFINES = $(PERL_PATH_SQ)
+PERL_DEFINES = $(PERL_PATH_SQ):$(PERLLIB_EXTRA_SQ)
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl perl/perl.mak GIT-PERL-DEFINES
GIT-VERSION-FILE
$(QUIET_GEN)$(RM) $@ $@+ && \
INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory
instlibdir` && \
+ INSTLIBDIR_EXTRA='$(PERLLIB_EXTRA_SQ)' && \
+ INSTLIBDIR="$$INSTLIBDIR$${INSTLIBDIR_EXTRA:+:$$INSTLIBDIR_EXTRA}" && \
sed -e '1{' \
-e 's|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e 'h' \
--
1.8.4.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: Fwd: Error with git-svn pushing a rename
Andreas Stricker wrote: > svn, Version 1.7.10 (r1485443) > > I tried to reproduce the problem with git version 1.8.4.2 and > Subversion version 1.8.4 (r1534716) with a fresh and pristine > subversion repo and a git-svn clone of it: I didn't manage to > reproduce the rename issue. Then I switched subversion back to > 1.7.10, created both the repo and the git-svn clone, switched > againt to 1.8.4.2 and then got an error. Unfortunately I didn't > check if the subversion perlbindings were regenerated, so I'm > not exactly sure. [...] > It looks like a fresh git svn clone may fix the problem. Yuck. Can you give an exact sequence of steps (including "Upgrade Subversion at this step") to reproduce the problem? That would help immensely --- if at all possible, I would very much like to keep existing git-svn repos working on upgrade. Thanks for your work so far on this. Sincerely, 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: Add a bugzilla website
On Fri, Nov 15, 2013 at 10:40:47AM +0100, ycollette.nos...@free.fr wrote: > And the conclusion is ? No bugzilla tool installed because somebody > want to build a gitbased bugzilla thing ? Personally, I do not want Yet Another Bugzilla Account. A project is significantly less likely to get a patch from me if I have to create an account to report a bug. Most of the patches I send to various projects are for bugs I've experienced and want to provide a fix for, so I send a small number of patches to many projects. I feel that the mailing list workflow ends up working very well for Git and it provides a low barrier to entry for those that want to send just one or two patches for problems that they're experiencing. It also allows me to see and comment on virtually every patch on the list, while ignoring threads I am not interested in, a combination which is difficult to achieve with a web-based bug tracker. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH] transport: Catch non positive --depth option value
On Wed, Nov 13, 2013 at 11:06 PM, "Andrés G. Aragoneses"
wrote:
> Instead of simply ignoring the value passed to --depth
> option when it is zero or negative, now it is caught
> and reported.
>
> This will let people know that they were using the
> option incorrectly (as depth<0 should be simply invalid,
> and under the hood depth==0 didn't mean 'no depth' or
> 'no history' but 'full depth' instead).
'full depth' may be confusing (is it --unshallow?). Other than that
the patch looks fine.
>
> Signed-off-by: Andres G. Aragoneses
> ---
> transport.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/transport.c b/transport.c
> index 7202b77..edd63eb 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -483,6 +483,8 @@ static int set_git_option(struct git_transport_options
> *opts,
> opts->depth = strtol(value, &end, 0);
> if (*end)
> die("transport: invalid depth option '%s'",
> value);
> + if (opts->depth < 1)
> + die("transport: invalid depth option '%s'
> (non positive)", value);
> }
> return 0;
> }
> --
> 1.8.1.2
--
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
[PATCH v2] transport.c: mark push status strings for translation
Mark strings like "[up to date]" passed to print_ref_status() for
translation with N_() instead of _() so they can remain untranslated
in porcelain mode.
While at there, mark some error strings in git push for translation
too.
Signed-off-by: Nguyễn Thái Ngọc Duy
Reviewed-by: Jonathan Nieder
---
builtin/push.c | 8 +++---
transport.c| 81 ++
2 files changed, 52 insertions(+), 37 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 7b1b66c..22e2d4c 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -319,7 +319,7 @@ static int push_with_options(struct transport *transport,
int flags)
if (!is_empty_cas(&cas)) {
if (!transport->smart_options)
- die("underlying transport does not support --%s option",
+ die(_("underlying transport does not support --%s
option"),
CAS_OPT_NAME);
transport->smart_options->cas = &cas;
}
@@ -426,7 +426,7 @@ static int option_parse_recurse_submodules(const struct
option *opt,
if (*flags & (TRANSPORT_RECURSE_SUBMODULES_CHECK |
TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND))
- die("%s can only be used once.", opt->long_name);
+ die(_("%s can only be used once."), opt->long_name);
if (arg) {
if (!strcmp(arg, "check"))
@@ -434,9 +434,9 @@ static int option_parse_recurse_submodules(const struct
option *opt,
else if (!strcmp(arg, "on-demand"))
*flags |= TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND;
else
- die("bad %s argument: %s", opt->long_name, arg);
+ die(_("bad %s argument: %s"), opt->long_name, arg);
} else
- die("option %s needs an argument (check|on-demand)",
+ die(_("option %s needs an argument (check|on-demand)"),
opt->long_name);
return 0;
diff --git a/transport.c b/transport.c
index 7202b77..1fb92a1 100644
--- a/transport.c
+++ b/transport.c
@@ -14,6 +14,7 @@
#include "url.h"
#include "submodule.h"
#include "string-list.h"
+#include "utf8.h"
/* rsync support */
@@ -627,16 +628,23 @@ static void print_ref_status(char flag, const char
*summary, struct ref *to, str
else
fprintf(stdout, "%s\n", summary);
} else {
- fprintf(stderr, " %c %-*s ", flag, TRANSPORT_SUMMARY_WIDTH,
summary);
+ int width = TRANSPORT_SUMMARY_WIDTH;
+ const char *localized_summary = _(summary);
+ /*
+* Compensate for the invisible bytes in utf-8
+* strings. The expression below is guaranteed always
+* positive (or zero in case of ascii strings) because
+* none of the doublewidth characters are ASCII
+* characters.
+*/
+ width += strlen(localized_summary) -
utf8_strwidth(localized_summary);
+ fprintf(stderr, " %c %-*s ", flag, width, localized_summary);
if (from)
fprintf(stderr, "%s -> %s",
prettify_refname(from->name), prettify_refname(to->name));
else
fputs(prettify_refname(to->name), stderr);
- if (msg) {
- fputs(" (", stderr);
- fputs(msg, stderr);
- fputc(')', stderr);
- }
+ if (msg)
+ fprintf(stderr, " (%s)", _(msg));
fputc('\n', stderr);
}
}
@@ -649,11 +657,11 @@ static const char *status_abbrev(unsigned char sha1[20])
static void print_ok_ref_status(struct ref *ref, int porcelain)
{
if (ref->deletion)
- print_ref_status('-', "[deleted]", ref, NULL, NULL, porcelain);
+ print_ref_status('-', N_("[deleted]"), ref, NULL, NULL,
porcelain);
else if (is_null_sha1(ref->old_sha1))
print_ref_status('*',
- (!prefixcmp(ref->name, "refs/tags/") ? "[new tag]" :
- "[new branch]"),
+ (!prefixcmp(ref->name, "refs/tags/") ? N_("[new tag]") :
+N_("[new branch]")),
ref, ref->peer_ref, NULL, porcelain);
else {
char quickref[84];
@@ -664,7 +672,7 @@ static void print_ok_ref_status(struct ref *ref, int
porcelain)
if (ref->forced_update) {
strcat(quickref, "...");
type = '+';
- msg = "forced update";
+ msg = N_("forced update");
} else {
strcat(quickref, "..");
type = ' ';
@@ -678,50 +686,57 @@ static void print_ok_ref_status(struct ref *ref, int
Re: [PATCH] transport.c: mark push status strings for translation
On Thu, Nov 14, 2013 at 6:25 AM, Jonathan Nieder wrote: >> if (from) >> fprintf(stderr, "%s -> %s", >> prettify_refname(from->name), prettify_refname(to->name)); > > I'm not sure this is correct for right-to-left languages. Something > to solve another day. I don't speak rtl languages and don't know the support status for them. But to me rtl on terminal is a terrible idea as it's assumed everywhere that the terminal prints from left to right. Anyway let's wait until a rtl translation comes to git, then we'll have somebody knowledgable about the languages to talk about. -- 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: Fwd: Possible bug report: `git commit -ammend`
On Fri, Nov 15, 2013 at 10:54 PM, Matthieu Moy wrote: > rhys evans writes: > >> I ran `git commit -ammend` on a repo where 1 out of 3 files changed >> were staged for commit. >> >> I would've expected an error to be thrown due to the double typo but >> instead it committed all 3 files with the message 'mend'. >> >> So it looks like it interpreted it as `git commit -a -m 'mend'`. > > Yes. This is a rather widespread convention (e.g. rm -fr == rm -r -f). > Git does a special-case for -amend to avoid confusion: > > $ git commit -amend > error: did you mean `--amend` (with two dashes ?) > > But it did not special-case the double-typo. "-m" taking a string without a space or '=' increases the risk of this typo. If it does require '=' or ' ' after -m then -ammend is more likely to be rejected. Anybody know why we should support -mabc, besides convenient? -- 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: Fwd: Possible bug report: `git commit -ammend`
On Sat, Nov 16, 2013 at 10:28:36AM +0700, Duy Nguyen wrote: > > Yes. This is a rather widespread convention (e.g. rm -fr == rm -r -f). > > Git does a special-case for -amend to avoid confusion: > > > > $ git commit -amend > > error: did you mean `--amend` (with two dashes ?) > > > > But it did not special-case the double-typo. > > "-m" taking a string without a space or '=' increases the risk of this > typo. If it does require '=' or ' ' after -m then -ammend is more > likely to be rejected. Anybody know why we should support -mabc, > besides convenient? For flags with optional arguments, "-m abc" would not work (we do not know if "abc" is the argument or the next flag). An example of such a flag is "git status -uall". We could disallow it for mandatory options, but that would create an inconsistency in the option parsing. Other than that, I think it is mostly convenience and compatibility with other option-parsing systems. -Peff -- 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
