Apologies for duplicates.
Perhaps the patch below will earn me a small bit of leeway.
-- Hugh Esco
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
user-manual.xml:3739: parser error : Opening and ending tag mismatch: emphasis
line 3739 and literal
char , but is
Hugh Esco writes:
> doing a source install of git v1.7.12.1,
> on the `make all doc` step, I get:
>
> user-manual.xml:3739: parser error : Opening and ending tag mismatch:
> emphasis line 3739 and literal
> char , but is actually expected to be a
> poin
>
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-bundle.xml:130: parser error :
Opening and ending tag mismatch: subscript line 130 and literal
such as master1 cannot be packaged, bu
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-check-ref-format.xml:162: parser
error : Opening and ending tag mismatch: emphasis line 162 and literal
me> is allowed to contain a s
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-config.xml:643: parser error :
Opening and ending tag mismatch: subscript line 643 and literal
ude.path is subject to tilde expansion
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-fast-import.1
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-fast-import.xml:732: parser error
: Opening and ending tag mismatch: superscript line 732 and literal
The
Hugh Esco writes:
> doing a source install of git v1.7.12.1,
> on the `make all doc` step, I get:
>
> xmlto: input does not validate (status 1)
> /usr/local/git-git-51993a4/Documentation/git-bundle.xml:130: parser error :
> Opening and ending tag mismatch: subscript line 130 and literal
> such
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-filter-branch.1
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:463: parser
error : Unescaped '<' not allowed in attributes values
Clone it with git
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-grep.1
xmlto: input does not validate (status 3)
/usr/local/git-git-51993a4/Documentation/git-grep.xml:601: element literal:
validity error : Element emphasis is not declared in literal list of possible
chi
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-push.1
xmlto: input does not validate (status 3)
/usr/local/git-git-51993a4/Documentation/git-push.xml:113: element literal:
validity error : Element emphasis is not declared in literal list of possible
ch
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-remote-helpers.1
xmlto: input does not validate (status 3)
/usr/local/git-git-51993a4/Documentation/git-remote-helpers.xml:135: element
literal: validity error : Element emphasis is not declared in literal
Michael Haggerty writes:
> longest_ancestor_length() relies on a textual comparison of directory
> parts to find the part of path that overlaps with one of the paths in
> prefix_list. But this doesn't work if any of the prefixes involves a
> symbolic link, because the directories will look diffe
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-rev-parse.1
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-rev-parse.xml:264: parser error :
Opening and ending tag mismatch: emphasis line 264 and literal
, or [), i
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
ASCIIDOC git-rm.xml
XMLTO git-rm.1
xmlto: input does not validate (status 3)
/usr/local/git-git-51993a4/Documentation/git-rm.xml:151: element literal:
validity error : Element emphasis is not declared in literal
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-stash.1
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-stash.xml:116: parser error :
Opening and ending tag mismatch: literal line 115 and simpara
^
/usr/l
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO gitcore-tutorial.7
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/gitcore-tutorial.xml:824: parser error
: Opening and ending tag mismatch: emphasis line 824 and literal
(not
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO gitcredentials.7
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/gitcredentials.xml:180: parser error :
Opening and ending tag mismatch: emphasis line 180 and literal
credenti
The latest maintenance release Git v1.7.12.2 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
277b759139ddb62c6935da37de8a483e2c234a97 git-1.7.12.2.tar.gz
5722156394c7478b2339a1d87aa894b
Hi,
a135f214 (gitk: Avoid Meta1-F5, 2012-04-07) changed the key binding
for reloading commits to shift-F5, but this new key binding doesn't
seem to be working here, because it doesn't call reloadcommits().
Choosing the reload menu item works. Shift-F5 works properly in other
applications.
Any id
Hi,
I use smart-http on Apache.
If nothing to be pushed / pulled, I do not want password to be
supplied. And allow git ls-remote to run without password
*.git/info/refs?service=git-upload-pack
*.git/info/refs?service=git-receive-pack
I only need authentication on
*.git/git-upload-pack
*.git/git
Hi!
I have repo1 with ~4 years of history and another repo2 with ~1 year of
history, both of which I don't want to loose. Now I want to join them so
that repo2 becomes a subdirectory whithin repo1, including all the
history of repo2.
A simple git-merge won't do because both repos have some same f
Am 30.09.2012 17:24 schrieb Tomas Carnecky:
> On Sun, 30 Sep 2012 17:17:53 +0200, Dirk SÃŒsserott
> wrote:
>> Hi!
>>
>> I have repo1 with ~4 years of history and another repo2 with ~1 year of
>> history, both of which I don't want to loose. Now I want to join them so
>> that repo2 becomes a subdi
Am 30.09.2012 17:34 schrieb Sascha Cunz:
>
> You might want to have a look at the subtree merge strategy (see man
> git-merge). Maybe that will already do what you want to.
>
>
>
> Sascha
>
Thank you as well. I wasn't aware of that option (or didn't figure out
what it actually does).
Dirk
--
On Sun, Sep 30, 2012 at 12:34:18AM -0700, Junio C Hamano wrote:
> I suspect that a tilde inside literal `` environment is mishandled
> in your versions of the documentation toolchain. Either you would
> need to upgrade some tool in the toolchain, or we would need patches
> to the source that woul
Hi Michael,
> The patch doesn't apply to the current master; it appears to have been
> built against master 883a2a3504 (2012-02-23) or older. It will have to
> be rebased to the current master.
Junio had asked that it be based on maint so that's what I (thought
I?) did. I'm happy to redo it aga
Your are correct. That is apparently the issue:
git@pbx:~$ asciidoc --version
asciidoc 8.2.7
This server is still running Debian Lenny.
Not sure when I will be able to rebuild it.
My apologies for spamming your bug reporting list
with all of that. I now have source installs of git
and gito
Am 30.09.2012 06:47, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>>> The only long term solution I can think of is to use some kind of UUID for
>>> the name, so that the names of newly added submodules won't have a chance
>>> to clash anymore. For the short term aborting "git submodule add"
Previously while reading the variable names in config files, there was
a 256 character limit with at most 128 of those characters being used
by the section header portion of the variable name. This limitation
was only enforced while reading the config files. It was possible to
write a config file
Hi Jeff,
Jeff King wrote:
> On Sun, Sep 30, 2012 at 10:05:27AM +1000, Paul Mackerras wrote:
>> Unfortunately this will wait for the git update-index command to
>> complete, making the GUI unresponsive while it executes, and that can
>> take minutes on a large repository (e.g. the linux kernel) on
On Sun, Sep 30, 2012 at 8:32 AM, Dirk Süsserott wrote:
> Am 30.09.2012 17:24 schrieb Tomas Carnecky:
>> On Sun, 30 Sep 2012 17:17:53 +0200, Dirk SÃŒsserott
>> wrote:
>>> Hi!
>>>
>>> I have repo1 with ~4 years of history and another repo2 with ~1 year of
>>> history, both of which I don't want to
When adding a new submodule it can happen that .git/modules/ already
contains a submodule repo, e.g. when a submodule is removed from the work
tree and another submodule is added at the same path. But then the work
tree of the submodule will be populated using the existing repository and
not the on
Currently "git am" does insane things if the mbox it is given contains
attachments with a MIME type that aren't "text/*".
In particular, it will still decode them, and pass them "one line at a
time" to the mail body filter, but because it has determined that they
aren't text (without actually
Jens Lehmann writes:
>> Good point! I will add a more detailed error message (including
>> the url of the default remote which is configured for the already
>> present submodule repo) and teach --force to skip the test and
>> resurrect that submodule repo.
>
> The message when "git submodule add"
On Sun, Sep 30, 2012 at 7:35 AM, 乙酸鋰 wrote:
> I use smart-http on Apache.
> If nothing to be pushed / pulled, I do not want password to be
> supplied. And allow git ls-remote to run without password
>
> *.git/info/refs?service=git-upload-pack
> *.git/info/refs?service=git-receive-pack
>
> I only n
On Fri, Sep 28, 2012 at 5:00 AM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Sep 27, 2012 at 7:47 AM, Shawn Pearce wrote:
>> * https://git.eclipse.org/r/7939
>>
>> Defines the new E003 index format and the bit set
>> implementation logic.
>
> Quote from the patch's message:
>
> "Currently, the new
On Sun, Sep 30, 2012 at 10:35:35PM +0800, 乙酸鋰 wrote:
> I use smart-http on Apache.
> If nothing to be pushed / pulled, I do not want password to be
> supplied. And allow git ls-remote to run without password
>
> *.git/info/refs?service=git-upload-pack
> *.git/info/refs?service=git-receive-pack
>
On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce wrote:
>> In Linus' Linux kernel tree there are currently about 323,178 commits.
>> If we store just the pre-parsed commit time as an int32 field this is
>> an additional 1.2 MiB of data
On Mon, Oct 1, 2012 at 8:49 AM, Shawn Pearce wrote:
> On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy
> wrote:
>> On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce wrote:
>>> In Linus' Linux kernel tree there are currently about 323,178 commits.
>>> If we store just the pre-parsed commit tim
On Sun, Sep 30, 2012 at 6:59 PM, Nguyen Thai Ngoc Duy wrote:
> On Mon, Oct 1, 2012 at 8:07 AM, Shawn Pearce wrote:
>>> You mentioned this before in your idea mail a while back. I wonder if
>>> it's worth storing bitmaps for all packs, not just the self contained
>>> ones.
>>
>> Colby and I starte
On Sun, Sep 30, 2012 at 7:05 PM, Nguyen Thai Ngoc Duy wrote:
> On Mon, Oct 1, 2012 at 8:49 AM, Shawn Pearce wrote:
>> On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy
>> wrote:
>>> On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce wrote:
In Linus' Linux kernel tree there are currently a
On 09/30/2012 08:20 PM, Ben Walton wrote:
>> The patch doesn't apply to the current master; it appears to have been
>> built against master 883a2a3504 (2012-02-23) or older. It will have to
>> be rebased to the current master.
>
> Junio had asked that it be based on maint so that's what I (though
Hi,
The order of options in git pull is not clear in the documentation
It only says
git pull [options] [ [...]]
So we have no idea which options should come first
I tried
git pull -v --no-tags --progress --no-ff origin
but failed with unknown option 'no-ff'.
But if I ran
git pull -v --no-ff --n
乙酸鋰 writes:
> The order of options in git pull is not clear in the documentation
> It only says
> git pull [options] [ [...]]
> So we have no idea which options should come first
>
> I tried
> git pull -v --no-tags --progress --no-ff origin
> but failed with unknown option 'no-ff'.
>
> But if I r
On 09/30/2012 10:00 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> longest_ancestor_length() relies on a textual comparison of directory
>> parts to find the part of path that overlaps with one of the paths in
>> prefix_list. But this doesn't work if any of the prefixes involves a
>>
On Mon, Oct 1, 2012 at 9:27 AM, Shawn Pearce wrote:
> Git has enough magic switches. It doesn't need yet another magic
> switch that one group of users needs to set, and another can safely
> ignore because their project's usage just happens to align with Linus
> Torvald's current world view.
I se
Michael Haggerty writes:
> I think I would advocate that the prefix has to match the front of
> the path exactly (including any trailing slashes) and either
>
> strlen(prefix) == 0
> or the prefix ended with a '/'
> or the prefix and path are identical
> or the character in path f
Am 28.09.2012 10:44, schrieb Stefan Näwe:
> I get "Not a Git repository: remote.git" as well, when I run
> git gui "somewhere" (i.e. not in "remote.git")
i.e.:
$ cd /not/a/repo
$ git gui
> and the select "Open Existing Repository".
>
> I get "Cannot use bare repository: .../remote.git" wh
Jens Lehmann wrote:
> I suspect you got the idea for this patch from Marc's recent comment:
> [...]
Yes, I did.
> That is just a single user so far indicating your patch /could/ be an
> improvement. I think we need quite some more votes on that before we
> should do a change like this.
I thought
Hi Jens,
Jens Lehmann wrote:
> I'm very interested in your feedback as a first time submodule user,
> what you wrote above makes sense and explains why you did that patch
> (and it would have been nice to read some of it in the commit message
> ;-). What information did you expect to get from a "g
49 matches
Mail list logo
