-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 16/12/2012 06:59, Junio C Hamano ha scritto:
I
Manlio Perillo manlio.peri...@gmail.com writes:
This works with a shell.
I'm using Python to write a custom git command.
I would be very surprised if Python lacked a way to spawn a
subprocess
Matt Kraai wrote:
From: Matt Kraai matt.kr...@amo.abbott.com
Signed-off-by: Matt Kraai matt.kr...@amo.abbott.com
---
Makefile | 19 +++
git-compat-util.h | 8 ++--
2 files changed, 25 insertions(+), 2 deletions(-)
snip
diff --git a/git-compat-util.h
On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
entry_count is used in update_one() for two purposes:
1. to skip through the number of processed entries in in-memory index
2. to record the number of entries this
Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano gits...@pobox.com
wrote:
Nicely explained. I wonder if we can also add a piece of test to
the patch 4/4 to demonstrate the issue with CE_REMOVE entries,
though.
A hand crafted one, maybe. I did
On Sat, Dec 15, 2012 at 06:24:09PM +, John Keeping wrote:
I think I'd just render them monospace everywhere. We are very
inconsistent about which form of quotes we use in the documentation (I
think because most of the developers read the source directly and not
the rendered asciidoc).
- because it describes a different form of API than the other api-* documents
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/technical/api-index.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/technical/api-index.sh
Email addresses in documentation are converted into mailto: hyperlinks
in the HTML output and footnotes in man pages. This isn't desirable for
cases where the address is used as an example and is not valid.
Particularly annoying is the example jane@laptop.(none) which appears
in git-shortlog(1)
While investigating Asciidoc's quoting in this thread [1], I noticed
that my system man pages don't display Asciidoc double quoted text
correctly.
[1] http://article.gmane.org/gmane.comp.version-control.git/211533
For example in git-fast-import(1):
Here name is the person’s display name (for
Bold yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right.
Likewise, change the color of the summarized total number of known
Now that we've adopted a traffic lights coloring scheme, yellow is
used for warning messages, so we need to re-color info messages to
something less alarmist. Blue is a universal color for informational
messages; however we are using that for skipped tests in order to
align with the color schemes
This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 85 ++--
1 file changed, 40 insertions(+), 45 deletions(-)
diff
The old output to say not ok - 1 messsage was working by accident
only because the test numbers are optional in TAP.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 4 ++--
t/test-lib.sh| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Skipped tests indicate incomplete test coverage. Whilst this is not a
test failure or other error, it's still not a complete success.
Other testsuite related software like automake, autotest and prove
seem to use blue for skipped tests, so let's follow suit.
Signed-off-by: Adam Spiers
This series of commits attempts to make test output coloring
more intuitive, so that:
- red is only used for things which have gone unexpectedly wrong:
test failures, unexpected test passes, and failures with the
framework,
- yellow is only used for known breakages,
- green is
Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case. As before,
these are run in a subdirectory to avoid disrupting the metrics for
the parent tests.
Signed-off-by:
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this is
an error which is potentially as bad as a failing test, and as such is
no longer portrayed as
John Keeping j...@keeping.me.uk writes:
Email addresses in documentation are converted into mailto: hyperlinks
in the HTML output and footnotes in man pages. This isn't desirable for
cases where the address is used as an example and is not valid.
Particularly annoying is the example
Adam Spiers g...@adamspiers.org writes:
This series of commits attempts to make test output coloring
more intuitive,...
Thanks; I understand that this is to replace the previous one
b465316 (tests: paint unexpectedly fixed known breakages in bold
red, 2012-09-19)---am I correct?
- red is
On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote:
Adam Spiers g...@adamspiers.org writes:
This series of commits attempts to make test output coloring
more intuitive,...
Thanks; I understand that this is to replace the previous one
b465316 (tests: paint unexpectedly
Conscientious newcomers to git development will read SubmittingPatches
and CodingGuidelines, but could easily miss the convention of
prefixing commit messages with a single word identifying the file
or area the commit touches.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
I fell into various newbie pitfalls when submitting my first patches
to git, despite my best attempts to adhere to documented guidelines.
This small patch series attempts to reduce the chances of other
developers making the same mistakes I did.
Adam Spiers (3):
SubmittingPatches: add convention
CodingGuidelines requests that code should be nice to older C compilers.
Since modern gcc can warn on code written using newer dialects such as C99,
it makes sense to take advantage of this by auto-detecting this capability
and enabling it when found.
Signed-off-by: Adam Spiers
The Try to be nice to older C compilers text is clearly a guideline
to be borne in mind whilst coding rather than when submitting patches.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
Documentation/CodingGuidelines | 8
Documentation/SubmittingPatches | 13 -
2 files
It looks like we are tracking the value of TCLTK_PATH in the main
Makefile for no good reason, as this is done in git-gui too and the
GIT-GUI-VARS is not used in the Makefile.
This patch removes the useless code used to do this tracking.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
When make is run, the python scripts are created from *.py files that
are changed to use the python given by PYTHON_PATH. And PYTHON_PATH
is set by default to /usr/bin/python on Linux.
This is nice except when you run make another time setting a
different PYTHON_PATH, because, as the python
Andreas Schwab sch...@linux-m68k.org writes:
s/form/from/
Andreas.
Thanks; will apply.
--
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
Thomas Ackermann th.ac...@arcor.de writes:
- because it describes a different form of API than the other api-* documents
Drop that - ; it is not like you are enumerating many reasons.
It makes me wonder if a more correct fix is to move this document
to the ../howto/ hierarchy.
The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.
For these commands, only options completion was available.
Full support for completion is now implemented, for git commands
The git-completion.bash script was using the git ls-tree command
without the --name-only option, with a sed filter to parse path names;
use the --name-only option, instead.
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
contrib/completion/git-completion.bash | 15 +--
1
The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.
For these commands, only options completion was available.
Full support for completion is now implemented, for git commands
On Fri, Sep 21, 2012 at 12:00:55PM -0700, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
It has been rebased on the latest master, and passed a full test run.
FYI, I applied the attached on top before queuing it in 'pu'.
Points to note:
* We match the underline and
Adam Spiers g...@adamspiers.org writes:
On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote:
Adam Spiers g...@adamspiers.org writes:
This series of commits attempts to make test output coloring
more intuitive,...
Thanks; I understand that this is to replace the previous
Adam Spiers g...@adamspiers.org writes:
Conscientious newcomers to git development will read SubmittingPatches
and CodingGuidelines, but could easily miss the convention of
prefixing commit messages with a single word identifying the file
or area the commit touches.
Signed-off-by: Adam
On Tue, Oct 16, 2012 at 09:12:58AM -0700, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
On Mon, Oct 15, 2012 at 3:31 PM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+For each pathname given via the command-line or from a file via
t/t9902-completion.sh is currently failing for me because I happen to
have a custom shell-script called git-check-email in ~/bin, which is
on my $PATH. This is different to a similar-looking case reported
recently, which was due to an unclean working tree:
Adam Spiers g...@adamspiers.org writes:
If we adopt this approach,...
diff --git a/Makefile b/Makefile
index a49d1db..aae70d4 100644
--- a/Makefile
+++ b/Makefile
@@ -331,8 +331,13 @@ endif
# CFLAGS and LDFLAGS are for the users to override from the command line.
CFLAGS = -g -O2
On Sun, Dec 16, 2012 at 05:52:05PM -0800, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
If we adopt this approach,...
diff --git a/Makefile b/Makefile
index a49d1db..aae70d4 100644
--- a/Makefile
+++ b/Makefile
@@ -331,8 +331,13 @@ endif
# CFLAGS and LDFLAGS are
John Keeping j...@keeping.me.uk writes:
diff --git a/Documentation/git-fast-import.txt
b/Documentation/git-fast-import.txt
index d1844ea..68bca1a 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -427,7 +427,7 @@ they made it.
Here `name` is the
Hi, List
I have two branches in the remote, say, origin/master, origin/foo. Then
when I tried to switch to the remote foo branch, the following two
methods gave me different results:
1. git checkout foo
2. git checkout origin/foo
The first method run silently with success, but the second
Adam Spiers g...@adamspiers.org writes:
OK; I expect these issues with the implementation are all
surmountable. I did not necessarily expect this to be the final
implementation anyhow, as indicated by my comments below the divider
line. However it's not clear to me what you think about the
On 17 December 2012 13:30, Woody Wu narkewo...@gmail.com wrote:
1. git checkout foo
2. git checkout origin/foo
The first method run silently with success, but the second method
complains that I got a 'detached HEAD'. So, I think I don't understand
the difference between 'foo' and
Christian Couder chrisc...@tuxfamily.org writes:
It looks like we are tracking the value of TCLTK_PATH in the main
Makefile for no good reason, as this is done in git-gui too and the
GIT-GUI-VARS is not used in the Makefile.
This was added to the main Makefile when we slurped gitk to our
Manlio Perillo manlio.peri...@gmail.com writes:
The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.
For these commands, only options completion was available.
Hrm, git mv
Manlio Perillo manlio.peri...@gmail.com writes:
The git-completion.bash script was using the git ls-tree command
without the --name-only option, with a sed filter to parse path names;
use the --name-only option, instead.
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
Did you
On 2012-12-17, Andrew Ardill andrew.ard...@gmail.com wrote:
On 17 December 2012 13:30, Woody Wu narkewo...@gmail.com wrote:
1. git checkout foo
2. git checkout origin/foo
The first method run silently with success, but the second method
complains that I got a 'detached HEAD'. So, I think I
On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote:
1. git checkout foo.
By this command, I think I am checking out files in my local branch
named foo, and after that I also switch to the branch. Right?
Correct. Your working directory (files) switch over to whatever your
local
John Keeping j...@keeping.me.uk writes:
I can't see any other uses of the $$ quote in the documentation, so
it's probably worth noting that I've tested this with Asciidoc 8.6.8,
although I can't see anything in the changelog to indicate that
Asciidoc's treatment of it has changed recently.
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill andrew.ard...@gmail.com
wrote:
On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote:
1. git checkout foo.
By this command, I think I am checking out files in my local branch
named foo, and after that I also switch to the branch.
On 17 December 2012 16:30, Tomas Carnecky tomas.carne...@gmail.com wrote:
'git checkout foo' has special meaning if a local branch with that name
doesn't exist but there is a remote branch with that name. In that case it's
equivalent to: git checkout -t -b foo origin/foo. Because that's what
On Sun, Dec 16, 2012 at 11:52 PM, Andrew Ardill andrew.ard...@gmail.com wrote:
This is true, but I don't think it is documented.
I noticed this, too. I was just about to send a patch to add this.
Chris
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
This is response to the questions posed in:
http://thread.gmane.org/gmane.comp.version-control.git/211624
It doesn't seem like the behavior implemented in 70c9ac2 is documented.
Chris Rorvick (2):
Documentation/git-checkout.txt: clarify usage
Documentation/git-checkout.txt: document
The forms of checkout that do not take a path are lumped together in the
DESCRIPTION section, but the description for this group is dominated by
explanation of the -b|-B form. Split these apart for more clarity.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-checkout.txt |
Document the behavior implemented in 70c9ac2 (DWIM git checkout
frotz to git checkout -b frotz origin/frotz).
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-checkout.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/git-checkout.txt
On 2012-12-17, Andrew Ardill andrew.ard...@gmail.com wrote:
On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote:
1. git checkout foo.
By this command, I think I am checking out files in my local branch
named foo, and after that I also switch to the branch. Right?
Correct. Your
On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote:
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill
andrew.ard...@gmail.com wrote:
On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote:
1. git checkout foo. By this command, I think I am checking out
files in my local
When make is run, the python scripts are created from *.py files that
are changed to use the python given by PYTHON_PATH. And PYTHON_PATH
is set by default to /usr/bin/python on Linux.
This is nice except when you run make another time setting a
different PYTHON_PATH, because, as the python
It looks like we are tracking the value of TCLTK_PATH in the main
Makefile for no good reason, as this is done in git-gui too and the
GIT-GUI-VARS is not used in the Makefile.
This patch removes the useless code used to do this tracking.
Maybe this code should have been moved to
In 62ba514 (Move gitk to its own subdirectory, 2007-11-17) some
code used to track TCLTK_PATH was left in the main Makefile instead
of being moved to the new Makefile that was created in gitk-git/.
The code left in the main Makefile should have been removed by a
previous patch in the same series
This is clearer to many people this way.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Makefile | 10 +-
git-gui/Makefile | 6 +++---
gitk-git/Makefile | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Makefile b/Makefile
index
Chris Rorvick ch...@rorvick.com writes:
The forms of checkout that do not take a path are lumped together in the
DESCRIPTION section, but the description for this group is dominated by
explanation of the -b|-B form. Split these apart for more clarity.
Signed-off-by: Chris Rorvick
Chris Rorvick ch...@rorvick.com writes:
Document the behavior implemented in 70c9ac2 (DWIM git checkout
frotz to git checkout -b frotz origin/frotz).
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-checkout.txt | 8
1 file changed, 8 insertions(+)
diff
On Mon, 17 Dec 2012 07:02:46 +, Woody Wu narkewo...@gmail.com wrote:
On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote:
'git checkout foo' has special meaning if a local branch with that
name doesn't exist but there is a remote branch with that name. In
that case it's
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch is 1.8.1-rc2; hopefully we can go
final around the end of next week.
Many topics are getting into good shape in
From: Junio C Hamano gits...@pobox.com
Christian Couder chrisc...@tuxfamily.org writes:
It looks like we are tracking the value of TCLTK_PATH in the main
Makefile for no good reason, as this is done in git-gui too and the
GIT-GUI-VARS is not used in the Makefile.
This was added to the
On 17 December 2012 18:21, Junio C Hamano gits...@pobox.com wrote:
does it format well (I didn't check)?
It applied cleanly for me on latest master, and the output looked
consistent with existing documentation.
Regards,
Andrew Ardill
--
To unsubscribe from this list: send the line unsubscribe
Andrew Ardill andrew.ard...@gmail.com writes:
On 17 December 2012 18:21, Junio C Hamano gits...@pobox.com wrote:
does it format well (I didn't check)?
It applied cleanly for me on latest master, and the output looked
consistent with existing documentation.
Thanks.
--
To unsubscribe from
Christian Couder chrisc...@tuxfamily.org writes:
From: Junio C Hamano gits...@pobox.com
Christian Couder chrisc...@tuxfamily.org writes:
It looks like we are tracking the value of TCLTK_PATH in the main
Makefile for no good reason, as this is done in git-gui too and the
GIT-GUI-VARS is
Christian Couder chrisc...@tuxfamily.org writes:
In 62ba514 (Move gitk to its own subdirectory, 2007-11-17) some
code used to track TCLTK_PATH was left in the main Makefile instead
of being moved to the new Makefile that was created in gitk-git/.
The code left in the main Makefile should
On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote:
On Mon, 17 Dec 2012 07:02:46 +, Woody Wu narkewo...@gmail.com wrote:
On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote:
'git checkout foo' has special meaning if a local branch with that
name doesn't exist but there
On Wed, 12 Dec 2012 11:57:47 -0800
Junio C Hamano gits...@pobox.com wrote:
Yann Dirson dir...@bertin.fr writes:
In this respect, they seem to be
lacking a few features, when compared to replace refs, but they have
different
uses, ...
Not reallyl; grafts were old hack whose
70 matches
Mail list logo
