Making the dashed lines longer was unnecessary and I will remove this.
There were in general the following "layout problems" I encountered while
trying to create git-doc.pdf:
- Wrong sectioning syntax (e.g. "===" instead of "---")
- Left-over shell scripting commands (in some release notes fil
There are "patched QT" and "unpatched QT" versions of wkhtmltopdf
(see http://code.google.com/p/wkhtmltopdf/). I am using V0.9.9 for Windows
which is "patched QT".
There is one drawback with wkhtmltopdf: At least on my Netbook (Win7 64bit,
Pentium 1.5GHz) it is very slow. It takes more than 3 hrs
Hi Julio.
No, i don't know this message before. Difficult that can be related to
a recent glibc change, i think. Perhaps eglibc ? I tomorrow take a
look, i am on travel now.
Best
2012/10/6, Junio C Hamano :
> Ramsay Jones writes:
>
>> The malloc checks can be disabled using the TEST_NO_MALLOC_CH
Jens Lehmann wrote:
> Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
>> Currently, the diff code does not differentiate between an explicit
>> '--submodule=short' being passed, and no submodule option being passed
>> on the command line. Making this differentiation will be important
>> when th
Junio C Hamano wrote:
> Thomas Ferris Nicolaisen writes:
>
>> On Fri, Oct 5, 2012 at 3:46 PM, Philippe Vaucher
>> wrote:
>>>
>>> > On the git-users mailing list we're trying someone to help with
>>> > running `git push` over FTP. That person is runnig Git 1.7.9.5
>>> > on Ubuntu 12.04.
>>>
>>> I
On Oct 2, 2012, at 3:09 PM, Junio C Hamano wrote:
> I'll find a brown paper bag big enough to hide in. Please disregard
> it.
>
> -- >8 --
> Subject: [PATCH] t4055: avoid use of sed 'a' command
Sorry about being slow to respond. The patch does work for me. I see it's
already been committed
Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra
>> wrote:
>>> On second thought, it might not be such a good idea. There are *lots*
>>> of variables that control the operation of each command, and it's hard
>>> to decide which ones
Ramkumar Ramachandra wrote:
>> Thomas Ferris Nicolaisen writes:
>>> At least according to the documentation[1], "Git natively supports [...]
>>> ftp".
>>>
>>> This could need some clarification if pushing over ftp is not supported.
[...]
> -Git natively supports ssh, git, http, https, ftp, ftps,
Am 07.10.2012 17:22, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
>>> Currently, the diff code does not differentiate between an explicit
>>> '--submodule=short' being passed, and no submodule option being passed
>>> on the command line.
Am 07.10.2012 21:49, schrieb Jens Lehmann:
> I forgot to mention that testing submodule_format_cfg would have to
> happen in cmd_diff() (between reading the config and parsing the
> command line options) instead of builtin_diff(). Something like this
> should do the trick (untested):
>
> diff --gi
On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> I'm creating a system where a lot of remotes constantly fetch from a
>> central repository for deployment purposes, but I've noticed that even
>> with a remote.$name.fetch configuration to only get certai
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>
>> With a weaker phrase, e.g. "These configuration variables may be of
>> interest", such a list may not hurt readers, but personally I do not
>> think it adds much value to have a list of variables without even a
>> single line description
On Sun, Oct 07, 2012 at 09:57:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> Has anyone started working on a next-gen Git protocol as a result of
> this discussion? If not I thought I'd give it a shot if/when I have
> time.
Unfortunately, client signaling the version is nasty to do in ways that
w
By default, "make doc" generates the manpages and htmldocs in the
Documentation directory, but you may want to change this depending
on the target environment, e.g. to include 'pdf'. Introduce a new
Makefile variable DEFAULT_DOC_TARGET to allow customizing this.
The primary motivation is to let u
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>>> Thomas Ferris Nicolaisen writes:
>
At least according to the documentation[1], "Git natively supports [...]
ftp".
This could need some clarification if pushing over ftp is not supported.
> [...]
>> -Git natively suppo
Jeff King writes:
> Yes. The more we talk about it, the more turned off I am by the idea.
> Above I posed my questions as "what _should_ we do when...". And I still
> think we _should_ default to --only with interactive, if we can find
> sane semantics. But until we can find them, it obviously do
Jeff King writes:
> [1] I would not be surprised if they do not actually format all that
> well. Though they are written in an asciidoc-ish style, they have
> not traditionally been formatted, and I suspect there are many small
> errors (like improper quoting of metacharacters) in the
Jeff King writes:
> Another way of doing this would be to format the individual troff
> manpages into dvi or postscript, convert that into pdf, and then
> concatenate that. Something like:
>
> for i in *.[157]; do
> man -Tdvi -l "$i" >"$i.dvi"
> dvipdfm "$i"
> done
> pdftk *.[157].p
Could we look into getting this patch into git/gitk?
On 10/02/12 11:04, Andrew Wong wrote:
> Refactored the code for binding modified function keys as Junio suggested.
>
> Andrew Wong (2):
> gitk: Refactor code for binding modified function keys
> gitk: Use bindshiftfunctionkey to bind Shift-F
When configured not to use themed widgets gitk may crash on launch with
a message that says that the image "bm-left disabled bm-left-gray"
doesn't exist. This happens when the left and right arrow buttons are
created.
The crash can be avoided by configuring the buttons differently
depending on whe
Could we look into getting these two patches into git/git-gui?
On 10/02/12 12:25, Andrew Wong wrote:
> I ran into a file name parsing issue in git-gui. If I'm in a subfolder and try
> to pass a full path to "git-gui blame", then "git-gui" will fail to detect the
> argument as a valid path. The fir
On Sun, Oct 07, 2012 at 01:39:32PM -0700, Junio C Hamano wrote:
> By default, "make doc" generates the manpages and htmldocs in the
> Documentation directory, but you may want to change this depending
> on the target environment, e.g. to include 'pdf'. Introduce a new
> Makefile variable DEFAULT_
On Sun, Oct 07, 2012 at 01:51:21PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes. The more we talk about it, the more turned off I am by the idea.
> > Above I posed my questions as "what _should_ we do when...". And I still
> > think we _should_ default to --only with interactive, i
On Sun, Oct 07, 2012 at 09:57:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Has anyone started working on a next-gen Git protocol as a result of
> this discussion? If not I thought I'd give it a shot if/when I have
> time.
I haven't, and don't really plan on it soon (I have a few smaller things
I'
Jeff King writes:
> On Sun, Oct 07, 2012 at 01:51:21PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Which is obviously one of:
>> >
>> > 1. Keep defaulting to "--include", as that is what we have been doing.
>> >
>> > 2. Forbid the cases where it would matter (i.e., when the
On Sun, Oct 07, 2012 at 03:23:31PM -0700, Junio C Hamano wrote:
> >> Yeah, I agree with the reasoning. This is an unessential feature
> >> that is with the problem for a long time, so let's go the route #1
> >> first before we do anything else.
> >
> > OK. I think Conrad's patch takes us most of
Ævar Arnfjörð Bjarmason writes:
> On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> I'm creating a system where a lot of remotes constantly fetch from a
>>> central repository for deployment purposes, but I've noticed that even
>>> with a remote.$na
Jeff King writes:
> Why not do it like this:
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 267dfe1..ca10313 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -152,7 +152,8 @@ endif
> endif
> endif
>
> -all: html man
> +DEFAULT_DOC_TARGET ?= h
Brian Charles Gernhardt writes:
> On Oct 2, 2012, at 3:09 PM, Junio C Hamano wrote:
>
>> I'll find a brown paper bag big enough to hide in. Please disregard
>> it.
>>
>> -- >8 --
>> Subject: [PATCH] t4055: avoid use of sed 'a' command
>
> Sorry about being slow to respond. The patch does work
Jeff King writes:
> On Sun, Oct 07, 2012 at 01:39:32PM -0700, Junio C Hamano wrote:
> ...
>> but it is not so far-fetched to imagine that Windows users may want to
>> omit manpages with
>>
>> $ DEFAULT_DOC_TARGET=html make doc
>
> That use case makes a lot more sense to me (or more likely se
Junio C Hamano writes:
> Jeff King writes:
>
>> Why not do it like this:
>>
>> diff --git a/Documentation/Makefile b/Documentation/Makefile
>> index 267dfe1..ca10313 100644
>> --- a/Documentation/Makefile
>> +++ b/Documentation/Makefile
>> @@ -152,7 +152,8 @@ endif
>> endif
>> endif
>>
>> -a
On Sun, Oct 07, 2012 at 10:14:28AM +0200, Thomas Ackermann wrote:
> There are "patched QT" and "unpatched QT" versions of wkhtmltopdf
> (see http://code.google.com/p/wkhtmltopdf/). I am using V0.9.9 for Windows
> which is "patched QT".
That's a definite compatibility question for taking your patc
On Sun, Oct 07, 2012 at 03:45:52PM -0700, Junio C Hamano wrote:
> So here is a proposed update based on your idea, to be squashed on
> top (i.e. the change to the top-level Makefile in the posted patch
> is not reverted).
>
> Does it make sense?
The change to Documentation/Makefile makes sense,
On Sun, Oct 07, 2012 at 03:40:19PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Sun, Oct 07, 2012 at 01:39:32PM -0700, Junio C Hamano wrote:
> > ...
> >> but it is not so far-fetched to imagine that Windows users may want to
> >> omit manpages with
> >>
> >> $ DEFAULT_DOC_TARGE
On Sun, Oct 07, 2012 at 07:07:03PM -0400, Jeff King wrote:
> Would it make sense to pull all of our platform-specific tweaks out into
> a config.mak.platform (right before config.mak.autogen)? That would be
> less surprising for cases like this, and I think it would make the
> Makefile a lot more
Jeff King writes:
> On Sun, Oct 07, 2012 at 07:07:03PM -0400, Jeff King wrote:
>
>> Would it make sense to pull all of our platform-specific tweaks out into
>> a config.mak.platform (right before config.mak.autogen)? That would be
>> less surprising for cases like this, and I think it would make
On Sun, Oct 07, 2012 at 04:25:58PM -0700, Junio C Hamano wrote:
> Yeah, modulo that the "defaults" is tracked and does not have to
> have the dash before "include" (it is an error if it is missing,
> no?). It may want to be named with s/defaults/autodetect/, though.
>
> > diff --git a/Makefile b
Jeff King writes:
> On Sun, Oct 07, 2012 at 04:25:58PM -0700, Junio C Hamano wrote:
>
>> Yeah, modulo that the "defaults" is tracked and does not have to
>> have the dash before "include" (it is an error if it is missing,
>> no?). It may want to be named with s/defaults/autodetect/, though.
>>
On Sat, Oct 06, 2012 at 09:23:59PM -0500, John Whitney wrote:
> >You said in your test script:
> >
> > # Committing test.txt or clearing .gitattributes does clear
> > # the "modified" status, but those options are undesirable
> >
> >Why is the commit undesirable? You have decided that CRs will
On Sat, Oct 6, 2012 at 1:48 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> +Unlike `.gitignore`, negative patterns are not supported.
>> +Patterns that match directories are also not supported.
>
> Is "are not supported" the right phrasing?
>
> I think it makes perfect sense not to
40 matches
Mail list logo
