* Re: [PATCH] gitweb: use decode_utf8 directly
From: Ismail Dönmez @ 2007-06-01 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexandre Julliard, git, Jakub Narebski
In-Reply-To: <7vr6ovzcgr.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
On Friday 01 June 2007 22:44:36 Junio C Hamano wrote:
> Alexandre Julliard <julliard@winehq.org> writes:
> > Sorry for the late nack, but it turns out that this patch breaks diff
> > output on the Wine server for files that are not utf-8.
> >
> > The cause is apparently that decode_utf8() returns undef for invalid
> > sequences instead of substituting a replacement char like
> > decode("utf8") does.
>
> Thanks for noticing. Will revert.
Why are reverting a correct bugfix? :( He's at most using outdated software.
*sigh*
/ismail
--
Perfect is the enemy of good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Junio C Hamano @ 2007-06-01 19:44 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Ismail Dönmez, git, Jakub Narebski
In-Reply-To: <87zm3ju6tg.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Sorry for the late nack, but it turns out that this patch breaks diff
> output on the Wine server for files that are not utf-8.
>
> The cause is apparently that decode_utf8() returns undef for invalid
> sequences instead of substituting a replacement char like
> decode("utf8") does.
Thanks for noticing. Will revert.
^ permalink raw reply
* [mingw port] git plumbing piping with CR/NL
From: Nguyen Thai Ngoc Duy @ 2007-06-01 18:23 UTC (permalink / raw)
To: Git Mailing List, Johannes Sixt
Hi,
I haven't had time looking at the code yet. I report here so that I
can free my memory for other things. I made a command like this:
$ git ls-tree -r HEAD|grep blah.cc|git update-index --index-info
and the output of git-status was:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: path/to/blah.cc\r
#
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: path/to/blah.cc\r
...
$ git version
git version 1.5.2.651.g80e39-dirty (if the commit isn't in the master
branch, it is based on master branch)
Apparently git should ignore \r at the end of the path. Will look at it later.
--
Duy
^ permalink raw reply
* Re: [MinGW port] Unable to repack on Clearcase dynamic views
From: Jan Hudec @ 2007-06-01 18:11 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Nguyen Thai Ngoc Duy, Paolo Teti, Git Mailing List,
Matthias Lederhofer, Junio C Hamano
In-Reply-To: <200705302028.15549.robin.rosenberg.lists@dewire.com>
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
On Wed, May 30, 2007 at 20:28:15 +0200, Robin Rosenberg wrote:
> Wasn't because it's better to make .git a link to a repository somewhere
> else? Just a guess.
>
> ln -s /somewhere/repo/.git .git
>
> Works fine for me (yes, in a clearcase dynamic view).
It works for me too. It requires cygwin version of git though, since windows
don't have native symlinks.
> BTW, Does anyone have something like git-cvsexportcommit for clearcase?
No, but it should not be too hard to create.
If you want to quickly import something, you can try starting with something
like:
diff clearcase-view git-checkout > p
lsdiff p | xargs -d '\n' cleartool checkout
patch -p $n < p
You'll have to sort out which directories to run which command in and how
many components to strip with -p in the patch. It also does not handle adding
and removing.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Alexandre Julliard @ 2007-06-01 16:51 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <200706011650.10650.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> Sorry but thats too old. Of course I am not the maintainer of GIT so its not
> for me to decide but well as David Woodhouse puts it, please join us in 21st
> century and start using UTF-8.
That's not very helpful. There can be many valid reasons for not using
utf-8, in our case compatibility with Windows tools is the main
reason. And even if we were to convert all our files today, it
wouldn't help when browsing older versions.
I'm not asking gitweb to magically guess the encoding of the files,
I'm happy with it replacing invalid sequences with some substitution
char, like it did before 1.5.2. But now it is deleting whole lines
from the diff, without any indication that something went wrong.
That's not an improvement IMNSHO.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Linus Torvalds @ 2007-06-01 16:29 UTC (permalink / raw)
To: Lars Hjemli; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <8c5c35580706010856s390b1157p3ea0d28cb2074cae@mail.gmail.com>
On Fri, 1 Jun 2007, Lars Hjemli wrote:
> On 6/1/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> >
> > Hmm.... I was thinking that the extra "path" level could be optional,
> > i.e., if there is no path.$path.submodule, then the name of the
> > submodule would simply be $path.
>
> Yeah, that should also work out. Time for a quick poll?
Ack. I think the natural thing for a lot of cases is the trivial "module
name == path" case, so having to have
[path "kernel"]
module = kernel
for that case just sounds unnecessary.
That said, I wonder if it wouldn't be more natural to do things the other
way around, because quite often a "module" (under CVS conventions) is a
*set* of directories, so with that in mind, it might be better to have the
mapping be something like this:
[module "infrastructure"]
submodule = lib
submodule = build
[submodule "lib"]
url = git://xyzzy/lib-1.2.3
[submodule "build"]
url = git://xyzzy/build-0.61
and make the rule be:
- submodules are named by their paths (ie "path == submodule")
- a module is a set of such submodules/paths
- if no "module" is defined, the default is to just use the
path/submodule name
IOW, in the above case, we have *three* modules:
- module "infrastructure", that is the union of submodules/paths "lib"
and "build"
- module "lib" (== submodule/path "lib")
- module "build" (== submodule/path "build")
and when you do a
git submodule checkout infrastructure
it would be basically equivalent to
git submodule checkout lib
git submodule checkout build
Hmm? That's how CVS users use modules (ie the "src" module may be much
more than a single subdirectory)
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Martin Koegler @ 2007-06-01 16:13 UTC (permalink / raw)
To: julliard; +Cc: git
Alexandre Julliard wrote:
>Junio C Hamano <junkio@cox.net> writes:
> > I would say that the patch is an improvement from the current
> > code so it should hit 'master'; I was a bit busy lately and then
> > am sick, and also we are post -rc1 freeze now and I was being
> > cautious, just in case some nacks from more informed parties
> > arrive late.
>
> Sorry for the late nack, but it turns out that this patch breaks diff
> output on the Wine server for files that are not utf-8.
>
> The cause is apparently that decode_utf8() returns undef for invalid
> sequences instead of substituting a replacement char like
> decode("utf8") does.
>
> That may be considered an Encode bug since we are running a fairly old
> version (1.99, coming with Debian 3.1), but I'd rather not upgrade
> perl on the server. Could the patch be reverted, or done differently?
I hit the same problem:
http://marc.info/?l=git&m=117978122420441&w=2
On my system, I use this patch as workaround:
http://marc.info/?l=git&m=118038526531694&w=2
mfg Martin Kögler
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Lars Hjemli @ 2007-06-01 15:56 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070601145104.GY955MdfPADPa@greensroom.kotnet.org>
On 6/1/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Fri, Jun 01, 2007 at 04:45:06PM +0200, Lars Hjemli wrote:
> > On 6/1/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> > >On Fri, Jun 01, 2007 at 11:25:42AM +0200, Lars Hjemli wrote:
> > >> [path '$path']
> > >> submodule=modulename
> > >> url=/some/url
> > >
> > >Wouldn't it make more sense to have
> > >
> > >[path '$path']
> > > submodule=modulename
> > >
> > >and
> > >
> > >[submodule '$modulename']
> > > url=/some/url
> > >
> > >in case the same module appears in more than one path?
> >
> > Yes, that would be a properly normalized model.
> >
> > Hmm.... Maybe we could allow both variations, with your suggestion
> > overriding mine if both are present? (I think there would be many
> > cases where the extra level of [submodule...] wouldn't be needed.
>
> Hmm.... I was thinking that the extra "path" level could be optional,
> i.e., if there is no path.$path.submodule, then the name of the
> submodule would simply be $path.
Yeah, that should also work out. Time for a quick poll?
--
larsh
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Sven Verdoolaege @ 2007-06-01 14:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <8c5c35580706010745l76fc5410l21f2e3f385693ad9@mail.gmail.com>
On Fri, Jun 01, 2007 at 04:45:06PM +0200, Lars Hjemli wrote:
> On 6/1/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> >On Fri, Jun 01, 2007 at 11:25:42AM +0200, Lars Hjemli wrote:
> >> [path '$path']
> >> submodule=modulename
> >> url=/some/url
> >
> >Wouldn't it make more sense to have
> >
> >[path '$path']
> > submodule=modulename
> >
> >and
> >
> >[submodule '$modulename']
> > url=/some/url
> >
> >in case the same module appears in more than one path?
>
> Yes, that would be a properly normalized model.
>
> Hmm.... Maybe we could allow both variations, with your suggestion
> overriding mine if both are present? (I think there would be many
> cases where the extra level of [submodule...] wouldn't be needed.
Hmm.... I was thinking that the extra "path" level could be optional,
i.e., if there is no path.$path.submodule, then the name of the
submodule would simply be $path.
skimo
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Lars Hjemli @ 2007-06-01 14:45 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070601093554.GV955MdfPADPa@greensroom.kotnet.org>
On 6/1/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Fri, Jun 01, 2007 at 11:25:42AM +0200, Lars Hjemli wrote:
> > On 6/1/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> > >Could you please document the proposed .gitmodules first?
> >
> > The man-page for git-submodule found in 'next' mentions how it uses
> > .gitmodules, but there isn't (yet) a separate man-page for
> > .gitmodules(5).
>
> That's what I'd like to see first.
> .gitmodules(5) will hopefully not change in an incompatible
> way after it is accepted, while there is no such constraint
> for git-submodule.
True
>
> > [path '$path']
> > submodule=modulename
> > url=/some/url
>
> Wouldn't it make more sense to have
>
> [path '$path']
> submodule=modulename
>
> and
>
> [submodule '$modulename']
> url=/some/url
>
> in case the same module appears in more than one path?
Yes, that would be a properly normalized model.
Hmm.... Maybe we could allow both variations, with your suggestion
overriding mine if both are present? (I think there would be many
cases where the extra level of [submodule...] wouldn't be needed.
Also, the url in .gitmodules will only function as the initially
suggested url stored in the 'superprojects' .git/config)
--
larsh
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Ismail Dönmez @ 2007-06-01 13:50 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <87zm3ju6tg.fsf@wine.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
On Friday 01 June 2007 16:45:31 Alexandre Julliard wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > I would say that the patch is an improvement from the current
> > code so it should hit 'master'; I was a bit busy lately and then
> > am sick, and also we are post -rc1 freeze now and I was being
> > cautious, just in case some nacks from more informed parties
> > arrive late.
>
> Sorry for the late nack, but it turns out that this patch breaks diff
> output on the Wine server for files that are not utf-8.
Isn't UTF-8 default even for Linux kernel now?
> The cause is apparently that decode_utf8() returns undef for invalid
> sequences instead of substituting a replacement char like
> decode("utf8") does.
>
> That may be considered an Encode bug since we are running a fairly old
> version (1.99, coming with Debian 3.1), but I'd rather not upgrade
> perl on the server. Could the patch be reverted, or done differently?
Sorry but thats too old. Of course I am not the maintainer of GIT so its not
for me to decide but well as David Woodhouse puts it, please join us in 21st
century and start using UTF-8.
/ismail
--
Perfect is the enemy of good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use decode_utf8 directly
From: Alexandre Julliard @ 2007-06-01 13:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ismail Dönmez, git, Jakub Narebski
In-Reply-To: <7vsladzp29.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I would say that the patch is an improvement from the current
> code so it should hit 'master'; I was a bit busy lately and then
> am sick, and also we are post -rc1 freeze now and I was being
> cautious, just in case some nacks from more informed parties
> arrive late.
Sorry for the late nack, but it turns out that this patch breaks diff
output on the Wine server for files that are not utf-8.
The cause is apparently that decode_utf8() returns undef for invalid
sequences instead of substituting a replacement char like
decode("utf8") does.
That may be considered an Encode bug since we are running a fairly old
version (1.99, coming with Debian 3.1), but I'd rather not upgrade
perl on the server. Could the patch be reverted, or done differently?
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: Breaking up repositories
From: Jakub Narebski @ 2007-06-01 10:25 UTC (permalink / raw)
To: git
In-Reply-To: <465EEF96.6050307@freedesktop.org>
Josh Triplett wrote:
> Jason Sewall wrote:
>> I recently imported my subversion repo with git-svn and I'm curious
>> what the best way to break up the monolithic repo (my many disparate
>> projects from my single svn repo) into individual git repos of their
>> own.
>
> In the specific case of git-svn, you can probably give git-svn the
> appropriate paths to import each project separately; that may do what you
> want, depending on your repository layout.
>
> In the general case, if you want to split a subtree of a git repo into a git
> repo, you want git-split, by Jamey Sharp and I:
> <http://people.freedesktop.org/~jamey/git-split>
> From a copy of the git repo you want to split, just run "git-split subdir",
> optionally with a newest and oldest commit, and it will output the sha1 of
> the new top commit for use as the new branch ref. Remove all other
> branches, reflogs, and other references to the old commits, and use prune
> or gc to get rid of old objects. Repeat as desired for other subdirs.
I have added info about git-split to Git Wiki
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
Please improve this information, and correct if it is wrong.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] catch asciidoc failures
From: Scott Lamb @ 2007-06-01 9:46 UTC (permalink / raw)
To: Jeff King; +Cc: Martin Waitz, Junio C Hamano, git, jonas.fonseca
In-Reply-To: <20070601091030.GA2215@coredump.intra.peff.net>
On Jun 1, 2007, at 2:10 AM, Jeff King wrote:
> %.html : %.txt
> rm -f $@+ $@
> $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
> - $(ASCIIDOC_EXTRA) -o - $< | \
> - sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
> + $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
> mv $@+ $@
Hmm, now the $@+ intermediary shouldn't be necessary anymore - with "-
o" it's asciidoc's responsibility to handle the output file correctly.
I think there's a lightbulb joke here somewhere. ;)
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: [PATCH] catch asciidoc failures
From: Jeff King @ 2007-06-01 9:43 UTC (permalink / raw)
To: Martin Waitz; +Cc: Scott Lamb, Junio C Hamano, git, jonas.fonseca
In-Reply-To: <20070601093929.GC3521@admingilde.org>
On Fri, Jun 01, 2007 at 11:39:29AM +0200, Martin Waitz wrote:
> very nice!
> Does that need any special asciidoc version?
I don't think so, but I'm not an asciidoc expert. Flipping through the
changelog, it looks like '-a' has existed since before 7.0.
-Peff
^ permalink raw reply
* Re: [PATCH] catch asciidoc failures
From: Martin Waitz @ 2007-06-01 9:39 UTC (permalink / raw)
To: Jeff King; +Cc: Scott Lamb, Junio C Hamano, git, jonas.fonseca
In-Reply-To: <20070601091030.GA2215@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 252 bytes --]
hoi :)
On Fri, Jun 01, 2007 at 05:10:30AM -0400, Jeff King wrote:
> As Jonas suggested, making it an asciidoc attribute is much more
> elegant (patch even tested!):
very nice!
Does that need any special asciidoc version?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Sven Verdoolaege @ 2007-06-01 9:35 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <8c5c35580706010225p7c34c3ceu8bbfb9996388d673@mail.gmail.com>
On Fri, Jun 01, 2007 at 11:25:42AM +0200, Lars Hjemli wrote:
> On 6/1/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> >Could you please document the proposed .gitmodules first?
>
> The man-page for git-submodule found in 'next' mentions how it uses
> .gitmodules, but there isn't (yet) a separate man-page for
> .gitmodules(5).
That's what I'd like to see first.
.gitmodules(5) will hopefully not change in an incompatible
way after it is accepted, while there is no such constraint
for git-submodule.
> [path '$path']
> submodule=modulename
> url=/some/url
Wouldn't it make more sense to have
[path '$path']
submodule=modulename
and
[submodule '$modulename']
url=/some/url
in case the same module appears in more than one path?
> Is it ok if gitmodules(5) appears as part of the planned patch-series?
For me it is.
skimo
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Lars Hjemli @ 2007-06-01 9:25 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070601085705.GT955MdfPADPa@greensroom.kotnet.org>
On 6/1/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Thu, May 31, 2007 at 02:17:30AM +0200, Lars Hjemli wrote:
> > 1. 'git-submodule init' saves submodule name and suggested url from
> > .gitmodules into .git/config (submodule.$name.url)
>
> Could you please document the proposed .gitmodules first?
The man-page for git-submodule found in 'next' mentions how it uses
.gitmodules, but there isn't (yet) a separate man-page for
.gitmodules(5).
But: when I implement the proposed plan, it will change the current
layout of .gitmodules from
[module '$path']
url=/some/url
to
[path '$path']
submodule=modulename
url=/some/url
Is it ok if gitmodules(5) appears as part of the planned patch-series?
--
larsh
^ permalink raw reply
* Re: [PATCH 1/4] Add 2 new contrib scripts.
From: David Kågedal @ 2007-06-01 9:22 UTC (permalink / raw)
To: git
In-Reply-To: <20070531223423.6005.59088.stgit@gandelf.nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> diff --git a/contrib/stg-unnew b/contrib/stg-unnew
> new file mode 100755
> index 0000000..5ac8781
> --- /dev/null
> +++ b/contrib/stg-unnew
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +set -e
> +
> +# stg-unnew - sort of "reverse an 'stg new'"
> +
> +# Remove the current patch from the stack, keeping its contents as
> +# uncommitted changes.
> +
> +# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
> +# Subject to the GNU GPL, version 2.
> +
> +patch=$(stg top)
> +stg pop
> +stg pick --fold $patch
> +stg delete $patch
>
This is something I've been missing. But I'd call it "stg merge" or
something, since what it does is that it merges the top patch into the
patch below it. But since "merge" means something else to git, it
might not be the best choice.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Lars Hjemli @ 2007-06-01 9:17 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git
In-Reply-To: <200706011008.38063.Josef.Weidendorfer@gmx.de>
On 6/1/07, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > On 5/28/07, Lars Hjemli <hjemli@gmail.com> wrote:
> > 3) 'git-submodule push' runs something like 'cd $path && git push
> > origin $branch', where $branch is found in .gitmodules
> > (path.$path.branch).
>
> So if you need superproject related corrections in the submodule,
> you always have to do it on branch "path.$path.branch" in the
> submodule to get it saved?
>
> I would assume that pushing the current branch should be enough.
> If you want to play with multiple different "corrections" on
> different branches in the submodule, you do not want to force
> the branch name to a unique one given in .gitmodules.
>
The current (and planned) implementation of git-submodule detaches
HEAD in the submodules, so there will not be a current branch unless
the user has done 'cd $path && git-checkout somebranch'.
We might take advantage of that fact:
* try to exec 'git-symbolic-ref HEAD'
* if it fails, push to path.$path.branch
* otherwise, push to the ref pointed to by HEAD
But this will still loose any changes on _other_ branches (that has
not been pushed to origin manually). I'm not sure if/how we can avoid
this, except by making $path be a symlink to .git/submodules/$name.git
(which has other issues...)
--
larsh
^ permalink raw reply
* Re: [PATCH] catch asciidoc failures
From: Jeff King @ 2007-06-01 9:10 UTC (permalink / raw)
To: Martin Waitz; +Cc: Scott Lamb, Junio C Hamano, git, jonas.fonseca
In-Reply-To: <20070601083621.GB3521@admingilde.org>
On Fri, Jun 01, 2007 at 10:36:21AM +0200, Martin Waitz wrote:
> perhaps we should simply change the pipe ordering to get asciidoc
> to the end of the pipeline so that all shells respect its exit code?
> [...]
> something like (untested):
> sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' $< |
> $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
> $(ASCIIDOC_EXTRA) -o $@+ -
That won't work. The text @@GIT_VERSION@@ is pulled in from the
asciidoc.conf file, so it's not even in the source file; it's only in
the built product.
As Jonas suggested, making it an asciidoc attribute is much more
elegant (patch even tested!):
-- >8 --
Documentation: robustify asciidoc GIT_VERSION replacement
Instead of using sed on the resulting file, we now have a
git_version asciidoc attribute. This means that we don't
pipe the output of asciidoc, which means we can detect build
failures.
Problem reported by Scott Lamb, solution suggested by Jonas Fonseca.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 6 ++----
Documentation/asciidoc.conf | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 3f92783..4064b38 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -112,8 +112,7 @@ clean:
%.html : %.txt
rm -f $@+ $@
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
- $(ASCIIDOC_EXTRA) -o - $< | \
- sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
mv $@+ $@
%.1 %.5 %.7 : %.xml
@@ -122,8 +121,7 @@ clean:
%.xml : %.txt
rm -f $@+ $@
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
- $(ASCIIDOC_EXTRA) -o - $< | \
- sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
mv $@+ $@
user-manual.xml: user-manual.txt user-manual.conf
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index fa7dc94..60e15ba 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -40,7 +40,7 @@ template::[header-declarations]
<refentrytitle>{mantitle}</refentrytitle>
<manvolnum>{manvolnum}</manvolnum>
<refmiscinfo class="source">Git</refmiscinfo>
-<refmiscinfo class="version">@@GIT_VERSION@@</refmiscinfo>
+<refmiscinfo class="version">{git_version}</refmiscinfo>
<refmiscinfo class="manual">Git Manual</refmiscinfo>
</refmeta>
<refnamediv>
--
1.5.2.871.g0ff23
^ permalink raw reply related
* Re: [PATCH] Let .git/config specify the url for submodules
From: Sven Verdoolaege @ 2007-06-01 8:57 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <8c5c35580705301717h4e9b127fr21ee19764f8ec288@mail.gmail.com>
On Thu, May 31, 2007 at 02:17:30AM +0200, Lars Hjemli wrote:
> 1. 'git-submodule init' saves submodule name and suggested url from
> .gitmodules into .git/config (submodule.$name.url)
Could you please document the proposed .gitmodules first?
Since it looks like I'm going to be forced to my submodule URLs there,
I need to know how to do it before I can start using submodules properly.
skimo
^ permalink raw reply
* Re: [PATCH] catch asciidoc failures
From: Jonas Fonseca @ 2007-06-01 8:55 UTC (permalink / raw)
To: Martin Waitz; +Cc: Scott Lamb, Junio C Hamano, git
In-Reply-To: <20070601083621.GB3521@admingilde.org>
On 6/1/07, Martin Waitz <tali@admingilde.org> wrote:
> On Thu, May 31, 2007 at 11:23:57PM -0700, Scott Lamb wrote:
> > If pipefail is available (GNU bash >= 3.00), fail when asciidoc returns
> > error rather than possibly later during XSLT.
>
> perhaps we should simply change the pipe ordering to get asciidoc
> to the end of the pipeline so that all shells respect its exit code?
For tig I also adopted the nice man page headers git has. However, I have
used asciidoc attributes provided on the command line avoid having to
use sed. I can make a patch later if nobody beats me. The required changes
are outlined below.
> > --- a/Documentation/Makefile
> > +++ b/Documentation/Makefile
> > @@ -111,6 +111,7 @@ clean:
> >
> > %.html : %.txt
> > rm -f $@+ $@
> > + set -o pipefail 2>/dev/null; \
> > $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
> > $(ASCIIDOC_EXTRA) -o - $< | \
> > sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
>
> something like (untested):
> sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' $< |
> $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
> $(ASCIIDOC_EXTRA) -o $@+ -
More untested stuff. Use -a to define git_version attribute:
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@ $<
Then change the @@GIT_VERSION@@ symbol in asciidoc.conf to {git_version}.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Josef Weidendorfer @ 2007-06-01 8:08 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <8c5c35580705301717h4e9b127fr21ee19764f8ec288@mail.gmail.com>
On Thursday 31 May 2007, Lars Hjemli wrote:
> On 5/28/07, Lars Hjemli <hjemli@gmail.com> wrote:
> > This changes git-submodule in a few ways:
>
> Please don't apply the "Let .git/config specify the url for
> submodules" patch, I'm having second thoughts ;-)
>
> Your design outline in
> http://article.gmane.org/gmane.comp.version-control.git/48287 is
> obviously superior, and I'd like to take a stab at it with something
> like this:
>
> 1. 'git-submodule init' saves submodule name and suggested url from
> .gitmodules into .git/config (submodule.$name.url)
>
> 2. 'git-submodule update' keeps the work tree updated for submodules
> with five separate (and optional) operations:
> a) git-clone --bare $url .git/submodules/$name.git
> b) git-clone -l -s .git/submodules/$name.git $path
> c) cd .git/submodules/$name.git && git-fetch
> d) cd $path && git-fetch
> e) cd $path && git-checkout $sha1
>
> 3) 'git-submodule push' runs something like 'cd $path && git push
> origin $branch', where $branch is found in .gitmodules
> (path.$path.branch).
So if you need superproject related corrections in the submodule,
you always have to do it on branch "path.$path.branch" in the
submodule to get it saved?
I would assume that pushing the current branch should be enough.
If you want to play with multiple different "corrections" on
different branches in the submodule, you do not want to force
the branch name to a unique one given in .gitmodules.
Josef
^ permalink raw reply
* Re: [PATCH] catch asciidoc failures
From: Martin Waitz @ 2007-06-01 8:36 UTC (permalink / raw)
To: Scott Lamb; +Cc: Junio C Hamano, git
In-Reply-To: <11806790373908-git-send-email-slamb@slamb.org>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
hoi :)
On Thu, May 31, 2007 at 11:23:57PM -0700, Scott Lamb wrote:
> If pipefail is available (GNU bash >= 3.00), fail when asciidoc returns
> error rather than possibly later during XSLT.
perhaps we should simply change the pipe ordering to get asciidoc
to the end of the pipeline so that all shells respect its exit code?
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -111,6 +111,7 @@ clean:
>
> %.html : %.txt
> rm -f $@+ $@
> + set -o pipefail 2>/dev/null; \
> $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
> $(ASCIIDOC_EXTRA) -o - $< | \
> sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
something like (untested):
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' $< |
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -o $@+ -
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox