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
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
* ycollette.nos...@free.fr 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 ...
And the conclusion is ? No bugzilla tool installed because somebody want to
build a gitbased bugzilla thing ?
YC
- Mail original -
De: Damien Wyart damien.wy...@gmail.com
À: ycollette nospam ycollette.nos...@free.fr
Cc: git@vger.kernel.org
Envoyé: Vendredi 15 Novembre 2013 09:53:26
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
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
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
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
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
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
Condense the two-step setup into one step, and give it an appropriate
name.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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
'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.
Use rev-parse in its place, making it easier for future patches to
modify the test script.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t6300-for-each-ref.sh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t6300-for-each-ref.sh
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 artag...@gmail.com
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c
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
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
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
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
rhys evans rhys.ev...@ft.com 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
On 15 November 2013 01:51, Konstantin Khomoutov
flatw...@users.sourceforge.net 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
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
Hi,
Andrew Ardill wrote:
On 15 November 2013 01:51, Konstantin Khomoutov
flatw...@users.sourceforge.net 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
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
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
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
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
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
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
On Wed, Nov 13, 2013 at 11:06 PM, Andrés G. Aragoneses
kno...@gmail.com 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 depth0 should be
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 pclo...@gmail.com
Reviewed-by:
On Thu, Nov 14, 2013 at 6:25 AM, Jonathan Nieder jrnie...@gmail.com 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
On Fri, Nov 15, 2013 at 10:54 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
rhys evans rhys.ev...@ft.com 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
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
32 matches
Mail list logo
