* Re: [PATCH] more dependencies in doc generation
From: Alexey Mahotkin @ 2007-09-20 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <bb5b640b0709201343j5a04a554ib91785b43464d4d2@mail.gmail.com>
On 9/21/07, Alexey Mahotkin <squadette@gmail.com> wrote:
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -135,11 +135,11 @@ clean:
> -%.xml : %.txt
> +%.xml : %.txt asciidoc.conf
This change is not needed, sorry.
--
Alexey Mahotkin
http://www.versioncontrolblog.com/
^ permalink raw reply
* Re: [PATCH 0/3] the return of the strbuf
From: Junio C Hamano @ 2007-09-20 21:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0709201248400.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 17 Sep 2007, Shawn O. Pearce wrote:
>
>> $ git log --pretty=format:%an --since=6.months.ago -- fast-import.c \
>> | sort | uniq -c | sort -nr
>> 14 Shawn O. Pearce
>> 3 Pierre Habouzit
>> 3 Junio C Hamano
>> 2 Simon Hausmann
>> 2 Alex Riesen
>> 1 Theodore Ts'o
>> 1 Sven Verdoolaege
>> 1 Sami Farin
>> 1 Nicolas Pitre
>> 1 Luiz Fernando N. Capitulino
>> 1 Dana L. How
>
> FWIW I'd do
>
> git shortlog -n --since=6.months.ago HEAD -- fast-import.c|grep "^[A-Z]"
>
> instead...
I am sure you certainly meant a single command without grep, like:
$ git shortlog -n -s --since=6.months.ago HEAD -- fast-import.c
^ permalink raw reply
* Re: [PATCH] new test from the submodule chapter of the user manual
From: Junio C Hamano @ 2007-09-20 21:35 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <20070920170831.GQ16235@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Thu, Sep 20, 2007 at 11:34:25AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Wed, 19 Sep 2007, Junio C Hamano wrote:
>> > Looks Ok to me, although I didn't verify the examples by
>> > actually running them myself this time (last round I did).
>>
>> So maybe we should do the same as with the tutorial: stick the examples
>> into a test script?
>
> what about this?
Far too inadequate. You test if "commit" reports success, but
do not check if what is committed is what you wanted to commit,
for example.
^ permalink raw reply
* [PATCH] handle Docbook XSL 1.72 (incompletely)
From: Alexey Mahotkin @ 2007-09-20 21:26 UTC (permalink / raw)
To: git
hi,
Fedora Core 7 has docbook-style-xsl-1.72.0-2.fc7
git-diff manpage (and couple of more, using callouts) is broken here:
EXAMPLES
Various ways to check your working tree
$ git diff \fB(1)\fR
$ git diff --cached \fB(2)\fR
$ git diff HEAD \fB(3)\fR
.sp \fB1. \fRChanges in the working tree not yet staged for
the next commit.
I have fixed this for 1.72 (and probably 1.7x in general), but it does
not work under older Docbook XSL, e.g. 1.6x. I guess we could check
for version number during build, but cannot provide complete patch, so
here is the interim solution:
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index af5b155..ec9060c 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -28,11 +28,11 @@ ifdef::backend-docbook[]
<example><title>{title}</title>
<literallayout>
ifdef::doctype-manpage[]
- .ft C
+⌂ft C
endif::doctype-manpage[]
|
ifdef::doctype-manpage[]
- .ft
+ ⌂ft
endif::doctype-manpage[]
</literallayout>
{title#}</example>
diff --git a/Documentation/callouts.xsl b/Documentation/callouts.xsl
index 6a361a2..b1b6882 100644
--- a/Documentation/callouts.xsl
+++ b/Documentation/callouts.xsl
@@ -1,17 +1,17 @@
<!-- callout.xsl: converts asciidoc callouts to man page format -->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="co">
- <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
+ <xsl:value-of
select="concat('▓fB(',substring-after(@id,'-'),')▓fR')"/>
</xsl:template>
<xsl:template match="calloutlist">
- <xsl:text>.sp </xsl:text>
+ <xsl:text> .sp </xsl:text>
<xsl:apply-templates/>
<xsl:text> </xsl:text>
</xsl:template>
<xsl:template match="callout">
- <xsl:value-of
select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
+ <xsl:value-of
select="concat('▓fB',substring-after(@arearefs,'-'),'.
▓fR')"/>
<xsl:apply-templates/>
- <xsl:text>.br </xsl:text>
+ <xsl:text>⌂br </xsl:text>
</xsl:template>
<!-- sorry, this is not about callouts, but attempts to work around
Someone more knowledgeable in this area should step in :)
Thank you,
--
Alexey Mahotkin
http://www.versioncontrolblog.com/
^ permalink raw reply related
* [PATCH] alphabetize LIB_OBJS
From: Alexey Mahotkin @ 2007-09-20 21:09 UTC (permalink / raw)
To: git
I often have to build new Gits on slow machines. Alphabetized list of
objects allows to estimate time to build completion.
Please apply.
Thank you,
diff --git a/Makefile b/Makefile
index 0055eef..4d3eef0 100644
--- a/Makefile
+++ b/Makefile
@@ -299,21 +299,27 @@ DIFF_OBJS = \
diffcore-delta.o log-tree.o
LIB_OBJS = \
- blob.o commit.o connect.o csum-file.o cache-tree.o base85.o \
- date.o diff-delta.o entry.o exec_cmd.o ident.o \
- interpolate.o \
- lockfile.o \
- patch-ids.o \
- object.o pack-check.o pack-write.o patch-delta.o path.o pkt-line.o \
- sideband.o reachable.o reflog-walk.o \
- quote.o read-cache.o refs.o run-command.o dir.o object-refs.o \
- server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
- tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
- revision.o pager.o tree-walk.o xdiff-interface.o \
- write_or_die.o trace.o list-objects.o grep.o match-trees.o \
- alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
- color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \
- convert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o
+ alloc.o archive-zip.o archive-tar.o attr.o \
+ base85.o blob.o \
+ cache-tree.o color.o commit.o config.o connect.o convert.o
csum-file.o ctype.o copy.o \
+ date.o decorate.o diff-delta.o dir.o \
+ entry.o environment.o exec_cmd.o \
+ grep.o \
+ help.o \
+ ident.o interpolate.o \
+ list-objects.o lockfile.o \
+ mailmap.o match-trees.o merge-file.o \
+ object.o object-refs.o \
+ pack-check.o pack-write.o pager.o patch-delta.o patch-ids.o path.o
path-list.o pkt-line.o progress.o \
+ quote.o \
+ reachable.o read-cache.o reflog-walk.o refs.o remote.o revision.o
run-command.o \
+ server-info.o setup.o sha1_file.o sha1_name.o shallow.o sideband.o
strbuf.o symlinks.o \
+ tag.o trace.o tree.o tree-walk.o \
+ usage.o \
+ write_or_die.o wt-status.o \
+ xdiff-interface.o \
+ unpack-trees.o utf8.o \
+ $(DIFF_OBJS)
BUILTIN_OBJS = \
builtin-add.o \
@@ -328,6 +334,7 @@ BUILTIN_OBJS = \
builtin-checkout-index.o \
builtin-check-ref-format.o \
builtin-commit-tree.o \
+ builtin-config.o \
builtin-count-objects.o \
builtin-describe.o \
builtin-diff.o \
@@ -351,12 +358,12 @@ BUILTIN_OBJS = \
builtin-mv.o \
builtin-name-rev.o \
builtin-pack-objects.o \
+ builtin-pack-refs.o \
builtin-prune.o \
builtin-prune-packed.o \
builtin-push.o \
builtin-read-tree.o \
builtin-reflog.o \
- builtin-config.o \
builtin-rerere.o \
builtin-reset.o \
builtin-rev-list.o \
@@ -366,6 +373,7 @@ BUILTIN_OBJS = \
builtin-runstatus.o \
builtin-shortlog.o \
builtin-show-branch.o \
+ builtin-show-ref.o \
builtin-stripspace.o \
builtin-symbolic-ref.o \
builtin-tag.o \
@@ -376,9 +384,7 @@ BUILTIN_OBJS = \
builtin-upload-archive.o \
builtin-verify-pack.o \
builtin-verify-tag.o \
- builtin-write-tree.o \
- builtin-show-ref.o \
- builtin-pack-refs.o
+ builtin-write-tree.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
EXTLIBS =
--
Alexey Mahotkin
http://www.versioncontrolblog.com/
^ permalink raw reply related
* [PATCH] more dependencies in doc generation
From: Alexey Mahotkin @ 2007-09-20 20:43 UTC (permalink / raw)
To: git
Hi,
I'm trying to solve the problem with `man git-diff' (unescaped troff
sequences in manpage), and the first thing that will obviously help is
the following patch:
diff --git a/Documentation/Makefile b/Documentation/Makefile
index fbefe9a..310d6a5 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -135,11 +135,11 @@ clean:
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
mv $@+ $@
-%.1 %.5 %.7 : %.xml
+%.1 %.5 %.7 : %.xml callouts.xsl
$(RM) $@
xmlto -m callouts.xsl man $<
-%.xml : %.txt
+%.xml : %.txt asciidoc.conf
$(RM) $@+ $@
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
It helps to regenerate things correctly when the stylesheets change.
Please apply.
Thank you,
--
Alexey Mahotkin
http://www.versioncontrolblog.com/
^ permalink raw reply related
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Dan Libby @ 2007-09-20 19:40 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Junio C Hamano, git
In-Reply-To: <20070918092909.GU31176@kiste.smurf.noris.de>
Hi Matthias,
So the svnimport (with your patch) chugged along for quite a while, but now
I've run into a new (related?) problem. Here's the output:
--
Merge parent branch: 57b2ce794c20e71efa9c7bd0cc71df72e01f5d39
Commit ID 37f501fd2fd0d309b4d3fdce77bac13c84646423
Writing to refs/heads/Verny
DONE: 2385 Verny 37f501fd2fd0d309b4d3fdce77bac13c84646423
Switching from 37f501fd2fd0d309b4d3fdce77bac13c84646423 to
0e1b0bb88f077b66c6cf537899ab6c0a69d5ec30 (/Cristian new code)
we do not like 'Cristian new code' as a tag name.
Cannot create tag Cristian new code: Bad file descriptor
--
This is a fatal error that stops the import.
regards,
On Tuesday 18 September 2007 03:29, Matthias Urlichs wrote:
> Some people seem to create SVN branch names with spaces
> or other shell metacharacters.
>
> Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
> ---
>
> Junio C Hamano:
> > > - open(H,"git-rev-parse --verify $parent |");
> > > + open(H,'-|',"git-rev-parse","--verify",$parent);
> >
> > I seem to be missing the context, but please describe what
> > problem this fixes in the commit log message. I guess some
> > people use shell metacharacters and/or SP in their branch names
> > and this is about that problem?
>
> Exactly. Sorry; it seems that the original question hasn't been posted
> to the mailing list.
>
> diff --git a/git-svnimport.perl b/git-svnimport.perl
> index d3ad5b9..aa5b3b2 100755
> --- a/git-svnimport.perl
> +++ b/git-svnimport.perl
> @@ -633,7 +633,7 @@ sub commit {
>
> my $rev;
> if($revision > $opt_s and defined $parent) {
> - open(H,"git-rev-parse --verify $parent |");
> + open(H,'-|',"git-rev-parse","--verify",$parent);
> $rev = <H>;
> close(H) or do {
> print STDERR "$revision: cannot find commit '$parent'!\n";
--
Dan Libby
Open Source Consulting
San Jose, Costa Rica
http://osc.co.cr
phone: 011 506 223 7382
Fax: 011 506 223 7359
^ permalink raw reply
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Dan Libby @ 2007-09-20 19:07 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20070918074753.GQ31176@kiste.smurf.noris.de>
Hi, it worked for the small test case. I am trying it on the large repo now,
and will let you know how it turns out. thanks!
On Tuesday 18 September 2007 01:47, Matthias Urlichs wrote:
> Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
> ---
> Please tell me whether that works for you.
>
> Somebody else, preferably its author, can fix git-svn. ;-)
>
> diff --git a/git-svnimport.perl b/git-svnimport.perl
> index d3ad5b9..aa5b3b2 100755
> --- a/git-svnimport.perl
> +++ b/git-svnimport.perl
> @@ -633,7 +633,7 @@ sub commit {
>
> my $rev;
> if($revision > $opt_s and defined $parent) {
> - open(H,"git-rev-parse --verify $parent |");
> + open(H,'-|',"git-rev-parse","--verify",$parent);
> $rev = <H>;
> close(H) or do {
> print STDERR "$revision: cannot find commit '$parent'!\n";
> --
> 1.5.2.5
--
Dan Libby
Open Source Consulting
San Jose, Costa Rica
http://osc.co.cr
phone: 011 506 223 7382
Fax: 011 506 223 7359
^ permalink raw reply
* Typo in git-svnimport
From: Mikael Magnusson @ 2007-09-20 19:16 UTC (permalink / raw)
To: git
Hi,
Found a typoe in the manpage for git-svnimport, says mote instead of more
in a place.
This is perhaps a bit silly, but if you want you can
git pull git://mikachu.ath.cx/git.git typo
--
Mikael Magnusson
^ permalink raw reply
* Re: Symbolic link documentation
From: Shawn O. Pearce @ 2007-09-20 19:16 UTC (permalink / raw)
To: Matt Seitz (matseitz); +Cc: git
In-Reply-To: <70952A932255A2489522275A628B97C3052E99F9@xmb-sjc-233.amer.cisco.com>
"Matt Seitz (matseitz)" <matseitz@cisco.com> wrote:
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> >
> > So Git handles symlinks in the working tree *without*
> > dereferencing them.
>
> Thanks. Is there a recommended procedure for tracking changes when the
> symlink target is outside the working tree?
Move the link target so its inside the working tree?
Git won't step outside of the working tree to look for or to record
changes. Its outside. We don't track things outside of the part
of the world you've asked us to track.
--
Shawn.
^ permalink raw reply
* RE: Symbolic link documentation
From: Matt Seitz (matseitz) @ 2007-09-20 19:11 UTC (permalink / raw)
To: git
In-Reply-To: <20070920181100.GV3099@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
From: spearce@spearce.org [mailto:spearce@spearce.org]
>
> So Git handles symlinks in the working tree *without*
> dereferencing them.
Thanks. Is there a recommended procedure for tracking changes when the
symlink target is outside the working tree?
--
Matt Seitz
Manager, File System Virtualization
Cisco Systems, Inc.
.:|:.:|:.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Matt Seitz.vcf --]
[-- Type: text/x-vcard; name="Matt Seitz.vcf", Size: 410 bytes --]
BEGIN:VCARD
VERSION:2.1
N:Seitz;Matt
FN:Matt Seitz
ORG:Cisco Systems, Inc
TITLE:Manager
TEL;WORK;VOICE:408-200-8000
ADR;WORK:;;3975 Freedom Circle, Floor 8;Santa Clara;CA;95054;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3975 Freedom Circle, Floor 8=0D=0ASanta Clara, CA 95054=0D=0AUnited States o=
f America
EMAIL;PREF;INTERNET:matseitz@cisco.com
REV:20070709T234049Z
END:VCARD
^ permalink raw reply
* Re: Symbolic link documentation
From: Matt Seitz @ 2007-09-20 18:50 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0709201851190.28395@racer.site>
"Johannes Schindelin" <Johannes.Schindelin@gmx.de> wrote in message
news:Pine.LNX.4.64.0709201851190.28395@racer.site...
>
> Well, he asked where the git user documentation talks about symbolic
> links, and I provided a pointer.
Thanks, I appreciated the pointers.
^ permalink raw reply
* Re: [PATCH] new test from the submodule chapter of the user manual
From: Johannes Schindelin @ 2007-09-20 18:47 UTC (permalink / raw)
To: Joel Becker; +Cc: Miklos Vajna, Junio C Hamano, git, J. Bruce Fields
In-Reply-To: <20070920175952.GC30391@tasint.org>
Hi,
On Thu, 20 Sep 2007, Joel Becker wrote:
> On Thu, Sep 20, 2007 at 07:08:31PM +0200, Miklos Vajna wrote:
> > +test_expect_success "create the submodules" '
> > + for i in a b c d
> > + do
> > + mkdir $i &&
> > + cd $i &&
> > + git init &&
> > + echo "module $i" > $i.txt &&
> > + git add $i.txt &&
> > + git commit -m "Initial commit, submodule $i" &&
> > + cd ..
> > + done
>
> Silly question: why use the '&&' when you can 'set -e'? As it
> currently stands, a failure will still go back around the loop...
A "set -e" will make the script exit AFAIR. That's not what we want. A
simple "|| break" after the "cd .." will work, though.
Ciao,
Dscho
^ permalink raw reply
* Re: Symbolic link documentation
From: Shawn O. Pearce @ 2007-09-20 18:11 UTC (permalink / raw)
To: Matt Seitz (matseitz); +Cc: git
In-Reply-To: <70952A932255A2489522275A628B97C3052E993B@xmb-sjc-233.amer.cisco.com>
"Matt Seitz (matseitz)" <matseitz@cisco.com> wrote:
> The git-update-index and git-update-ref manual references are the
> closest to what I was looking for. Both are more low-level and
> technical than what I was hoping for, and the discussion in
> git-update-index seems targeted primarily at how symlinks are translated
> on file systems that don't support symlinks.
>
> I guess I was looking for something like the GNU "tar" documentation of
> how symlinks are handled
> (http://www.gnu.org/software/tar/manual/html_node/dereference.html#deref
> erence).
Git never dereferences a symlink that are stored as part of the
revision data. The only time we dereference a symlink is when it
is used inside of .git/refs, or as .git/HEAD, which is what the
git-update-ref manpage was talking about.
So Git handles symlinks in the working tree *without* dereferencing
them. Internally we store the target of the symlink, much as
tar would store the target of the symlink. There is no way to
activate a dereference behavior (--dereference / -h in GNU tar)
as typically you want to preseve the symlink as a symlink to the
target; its part of your source code.
Maybe this is a good hint that the user manual should have a section
on symbolic links. Its obvious to old Git hands that a symlink is
nothing more than a file with a slightly different mode, but that
may not be obvious to people who are new to Git.
--
Shawn.
^ permalink raw reply
* RE: Symbolic link documentation
From: Matt Seitz (matseitz) @ 2007-09-20 17:52 UTC (permalink / raw)
To: git
In-Reply-To: <20070920172736.GU3099@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
From: spearce@spearce.org [mailto:spearce@spearce.org]
>
> > Documentation/git-update-index.txt:to 'false' (see
> > gitlink:git-config[1]), symbolic links are checked out
> Documentation/git-update-index.txt:from symbolic link to regular file.
> > Documentation/technical/racy-git.txt:files vs symbolic links) and
> > executable bits (only for regular
>
> These are probably what Matt was looking for.
The git-update-index and git-update-ref manual references are the
closest to what I was looking for. Both are more low-level and
technical than what I was hoping for, and the discussion in
git-update-index seems targeted primarily at how symlinks are translated
on file systems that don't support symlinks.
I guess I was looking for something like the GNU "tar" documentation of
how symlinks are handled
(http://www.gnu.org/software/tar/manual/html_node/dereference.html#deref
erence).
--
Matt Seitz
Manager, File System Virtualization
Cisco Systems, Inc.
.:|:.:|:.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Matt Seitz.vcf --]
[-- Type: text/x-vcard; name="Matt Seitz.vcf", Size: 410 bytes --]
BEGIN:VCARD
VERSION:2.1
N:Seitz;Matt
FN:Matt Seitz
ORG:Cisco Systems, Inc
TITLE:Manager
TEL;WORK;VOICE:408-200-8000
ADR;WORK:;;3975 Freedom Circle, Floor 8;Santa Clara;CA;95054;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3975 Freedom Circle, Floor 8=0D=0ASanta Clara, CA 95054=0D=0AUnited States o=
f America
EMAIL;PREF;INTERNET:matseitz@cisco.com
REV:20070709T234049Z
END:VCARD
^ permalink raw reply
* Re: [PATCH] new test from the submodule chapter of the user manual
From: Joel Becker @ 2007-09-20 17:59 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <20070920170831.GQ16235@genesis.frugalware.org>
On Thu, Sep 20, 2007 at 07:08:31PM +0200, Miklos Vajna wrote:
> +test_expect_success "create the submodules" '
> + for i in a b c d
> + do
> + mkdir $i &&
> + cd $i &&
> + git init &&
> + echo "module $i" > $i.txt &&
> + git add $i.txt &&
> + git commit -m "Initial commit, submodule $i" &&
> + cd ..
> + done
Silly question: why use the '&&' when you can 'set -e'? As it
currently stands, a failure will still go back around the loop...
Joel
--
"Sometimes when reading Goethe I have the paralyzing suspicion
that he is trying to be funny."
- Guy Davenport
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: Symbolic link documentation
From: Johannes Schindelin @ 2007-09-20 17:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matt Seitz (matseitz), git
In-Reply-To: <20070920172736.GU3099@spearce.org>
Hi,
On Thu, 20 Sep 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 20 Sep 2007, Matt Seitz (matseitz) wrote:
> >
> > > Where does the git user documentation discuss how git handles
> > > symbolic links?
> >
> > $ git grep symbolic Documentation/ | grep link
> > [...]
> > Documentation/config.txt: If false, symbolic links are checked out as small plain files that
> > Documentation/config.txt: symbolic links. True by default.
> > Documentation/git-update-index.txt:to 'false' (see gitlink:git-config[1]), symbolic links are checked out
> > Documentation/git-update-index.txt:from symbolic link to regular file.
> > Documentation/technical/racy-git.txt:files vs symbolic links) and executable bits (only for regular
>
> These are probably what Matt was looking for.
Well, he asked where the git user documentation talks about symbolic
links, and I provided a pointer.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] new test from the submodule chapter of the user manual
From: Miklos Vajna @ 2007-09-20 17:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <Pine.LNX.4.64.0709201133590.28395@racer.site>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Thu, Sep 20, 2007 at 11:34:25AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 19 Sep 2007, Junio C Hamano wrote:
> > Looks Ok to me, although I didn't verify the examples by
> > actually running them myself this time (last round I did).
>
> So maybe we should do the same as with the tutorial: stick the examples
> into a test script?
what about this?
t/t3060-subprojects-tutorial.sh | 62 +++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100755 t/t3060-subprojects-tutorial.sh
diff --git a/t/t3060-subprojects-tutorial.sh b/t/t3060-subprojects-tutorial.sh
new file mode 100755
index 0000000..2fcf4ab
--- /dev/null
+++ b/t/t3060-subprojects-tutorial.sh
@@ -0,0 +1,62 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Miklos Vajna
+#
+
+test_description='A simple subprojects tutorial in the form of a test case'
+
+. ./test-lib.sh
+
+test_expect_success "create the submodules" '
+ for i in a b c d
+ do
+ mkdir $i &&
+ cd $i &&
+ git init &&
+ echo "module $i" > $i.txt &&
+ git add $i.txt &&
+ git commit -m "Initial commit, submodule $i" &&
+ cd ..
+ done
+'
+
+test_expect_success "create the superproject" '
+ mkdir super &&
+ cd super &&
+ git init &&
+ for i in a b c d
+ do
+ git submodule add '`pwd`'/$i
+ done
+'
+
+test_expect_success "commit in the superproject" '
+ git commit -m "Add submodules a, b, c and d." &&
+ cd ..
+'
+
+test_expect_success "clone the superproject" '
+ git clone super cloned &&
+ cd cloned
+'
+
+test_expect_success "submodule init" '
+ git submodule init
+'
+
+test_expect_success "submodule update" '
+ git submodule update
+'
+
+test_expect_success "update the submodule from within the superproject" '
+ cd a &&
+ echo "adding a line again" >> a.txt &&
+ git commit -a -m "Updated the submodule from within the superproject." &&
+ git push &&
+ cd .. &&
+ git add a &&
+ git commit -m "Updated submodule a." &&
+ git push
+'
+
+test_done
--
1.5.3.2.80.g077d6f-dirty
^ permalink raw reply related
* Re: Symbolic link documentation
From: Shawn O. Pearce @ 2007-09-20 17:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matt Seitz (matseitz), git
In-Reply-To: <Pine.LNX.4.64.0709201819340.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 20 Sep 2007, Matt Seitz (matseitz) wrote:
>
> > Where does the git user documentation discuss how git handles symbolic
> > links?
>
> $ git grep symbolic Documentation/ | grep link
> Documentation/RelNotes-1.5.0.2.txt: in place of the symbolic link. The default strategy,
> Documentation/RelNotes-1.5.0.2.txt: that was pointed at by the symbolic link. Both of these
> Documentation/RelNotes-1.5.0.2.txt: when changes to a symbolic link conflicted. It should have
> Documentation/RelNotes-1.5.0.2.txt: file the symbolic link pointed at.
> Documentation/RelNotes-1.5.1.5.txt: directory $PWD points at is a symbolic link.
> Documentation/RelNotes-1.5.1.6.txt: directory $PWD points at is a symbolic link.
> Documentation/RelNotes-1.5.1.txt: in place of the symbolic link. The default strategy,
> Documentation/RelNotes-1.5.1.txt: that was pointed at by the symbolic link. Both of these
> Documentation/RelNotes-1.5.1.txt: when changes to a symbolic link conflicted. It should have
> Documentation/RelNotes-1.5.1.txt: file the symbolic link pointed at.
> Documentation/RelNotes-1.5.3.2.txt: - an untracked symbolic link to a directory made it fart;
Many of these release notes are talking about bugs that we fixed
related to switching between revisions where in one revision the
path was a symlink and in the other revision it was a directory or
a file (or vice-versa).
> Documentation/config.txt: If false, symbolic links are checked out as small plain files that
> Documentation/config.txt: symbolic links. True by default.
> Documentation/git-update-index.txt:to 'false' (see gitlink:git-config[1]), symbolic links are checked out
> Documentation/git-update-index.txt:from symbolic link to regular file.
> Documentation/technical/racy-git.txt:files vs symbolic links) and executable bits (only for regular
These are probably what Matt was looking for.
> Documentation/config.txt: and other symbolic reference files, use symbolic links.
> Documentation/config.txt: expect HEAD to be a symbolic link.
> Documentation/core-tutorial.txt: This is similar to a symbolic link and points at
> Documentation/git-local-fetch.txt: Instead of regular file-to-file copying use symbolic links to the objects
> Documentation/git-symbolic-ref.txt:In the past, `.git/HEAD` was a symbolic link pointing at
> Documentation/git-symbolic-ref.txt:advertised (horrors). Therefore symbolic links are now deprecated
> Documentation/git-update-ref.txt:these symbolic pointers, whether they are symlinks or these
> Documentation/git-update-ref.txt:"regular file symbolic refs". It follows *real* symlinks only
> Documentation/glossary.txt: references are manipulated with the gitlink:git-symbolic-ref[1]
> Documentation/repository-layout.txt: a symbolic link instead of a symref that points at the current
These are all about how Git stores refs, and how HEAD used to be
a symbolic link but has since changed to a symbolic reference...
So less useful to what he was looking for I think.
--
Shawn.
^ permalink raw reply
* Re: Symbolic link documentation
From: Shawn O. Pearce @ 2007-09-20 17:25 UTC (permalink / raw)
To: Matt Seitz (matseitz); +Cc: git
In-Reply-To: <70952A932255A2489522275A628B97C3052E98EB@xmb-sjc-233.amer.cisco.com>
"Matt Seitz (matseitz)" <matseitz@cisco.com> wrote:
> Where does the git user documentation discuss how git handles symbolic
> links?
About the only mention I can find appears to be in git-config where
it talks a little bit about the core.symlinks configuration option.
But in general Git treats symlinks as though they were plain text
files. The content of the "file" is the target of the symlink.
Use `git-add link` to stage the symlink for the next commit (just
like a file), `git-mv` to rename a symlink (just like a file), etc.
Editing a symlink to point to a new target is just a matter of
using the OS' tools (e.g. `ln -sf newdst link`).
So long as core.symlinks isn't set or is set to true Git will
recreate the symlink upon checkout of the revision, just like it
recreates plain text files.
--
Shawn.
^ permalink raw reply
* Re: Symbolic link documentation
From: Johannes Schindelin @ 2007-09-20 17:20 UTC (permalink / raw)
To: Matt Seitz (matseitz); +Cc: git
In-Reply-To: <70952A932255A2489522275A628B97C3052E98EB@xmb-sjc-233.amer.cisco.com>
Hi,
On Thu, 20 Sep 2007, Matt Seitz (matseitz) wrote:
> Where does the git user documentation discuss how git handles symbolic
> links?
$ git grep symbolic Documentation/ | grep link
Documentation/RelNotes-1.5.0.2.txt: in place of the symbolic link. The default strategy,
Documentation/RelNotes-1.5.0.2.txt: that was pointed at by the symbolic link. Both of these
Documentation/RelNotes-1.5.0.2.txt: when changes to a symbolic link conflicted. It should have
Documentation/RelNotes-1.5.0.2.txt: file the symbolic link pointed at.
Documentation/RelNotes-1.5.1.5.txt: directory $PWD points at is a symbolic link.
Documentation/RelNotes-1.5.1.6.txt: directory $PWD points at is a symbolic link.
Documentation/RelNotes-1.5.1.txt: in place of the symbolic link. The default strategy,
Documentation/RelNotes-1.5.1.txt: that was pointed at by the symbolic link. Both of these
Documentation/RelNotes-1.5.1.txt: when changes to a symbolic link conflicted. It should have
Documentation/RelNotes-1.5.1.txt: file the symbolic link pointed at.
Documentation/RelNotes-1.5.3.2.txt: - an untracked symbolic link to a directory made it fart;
Documentation/config.txt: If false, symbolic links are checked out as small plain files that
Documentation/config.txt: symbolic links. True by default.
Documentation/config.txt: and other symbolic reference files, use symbolic links.
Documentation/config.txt: expect HEAD to be a symbolic link.
Documentation/core-tutorial.txt: This is similar to a symbolic link and points at
Documentation/git-local-fetch.txt: Instead of regular file-to-file copying use symbolic links to the objects
Documentation/git-symbolic-ref.txt:In the past, `.git/HEAD` was a symbolic link pointing at
Documentation/git-symbolic-ref.txt:advertised (horrors). Therefore symbolic links are now deprecated
Documentation/git-update-index.txt:to 'false' (see gitlink:git-config[1]), symbolic links are checked out
Documentation/git-update-index.txt:from symbolic link to regular file.
Documentation/git-update-ref.txt:these symbolic pointers, whether they are symlinks or these
Documentation/git-update-ref.txt:"regular file symbolic refs". It follows *real* symlinks only
Documentation/glossary.txt: references are manipulated with the gitlink:git-symbolic-ref[1]
Documentation/repository-layout.txt: a symbolic link instead of a symref that points at the current
Documentation/technical/racy-git.txt:files vs symbolic links) and executable bits (only for regular
Hth,
Dscho
^ permalink raw reply
* Symbolic link documentation
From: Matt Seitz (matseitz) @ 2007-09-20 17:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 170 bytes --]
Where does the git user documentation discuss how git handles symbolic
links?
--
Matt Seitz
Manager, File System Virtualization
Cisco Systems, Inc.
.:|:.:|:.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Matt Seitz.vcf --]
[-- Type: text/x-vcard; name="Matt Seitz.vcf", Size: 410 bytes --]
BEGIN:VCARD
VERSION:2.1
N:Seitz;Matt
FN:Matt Seitz
ORG:Cisco Systems, Inc
TITLE:Manager
TEL;WORK;VOICE:408-200-8000
ADR;WORK:;;3975 Freedom Circle, Floor 8;Santa Clara;CA;95054;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3975 Freedom Circle, Floor 8=0D=0ASanta Clara, CA 95054=0D=0AUnited States o=
f America
EMAIL;PREF;INTERNET:matseitz@cisco.com
REV:20070709T234049Z
END:VCARD
^ permalink raw reply
* Re: [PATCH] Prevent using bold text in entire gui for some fonts sometimes
From: Shawn O. Pearce @ 2007-09-20 17:01 UTC (permalink / raw)
To: Simon Sasburg; +Cc: git
In-Reply-To: <981e6de60709181533o24ef0e45w7925070b5e78ef56@mail.gmail.com>
Simon Sasburg <simon.sasburg@gmail.com> wrote:
> When I first saw git-gui on windows, I noticed it wasn't using ugly
> bold fonts for it's entire gui like it was in linux. I came up with
> the following patch to fix this there.
>
> And it worked, trange thing was, even git-gui without this patch
> applied was using normal fonts now. The patch didn't seem to make any
> difference for me anymore. So I chalked this up to weirdness of my
> system.
>
> Yesterday though a saw that a friends git-gui was showing the same
> problem with the entire gui being in bold text. And this patch fixed
> it.
>
> So its a bit weird that this patch seemed to have 'permanent' effects
> for me, even after it was reverted.... but on the other hand it's
> really trivial.
Yea, I can't explain that either. But this patch is really trivial
so I'm applying it anyway. Doesn't break anyone who was already
using a normal weight on their font and it should prevent others
from picking up bold everywhere. Thanks.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/5] strbuf API additions and enhancements.
From: Jeff King @ 2007-09-20 16:10 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: git
In-Reply-To: <87lkb1iz0i.fsf@Astalo.kon.iki.fi>
On Thu, Sep 20, 2007 at 10:20:29AM +0300, Kalle Olavi Niemitalo wrote:
> Normative text in 7.15p3 confirms this: "The object ap may be
> passed as an argument to another function; if that function
> invokes the va_arg macro with parameter ap, the value of ap in
> the calling function is indeterminate and shall be passed to the
> va_end macro prior to any further reference to ap."
>
> Therefore va_copy is needed here, at least in principle.
Not just in principle; a few months ago, I ran afoul of the same issue
using gcc + glibc6, so it is a real problem for our target platforms
(sorry, I don't have a test case anymore, but I recall getting
undefined-ish behavior from my print statements).
-Peff
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: David Brown @ 2007-09-20 15:16 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200709192103.53526.simon@lst.de>
On Wed, Sep 19, 2007 at 09:03:50PM +0200, Simon Hausmann wrote:
>On Wednesday 19 September 2007 20:15:03 David Brown wrote:
>> git-p4 was missing the execute bit setting if the file had other attribute
>> bits set.
>> ---
>I'm fine with this, so unless you find a better way:
>
>Acked-By: Simon Hausmann <simon@lst.de>
I sent out an improved version of this patch yesterday
<1190232768445-git-send-email-git@davidb.org> that I'd like to get
approved. I guess I'm not quite sure what happens at this point with a
patch.
Thanks,
David
^ 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