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
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 me
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
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
---
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 i
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
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 s
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/Make
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 co
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 unsubs
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 alway
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 g
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 need
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 co
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
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/majordom
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.
>
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 mu
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 d
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
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 +
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
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 inclu
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 w
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
---
'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.
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 eventu
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: al
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 workflo
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 namespac
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.
* 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-co
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 obs
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 namespac
34 matches
Mail list logo
