bug report, v1.7.12.1 -- user-manual.xml:3739: parser error
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 emphasis role=strong/literal, but is actually expected to be a poin
^
user-manual.xml:3741: parser error : Opening and ending tag mismatch: literal
line 3741 and emphasis
mit. Note that whenever a SHA-1 is passed as literalunsigned char /emphasis
^
unable to parse user-manual.xml
make[1]: *** [user-manual.html] Error 6
make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation'
make: *** [doc] Error 2
--
Hugh Esco
skype: hresco3_ ; 678-921-8186 x21
http://www.CampaignFoundations.com/
Providing Application Hosting, Telephony,
Custom Development and Consulting Services
to Green Candidates, Green Parties and
the non profits working for a just and sustainable future.
if( $insurance-rationing() ) { $people-die(); }
if( isa_ok($self,'Troy::Davis') =~ m/^ok/) { $people-are_whole(); }
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report, v1.7.12.1 -- user-manual.xml:3739: parser error
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 emphasis role=strong/literal, but is actually expected to be a poin
^
user-manual.xml:3741: parser error : Opening and ending tag mismatch: literal
line 3741 and emphasis
mit. Note that whenever a SHA-1 is passed as literalunsigned char /emphasis
^
unable to parse user-manual.xml
make[1]: *** [user-manual.html] Error 6
make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation'
make: *** [doc] Error 2
--
and the patch which permitted me to proceed
although it removes a malformed emphasis tag
--
3739c3739
char /literal, but is actually expected to be a pointer to
literalunsigned
---
char emphasis role=strong/literal, but is actually expected to be a
pointer to literalunsigned
3741c3741
commit. Note that whenever a SHA-1 is passed as literalunsigned char
/literal, it
---
commit. Note that whenever a SHA-1 is passed as literalunsigned char
/emphasis/literal, it
--
I've encountered another issue with:
Documentation/git-bundle.xml
I will post the details in a distinct message,
perhaps even with another patch if I can sort this out.
--
Hugh Esco
skype: hresco3_ ; 678-921-8186 x21
http://www.CampaignFoundations.com/
Providing Application Hosting, Telephony,
Custom Development and Consulting Services
to Green Candidates, Green Parties and
the non profits working for a just and sustainable future.
if( $insurance-rationing() ) { $people-die(); }
if( isa_ok($self,'Troy::Davis') =~ m/^ok/) { $people-are_whole(); }
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug report, v1.7.12.1 -- user-manual.xml:3739: parser error
Hugh Esco he...@campaignfoundations.com 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 emphasis role=strong/literal, but is actually expected to be a poin ^ user-manual.xml:3741: parser error : Opening and ending tag mismatch: literal line 3741 and emphasis mit. Note that whenever a SHA-1 is passed as literalunsigned char /emphasis ^ unable to parse user-manual.xml make[1]: *** [user-manual.html] Error 6 make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation' make: *** [doc] Error 2 Thanks for a report. I and other regulars on the list who run make doc are not getting that error (otherwise the source wouldn't have tagged as a release), so there must be some difference between the environments that are supported and your setting. As described in the INSTALL document at the top-level of the source tree, our documentation toolchain has external dependencies on asciidoc, xmlto, and docbook-xsl among other things. My quick check seems indicate that I am using asciidoc 8.5.2-1, xmlto 0.0.23-2, and docbook-xsl 1.75.2. What version are you using? It could be you are using a newer version of something that is backward incompatible we haven't encountered (or you could be using a version that is too stale). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report, v1.7.12.1 -- Documentation/git-check-ref-format.xml:162: parser error
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
megt; is allowed to contain a single literalemphasis role=strong/literal
^
/usr/local/git-git-51993a4/Documentation/git-check-ref-format.xml:164: parser
error : Opening and ending tag mismatch: literal line 164 and emphasis
literalfoo//emphasis/bar/literal but not literalfoo/bar*/litera
^
make[1]: *** [git-check-ref-format.1] Error 1
make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation'
make: *** [doc] Error 2
---
and the patch which permitted me to proceed
---
162c162
enabled, lt;refnamegt; is allowed to contain a single
literal/literal
---
enabled, lt;refnamegt; is allowed to contain a single
literalemphasis role=strong/literal
164c164
literalfoo/bar/literal but not literalfoo/bar*/literal).
---
literalfoo//emphasis/bar/literal but not
literalfoo/bar*/literal).
---
Next issue shows up in:
Documentation/git-config.xml
details coming under separate cover.
--
Hugh Esco
skype: hresco3_ ; 678-921-8186 x21
http://www.CampaignFoundations.com/
Providing Application Hosting, Telephony,
Custom Development and Consulting Services
to Green Candidates, Green Parties and
the non profits working for a just and sustainable future.
if( $insurance-rationing() ) { $people-die(); }
if( isa_ok($self,'Troy::Davis') =~ m/^ok/) { $people-are_whole(); }
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report, v1.7.12.1 -- Documentation/git-config.xml:643: parser error
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/literal is subject to tilde expansion: literalsubscript//literal ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:644: parser error : Opening and ending tag mismatch: literal line 644 and subscript is expanded to the value of literal$HOME/literal, and literal/subscriptu ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:1354: parser error : Opening and ending tag mismatch: subscript line 1354 and literal of files which are not meant to be tracked. literalsubscript//literal ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:1355: parser error : Opening and ending tag mismatch: literal line 1355 and subscript to the value of literal$HOME/literal and literal/subscriptuser/ ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:2304: parser error : Opening and ending tag mismatch: subscript line 2304 and literal literalsubscript//literal is expanded to the value of literal$ ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:2304: parser error : Opening and ending tag mismatch: literal line 2304 and subscript is expanded to the value of literal$HOME/literal and literal/subscript ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4609: parser error : Opening and ending tag mismatch: emphasis line 4609 and literal oes not understand the version 2 literalemphasis role=strong.idx/literal ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4611: parser error : Opening and ending tag mismatch: literal line 4611 and emphasis that will copy both literal/emphasis.pack/literal file and corresponding ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4611: parser error : Opening and ending tag mismatch: emphasis line 4611 and literal /literal file and corresponding literalemphasis role=strong.idx/literal ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4613: parser error : Opening and ending tag mismatch: literal line 4613 and emphasis older version of git. If the literal/emphasis.pack/literal file is smaller ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4617: parser error : Opening and ending tag mismatch: literal line 4617 and emphasis the literal/emphasis.idx/literal file./simpara ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4617: parser error : Opening and ending tag mismatch: emphasis line 4616 and literal the literal/emphasis.idx/literal file./simpara ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4666: parser error : Opening and ending tag mismatch: emphasis line 4666 and literal ralgit config pretty.changelog format:emphasis role=strong %H %s/literal ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4668: parser error : Opening and ending tag mismatch: literal line 4668 and emphasis to be equivalent to running literalgit log --pretty=format:/emphasis ^ make[1]: *** [git-config.1] Error 1 make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation' make: *** [doc] Error 2 --- and the patch which permitted me to proceed --- 643,644c643,644 found. The value of literalinclude.path/literal is subject to tilde expansion: literal//literal is expanded to the value of literal$HOME/literal, and literaluser//literal to the specified --- found. The value of literalinclude.path/literal is subject to tilde expansion: literalsubscript//literal is expanded to the value of literal$HOME/literal, and literal/subscriptuser//literal to the specified 1354,1355c1354,1355 of files which are not meant to be tracked. literal//literal is expanded to the value of literal$HOME/literal and literaluser//literal to the specified user's --- of files which are not meant to be tracked. literalsubscript//literal is expanded
Re: bug report, v1.7.12.1 -- Documentation/git-bundle.xml:130: parser error
Hugh Esco he...@yourmessagedelivered.com 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 as literalmastersubscript1/literal cannot be packaged, but are
perfec
^
/usr/local/git-git-51993a4/Documentation/git-bundle.xml:134: parser error :
Opening and ending tag mismatch: literal line 134 and subscript
specified explicitly (e.g. literal^master/subscript10/literal), or
implici
^
make[1]: *** [git-bundle.1] Error 1
make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation'
make: *** [doc] Error 2
---
and the patch which permitted me to proceed
---
130c130
such as literalmaster/literalsubscript1/subscript cannot be
packaged, but are perfectly suitable for
PLEASE STOP.
git-anything.xml files are _not_ the source files we edit, so
patches to them are not useful for us.
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 would look like:
-such as `master~1` cannot be packaged,...
+such as `master{tilde}1` cannot be packaged,...
to work around this problem if the version of the problematic tool
you are using is widespread.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report, v1.7.12.1 -- Documentation/git-grep.xml:601: element literal: validity error
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
children
/usr/local/git-git-51993a4/Documentation/git-grep.xml:601: element literal:
validity error : Element emphasis is not declared in literal list of possible
children
/usr/local/git-git-51993a4/Documentation/git-grep.xml:612: element literal:
validity error : Element emphasis is not declared in literal list of possible
children
Document /usr/local/git-git-51993a4/Documentation/git-grep.xml does not validate
make[1]: *** [git-grep.1] Error 3
make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation'
make: *** [doc] Error 2
---
and the patch which permitted me to proceed
---
601c601
literalgit grep time_t #8212; *.[ch]/literal
---
literalgit grep emphasistime_t/emphasis #8212;
emphasis*.[ch]/emphasis/literal
612c612
literalgit grep -e #define --and \( -e MAX_PATH -e PATH_MAX \)/literal
---
literalgit grep -e emphasis#define/emphasis --and \( -e MAX_PATH -e
PATH_MAX \)/literal
--
Hugh Esco
skype: hresco3_ ; 678-921-8186 x21
http://www.CampaignFoundations.com/
Providing Application Hosting, Telephony,
Custom Development and Consulting Services
to Green Candidates, Green Parties and
the non profits working for a just and sustainable future.
if( $insurance-rationing() ) { $people-die(); }
if( isa_ok($self,'Troy::Davis') =~ m/^ok/) { $people-are_whole(); }
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report, v1.7.12.1 -- Documentation/git-remote-helpers.xml:135: element literal: validity error
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 list of possible children /usr/local/git-git-51993a4/Documentation/git-remote-helpers.xml:144: element literal: validity error : Element emphasis is not declared in literal list of possible children /usr/local/git-git-51993a4/Documentation/git-remote-helpers.xml:246: element literal: validity error : Element emphasis is not declared in literal list of possible children /usr/local/git-git-51993a4/Documentation/git-remote-helpers.xml:255: element literal: validity error : Element emphasis is not declared in literal list of possible children Document /usr/local/git-git-51993a4/Documentation/git-remote-helpers.xml does not validate make[1]: *** [git-remote-helpers.1] Error 3 make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation' make: *** [doc] Error 2 --- and the patch which permitted me to proceed --- 135c135 literalrefspec refs/heads/:refs/svn/origin/branches//literal --- literalrefspec refs/heads/emphasis role=strong:refs/svn/origin/branches//emphasis/literal 144c144 there is an implied literalrefspec :/literal./simpara --- there is an implied literalrefspec emphasis role=strong:/emphasis/literal./simpara 246c246 literalrefspec refs/heads/:refs/svn/origin/branches//literal --- literalrefspec refs/heads/emphasis role=strong:refs/svn/origin/branches//emphasis/literal 255c255 there is an implied literalrefspec :/literal./simpara --- there is an implied literalrefspec emphasis role=strong:/emphasis/literal./simpara -- Hugh Esco 404-424-8701 YourMessageDelivered.com Keeping Your Group in the Loop No Matter How Large or How Small -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 8/9] longest_ancestor_length(): resolve symlinks before comparing paths
Michael Haggerty mhag...@alum.mit.edu 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 different even though they might logically refer to the same directory. So canonicalize the paths listed in prefix_list using real_path_if_valid() before trying to find matches. I somehow feel that this is making the logic unnecessarily convoluted by solving the problem at a wrong level. If longest_ancestor_length() takes a single string and a list of candidate string prefixes, conceptually it should be usable for any hierarchy-looking string that uses slashes as hierarchy separator (e.g. refs that may be stored in packed-refs that you cannot expect lstat(2) or readlink(2) to give you any sensible results). The real problem is that the list given from the environment may contain a path that violates that it suffices to take the longest string-prefix taking slashes into account assumption in such a generic l-a-l implementation, no? And this patch solves it by making l-a-l _less_ generic and forcing it to be aware of the glitch of its caller (you can either blame clueless user who lies when setting the GIT_CEILING_DIRECTORIES by including paths contaminated with symlinks, or blame the calling setup_git_directory_gently_1() function that does not resolve the symbolic links before calling this function). As l-a-l is only used by the stop at the ceiling logic, isn't it a far simpler solution to keep the function work at the string level, and make the caller fix its input, i.e. the value taken from the environment variable, before calling it? That is, grab the value of GIT_CEILING_DIRECTORIES, split it into a list at PATH_SEP (while rejecting any non-absolute paths), normalize the elements of that list by resolving symbolic links, and then pass the cwd[] and the normalized string list to l-a-l? The resulting callsite in setup_git_directory_gently_1() would pass cwd[] and the ceiling_dirs (which now is a string list), all of whose elements would happen to begin with / (or dos drive prefix followed by the root symbol), but l-a-l can be written in such a way that it does not even require that all the input has to begin at root, which would later make it usable with things that are not paths (references, for example, all of which begin with refs/ and not /refs/). Hrm? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report, v1.7.12.1 -- Documentation/git-rev-parse.xml:264: parser error
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
literalemphasis role=strong/literal, or literal[/literal), it is tur
^
/usr/local/git-git-51993a4/Documentation/git-rev-parse.xml:264: parser error :
Opening and ending tag mismatch: literal line 264 and emphasis
/literal), it is turned into a prefix match by appending literal//emphasis
^
/usr/local/git-git-51993a4/Documentation/git-rev-parse.xml:277: parser error :
Opening and ending tag mismatch: emphasis line 277 and literal
character (literal?/literal, literalemphasis role=strong/literal
^
/usr/local/git-git-51993a4/Documentation/git-rev-parse.xml:278: parser error :
Opening and ending tag mismatch: literal line 278 and emphasis
match by appending literal//emphasis/literal.
^
make[1]: *** [git-rev-parse.1] Error 1
make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation'
make: *** [doc] Error 2
---
and the patch which permitted me to proceed
---
264c264
literal/literal, or literal[/literal), it is turned into a prefix
match by appending literal//literal./simpara
---
literalemphasis role=strong/literal, or literal[/literal), it is
turned into a prefix match by appending
literal//emphasis/literal./simpara
277,278c277,278
character (literal?/literal, literal/literal, or
literal[/literal), it is turned into a prefix
match by appending literal//literal.
---
character (literal?/literal, literalemphasis
role=strong/literal, or literal[/literal), it is turned into a prefix
match by appending literal//emphasis/literal.
--
Hugh Esco
skype: hresco3_ ; 678-921-8186 x21
http://www.CampaignFoundations.com/
Providing Application Hosting, Telephony,
Custom Development and Consulting Services
to Green Candidates, Green Parties and
the non profits working for a just and sustainable future.
if( $insurance-rationing() ) { $people-die(); }
if( isa_ok($self,'Troy::Davis') =~ m/^ok/) { $people-are_whole(); }
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report, v1.7.12.1 -- Documentation/git-rm.xml:151: element literal: validity error
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 list of possible
children
/usr/local/git-git-51993a4/Documentation/git-rm.xml:151: element literal:
validity error : Element emphasis is not declared in literal list of possible
children
Document /usr/local/git-git-51993a4/Documentation/git-rm.xml does not validate
make[1]: *** [git-rm.1] Error 3
make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation'
make: *** [doc] Error 2
---
and the patch which permitted me to proceed
---
151c151
using literalgit rm d*/literal and literalgit rm d/*/literal, as the
former will
---
using literalgit rm emphasisd*/emphasis/literal and literalgit rm
emphasisd/*/emphasis/literal, as the former will
--
Hugh Esco
skype: hresco3_ ; 678-921-8186 x21
http://www.CampaignFoundations.com/
Providing Application Hosting, Telephony,
Custom Development and Consulting Services
to Green Candidates, Green Parties and
the non profits working for a just and sustainable future.
if( $insurance-rationing() ) { $people-die(); }
if( isa_ok($self,'Troy::Davis') =~ m/^ok/) { $people-are_whole(); }
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report, v1.7.12.1 -- Documentation/gitcore-tutorial.xml:824: parser error
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 (notice the asterisk literalemphasis role=strong/literal character), and ^ /usr/local/git-git-51993a4/Documentation/gitcore-tutorial.xml:828: parser error : Opening and ending tag mismatch: literal line 828 and emphasis All of them have non blank characters in the first column (literal/emphasis ^ /usr/local/git-git-51993a4/Documentation/gitcore-tutorial.xml:1263: parser error : Opening and ending tag mismatch: emphasis line 1263 and literal raYou will see two files, literalpack-emphasis role=strong.pack/literal ^ /usr/local/git-git-51993a4/Documentation/gitcore-tutorial.xml:1263: parser error : Opening and ending tag mismatch: literal line 1263 and emphasis teralpack-emphasis role=strong.pack/literal and literalpack-/emphasis ^ make[1]: *** [gitcore-tutorial.7] Error 1 make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation' make: *** [doc] Error 2 --- and the patch which permitted me to proceed --- 824c824 (notice the asterisk literal/literal character), and the first column for --- (notice the asterisk literalemphasis role=strong/literal character), and the first column for 828c828 All of them have non blank characters in the first column (literal/literal --- All of them have non blank characters in the first column (literal/emphasis/literal 1263c1263 notesimparaYou will see two files, literalpack-.pack/literal and literalpack-.idx/literal, --- notesimparaYou will see two files, literalpack-emphasis role=strong.pack/literal and literalpack-/emphasis.idx/literal, -- Hugh Esco 404-424-8701 YourMessageDelivered.com Keeping Your Group in the Loop No Matter How Large or How Small -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.7.12.2
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 5722156394c7478b2339a1d87aa894bc4d2f5d6b git-htmldocs-1.7.12.2.tar.gz 8cf6fd255e83226b4abcdcd68dcf315c1995fd92 git-manpages-1.7.12.2.tar.gz Also the following public repositories all have a copy of the v1.7.12.2 tag and the maint branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git 1.7.12.2 Release Notes == Fixes since v1.7.12.1 - * When git am is fed an input that has multiple Content-type: ... header, it did not grok charset= attribute correctly. * Even during a conflicted merge, git blame $path always meant to blame uncommitted changes to the working tree version; make it more useful by showing cleanly merged parts as coming from the other branch that is being merged. * git blame MAKEFILE run in a history that has Makefile but not MAKEFILE should say No such file MAKEFILE in HEAD, but got confused on a case insensitive filesystem and failed to do so. * git fetch --all, when passed --no-tags, did not honor the --no-tags option while fetching from individual remotes (the same issue existed with --tags, but combination --all --tags makes much less sense than --all --no-tags). * git log/diff/format-patch --stat showed the N line(s) added comment in user's locale and caused careless submitters to send patches with such a line in them to projects whose project language is not their language, mildly irritating others. Localization to the line has been disabled for now. * git log --all-match --grep=A --grep=B ought to show commits that mention both A and B, but when these three options are used with --author or --committer, it showed commits that mention either A or B (or both) instead. * The subcommand to remove the definition of a remote in git remote was named rm even though all other subcommands were spelled out. Introduce git remote remove to remove confusion, and keep rm as a backward compatible synonym. Also contains a handful of documentation updates. Changes since v1.7.12.1 are as follows: Dan Johnson (1): fetch --all: pass --tags/--no-tags through to each remote David Gould (1): run-command.c: fix broken list iteration in clear_child_for_cleanup Felipe Contreras (1): completion: fix shell expansion of items Jeff King (4): argv-array: add pop function argv-array: fix bogus cast when freeing array fetch: use argv_array instead of hand-building arrays Revert completion: fix shell expansion of items Jens Lehmann (1): submodule: use argv_array instead of hand-building arrays Jeremy White (1): Documentation: describe subject more precisely Jonathan Duke Leto (1): Improve the description of GIT_PS1_SHOWUPSTREAM Junio C Hamano (11): mailinfo: strip RE: prefix blame $path: avoid getting fooled by case insensitive filesystems blame: allow blame file in the middle of a conflicted merge grep: teach --debug option to dump the parse tree log --grep/--author: honor --all-match honored for multiple --grep patterns log: document use of multiple commit limiting options grep.c: mark private file-scope symbols as static mailinfo: do not concatenate charset= attribute values from mime headers grep.c: make two symbols really file-scope static this time Start preparation for 1.7.12.2 Git 1.7.12.2 Michael J Gruber (6): grep: show --debug output only once t7810-grep: bring log --grep tests in common form t7810-grep: test multiple --grep with and without --all-match t7810-grep: test multiple --author with --all-match t7810-grep: test interaction of multiple --grep and --author options t7810-grep: test --all-match with multiple --grep and --author options Nguyễn Thái Ngọc Duy (3): remote: prefer subcommand name 'remove' to 'rm' doc: move rev-list option -n from git-log.txt to rev-list-options.txt Revert diffstat back to English Ralf Thielow (1): l10n: de.po: correct translation of a 'rebase' message Stefan Naewe (1): ls-remote: document the '--get-url' option Stephen Boyd (1): Documentation: Document signature showing options Thynson (2): l10n: Unify the translation for '(un)expected' l10n: Improve many translation for zh_CN -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to
gitk: can't reload commits with new key binding
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 ideas? Thanks, Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git smart-http do not authent to allow git ls-remote to be called anonymously
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-receive-pack /etc/apache/httpd.conf LocationMatch ^/git/.*/git-(upload|receive)-pack$ AuthType Basic AuthName staff only AuthUserFile /etc/apache/apache.pwd Require valid-user /LocationMatch However this does not work. It does not ask for password at all. I use Ubuntu 10.04, Apache 2.2.14, Git 1.7.11.3. Directory structure: any depth (more than 1 subdir) of path from /git to .git folders Could you advise how to configure this? Is this a bug? Regards, ch3cooli -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Merging/joining two repos (repo2 should be a subdirectory of repo1)
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 files (at least e.g. .gitignore) in their root directories. Of course I could resolve the conflicts, but I don't want that. My naive approach is move everything in $repo2 one directory below and then merge $repo2 into $repo1. Actually I wouldn' call that a merge but an import. I know of git filter-branch --subdirectory-filter foodir but that's just the opposite of what I need. Is there a nifty trick to get this? Or will I have to do git filter-branch --tree-filter 'mkdir subdir git mv * subdir' --all on $repo2 and then git merge $repo2 in $repo1? Thanks in advance Dirk -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merging/joining two repos (repo2 should be a subdirectory of repo1)
Am 30.09.2012 17:24 schrieb Tomas Carnecky: On Sun, 30 Sep 2012 17:17:53 +0200, Dirk SÃŒsserott newslet...@dirk.my1.cc 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 subdirectory whithin repo1, including all the history of repo2. A simple git-merge won't do because both repos have some same files (at least e.g. .gitignore) in their root directories. Of course I could resolve the conflicts, but I don't want that. My naive approach is move everything in $repo2 one directory below and then merge $repo2 into $repo1. Actually I wouldn' call that a merge but an import. I know of git filter-branch --subdirectory-filter foodir but that's just the opposite of what I need. Is there a nifty trick to get this? Or will I have to do git filter-branch --tree-filter 'mkdir subdir git mv * subdir' --all on $repo2 and then git merge $repo2 in $repo1? http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html Wow! Thanks for that quick and *very* helpful answer! :-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merging/joining two repos (repo2 should be a subdirectory of repo1)
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug report, v1.7.12.1 -- Documentation/git-bundle.xml:130: parser error
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 would look like:
-such as `master~1` cannot be packaged,...
+such as `master{tilde}1` cannot be packaged,...
to work around this problem if the version of the problematic tool
you are using is widespread.
That would not work, as commit 6cf378f turned off no-inline-literal, and
modern asciidoc would not expand that {tilde} at all. My guess is that
Hugh is using a version of asciidoc older than 8.4.1, which was the
first version to understand inline literals.
This came up already once before:
http://thread.gmane.org/gmane.comp.version-control.git/198733
where the culprit was older third-party RPMs on RHEL5. It can be worked
around by upgrading asciidoc, or using make quick-install-doc to pull
the pre-built versions.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the hard coded length limit on variable names in config files
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 against master if that's better though. The preferred format for multiline comments in the git project is /* * Truncate the var name back to the section header prior to * grabbing the suffix part of the name and the value. */ Oops; Will fix. In the old code, get_base_var() read the string into var and returned var's length (or -1 on error). The fact that the length of var was first reset to zero is somewhat implicit in the fact that no length parameter is being passed to get_base_var(). But in the new version, get_base_var() is passed a strbuf. Often, operations with strbufs append to the strbuf, and this is what I first assumed. It took me a while to realize that get_base_var() calls strbuf_reset() before getting to work. Moreover, get_base_var() still returns the length of what it found, which is redundant with a strbuf and therefore unexpected. So when the return value of get_base_var() is stored into baselen, it is not really obvious that it is the string's length. Ok, that's a fair criticism. When I was creating the patch, I thought that placing the strbuf_reset in get_base_var() seemed nicer as it matched the baselen = 0 which effectively reset the old character array. Your point is well taken though and I think it makes sense to switch things around the way you've suggested. Finally, I realize that the MAXNAME constant was not exported and I can't find the old length limits documented anywhere, but I nevertheless worry a little bit that one of the users of the config API has a built-in assumption that names can never be longer than 256 characters (for example, a config_fn_t function might try to store the name into a fixed-length buffer). Hopefully such code would never have been written or accepted, but...? If you have thought about this or audited the callers, please mention that in your commit message. I did look through the code to see if anything was relying on fixed size buffers and I didn't see anything. I'll update the commit message with this info too. I'll send a modified patch shortly. Thanks for the review! -Ben -- --- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug report, v1.7.12.1 -- Documentation/git-bundle.xml:130: parser error
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 gitolite installed and presumably working on this
server and promise not to bother you further with
that issue.
-- Hugh Esco
Date: Sun, 30 Sep 2012 14:02:09 -0400
From: Jeff King p...@peff.net
To: Junio C Hamano gits...@pobox.com
Cc: he...@yourmessagedelivered.com, git@vger.kernel.org
Subject: Re: bug report, v1.7.12.1 -- Documentation/git-bundle.xml:130:
parser error
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 would look like:
-such as `master~1` cannot be packaged,...
+such as `master{tilde}1` cannot be packaged,...
to work around this problem if the version of the problematic tool
you are using is widespread.
That would not work, as commit 6cf378f turned off no-inline-literal, and
modern asciidoc would not expand that {tilde} at all. My guess is that
Hugh is using a version of asciidoc older than 8.4.1, which was the
first version to understand inline literals.
This came up already once before:
http://thread.gmane.org/gmane.comp.version-control.git/198733
where the culprit was older third-party RPMs on RHEL5. It can be worked
around by upgrading asciidoc, or using make quick-install-doc to pull
the pre-built versions.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Let git submodule add fail when .git/modules/name already exists
Am 30.09.2012 06:47, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de 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 when a submodule of that name already exists in .git/modules of the superproject together with the ability to provide a custom name might at least solve the local clashes. That assumes that the addition of the submodule for the second time is to add a completely different submodule at the same location and is done on purpose, but is that a sensible assumption? If a superproject that is about an embedded appliance used to have a submodule A bound at its path kernel, but for some reason stopped shipping with kernel and then later reintroduced the directory kernel bound to some submodule B, my gut feeling is that it is just as likely (if not more likely) that A and B are indeed the same submodule (i.e. it shares the same history) as they are totally unrelated. Could it be that it is a user error combined with the immaturity of git submodule tool that does not yet support it used to be here, but it disappears for a while and then it reappears in the history of the superproject very well that caused the user to manually add a new submodule which in fact is the same submodule at the same path? I think failing with a better error message is a good idea. It should suggest to either resurrect the submodule that is stashed away in $GIT_DIR/modules/$name if it indeed is the same, or to give it a different name (perhaps kernel used to be pointing at the Linux kernel history, then the user is replacing it with a totally different implementation that is really from different origin and do not share any history, perhaps BSD). In such a case, the user may want to pick bsd-kernel or something as its name, to differentiate it. 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. Using some kind of UUID can easily be added in a subsequent patch,... I would suggest thinking really long and hard before saying UUID. Absolutely. It is an easy cop-out to ensure uniqueness, but risks to allow two people (or one person at two different time) to give two unrelated names to a single thing that actually is the same. I'm not too worried about that (even though it would be good for the disk footprint). And I couldn't come up with a better way to solve the problem we currently have when the same name is used for two different submodule repos. A better alternative might be to use the commit object name at the root of the history of the submodule, which would catch the simplest and most common case of the mistake, I would think. This won't work well e.g. when one uses a fork of another repo, that will contain different commits while still having the same root commit. I was also thinking about hashing the URL, but that will break when the user reconfigures the URL to somewhere else. After playing with some ideas I couldn't find a way to let the submodule's repo provide sufficient uniqueness. I'd say for now we go with the detection of name clashes and let the user choose if he wants to resurrect that submodule repo or if he wants to choose another name. But if we notice further down the road that collisions are a problem in real life, we can think again if UUIDs - or something else - might be a solution. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove the hard coded length limit on variable names in config files
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 that was not subsequently readable.
Instead of enforcing this limitation for both reading and writing,
remove it entirely by changing the var member of the config_file
struct to a strbuf instead of a fixed length buffer. Update all of
the parsing functions in config.c to use the strbuf instead of the
static buffer.
The parsing functions that returned the base length of the variable
name now return simply 0 for success and -1 for failure. The base
length information is obtained through the strbuf's len member.
We now send the buf member of the strbuf to external callback
functions to preserve the external api. None of the external callers
rely on the old size limitation for sizing their own buffers so
removing the limit should have no externally visible effect.
Signed-off-by: Ben Walton bdwal...@gmail.com
---
config.c | 59 +--
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/config.c b/config.c
index 08e47e2..24fb2d2 100644
--- a/config.c
+++ b/config.c
@@ -10,8 +10,6 @@
#include strbuf.h
#include quote.h
-#define MAXNAME (256)
-
typedef struct config_file {
struct config_file *prev;
FILE *f;
@@ -19,7 +17,7 @@ typedef struct config_file {
int linenr;
int eof;
struct strbuf value;
- char var[MAXNAME];
+ struct strbuf var;
} config_file;
static config_file *cf;
@@ -260,7 +258,7 @@ static inline int iskeychar(int c)
return isalnum(c) || c == '-';
}
-static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)
+static int get_value(config_fn_t fn, void *data, struct strbuf *name)
{
int c;
char *value;
@@ -272,11 +270,9 @@ static int get_value(config_fn_t fn, void *data, char
*name, unsigned int len)
break;
if (!iskeychar(c))
break;
- name[len++] = tolower(c);
- if (len = MAXNAME)
- return -1;
+ strbuf_addch(name, tolower(c));
}
- name[len] = 0;
+
while (c == ' ' || c == '\t')
c = get_next_char();
@@ -288,10 +284,10 @@ static int get_value(config_fn_t fn, void *data, char
*name, unsigned int len)
if (!value)
return -1;
}
- return fn(name, value, data);
+ return fn(name-buf, value, data);
}
-static int get_extended_base_var(char *name, int baselen, int c)
+static int get_extended_base_var(struct strbuf *name, int c)
{
do {
if (c == '\n')
@@ -302,7 +298,7 @@ static int get_extended_base_var(char *name, int baselen,
int c)
/* We require the format to be '[base extension]' */
if (c != '')
return -1;
- name[baselen++] = '.';
+ strbuf_addch(name, '.');
for (;;) {
int c = get_next_char();
@@ -315,37 +311,31 @@ static int get_extended_base_var(char *name, int baselen,
int c)
if (c == '\n')
goto error_incomplete_line;
}
- name[baselen++] = c;
- if (baselen MAXNAME / 2)
- return -1;
+ strbuf_addch(name, c);
}
/* Final ']' */
if (get_next_char() != ']')
return -1;
- return baselen;
+ return 0;
error_incomplete_line:
cf-linenr--;
return -1;
}
-static int get_base_var(char *name)
+static int get_base_var(struct strbuf *name)
{
- int baselen = 0;
-
for (;;) {
int c = get_next_char();
if (cf-eof)
return -1;
if (c == ']')
- return baselen;
+ return 0;
if (isspace(c))
- return get_extended_base_var(name, baselen, c);
+ return get_extended_base_var(name, c);
if (!iskeychar(c) c != '.')
return -1;
- if (baselen MAXNAME / 2)
- return -1;
- name[baselen++] = tolower(c);
+ strbuf_addch(name, tolower(c));
}
}
@@ -353,7 +343,7 @@ static int git_parse_file(config_fn_t fn, void *data)
{
int comment = 0;
int baselen = 0;
- char *var = cf-var;
+ struct strbuf *var = cf-var;
/* U+FEFF Byte Order Mark in UTF8 */
static const unsigned char *utf8_bom = (unsigned char *) \xef\xbb\xbf;
@@ -389,17 +379,24 @@ static int git_parse_file(config_fn_t fn, void *data)
Re: [PATCH] gitk: refresh the index before running diff-files
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 a machine with a slow disk and a cold disk cache. We will need to make the git update-index execute asynchronously. Good point. We're getting out of my very limited tcl cargo-culting skills now, so I'll let somebody more clueful do that fix. You might find the following patch and discussion entertaining: http://thread.gmane.org/gmane.comp.version-control.git/144182 Not my itch, but it was fun to write back then. ;-) Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merging/joining two repos (repo2 should be a subdirectory of repo1)
On Sun, Sep 30, 2012 at 8:32 AM, Dirk Süsserott newslet...@dirk.my1.cc wrote: Am 30.09.2012 17:24 schrieb Tomas Carnecky: On Sun, 30 Sep 2012 17:17:53 +0200, Dirk SÃŒsserott newslet...@dirk.my1.cc 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 subdirectory whithin repo1, including all the history of repo2. A simple git-merge won't do because both repos have some same files (at least e.g. .gitignore) in their root directories. Of course I could resolve the conflicts, but I don't want that. My naive approach is move everything in $repo2 one directory below and then merge $repo2 into $repo1. Actually I wouldn' call that a merge but an import. I know of git filter-branch --subdirectory-filter foodir but that's just the opposite of what I need. Is there a nifty trick to get this? Or will I have to do git filter-branch --tree-filter 'mkdir subdir git mv * subdir' --all on $repo2 and then git merge $repo2 in $repo1? http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html Wow! Thanks for that quick and *very* helpful answer! :-) Hi Dirk, You should also take a look at contrib/subtree/ in the git source tree. git subtree does pretty much exactly what you're looking to do, and it is a bit more user-friendly than the plumbing commands. https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] submodule add: Fail when .git/modules/name already exists unless forced
When adding a new submodule it can happen that .git/modules/name 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 one the user provided, which results in an incorrect work tree. On the other hand the user might reactivate a submodule removed earlier, then reusing that .git directory is the Right Thing to do. As git can't decide what is the case, error out and tell the user she should use either use a different name for the submodule with the --name option or can reuse the .git directory for the newly added submodule by providing the --force option (which only makes sense when the upstream matches, so the error message lists all remotes of .git/modules/name). In one test in t7406 the --force option had to be added to git submodule add, as that test re-adds a formerly removed submodule. Reported-by: Jonathan Johnson m...@jondavidjohn.com Signed-off-by: Jens Lehmann jens.lehm...@web.de --- Am 30.09.2012 21:19, schrieb Jens Lehmann: Am 30.09.2012 06:47, schrieb Junio C Hamano: I think failing with a better error message is a good idea. It should suggest to either resurrect the submodule that is stashed away in $GIT_DIR/modules/$name if it indeed is the same, or to give it a different name (perhaps kernel used to be pointing at the Linux kernel history, then the user is replacing it with a totally different implementation that is really from different origin and do not share any history, perhaps BSD). In such a case, the user may want to pick bsd-kernel or something as its name, to differentiate it. 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 finds .git/modules/name is: A git directory for 'name' is found locally with remote(s): originurl(s) from .git/modules/name If you want to reuse this local git directory instead of cloning again from url given on command line use the '--force' option. If the local git directory is not the correct repo or you are unsure what this means choose another name with the '--name' option. When run with the --force option the following message is printed: Reactivating local git directory for submodule 'name'. git-submodule.sh| 15 ++- t/t7400-submodule-basic.sh | 30 ++ t/t7406-submodule-update.sh | 2 +- 3 files changed, 45 insertions(+), 2 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh index 22febb1..e8112c8 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -359,7 +359,20 @@ Use -f if you really want to add it. 2 fi else - + if test -d .git/modules/$sm_name + then + if test -z $force + then + echo 2 $(eval_gettext A git directory for '\$sm_name' is found locally with remote(s):) + GIT_DIR=.git/modules/$sm_name GIT_WORK_TREE=. git remote -v | grep '(fetch)' | sed -e s,^, , -e s,' (fetch)',, 2 + echo 2 $(eval_gettext If you want to reuse this local git directory instead of cloning again from) + echo 2 $realrepo + echo 2 $(eval_gettext use the '--force' option. If the local git directory is not the correct repo) + die $(eval_gettext or you are unsure what this means choose another name with the '--name' option.) + else + echo $(eval_gettext Reactivating local git directory for submodule '\$sm_name'.) + fi + fi module_clone $sm_path $sm_name $realrepo $reference || exit ( clear_local_git_env diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh index 78bf739..f1a94f7 100755 --- a/t/t7400-submodule-basic.sh +++ b/t/t7400-submodule-basic.sh @@ -726,4 +726,34 @@ test_expect_success 'submodule add --name allows to replace a submodule with ano ) ' +test_expect_success 'submodule add with an existing name fails unless forced' ' + ( + cd addtest2 + rm -rf repo + git rm repo + test_must_fail git submodule add -q --name repo_new $submodurl/repo.git repo + test ! -d repo + echo repo expect + git config -f .gitmodules submodule.repo_new.path actual + test_cmp expect actual + echo $submodurl/bare.git expect + git config -f .gitmodules submodule.repo_new.url actual +
mailinfo: don't require text mime type for attachments
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 looking at the contents, just at the mime
type) the line will be the encoding line (eg 'base64') rather than a
line of *content*.
Which then will cause the text filtering to fail, because we won't
correctly notice when the attachment text switches from the commit message
to the actual patch. Resulting in a patch failure, even if patch may be a
perfectly well-formed attachment, it's just that the message type may be
(for example) application/octet-stream instead of text/plain.
Just remove all the bogus games with the message_type. The only difference
that code creates is how the data is passed to the filter function
(chunked per-pred-code line or per post-decode line), and that difference
is *wrong*, since chunking things per pre-decode line can never be a
sensible operation, and cannot possibly matter for binary data anyway.
This code goes all the way back to March of 2007, in commit 87ab79923463
(builtin-mailinfo.c infrastrcture changes), and apparently Don used to
pass random mbox contents to git. However, the pre-decode vs post-decode
logic really shouldn't matter even for that case, and more importantly, I
fed git am crap is not a valid reason to break *real* patch attachments.
If somebody really cares, and determines that some attachment is binary
data (by looking at the data, not the MIME-type), the whole attachment
should be dismissed, rather than fed in random-sized chunks to
handle_filter().
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Cc: Don Zickus dzic...@redhat.com
---
builtin/mailinfo.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 2b3f4d955eaa..da231400b327 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -19,9 +19,6 @@ static struct strbuf email = STRBUF_INIT;
static enum {
TE_DONTCARE, TE_QP, TE_BASE64
} transfer_encoding;
-static enum {
- TYPE_TEXT, TYPE_OTHER
-} message_type;
static struct strbuf charset = STRBUF_INIT;
static int patch_lines;
@@ -184,8 +181,6 @@ static void handle_content_type(struct strbuf *line)
struct strbuf *boundary = xmalloc(sizeof(struct strbuf));
strbuf_init(boundary, line-len);
- if (!strcasestr(line-buf, text/))
-message_type = TYPE_OTHER;
if (slurp_attr(line-buf, boundary=, boundary)) {
strbuf_insert(boundary, 0, --, 2);
if (++content_top content[MAX_BOUNDARIES]) {
@@ -657,7 +652,6 @@ again:
/* set some defaults */
transfer_encoding = TE_DONTCARE;
strbuf_reset(charset);
- message_type = TYPE_TEXT;
/* slurp in this section's info */
while (read_one_header_line(line, fin))
@@ -871,11 +865,6 @@ static void handle_body(void)
strbuf_insert(line, 0, prev.buf, prev.len);
strbuf_reset(prev);
- /* binary data most likely doesn't have newlines */
- if (message_type != TYPE_TEXT) {
- handle_filter(line);
- break;
- }
/*
* This is a decoded line that may contain
* multiple new lines. Pass only one chunk
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git smart-http do not authent to allow git ls-remote to be called anonymously
On Sun, Sep 30, 2012 at 7:35 AM, 乙酸鋰 ch3co...@gmail.com 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 need authentication on *.git/git-upload-pack *.git/git-receive-pack /etc/apache/httpd.conf LocationMatch ^/git/.*/git-(upload|receive)-pack$ AuthType Basic AuthName staff only AuthUserFile /etc/apache/apache.pwd Require valid-user /LocationMatch However this does not work. It does not ask for password at all. This sounds like a bug in your Apache configuration. I would verify it prompts for a password as expected before worrying about the Git client: curl -v http://localhost/git/blah/git-upload-pack should fail with a 401 requesting access to staff only. Once this is working, git will present authorization as necessary during the /git-upload-pack|git-receive-pack calls. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git smart-http do not authent to allow git ls-remote to be called anonymously
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 I only need authentication on *.git/git-upload-pack *.git/git-receive-pack /etc/apache/httpd.conf LocationMatch ^/git/.*/git-(upload|receive)-pack$ AuthType Basic AuthName staff only AuthUserFile /etc/apache/apache.pwd Require valid-user /LocationMatch However this does not work. It does not ask for password at all. What is it in the final sentence? Does the server not tell the git client that authorization is required, and actually serve the request? If so, then that is a bug in your apache config. Or is it that the server tells git that it needs authorization, but git does not prompt, and instead just fails with Authentication failed. In that case, the issue is that you need a newer git client. Traditionally the client expected to handle authentication during the initial info/refs request. I added support for handling authentication during later requests in commit b81401c, which is in git v1.7.11.7 and v1.7.12.1. You should reconsider whether this is what you really want, though. With the configuration you showed, anyone will be able to get a list of all refs and their sha1s. So they would know all your branch names, and they could even potentially find out what's in your branches by making offline guesses and comparing them to your branch sha1s (the feasibility of this would depend on exactly what you're storing). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Commit cache to speed up rev-list and merge
On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce spea...@spearce.org 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 in the pack-*.idx file, assuming we can use additional data like pack offset position to correlate commit to the parsed int. If we stored parent pointers in a similar way you probably need at least 3.6 MiB of additional disk space on the index. For example, use 12 bytes for each commit to store enough of the parsed commit time to sort commits, and up to 2 parent pointers per commit with a reserved magic value for octopus merges to mean the commit itself has to be parsed to get the graph structure correct. This is much better than my naive approach (storing sha-1 and timestamps). We could use less space by storing parent pointer of non-merge commits only. Merge commits linux-2.6 is 6% the number of commits. git.git has higher percentage, 21%. I bet many projects do not merge as much and the number of merge commits is less than 5%. Some projects merge quite often. Android's frameworks/base repository has a very large number of merges. Out of 79905 commits reachable from the master branch, 65.3% are merges. So actually there are more merge commits in the Android history than there are code commits. A cache of only non-merges may be worthless on such a history. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Commit cache to speed up rev-list and merge
On Mon, Oct 1, 2012 at 8:49 AM, Shawn Pearce spea...@spearce.org wrote: On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce spea...@spearce.org 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 in the pack-*.idx file, assuming we can use additional data like pack offset position to correlate commit to the parsed int. If we stored parent pointers in a similar way you probably need at least 3.6 MiB of additional disk space on the index. For example, use 12 bytes for each commit to store enough of the parsed commit time to sort commits, and up to 2 parent pointers per commit with a reserved magic value for octopus merges to mean the commit itself has to be parsed to get the graph structure correct. This is much better than my naive approach (storing sha-1 and timestamps). We could use less space by storing parent pointer of non-merge commits only. Merge commits linux-2.6 is 6% the number of commits. git.git has higher percentage, 21%. I bet many projects do not merge as much and the number of merge commits is less than 5%. Some projects merge quite often. Android's frameworks/base repository has a very large number of merges. Out of 79905 commits reachable from the master branch, 65.3% are merges. So actually there are more merge commits in the Android history than there are code commits. A cache of only non-merges may be worthless on such a history. The good thing about these cache is it's configurable. Merge-preferred projects can choose to cache the first two parents. Non-merge projects can choose to cache just the first parent. We don't need a fixed format for both. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using bitmaps to accelerate fetch and clone
On Sun, Sep 30, 2012 at 6:59 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Mon, Oct 1, 2012 at 8:07 AM, Shawn Pearce spea...@spearce.org 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 started talking about this late last week too. It seems feasible, but does add a bit more complexity to the algorithm used when enumerating. Yes. Though at server side, if it's too much trouble, the packer can just ignore open packs and use only closed ones. Its not trouble once the code is written. We were just trying to be expedient in producing a prototype that we could start to deploy on real-world workloads. Enumerating the non-closed-pack objects using the classical implementation is still slow and consumes CPU time at the server, using partial bitmaps should eliminate most of that CPU usage and reduce server loads. One of the more troublesome problems is building the bitmaps is difficult from a streaming processor like index-pack. You need the reachability graph for all objects, which is not currently produced when moving data over the wire. We do an fsck after-the-fact to verify we didn't get corrupt data, but this is optional and currently after the pack is stored. We need to refactor this code to run earlier to get the bitmap built. If we take Peff's idea and put the bitmap data into a new stream rather than the pack-*.idx file we can produce the bitmap at the same time as the fsck check, which is probably a simpler change. We could have one leaf bitmap per pack to mark all leaves where we'll need to traverse outside the pack. Commit leaves are the best as we can potentially reuse commit bitmaps from other packs. Tree leaves will be followed in the normal/slow way. Yes, Colby proposed the same idea. We cannot make a leaf bitmap per pack. The leaf SHA-1s are not in the pack and therefore cannot have a bit assigned to them. We could mark all objects _in_ the pack that lead to an external object. That's what I meant by leaves. We need to parse the leaves to find out actual SHA-1s that are outside the pack. OK, yes, I was being pretty stupid. Of course we could mark the objects _in_ the pack as leaves and parse the leaves when we need to find the external pointers. Or we could go with your approach below too. I actually think my approach may be better. The root tree of a leaf commit would need to be scanned every time to identify trees that are reachable from this leaf commit, but are not reachable in the ancestry of the leaf's parents. This turns out to be rather expensive to compute every time a server or an fsck algorithm considers the partial pack. Its also somewhat uncommon for such an object to exist, it has to happen by an unrelated side branch introducing the same object and the creator of the pack seeing that object already exist and not including it in the pack. Defining the pack's edge as a list of SHA-1s not in this pack but known to be required allows us to compute that leaf root tree reachability once, and never consider parsing it again. Which saves servers that host frequently accessed Git repositories but aren't repacking all of the time. (FWIW we repack frequently, I hear GitHub does too, because a fully repacked repository serves clients better than a partially packed one.) We could add a new section that listed the unique leaf SHA-1s in their own private table, and then assigned per bitmap a leaf bitmap that set to 1 for any leaf object that is outside of the pack. One of the problems we have seen with these non-closed packs is they waste an incredible amount of disk. As an example, do a `git fetch` from Linus tree when you are more than a few weeks behind. You will get back more than 100 objects, so the thin pack will be saved and completed with additional base objects. That thin pack will go from a few MiBs to more than 40 MiB of data on disk, thanks to the redundant base objects being appended to the end of the pack. For most uses these packs are best eliminated and replaced with a new complete closure pack. The redundant base objects disappear, and Git stops wasting a huge amount of disk. That's probably a different problem. I appreciate disk savings but I would not want to wait a few more minutes for repack on every git-fetch. But if this bitmap thing makes repack much faster than currently, repacking after every git-fetch may become practical. I know the Counting objects phase of a repack is very expensive, but so too is the time required to do the IO in and out of every object in the repository. Spinning disks only transfer data so fast. Assuming the drive can move 50 MiB/s each way, a 500 MiB repository will take 10 seconds just to write back out the new pack. You aren't ever going to want to wait for repacking during git-fetch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a
Re: Commit cache to speed up rev-list and merge
On Sun, Sep 30, 2012 at 7:05 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Mon, Oct 1, 2012 at 8:49 AM, Shawn Pearce spea...@spearce.org wrote: On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce spea...@spearce.org 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 in the pack-*.idx file, assuming we can use additional data like pack offset position to correlate commit to the parsed int. If we stored parent pointers in a similar way you probably need at least 3.6 MiB of additional disk space on the index. For example, use 12 bytes for each commit to store enough of the parsed commit time to sort commits, and up to 2 parent pointers per commit with a reserved magic value for octopus merges to mean the commit itself has to be parsed to get the graph structure correct. This is much better than my naive approach (storing sha-1 and timestamps). We could use less space by storing parent pointer of non-merge commits only. Merge commits linux-2.6 is 6% the number of commits. git.git has higher percentage, 21%. I bet many projects do not merge as much and the number of merge commits is less than 5%. Some projects merge quite often. Android's frameworks/base repository has a very large number of merges. Out of 79905 commits reachable from the master branch, 65.3% are merges. So actually there are more merge commits in the Android history than there are code commits. A cache of only non-merges may be worthless on such a history. The good thing about these cache is it's configurable. Merge-preferred projects can choose to cache the first two parents. Non-merge projects can choose to cache just the first parent. We don't need a fixed format for both. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the hard coded length limit on variable names in config files
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 (thought I?) did. I'm happy to redo it against master if that's better though. That explains it. Sorry, I hadn't seen that conversation. (In the future, if a patch applies against something other than master, please add a note in the cover letter or in the patch comment after the --.) It is OK with me to leave the patch against maint, if that is what Junio wanted. It would help, though, if you rebase it to the latest maint (the conflict seems easy to fix). Thanks, Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git pull --no-ff documentation
Hi, The order of options in git pull is not clear in the documentation It only says git pull [options] [repository [refspec...]] 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 --no-tags --progress origin it succeeded. Regards, ch3cooli -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull --no-ff documentation
乙酸鋰 ch3co...@gmail.com writes:
The order of options in git pull is not clear in the documentation
It only says
git pull [options] [repository [refspec...]]
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 --no-tags --progress origin
it succeeded.
This actually is not about --no-ff but about --no-tags. Any option
that pull itself does not care about stops the command line parser
and the remainder of the command line is fed to underlying fetch.
Perhaps something like this? But you should trace the codepath
involved to see if this covers all uses of the --tags before using
it for real projects, as I didn't.
git-pull.sh | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git i/git-pull.sh w/git-pull.sh
index 2a10047..a53c1e5 100755
--- i/git-pull.sh
+++ w/git-pull.sh
@@ -39,7 +39,7 @@ test -z $(git ls-files -u) || die_conflict
test -f $GIT_DIR/MERGE_HEAD die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
-log_arg= verbosity= progress= recurse_submodules=
+log_arg= verbosity= progress= recurse_submodules= fetch_tags=
merge_args= edit=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=${curr_branch#refs/heads/}
@@ -62,6 +62,8 @@ do
progress=--no-progress ;;
-n|--no-stat|--no-summary)
diffstat=--no-stat ;;
+ -t|--t|--ta|--tag|--tags|--no-tags)
+ fetch_tags=$1 ;;
--stat|--summary)
diffstat=--stat ;;
--log|--no-log)
@@ -141,15 +143,12 @@ done
error_on_no_merge_candidates () {
exec 2
- for opt
- do
- case $opt in
- -t|--t|--ta|--tag|--tags)
- echo Fetching tags only, you probably meant:
- echo git fetch --tags
- exit 1
- esac
- done
+ case $fetch_tags in
+ -t|--t|--ta|--tag|--tags)
+ echo Fetching tags only, you probably meant:
+ echo git fetch --tags
+ exit 1
+ esac
if test true = $rebase
then
@@ -213,7 +212,7 @@ test true = $rebase {
done
}
orig_head=$(git rev-parse -q --verify HEAD)
-git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok
$@ || exit 1
+git fetch $verbosity $progress $dry_run $recurse_submodules $fetch_tags
--update-head-ok $@ || exit 1
test -z $dry_run || exit 0
curr_head=$(git rev-parse -q --verify HEAD)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 8/9] longest_ancestor_length(): resolve symlinks before comparing paths
On 09/30/2012 10:00 AM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu 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 different even though they might logically refer to the same directory. So canonicalize the paths listed in prefix_list using real_path_if_valid() before trying to find matches. I somehow feel that this is making the logic unnecessarily convoluted by solving the problem at a wrong level. If longest_ancestor_length() takes a single string and a list of candidate string prefixes, conceptually it should be usable for any hierarchy-looking string that uses slashes as hierarchy separator (e.g. refs that may be stored in packed-refs that you cannot expect lstat(2) or readlink(2) to give you any sensible results). The real problem is that the list given from the environment may contain a path that violates that it suffices to take the longest string-prefix taking slashes into account assumption in such a generic l-a-l implementation, no? And this patch solves it by making l-a-l _less_ generic and forcing it to be aware of the glitch of its caller (you can either blame clueless user who lies when setting the GIT_CEILING_DIRECTORIES by including paths contaminated with symlinks, or blame the calling setup_git_directory_gently_1() function that does not resolve the symbolic links before calling this function). As l-a-l is only used by the stop at the ceiling logic, isn't it a far simpler solution to keep the function work at the string level, and make the caller fix its input, i.e. the value taken from the environment variable, before calling it? That is, grab the value of GIT_CEILING_DIRECTORIES, split it into a list at PATH_SEP (while rejecting any non-absolute paths), normalize the elements of that list by resolving symbolic links, and then pass the cwd[] and the normalized string list to l-a-l? The resulting callsite in setup_git_directory_gently_1() would pass cwd[] and the ceiling_dirs (which now is a string list), all of whose elements would happen to begin with / (or dos drive prefix followed by the root symbol), but l-a-l can be written in such a way that it does not even require that all the input has to begin at root, which would later make it usable with things that are not paths (references, for example, all of which begin with refs/ and not /refs/). I agree that longest_ancestor_length() is not very generic or interesting anymore. Nearly all of its added value comes from the normalize_path_callback() helper function. One possibility would be to inline it at the one place it is called. The function string_list_longest_prefix() was my attempt to isolate the kernel of generic functionality from longest_ancestor_path(). It is *almost* the function that you are proposing, with the exception that it does not ensure that the prefix match ends at a / boundary. So another alternative could be to change this function to respect / boundaries. (After the change, the function might not belong in the string-list API anymore.) However, the semantics of a function that matches prefixes at / boundaries is not entirely obvious. Suppose we would implement the test via a function like path_prefixcmp(path, prefix). I can think of a few policy questions that would have to be answered: * Is a trailing slash on the prefix argument required, optional, or prohibited? What if the prefix is / or // or c:/? * Is a trailing slash on the path argument optional/prohibited? Are / or // allowed as path arguments? * Is a path its own prefix? path_prefixcmp(a/b, a/b) - true or false? (For the implementation of longest_ancestor_path(), we would prefer this to return false.) Or does the answer depend on whether the prefix has a trailing slash? path_prefixcmp(a/b, a/b) - true? path_prefixcmp(a/b, a/b/) - false? Part of the reason that I implemented string_list_longest_prefix() instead of the function that you suggest is that the behavior of the former is far more obvious. 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 following the matching part is a '/' This would allow the is path its own prefix policy to be decided by the caller by either including or omitting a trailing slash on the prefix argument. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Commit cache to speed up rev-list and merge
On Mon, Oct 1, 2012 at 9:27 AM, Shawn Pearce spea...@spearce.org 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 see it as tuning, not switching. It's like setting the number of commits where bitmaps are taken. We can see the commit cache as a table, where columns are commit properties. We have a column for date, one for the first parent. Users can choose to have a third column for the second parent, or another one for root tree sha-1. The implementation could be made generic to support caching any n sha1-columns. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 8/9] longest_ancestor_length(): resolve symlinks before comparing paths
Michael Haggerty mhag...@alum.mit.edu 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 following the matching part is a '/' This would allow the is path its own prefix policy to be decided by the caller by either including or omitting a trailing slash on the prefix argument. I think that is sensible thing to do. The primary thing I found questionable was that the function, given /net/wink/project/frotz to check against /pub:/s (or /pub/:/s/ if you like), will report that /net/wink/project directory is the longest ancestor, when /s is a symlink that happens to point at /net/wink/project. It is very counter-intuitive when you view its two input strings as strings. By making its sole caller expand the symbolic links, it would be a lot clearer what is going on to anybody who follow the codepath. We have one path obtained from getcwd() and a set of paths all of which are real paths without symbolic aliasing, and we check if one among the latter cover an earlier part of the former. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
