Commit 7dff9b3 (Support 'raw' date format) added a raw date format.
Update the git-for-each-ref documentation to include this.
Signed-off-by: John Keeping
---
On Mon, Jan 21, 2013 at 05:02:52PM +0100, Michael Haggerty wrote:
> Shouldn't "raw" be preceded with a
Commit 7dff9b3 (Support 'raw' date format) added a raw date format.
Update the git-for-each-ref documentation to include this.
Signed-off-by: John Keeping
---
Documentation/git-for-each-ref.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gi
On Mon, Jan 21, 2013 at 07:43:40AM -0500, Eric S. Raymond wrote:
> John Keeping :
>> I also disagree that cvsps outputs commits *newer* than T since it will
>> also output commits *at* T, which is what I changed with the patch in my
>> previous message.
>
> Ah.
On Mon, Jan 21, 2013 at 06:28:53AM -0500, Eric S. Raymond wrote:
> John Keeping :
>> But this is nothing more than a sticking plaster that happens to do
>> enough in this particular case
>
> I'm beginning to think that's the best outcome we ever get in this
> p
On Sun, Jan 20, 2013 at 06:20:08PM -0500, Eric S. Raymond wrote:
> John Keeping :
>> I don't think there is any way to solve this without giving cvsps more
>> information, probably the last commit time for all git branches, but
>> perhaps I'm missing a fast-import f
I've now spent some time looking at git-cvsimport-3.py from
jc/cvsimport-upgrade and made some progress in making it pass more of
the Git test suite (my work in progress is at [1]).
However, I think there is a fundamental problem with the way it handles
incremental imports and I'm hoping someone w
On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
>> git-p4 supports Python 2.6 and later versions of Python 2. Since Python
>> 2.8 will never exist [1], it is most concise to just list the supported
>> versions.
>
> Thanks;
On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>> On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
>>> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping wrote:
>>>> On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Ror
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping wrote:
>> On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
>>> These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
>>
On Sun, Jan 20, 2013 at 03:05:18PM +0100, Stephen Kelly wrote:
> I find the fixup command during an interactive rebase useful.
>
> Sometimes when cleaning up a branch, I end up in a situation like this:
>
> pick 07bc3c9 Good commit.
> pick 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 A
in that
case Python 2 will interpret '()' as an empty tuple and print it as
'()'; inserting an empty string fixes this.
Signed-off-by: John Keeping
Acked-by: Sverre Rabbelier
---
git-remote-testpy.py | 28 ++--
1 file changed, 14 insertions(+), 14 dele
: fix
race when spawning fast-import).
Signed-off-by: John Keeping
---
git-remote-testpy.py | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index 197b7be..5dbf1cc 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
d by git-remote-testpy for its git mirror
of the remote repository, but this tool should not have any serious
users as it is used primarily to test the Python remote helper
framework.
The use of encode() moves the required Python version forward to 2.0.
Signed-off-by: John Keeping
---
git-remot
The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).
Signed-off-by: John Keeping
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Using the approach detailed in the Python documentation[1], run 2to3 on
the code as part of the build if building with Python 3.
The code itself requires no changes to convert cleanly.
[1] http://docs.python.org/3.3/howto/pyporting.html#during-installation
Signed-off-by: John Keeping
Acked-by
When different version of python are used to build via distutils, the
behaviour can change. Detect changes in version and pass --force in
this case.
Signed-off-by: John Keeping
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files changed, 8 insertions
ed before Python 2.7 so in order to maintain compatibility
with the maximum range of Python versions we use an explicit call to
encode().
Signed-off-by: John Keeping
---
git_remote_helpers/git/importer.py | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/git_remote_hel
Change inline Python to call "print" as a function not a statement.
This is harmless because Python 2 will see the parentheses as redundant
grouping but they are necessary to run this code with Python 3.
Signed-off-by: John Keeping
---
git_remote_helpers/Makefile | 2 +-
1 file
th Python 3) to point at
Python documentation instead of the Python wiki.
- Add a comment in patch 7 (git-remote-testpy: don't do unbuffered text
I/O), as suggested by Sverre.
John Keeping (8):
git_remote_helpers: Allow building with Python 3
git_remote_helpers: fix input when ru
Hi Chris,
On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
> These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
> tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent
> to Eric (fixes revision map.)
Did you post the fix for the revision map pub
git-p4 supports Python 2.6 and later versions of Python 2. Since Python
2.8 will never exist [1], it is most concise to just list the supported
versions.
[1] http://www.python.org/dev/peps/pep-0404/
Signed-off-by: John Keeping
Acked-by: Pete Wyckoff
---
Since v1:
- Fixed a typo in the commit
On Sat, Jan 19, 2013 at 05:31:35PM -0800, David Aguilar wrote:
> On Sat, Jan 19, 2013 at 4:01 AM, John Keeping wrote:
>> Since Pyhton
>> 2.8 will never exist [1]
>
> Tiny typo: Python misspelled as Pyhton
Thanks. v2 on its way.
John
--
To unsubscribe from thi
git-p4 supports Python 2.6 and later versions of Python 2. Since Pyhton
2.8 will never exist [1], it is most concise to just list the supported
versions.
[1] http://www.python.org/dev/peps/pep-0404/
Signed-off-by: John Keeping
---
INSTALL | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Fri, Jan 18, 2013 at 02:26:06PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>> On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
>>> These early versions may not be unstable in the "this does not
>>> behave as specified in the langu
On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>> As more people have started trying to support Python 3 in the wild, it
>> has become clear that it is often easier to have a single codebase that
>> works with both Python 2 and Pytho
On Fri, Jan 18, 2013 at 11:04:15AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
>> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
>> index 69f7e9b..baf3b41 100644
>> --- a/Documentation/CodingGuidelines
>> +++ b/Documentation
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [2], there isn't any disagreement about using
2.6 as a base (see also [3]).
- T
On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote:
> On Thu, Jan 17, 2013 at 10:53 AM, John Keeping wrote:
> > [1] http://wiki.python.org/moin/PortingPythonToPy3k
>
> This link seems dead.
Looks like the Python wiki is down [1].
I'll replace it with [2]
On Thu, Jan 17, 2013 at 02:24:37PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
>> You're right - I think we need to add ", errors='replace'" to the call
>> to encode.
>
> Of if it is used just as a opaque token, you can .encode(&#x
--git-dir=/over/there.git svn find-rev HEAD)
Signed-off-by: John Keeping
---
Documentation/git-svn.txt | 10 ++
git-svn.perl | 12 ++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index
On Thu, Jan 17, 2013 at 09:00:48PM +, John Keeping wrote:
> On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>>
>>> Under Python 3 'hasher.update(...)' must take a byte string and not a
>>> unicode string. Ex
On Thu, Jan 17, 2013 at 12:36:33PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
>> Under Python 3 'hasher.update(...)' must take a byte string and not a
>> unicode string. Explicitly encode the argument to this method as UTF-8
>> so that this code work
in that
case Python 2 will interpret '()' as an empty tuple and print it as
'()'; inserting an empty string fixes this.
Signed-off-by: John Keeping
---
git-remote-testpy.py | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/gi
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method as UTF-8
so that this code works under Python 3.
This moves the required Python version forward to 2.0.
Signed-off-by: John Keeping
---
git-remote-tes
: fix
race when spawning fast-import).
Signed-off-by: John Keeping
---
git-remote-testpy.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index f8dc196..bc5e3cf 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).
Signed-off-by: John Keeping
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Using the approach detailed on the Python wiki[1], run 2to3 on the code
as part of the build if building with Python 3.
The code itself requires no changes to convert cleanly.
[1] http://wiki.python.org/moin/PortingPythonToPy3k
Signed-off-by: John Keeping
---
git_remote_helpers/setup.py | 10
When different version of python are used to build via distutils, the
behaviour can change. Detect changes in version and pass --force in
this case.
Signed-off-by: John Keeping
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files changed, 8 insertions
ed before Python 2.7 so in order to maintain compatibility
with the maximum range of Python versions we use an explicit call to
encode().
Signed-off-by: John Keeping
---
git_remote_helpers/git/importer.py | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/git_remote_hel
Change inline Python to call "print" as a function not a statement.
This is harmless because Python 2 will see the parentheses as redundant
grouping but they are necessary to run this code with Python 3.
Signed-off-by: John Keeping
---
git_remote_helpers/Makefile | 2 +-
1 file
ant
git-p4"?
Changes since v1:
* rebased on master after fc/remote-testgit-feature-done was merged,
leading to an extra change in patch 8 (git-remote-testpy: call print
as a function)
* changed patch 2 (git_remote_helpers: fix input when running under
Python 3) to treat ref names as byt
On Thu, Jan 17, 2013 at 08:44:20AM -0800, Linus Torvalds wrote:
> On Thu, Jan 17, 2013 at 3:00 AM, John Keeping wrote:
>>
>> There's also a warning that triggers with clang 3.2 but not clang trunk,
>> which
>> I think is a legitimate warning - perhaps someone
use array indexing to silence this warning
prefix = COLONS + offset;
^
& [ ]
Suppress this by making the suggested change.
Signed-off-by: John Keeping
---
On Thu, Jan 17, 2013 at 11:00:08AM +, John Keepi
On Thu, Jan 17, 2013 at 11:32:39AM +0100, Antoine Pelisse wrote:
> John, could you confirm that you trigger the -Wtautological-compare
> warning with your version of clang ?
Yes, the warning is still there with both 3.2 and a recent trunk build
but this patch squelches it.
> And that this patch m
On Wed, Jan 16, 2013 at 07:01:37PM +, John Keeping wrote:
> On Wed, Jan 16, 2013 at 10:24:49AM -0800, Jeff King wrote:
> > On Wed, Jan 16, 2013 at 06:22:40PM +0000, John Keeping wrote:
> >
> > Thanks for checking. I'd rather squelch the warning completely (as in my
On Wed, Jan 16, 2013 at 11:47:22PM +0100, Antoine Pelisse wrote:
> clang incorrectly reports a constant conversion warning (implicit
> truncation to bit field) when using the "flag &= ~FLAG" form, because
> ~FLAG needs to be truncated.
>
> Convert this form to "flag = flag & ~FLAG" fixes the issue
On Wed, Jan 16, 2013 at 10:24:49AM -0800, Jeff King wrote:
> On Wed, Jan 16, 2013 at 06:22:40PM +0000, John Keeping wrote:
>
> > > > [1] http://llvm.org/bugs/show_bug.cgi?id=13747
> > >
> > > Yeah, I think it is exactly the same issue, and the fix they mentio
On Wed, Jan 16, 2013 at 10:15:58AM -0800, Jeff King wrote:
> On Wed, Jan 16, 2013 at 06:12:03PM +0000, John Keeping wrote:
>
> > On Wed, Jan 16, 2013 at 10:00:42AM -0800, Jeff King wrote:
> > > It is not about the macro itself, but rather the callsites that do not
> >
On Wed, Jan 16, 2013 at 10:00:42AM -0800, Jeff King wrote:
> It is not about the macro itself, but rather the callsites that do not
> return error, but call it for its printing side effect. It seems that
> clang -Wunused-value is OK with unused values from functions being
> discarded, but not with
On Wed, Jan 16, 2013 at 06:12:57PM +0100, Antoine Pelisse wrote:
> FWIW, I also happen to have the warning:
>
> advice.c:69:2: warning: expression result unused [-Wunused-value]
> error("'%s' is not possible because you have unmerged files.", me);
> ^~~~
On Wed, Jan 16, 2013 at 01:45:36PM +0100, Michael J Gruber wrote:
> John Keeping venit, vidit, dixit 16.01.2013 11:42:
>> On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
>>> The current output of "git remote -v" does not distinguish between
>>>
On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
> The current output of "git remote -v" does not distinguish between
> explicitly configured push URLs and those coming from fetch lines.
>
> Revise the output so so that URLs are distinguished by their labels:
>
> (fetch): fetch c
On Tue, Jan 15, 2013 at 07:03:16PM -0500, Pete Wyckoff wrote:
> j...@keeping.me.uk wrote on Tue, 15 Jan 2013 22:40 +:
>> This is what keeping the refs as byte strings looks like.
>
> As John knows, it is not possible to interpret text from a byte
> string without talking about the character en
On Sun, Jan 13, 2013 at 05:52:38PM +, John Keeping wrote:
> On Sun, Jan 13, 2013 at 12:14:02PM -0500, Pete Wyckoff wrote:
>> j...@keeping.me.uk wrote on Sun, 13 Jan 2013 16:26 +:
>>> On Sat, Jan 12, 2013 at 06:30:44PM -0500, Pete Wyckoff wrote:
>>> > j...@keep
ed before Python 2.7 so in order to maintain compatibility
with the maximum range of Python versions we use an explicit call to
encode().
Signed-off-by: John Keeping
---
On Tue, Jan 15, 2013 at 02:04:29PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>>> That really feels wrong.
On Tue, Jan 15, 2013 at 12:51:13PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>> Although 2to3 will fix most issues in Python 2 code to make it run under
>> Python 3, it does not handle the new strict separation between byte
>> strings and unicode strings. The
eference.c#L261
[2]
https://github.com/libgit2/pygit2/blob/e34911b63e5d2266f9f72a4e3f32e27b13190feb/include/pygit2/utils.h#L55
Signed-off-by: John Keeping
---
I think this is in fact the best way to handle this, and I hope the
above description clarified why I don't think we want to tre
On Mon, Jan 14, 2013 at 01:06:16PM +0100, Matthieu Moy wrote:
> George Karpenkov writes:
>> I've managed to corrupt my very valuable repository with a recursive
>> sed which went wrong.
>> I wanted to convert all tabs to spaces with the following command:
>>
>> find ./ -name '*.*' -exec sed -i 's/
On Mon, Jan 14, 2013 at 05:48:18AM +0100, Michael Haggerty wrote:
> On 01/13/2013 05:17 PM, John Keeping wrote:
>> On Sun, Jan 13, 2013 at 04:26:39AM +0100, Michael Haggerty wrote:
>>> On 01/12/2013 08:23 PM, John Keeping wrote:
>>>> Although 2to3 will fix most issu
On Sun, Jan 13, 2013 at 12:14:02PM -0500, Pete Wyckoff wrote:
> j...@keeping.me.uk wrote on Sun, 13 Jan 2013 16:26 +:
>> On Sat, Jan 12, 2013 at 06:30:44PM -0500, Pete Wyckoff wrote:
>> > j...@keeping.me.uk wrote on Sat, 12 Jan 2013 19:23 +:
>> >> When different version of python are used t
On Sun, Jan 13, 2013 at 11:40:45AM -0500, Pete Wyckoff wrote:
> j...@keeping.me.uk wrote on Sun, 13 Jan 2013 00:41 +:
>> On Sat, Jan 12, 2013 at 06:43:04PM -0500, Pete Wyckoff wrote:
>> > Can you give me some hints about the byte/unicode string issues
>> > in git-p4.py? There's really only one
On Sat, Jan 12, 2013 at 04:27:36PM +0100, Michael Haggerty wrote:
>> Even if we were to rip out the fallback code that uses the 2.7-only
>> subprocess.check_output() on "cvsps -V", the function is also used
>> for doing the real work interacting with cvsps-3.x, so I think this
>> patch will be
On Sat, Jan 12, 2013 at 06:30:44PM -0500, Pete Wyckoff wrote:
> j...@keeping.me.uk wrote on Sat, 12 Jan 2013 19:23 +:
>> When different version of python are used to build via distutils, the
>> behaviour can change. Detect changes in version and pass --force in
>> this case.
>[..]
>> diff --gi
On Sun, Jan 13, 2013 at 04:26:39AM +0100, Michael Haggerty wrote:
> On 01/12/2013 08:23 PM, John Keeping wrote:
>> Although 2to3 will fix most issues in Python 2 code to make it run under
>> Python 3, it does not handle the new strict separation between byte
>> strings and un
On Sun, Jan 13, 2013 at 12:41:30AM +, John Keeping wrote:
> On Sat, Jan 12, 2013 at 06:43:04PM -0500, Pete Wyckoff wrote:
>> Can you give me some hints about the byte/unicode string issues
>> in git-p4.py? There's really only one place that does:
>>
>>
tests pass with python3 except t98* (git-p4), but
>> there are a couple of topics in-flight which will affect that
>> (fc/remote-testgit-feature-done and er/replace-cvsimport).
>>
>> John Keeping (8):
>> git_remote_helpers: Allow building with Python 3
>> git_remo
in that
case Python 2 will interpret '()' as an empty tuple and print it as
'()'; inserting an empty string fixes this.
Signed-off-by: John Keeping
---
git-remote-testpy.py | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/git-re
: fix
race when spawning fast-import).
Signed-off-by: John Keeping
---
git-remote-testpy.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index 58aa1ae..815222f 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method as UTF-8
so that this code works under Python 3.
This moves the required Python version forward to 2.0.
Signed-off-by: John Keeping
---
git-remote-tes
The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).
Signed-off-by: John Keeping
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Using the approach detailed on the Python wiki[1], run 2to3 on the code
as part of the build if building with Python 3.
The code itself requires no changes to convert cleanly.
[1] http://wiki.python.org/moin/PortingPythonToPy3k
Signed-off-by: John Keeping
---
git_remote_helpers/setup.py | 10
When different version of python are used to build via distutils, the
behaviour can change. Detect changes in version and pass --force in
this case.
Signed-off-by: John Keeping
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files changed, 8 insertions
string into a unicode
string. In this instance, use the locale under which the application is
running.
Signed-off-by: John Keeping
---
git_remote_helpers/git/importer.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git_remote_helpers/git/importer.py
b/git_remote_helpers/git
Change inline Python to call "print" as a function not a statement.
This is harmless because Python 2 will see the parentheses as redundant
grouping but they are necessary to run this code with Python 3.
Signed-off-by: John Keeping
---
git_remote_helpers/Makefile | 2 +-
1 file
o be decoded to unicode.
With these patches all tests pass with python3 except t98* (git-p4), but
there are a couple of topics in-flight which will affect that
(fc/remote-testgit-feature-done and er/replace-cvsimport).
John Keeping (8):
git_remote_helpers: Allow building with Python 3
git_remo
Commit 00d3947 (Teach --wrap to only indent without wrapping) added
special behaviour for a width of zero in the '-w' argument to
'git-shortlog' but this was not documented. Fix this.
Signed-off-by: John Keeping
---
Documentation/git-shortlog.txt | 3 +++
1 file changed, 3
The options in git-fast-import(1) are not currently arranged in a
logical order, which has caused the '--done' options to be documented
twice (commit 3266de10).
Rearrange them into logical groups under subheadings.
Suggested-by: Jonathan Nieder
Signed-off-by: John Keeping
---
Doc
=> 'Performance and Compression Tuning'
* '--export-pack-edges' moves to 'Performance and Compression Tuning'
* '--cat-blob-fd' moves to 'Options for Frontends'
John Keeping (2):
git-fast-import(1): combine documentation of --[no-]relative
The descriptions of '--relative-marks' and '--no-relative-marks' make
more sense when read together instead of as two independent options.
Combine them into a single description block.
Signed-off-by: John Keeping
---
Documentation/git-fast-import.txt | 10 -
The '--done' option to git-fast-import is documented twice in its manual
page. Combine the best bits of each description, keeping the location
of the instance that was added first.
Signed-off-by: John Keeping
---
The commit description gained some noise in v2; this version should be
On Tue, Jan 08, 2013 at 06:54:09PM +0100, Manlio Perillo wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Il 05/01/2013 21:23, Marc Khouzam ha scritto:
>> [...]
>> 4- Completion choices include their entire path, which is not what bash does
>> by default. For example:
>>> cd git/cont
On Sat, Jan 05, 2013 at 04:06:52PM +, John Keeping wrote:
The '--done' option to git-fast-import is documented twice in its manual
page. Combine the best bits of each description, keeping the location
of the instance that was added first.
Signed-off-by: John Keeping
---
Change
On Sun, Jan 06, 2013 at 06:42:16PM -0800, Junio C Hamano wrote:
> * jk/maint-fast-import-doc-dedup-done (2013-01-05) 1 commit
> - git-fast-import(1): remove duplicate "--done" option
>
> Will merge to 'next' and 'master' as a quick "oops" fix.
>
> The "logical order" reorganization can come af
On Sun, Jan 06, 2013 at 05:51:09AM -0800, Jonathan Nieder wrote:
> John Keeping wrote:
>> I left the "Semantics of execution" options with the general options
>> since I couldn't think of a sensible heading
>
> Neat trick. :)
I took inspiration from git-pull
#x27;, but I think the result is reasonable.
-- <8 --
The options in git-fast-import(1) are not currently arranged in a
logical order, which has caused the '--done' options to be documented
twice (commit 3266de10).
Rearrange them into logical groups under subheadings.
While doing this
built
> when asciidoc.conf changes and not just the manual pages from
> unchanged XML, and move the dependencies from a recipeless rule to the
> rules with commands that use asciidoc.conf to make the dependencies
> easier to understand and maintain.
>
> Reported-by: John Keeping
&g
-by: John Keeping
---
Documentation/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index e53d333..71d2b4a 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -178,7 +178,7 @@ all: html man
html
The "--done" option to git-fast-import is documented twice in its manual
page. Combine the best bits of each description, keeping the location
of the instance that was added first.
Signed-off-by: John Keeping
---
I'm guessing that the reason the option was documented again (in
On Sun, Dec 16, 2012 at 09:29:24PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>> Here `` is the person's display name (for example
>> ``Com M Itter'') and `` is the person's email address
>> -(``c...@example.com''). `LT` a
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
ess monospaced so that it
matches the block examples surrounding that paragraph.
Helped-by: Jeff King
Signed-off-by: John Keeping
---
On Sun, Dec 16, 2012 at 07:04:05AM -0500, Jeff King wrote:
> Furthermore, the right way to suppress
> expansion of macros is with a backslash escape.
[snipp
On Sat, Dec 15, 2012 at 12:20:18PM -0500, Jeff King wrote:
> On Sat, Dec 15, 2012 at 03:03:15PM +0000, John Keeping wrote:
>> Mail addresses in documentation are converted into mailto: hyperlinks in
>> the HTML output and footnotes in man pages. This isn't desirable for
>&g
that it
matches the block examples surrounding that paragraph.
Signed-off-by: John Keeping
---
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
801 - 893 of 893 matches
Mail list logo
