-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 16/12/2012 06:59, Junio C Hamano ha scritto:
> I
> Manlio Perillo 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 with an enviro
Matt Kraai wrote:
From: Matt Kraai
Signed-off-by: Matt Kraai
---
Makefile | 19 +++
git-compat-util.h | 8 ++--
2 files changed, 25 insertions(+), 2 deletions(-)
snip
diff --git a/git-compat-util.h b/git-compat-util.h
index 2e79b8a..6c588ca 100644
--- a/git-com
Signed-off-by: Thomas Ackermann
---
Documentation/technical/api-index-skel.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/technical/api-index-skel.txt
b/Documentation/technical/api-index-skel.txt
index af7cc2e..730cfac 100644
--- a/Documentation/technical/api-index-skel.
s/form/from/
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kerne
On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy 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 cache-tree covers on disk
>>
>>
Nguyen Thai Ngoc Duy wrote:
>On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano
>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 not attempt to recreate it
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 asc
- because it describes a different form of API than the other api-* documents
Signed-off-by: Thomas Ackermann
---
Documentation/technical/api-index.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/technical/api-index.sh
b/Documentation/technical/api-ind
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 is the person’s display name (for exam
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
breakage
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 scheme
This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.
Signed-off-by: Adam Spiers
---
t/t-basic.sh | 85 ++--
1 file changed, 40 insertions(+), 45 deletions(-)
diff --git a/t/t-basi
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
---
t/t-basic.sh | 4 ++--
t/test-lib.sh| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basi
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
---
t/te
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 only
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: A
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 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 "jane@laptop.(none)"
Adam Spiers 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 only used for thin
On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
> Adam Spiers 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
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
---
Documentation/SubmittingPatches | 8 ++
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
---
If we adopt th
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
---
Documentation/CodingGuidelines | 8
Documentation/SubmittingPatches | 13 -
2 files changed, 8 insert
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
---
.gitignore | 1 -
Ma
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 script
Andreas Schwab 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 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.
>
> Signed-off-by: Thomas Ac
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 where
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
---
contrib/completion/git-completion.bash | 15 +--
1 file changed, 1 insertion(
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 where
On Fri, Sep 21, 2012 at 12:00:55PM -0700, Junio C Hamano wrote:
> Adam Spiers 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 the title of
Adam Spiers writes:
> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
>> Adam Spiers 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 unexpectedl
Adam Spiers 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 Spiers
> ---
> D
On Tue, Oct 16, 2012 at 09:12:58AM -0700, Junio C Hamano wrote:
> Adam Spiers writes:
> > On Mon, Oct 15, 2012 at 3:31 PM, Junio C Hamano wrote:
> >> Nguyễn Thái Ngọc Duy writes:
> >>> +For each pathname given via the command-line or from a file via
> >>> +`--stdin`, this command will list the
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:
http://thread.gmane.org/gmane.comp.ver
Adam Spiers 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 -Wall
> +GCC_DE
On Sun, Dec 16, 2012 at 05:52:05PM -0800, Junio C Hamano wrote:
> Adam Spiers 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 t
John Keeping 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 `` is the person's displ
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 method
Adam Spiers 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 idea in
> princi
On 17 December 2012 13:30, Woody Wu 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 'origin/foo'. Can someon
Christian Couder 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
project at the top-level,
Manlio Perillo 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 CO" completes it to "CO
Manlio Perillo 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
> ---
Did you miss the different handling between blobs and
On 2012-12-17, Andrew Ardill wrote:
> On 17 December 2012 13:30, Woody Wu 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 differenc
On 17 December 2012 16:06, Woody Wu 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 branch 'foo' points to
John Keeping 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.
Thanks.
> Do
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill
wrote:
> On 17 December 2012 16:06, Woody Wu 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 dire
On 17 December 2012 16:30, Tomas Carnecky 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 people
> usually want.
On Sun, Dec 16, 2012 at 11:52 PM, Andrew Ardill 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 majord...@vger.kernel
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 70c9ac
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
---
Documentation/git-checkout.txt | 26 ++
Document the behavior implemented in 70c9ac2 (DWIM "git checkout
frotz" to "git checkout -b frotz origin/frotz").
Signed-off-by: Chris Rorvick
---
Documentation/git-checkout.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkou
On 2012-12-17, Andrew Ardill wrote:
> On 17 December 2012 16:06, Woody Wu 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
On 2012-12-17, Tomas Carnecky wrote:
> On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill
> wrote:
>> On 17 December 2012 16:06, Woody Wu 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
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 script
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 gitk-git/Makefile
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 a
This is clearer to many people this way.
Signed-off-by: Christian Couder
---
Makefile | 10 +-
git-gui/Makefile | 6 +++---
gitk-git/Makefile | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Makefile b/Makefile
index 7db8445..e055c9a 100644
--- a/Makefil
Chris Rorvick 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
> ---
> Documentation
Chris Rorvick writes:
> Document the behavior implemented in 70c9ac2 (DWIM "git checkout
> frotz" to "git checkout -b frotz origin/frotz").
>
> Signed-off-by: Chris Rorvick
> ---
> Documentation/git-checkout.txt | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/git-
On Mon, 17 Dec 2012 07:02:46 +, Woody Wu wrote:
> On 2012-12-17, Tomas Carnecky 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/
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
>
> Christian Couder 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 gi
On 17 December 2012 18:21, Junio C Hamano 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 git" in
the body
Andrew Ardill writes:
> On 17 December 2012 18:21, Junio C Hamano 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 this list: send the line "unsubscribe
Christian Couder writes:
> From: Junio C Hamano
>>
>> Christian Couder 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
Christian Couder 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 have been removed by a
On 2012-12-17, Tomas Carnecky wrote:
> On Mon, 17 Dec 2012 07:02:46 +, Woody Wu wrote:
>> On 2012-12-17, Tomas Carnecky 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 e
On Wed, 12 Dec 2012 11:57:47 -0800
Junio C Hamano wrote:
> Yann Dirson 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 use is still supported
72 matches
Mail list logo
