Re: [PATCH] submodule: make 'show' an alias for 'summary'
Hi Jens, Jens Lehmann wrote: > I'm very interested in your feedback as a first time submodule user, > what you wrote above makes sense and explains why you did that patch > (and it would have been nice to read some of it in the commit message > ;-). What information did you expect to get from a "git submodule > show" which isn't already provided by "git status" and "git diff" > (especially as they give you some information the "git submodule" > commands don't)? I expected 'git submodule show' to list all the submodules, and show changes to specific submodules like the 'git submodule summary' output. Ram -- 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] submodule: use abbreviated sha1 in 'status' output
Jens Lehmann wrote: > I suspect you got the idea for this patch from Marc's recent comment: > [...] Yes, I did. > That is just a single user so far indicating your patch /could/ be an > improvement. I think we need quite some more votes on that before we > should do a change like this. I thought it's a porcelain command like 'git status'- we don't need votes to change the output format of 'git status', do we? Ram -- 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 gui does not open bare repositories
Am 28.09.2012 10:44, schrieb Stefan Näwe:
> I get "Not a Git repository: remote.git" as well, when I run
> git gui "somewhere" (i.e. not in "remote.git")
i.e.:
$ cd /not/a/repo
$ git gui
> and the select "Open Existing Repository".
>
> I get "Cannot use bare repository: .../remote.git" when I run git gui
> from inside the "remote.git" directory.
i.e.:
$ cd /path/to/bare-repo.git
$ git gui
> Both on WinXP with msysGit.
And the same on Linux with Git v1.7.12
Stefan
--
/dev/random says: Press any key to continue or any other key to quit...
python -c "print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
--
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 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
Re: Commit cache to speed up rev-list and merge
On Mon, Oct 1, 2012 at 9:27 AM, Shawn Pearce wrote: > Git has enough magic switches. It doesn't need yet another magic > switch that one group of users needs to set, and another can safely > ignore because their project's usage just happens to align with Linus > Torvald's current world view. I 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 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
On 09/30/2012 10:00 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> longest_ancestor_length() relies on a textual comparison of directory
>> parts to find the part of path that overlaps with one of the paths in
>> prefix_list. But this doesn't work if any of the prefixes involves a
>> 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 majordom
Re: git pull --no-ff documentation
乙酸鋰 writes:
> The order of options in git pull is not clear in the documentation
> It only says
> git pull [options] [ [...]]
> So we have no idea which options should come first
>
> I tried
> git pull -v --no-tags --progress --no-ff origin
> but failed with unknown option 'no-ff'.
>
> But if I 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
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] [ [...]] 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: [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
Re: Commit cache to speed up rev-list and merge
On Sun, Sep 30, 2012 at 7:05 PM, Nguyen Thai Ngoc Duy wrote: > On Mon, Oct 1, 2012 at 8:49 AM, Shawn Pearce wrote: >> On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy >> wrote: >>> On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce wrote: In Linus' Linux kernel tree there are currently 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: Using bitmaps to accelerate fetch and clone
On Sun, Sep 30, 2012 at 6:59 PM, Nguyen Thai Ngoc Duy wrote: > On Mon, Oct 1, 2012 at 8:07 AM, Shawn Pearce wrote: >>> You mentioned this before in your idea mail a while back. I wonder if >>> it's worth storing bitmaps for all packs, not just the self contained >>> ones. >> >> Colby and I 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: s
Re: Commit cache to speed up rev-list and merge
On Mon, Oct 1, 2012 at 8:49 AM, Shawn Pearce wrote: > On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy > wrote: >> On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce wrote: >>> In Linus' Linux kernel tree there are currently about 323,178 commits. >>> If we store just the pre-parsed commit 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: Commit cache to speed up rev-list and merge
On Thu, Sep 27, 2012 at 7:14 PM, Nguyen Thai Ngoc Duy wrote: > On Thu, Sep 27, 2012 at 10:51 PM, Shawn Pearce wrote: >> In Linus' Linux kernel tree there are currently about 323,178 commits. >> If we store just the pre-parsed commit time as an int32 field this is >> an additional 1.2 MiB of data 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: 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 > > > AuthType Basic > AuthName "staff only" > AuthUserFile /etc/apache/apache.pwd > Require valid-user > > > 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: Using bitmaps to accelerate fetch and clone
On Fri, Sep 28, 2012 at 5:00 AM, Nguyen Thai Ngoc Duy wrote: > On Thu, Sep 27, 2012 at 7:47 AM, Shawn Pearce wrote: >> * https://git.eclipse.org/r/7939 >> >> Defines the new E003 index format and the bit set >> implementation logic. > > Quote from the patch's message: > > "Currently, the new index format can only be used with pack files that > contain a complete closure of the object graph e.g. the result of a > garbage collection." > > 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. > 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 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. This would probably take up the least amount of disk space, vs. storing the list of leaf SHA-1s after each bitmap. If a pack has only 1 bitmap (e.g. it is a small chunk of recent history) there is really no difference in disk usage. If the pack has 2 or 3 commit bitmaps along a string of approximately 300 commits, you will have an identical leaf set for each of those bitmaps so using a single leaf SHA-1 table would support reusing the redundant leaf pointers. 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. > For connectivity check, fewer trees/commits to deflate/parse means > less time. And connectivity check is done on every git-fetch (I > suspect the other end of a push also has the same check). It's not > unusual for me to fetch some repos once every few months so these > incomplete packs could be quite big and it'll take some time for gc > --auto to kick in (of course we could adjust gc --auto to start based > on the number of non-bitmapped objects, in additional to number of > packs). Yes, of course. -- 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, 乙酸鋰 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 > > > AuthType Basic > AuthName "staff only" > AuthUserFile /etc/apache/apache.pwd > Require valid-user > > > 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: [PATCH v2 2/2] submodule add: Fail when .git/modules/ already exists unless forced
Jens Lehmann writes: >> Good point! I will add a more detailed error message (including >> the url of the default remote which is configured for the already >> present submodule repo) and teach --force to skip the test and >> resurrect that submodule repo. > > The message when "git submodule add" finds .git/modules/ is: > > A git directory for '' is found locally with remote(s): > origin > > If you want to reuse this local git directory instead of cloning again from > > 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 ''. Thanks, will re-queue. The approach "submodule rm" takes when removing a project is to treat the removed submodule as not necessary for the current commit in the superproject, but it is considered necessary elsewhere in the history of the superproject, and that is why we stash away the repository in $GIT_DIR/modules of the superproject. We may however want to think about another mode of user error where the user runs "submodule add $path" for a wrong repository, realizes the mistake _before_ making any commit and try to repoint the $path to a correct repository. The behaviour of "submodule add" in this patch, and the behaviour of existing "submodule rm", assumes that the user is not stupid and won't make such a mistake, but to recover, the user may need a way to really nuke the submodule repository that was added by the earlier misteake (which is not needed anywhere in the history of the superproject) and $GIT_DIR/module/$name really replaced with the updated one. I don't know how important to support a recovery procedure from such mistakes, though. -- 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
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
Cc: Don Zickus
---
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
[PATCH v2 2/2] submodule add: Fail when .git/modules/ already exists unless forced
When adding a new submodule it can happen that .git/modules/ already contains a submodule repo, e.g. when a submodule is removed from the work tree and another submodule is added at the same path. But then the work tree of the submodule will be populated using the existing repository and not the 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/). 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 Signed-off-by: Jens Lehmann --- 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/ is: A git directory for '' is found locally with remote(s): origin> If you want to reuse this local git directory instead of cloning again from 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 ''. 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 && + test_
Re: Merging/joining two repos (repo2 should be a subdirectory of repo1)
On Sun, Sep 30, 2012 at 8:32 AM, Dirk Süsserott wrote: > Am 30.09.2012 17:24 schrieb Tomas Carnecky: >> On Sun, 30 Sep 2012 17:17:53 +0200, Dirk SÃŒsserott >> wrote: >>> Hi! >>> >>> I have repo1 with ~4 years of history and another repo2 with ~1 year of >>> history, both of which I don't want to 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
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
[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
---
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)
c
Re: [PATCH 0/2] Let "git submodule add" fail when .git/modules/ already exists
Am 30.09.2012 06:47, schrieb Junio C Hamano: > Jens Lehmann writes: > >>> The only long term solution I can think of is to use some kind of UUID for >>> the name, so that the names of newly added submodules won't have a chance >>> to clash anymore. For the short term aborting "git submodule add" 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
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
To: Junio C Hamano
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] 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
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: 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: 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 > 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
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
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 AuthType Basic AuthName "staff only" AuthUserFile /etc/apache/apache.pwd Require valid-user 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
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
[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 - 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
bug report, v1.7.12.1 -- Documentation/gitcredentials.xml:180: parser error
doing a source install of git v1.7.12.1, on the `make all doc` step, I get: XMLTO gitcredentials.7 xmlto: input does not validate (status 1) /usr/local/git-git-51993a4/Documentation/gitcredentials.xml:180: parser error : Opening and ending tag mismatch: emphasis line 180 and literal credential. (which applies to all cre ^ /usr/local/git-git-51993a4/Documentation/gitcredentials.xml:181: parser error : Opening and ending tag mismatch: literal line 181 and emphasis credential.., where matches ^ make[1]: *** [gitcredentials.7] Error 1 make[1]: Leaving directory `/usr/local/git-git-51993a4/Documentation' make: *** [doc] Error 2 pbx:/usr/local/git-git-51993a4# diff Documentation/gitcore-tutorial.xml ~hesco/gitcore-tutorial.xml 824c824 < (notice the asterisk character), and the first column for --- > (notice the asterisk character), > and the first column for 828c828 < All of them have non blank characters in the first column ( --- > All of them have non blank characters in the first column > ( 1263c1263 < You will see two files, pack-.pack and pack-.idx, --- > You will see two files, pack- role="strong">.pack and pack-.idx, --- and the patch which permitted me to proceed --- 180,181c180,181 < credential. (which applies to all credentials), or < credential. ., where matches the context as described --- > credential. (which applies to all > credentials), or > credential. ., where > matches the context as described And with the resolution of this bug, the `make doc all` completed without further error. Not sure if my version of the xml parser does not recognize the emphasis tag, although many of these involved overlapping tags and sometimes I saw tags which wrapped literally nothing at all. Have no idea what that might have been about. -- 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 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 (< ^ /usr/local/git-git-51993a4/Documentation/gitcore-tutorial.xml:1263: parser error : Opening and ending tag mismatch: emphasis line 1263 and literal ra>You will see two files, pack-.pack ^ /usr/local/git-git-51993a4/Documentation/gitcore-tutorial.xml:1263: parser error : Opening and ending tag mismatch: literal line 1263 and emphasis teral>pack-.pack and pack- ^ 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 character), and the first column for --- > (notice the asterisk character), > and the first column for 828c828 < All of them have non blank characters in the first column ( --- > All of them have non blank characters in the first column > ( 1263c1263 < You will see two files, pack-.pack and pack-.idx, --- > You will see two files, pack- role="strong">.pack and pack-.idx, -- 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
bug report, v1.7.12.1 -- Documentation/git-stash.xml:116: parser error
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-stash.1
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-stash.xml:116: parser error :
Opening and ending tag mismatch: literal line 115 and simpara
^
/usr/local/git-git-51993a4/Documentation/git-stash.xml:117: parser error :
Opening and ending tag mismatch: simpara line 111 and listitem
^
/usr/local/git-git-51993a4/Documentation/git-stash.xml:118: parser error :
Opening and ending tag mismatch: listitem line 110 and varlistentry
^
/usr/local/git-git-51993a4/Documentation/git-stash.xml:211: parser error :
Opening and ending tag mismatch: varlistentry line 106 and variablelist
^
/usr/local/git-git-51993a4/Documentation/git-stash.xml:212: parser error :
Opening and ending tag mismatch: variablelist line 49 and refsect1
^
/usr/local/git-git-51993a4/Documentation/git-stash.xml:348: parser error :
Opening and ending tag mismatch: refsect1 line 47 and refentry
^
/usr/local/git-git-51993a4/Documentation/git-stash.xml:349: parser error :
Premature end of data in tag refentry line 3
^
make[1]: *** [git-stash.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
---
115c115
< it will accept any format known to git diff
(e.g., git stash show
---
> it will accept any format known to git diff
> (e.g., git stash show
--
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 git rm d* and git rm d/*, as the
former will
---
> using git rm d* and git rm
> d/*, 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/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
, or [), 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
), it is turned into a prefix match by appending /
^
/usr/local/git-git-51993a4/Documentation/git-rev-parse.xml:277: parser error :
Opening and ending tag mismatch: emphasis line 277 and literal
character (?,
^
/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 /.
^
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
> , or [), it is turned into a prefix
> match by appending >literal>/.
---
< , or [), it is
turned into a prefix match by appending
/.
277,278c277,278
> character (?, , or
> [), it is turned into a prefix
> match by appending /.
---
< character (?, , or [), it is turned into a prefix
< match by appending /.
--
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: [PATCH v2 8/9] longest_ancestor_length(): resolve symlinks before comparing paths
Michael Haggerty writes: > longest_ancestor_length() relies on a textual comparison of directory > parts to find the part of path that overlaps with one of the paths in > prefix_list. But this doesn't work if any of the prefixes involves a > symbolic link, because the directories will look 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-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 < refspec refs/heads/:refs/svn/origin/branches/ --- > refspec refs/heads/ role="strong">:refs/svn/origin/branches/ 144c144 < there is an implied refspec :. --- > there is an implied refspec role="strong">:. 246c246 < refspec refs/heads/:refs/svn/origin/branches/ --- > refspec refs/heads/ role="strong">:refs/svn/origin/branches/ 255c255 < there is an implied refspec :. --- > there is an implied refspec role="strong">:. -- 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
bug report, v1.7.12.1 -- Documentation/git-push.xml:113: element literal: validity error
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-push.1
xmlto: input does not validate (status 3)
/usr/local/git-git-51993a4/Documentation/git-push.xml:113: element literal:
validity error : Element emphasis is not declared in literal list of possible
children
Document /usr/local/git-git-51993a4/Documentation/git-push.xml does not validate
make[1]: *** [git-push.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
---
113c113
< git push --prune remote refs/heads/:refs/tmp/ would
---
> git push --prune remote refs/heads/ role="strong">:refs/tmp/ would
--
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-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
> git grep time_t — *.[ch]
---
< git grep time_t —
*.[ch]
612c612
< git grep -e #define --and \( -e MAX_PATH -e PATH_MAX \)
---
> git grep -e #define --and \( -e MAX_PATH -e
> PATH_MAX \)
--
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-filter-branch.xml:463: parser error
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-filter-branch.1
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:463: parser
error : Unescaped '<' not allowed in attributes values
Clone it with git clone file
^
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:463: parser
error : attributes construct error
Clone it with git clone file
^
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:463: parser
error : Couldn't find end of Start Tag ulink line 463
Clone it with git clone file
^
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:463: parser
error : expected '>'
Clone it with git clone file
^
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:463: parser
error : expected '>'
t clone file:///path/to/repofile:///path/to/repofile:///path/to/repo
^
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:468: parser
error : Opening and ending tag mismatch: itemizedlist line 460 and simpara
^
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:469: parser
error : Opening and ending tag mismatch: refsect1 line 433 and listitem
^
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:470: parser
error : Opening and ending tag mismatch: refentry line 3 and itemizedlist
^
/usr/local/git-git-51993a4/Documentation/git-filter-branch.xml:471: parser
error : Extra content at the end of the document
If you really don't want to clone it, for whatever reasons, check the
^
make[1]: *** [git-filter-branch.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
---
463c463
> Clone it with git clone url="file:///path/to/repo">file:///path/to/repo. The clone
---
< Clone it with git clone file:///path/to/repo>.
The clone
--
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 -- Documentation/git-bundle.xml:130: parser error
Hugh Esco writes:
> doing a source install of git v1.7.12.1,
> on the `make all doc` step, I get:
>
> xmlto: input does not validate (status 1)
> /usr/local/git-git-51993a4/Documentation/git-bundle.xml:130: parser error :
> Opening and ending tag mismatch: subscript line 130 and literal
> such as master1 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. ^master10), 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 master1 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-fast-import.xml:732: parser error
doing a source install of git v1.7.12.1,
on the `make all doc` step, I get:
XMLTO git-fast-import.1
xmlto: input does not validate (status 1)
/usr/local/git-git-51993a4/Documentation/git-fast-import.xml:732: parser error
: Opening and ending tag mismatch: superscript line 732 and literal
The 0 suffix is necessary as fast-impor
^
/usr/local/git-git-51993a4/Documentation/git-fast-import.xml:734: parser error
: Opening and ending tag mismatch: literal line 734 and superscript
m command is even read from the input. Adding
^
make[1]: *** [git-fast-import.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
---
Sorry, got a bit ahead of myself and forgot to grab
a copy I could diff against. But in short I simply
removed the superscript tags and that was sufficient
to making this work.
--
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 is subject to tilde expansion: /$HOME, and u ^ /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. "/ ^ /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 $HOME and "user/ ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:2304: parser error : Opening and ending tag mismatch: subscript line 2304 and literal "/" is expanded to the value of $ ^ /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 $HOME and " ^ /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 .idx ^ /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 .pack 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 .idx ^ /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 .pack 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 .idx file. ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4617: parser error : Opening and ending tag mismatch: emphasis line 4616 and literal the .idx file. ^ /usr/local/git-git-51993a4/Documentation/git-config.xml:4666: parser error : Opening and ending tag mismatch: emphasis line 4666 and literal ral>git config pretty.changelog "format: %H %s"git log "--pretty=format: ^ 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 include.path is subject to tilde expansion: / < is expanded to the value of $HOME, and user/ to the specified --- > found. The value of include.path is subject to tilde > expansion: / > is expanded to the value of $HOME, and > user/ to the specified 1354,1355c1354,1355 < of files which are not meant to be tracked. "/" is expanded < to the value of $HOME and "user/" to the specified user's --- > of files which are not meant to be tracked. > "/" is expanded > to the value of $HOME and > "user/" to the specified user's 2304c2304 < "/" is expanded to the value of $HOME and "user/" to the --- > "/" is expanded to the value of > $HOME and "user/" to the 4609c4609 < If you have an old git that does not understand the version 2 .idx file, --- > If you have an old git that does not understand the version 2 > .idx file, 4611c4611 < that will copy both .pack file and corresponding .idx file from the --- > that will copy both .pack file and > corresponding .idx file from the 4613c4613 < older version of git. If the .pack file is smaller than 2 GB, however, --- > older version of git. If the .pack file is > smaller than 2 GB, however, 4616,4617c4616,4617 < on the .pack file to regenerate < the .idx file. --- > on the .pack file to regenerate > the .idx file. 4666c4666 < running git config pretty.changelog "format: %H %s" --- > running git config pretty.changelog "format: role="strong"> %H %s" 4668c4668 < to be equivalent to running git log "--pretty=format: %H %s". --- > to be equiva
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 me> is allowed to contain a single foo//bar but not foo/bar* --- > enabled,is allowed to contain a single > 164c164 < foo/bar but not foo/bar*). --- > foo//bar but not > foo/bar*). --- 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-bundle.xml:130: 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-bundle.xml:130: parser error : Opening and ending tag mismatch: subscript line 130 and literal such as master1 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. ^master10), 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 master1 cannot be packaged, > but are perfectly suitable for --- < such as master1 cannot be packaged, but are perfectly suitable for 134c134 > specified explicitly (e.g. > ^master10), or implicitly (e.g. --- < specified explicitly (e.g. ^master10), or implicitly (e.g. --- --- Next bug encountered with: Documentation/git-check-ref-format.xml details to follow in next email. -- 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: bug report, v1.7.12.1 -- user-manual.xml:3739: parser error
Hugh Esco writes: > doing a source install of git v1.7.12.1, > on the `make all doc` step, I get: > > user-manual.xml:3739: parser error : Opening and ending tag mismatch: > emphasis line 3739 and literal > char , but is actually expected to be a > poin > ^ > 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 unsigned char > > > ^ > 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 -- 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 , 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 unsigned char
^
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 tag
--
3739c3739
< char , but is actually expected to be a pointer to
unsigned
---
> char , but is actually expected to be a
> pointer to unsigned
3741c3741
< commit. Note that whenever a SHA-1 is passed as unsigned char
, it
---
> commit. Note that whenever a SHA-1 is passed as unsigned char
> , 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
