* [PATCH] Reword -M, when in `git log`s documention, to suggest --follow
From: Alex Vandiver @ 2009-12-21 20:40 UTC (permalink / raw)
To: git
The documentation for `git log` is sadly misleading when it comes
to tracking renames. By far the most common option that users
new to git want is the ability to view the history of a file
across renames. Unfortunately, `git log --help` shows:
NAME
git-log - Show commit logs
[...]
OPTIONS
[...]
-M
Detect renames.
...and most users stop reading there. Unfortunately, what
they're generally looking for comes significantly later:
[...]
--follow
Continue listing the history of a file beyond renames.
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
Documentation/diff-options.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 8707d0e..bcbad88 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -175,7 +175,13 @@ endif::git-format-patch[]
Break complete rewrite changes into pairs of delete and create.
-M::
+ifdef::git-log[]
+ Show renames in diff output. See `--follow` to track history
+ across renames.
+endif::git-log[]
+ifndef::git-log[]
Detect renames.
+endif::git-log[]
-C::
Detect copies as well as renames. See also `--find-copies-harder`.
--
1.6.6.rc0.363.g69d13.dirty
^ permalink raw reply related
* Re: Delete a commit
From: Bertram Scharpf @ 2009-12-21 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <hgocfi$pge$1@ger.gmane.org>
Hi,
Am Montag, 21. Dez 2009, 18:49:36 +0100 schrieb Johan 't Hart:
> Bertram Scharpf schreef:
>
>> % git fsck --lost-found
>> dangling commit 6abc221327e896c850c56dafae92277bcfe68e2b
>> It is still there. This is the one I want to delete.
>
> It is not in the history of any head anymore, so you could consider it
> deleted. ('git log' does not show this commit)
>
> If you want to prune unreferenced objects, try:
> git prune
>
> ('git help prune' for options)
In the meantime I detected the gc.pruneExpire config variable. I
didn't get that to work on all versions that I have installed on
different machines, but I just wanted to understand what has to
happen with the commit.
Thank you!
Bertram
--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
^ permalink raw reply
* Re: git's fascination with absolute paths
From: Avery Pennarun @ 2009-12-21 22:09 UTC (permalink / raw)
To: J Chapman Flack; +Cc: git
In-Reply-To: <4B2FC17A.3010705@math.purdue.edu>
On Mon, Dec 21, 2009 at 1:42 PM, J Chapman Flack <jflack@math.purdue.edu> wrote:
> In general it seems best for a program to stay free of assumptions
> about absolute paths except when there is a specific functional
> requirement that needs them. I assume there is something git does
> that requires it to have this limitation, but it's not intuitive
> to me if I just think about what I expect an scm system to do.
> I've searched on 'absolute' in the list archive to see if there
> was a past discussion like "we've decided we need absolute paths
> everywhere because X" but I didn't find any. Can someone
> describe what the reasoning was? A security concern perhaps?
> (And one more serious than the race condition built into
> make_absolute_path?)
I think it's probably just because it's easier to deal with absolute
paths than relative ones. Those ".." things can be annoying,
particularly inside scripts, etc, and git uses a lot of scripts. Much
more straightforward to just normalize all the paths once and be sure
there are no weird dots in them.
Not to say that it can't be done... just that it seems nobody has been
inspired to do so. I'm guessing most of the existing developers still
won't be inspired to do it based on your rather unusual use case;
however, they might accept patches.
> Or, perhaps I should be asking, what is there in git that will
> break if I recompile it with make_absolute_path(p){return p;}?
> Does it store absolute paths in the db? Would a recompiled
> version produce a db other gits couldn't read?
You might try this and then see what happens in 'make test'. I
imagine a set of clean patches that removed a lot of assumptions about
absolute paths, without breaking any unit tests, would be something
worth considering for integration into git.
Have fun,
Avery
^ permalink raw reply
* [PATCH] git-svn: Remove obsolete MAXPARENT check
From: Andrew Myrick @ 2009-12-21 22:22 UTC (permalink / raw)
To: git; +Cc: sam, normalperson, Andrew Myrick
Change git-svn not to impose a limit of 16 parents on a merge.
This limit in git-svn artificially prevents cloning svn repositories
that contain commits with more than 16 merge parents.
The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit
ef98c5cafb3e799b1568bb843fcd45920dc62f16, so there is no need to check for it
it in git-svn.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
---
git-svn.perl | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0a6460e..92c40da 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2447,12 +2447,6 @@ sub get_commit_parents {
next if $seen{$p};
$seen{$p} = 1;
push @ret, $p;
- # MAXPARENT is defined to 16 in commit-tree.c:
- last if @ret >= 16;
- }
- if (@tmp) {
- die "r$log_entry->{revision}: No room for parents:\n\t",
- join("\n\t", @tmp), "\n";
}
@ret;
}
--
1.6.6.rc3.dirty
^ permalink raw reply related
* Re: [PATCH] git-svn: Remove obsolete MAXPARENT check
From: Eric Wong @ 2009-12-21 22:39 UTC (permalink / raw)
To: Junio C Hamano, Andrew Myrick; +Cc: git, sam
In-Reply-To: <1261434174-298-1-git-send-email-amyrick@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> Change git-svn not to impose a limit of 16 parents on a merge.
>
> This limit in git-svn artificially prevents cloning svn repositories
> that contain commits with more than 16 merge parents.
>
> The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit
> ef98c5cafb3e799b1568bb843fcd45920dc62f16, so there is no need to check for it
> it in git-svn.
>
> Signed-off-by: Andrew Myrick <amyrick@apple.com>
Thanks Andrew,
Acked-by: Eric Wong <normalperson@yhbt.net>
and pushed out to git://git.bogomips.org/git-svn along with the
rest of the stuff already pushed out last night.
Andrew Myrick (1):
git-svn: Remove obsolete MAXPARENT check
Eric Wong (2):
git svn: fix --revision when fetching deleted paths
update release notes for git svn in 1.6.6
Sam Vilain (5):
git-svn: expand the svn mergeinfo test suite, highlighting some failures
git-svn: memoize conversion of SVN merge ticket info to git commit ranges
git-svn: fix some mistakes with interpreting SVN mergeinfo commit ranges
git-svn: exclude already merged tips using one rev-list call
git-svn: detect cherry-picks correctly.
--
Eric Wong
^ permalink raw reply
* Re: git's fascination with absolute paths
From: Junio C Hamano @ 2009-12-22 0:26 UTC (permalink / raw)
To: Avery Pennarun; +Cc: J Chapman Flack, git
In-Reply-To: <32541b130912211409j540928c0g8e944fcc05c44f82@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Mon, Dec 21, 2009 at 1:42 PM, J Chapman Flack <jflack@math.purdue.edu> wrote:
>> In general it seems best for a program to stay free of assumptions
>> about absolute paths except when there is a specific functional
>> requirement that needs them. I assume there is something git does
>> that requires it to have this limitation, but it's not intuitive
>> to me if I just think about what I expect an scm system to do.
>> I've searched on 'absolute' in the list archive to see if there
>> was a past discussion like "we've decided we need absolute paths
>> everywhere because X" but I didn't find any. Can someone
>> describe what the reasoning was? A security concern perhaps?
>> (And one more serious than the race condition built into
>> make_absolute_path?)
>
> I think it's probably just because it's easier to deal with absolute
> paths than relative ones. Those ".." things can be annoying,
> particularly inside scripts, etc, and git uses a lot of scripts. Much
> more straightforward to just normalize all the paths once and be sure
> there are no weird dots in them.
Not really. The scripts can work with ".." just fine, as long as they
know how to use "cd_to_topdir" and "rev-parse --show-prefix" correctly.
While I do not necessarily agree with the original claim that hiding
higher level of hierarchies are "standard" practice in UNIX (it instead
falls into "an unusual set-up that is permitted but you have to be
careful" category), I don't think it is fundamental that we need read
access all the way up to the root level. It is only that getcwd(3) does.
At the basic work tree and index operations operate relative to the root
of the work tree. Originally, almost no privision was made to run from a
subdirectory of a work tree (you were expected to run from the top-level,
having ./.git as the meta information sture), and we didn't have to run
any getcwd(3). Later we added "look at parent directories until we find
the one that has .git subdirectory, while remembering how many levels we
went up", in order to support operations from a subdirectory of a work
tree. The commands chdir up to the root of the work tree and would use
the path they climbed as a pathspec to limit the scope of their operation.
While "counting how many levels we went up" can be expressed by a sequence
of "../", turning it to the directory prefix means at some point you would
need to do what getcwd(3) does. It wants to be able to read ".." to give
you an absolute path.
By rewriting that part of the "root-level-discovery" code to do something
like
- while test -d .git is not true:
- stat(".") to get the inum;
- chdir(".."); and
- opendir(".") and readdir() to find where we were;
while going up every level, you should be able to construct the prefix
without being to able to read all the way up to the filesystem root. You
only need to be able to read your work tree.
Admittedly the code complexity got worse later when we added support for
GIT_WORK_TREE and also GIT_CEILING_DIRECTORIES, as they fundamentally need
to know where you are relative to the root of the filesystem tree and need
a working getcwd(3) support, which J Chapman's set-up refuses to give.
Also I wouldn't be surprised if the support for these two features cheat
in order to reduce code complexity by always using absolute paths even in
places where a path relative to the root of the work tree might have
sufficed.
^ permalink raw reply
* Huge pack file from small unpacked objects
From: Nick Triantos @ 2009-12-22 6:19 UTC (permalink / raw)
To: 'git@vger.kernel.org'
In-Reply-To: <404585ED79625A40AB5A9884ECA9A63B3E02083F@VMBX125.ihostexchange.net>
Hi,
(re-sending.. I'm not sure if my last send made it to the list, I got a bounce because it had HTML.)
I recently created a repo from SVN via git-svn. The bare repo was about ~600MB. I cloned it, and on the clone, I added 2 small files (.gitignore and .gitattributes) to a branch, merged them to master, and pushed that back to the origin. The cloned repo remains at about 600MB, while my origin repo (the one from svn) is now about 2.4GB. I found that it created a file in objects/pack which accounts for this huge size.
I've tried running 'git repack -a -d' but that didn't shrink the size of this pack file.
Any ideas why the pack file is so huge? Anything I can do to shrink it? My coworkers are understandably unhappy that the repo is so huge now (makes for very slow pulls)
thanks,
-Nick
^ permalink raw reply
* Re: git's fascination with absolute paths
From: Junio C Hamano @ 2009-12-22 6:30 UTC (permalink / raw)
To: Avery Pennarun; +Cc: J Chapman Flack, git
In-Reply-To: <7v637z6ehg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Not really. The scripts can work with ".." just fine, as long as they
> know how to use "cd_to_topdir" and "rev-parse --show-prefix" correctly.
>
> While I do not necessarily agree with the original claim that hiding
> higher level of hierarchies are "standard" practice in UNIX (it instead
> falls into "an unusual set-up that is permitted but you have to be
> careful" category), I don't think it is fundamental that we need read
> access all the way up to the root level. It is only that getcwd(3) does.
>
> At the basic level, work tree and index operations operate relative to the root
> of the work tree. Originally, almost no privision was made to run from a
> subdirectory of a work tree (you were expected to run from the top-level,
> having ./.git as the meta information sture), and we didn't have to run
> any getcwd(3). Later we added "look at parent directories until we find
> the one that has .git subdirectory, while remembering how many levels we
> went up", in order to support operations from a subdirectory of a work
> tree. The commands chdir up to the root of the work tree and would use
> the path they climbed as a pathspec to limit the scope of their operation.
>
> While "counting how many levels we went up" can be expressed by a sequence
> of "../", turning it to the directory prefix means at some point you would
> need to do what getcwd(3) does. It wants to be able to read ".." to give
> you an absolute path.
>
> By rewriting that part of the "root-level-discovery" code to do something
> like
>
> - while test -d .git is not true:
> - stat(".") to get the inum;
> - chdir(".."); and
> - opendir(".") and readdir() to find where we were;
>
> while going up every level, you should be able to construct the prefix
> without being to able to read all the way up to the filesystem root. You
> only need to be able to read your work tree.
>
> Admittedly the code complexity got worse later when we added support for
> GIT_WORK_TREE and also GIT_CEILING_DIRECTORIES, as they fundamentally need
> to know where you are relative to the root of the filesystem tree and need
> a working getcwd(3) support, which J Chapman's set-up refuses to give.
>
> Also I wouldn't be surprised if the support for these two features cheat
> in order to reduce code complexity by always using absolute paths even in
> places where a path relative to the root of the work tree might have
> sufficed.
Clarificaiton.
The above, like many other messages from me, was not meant as a
justification, but a mere explanation of the historical fact. IOW, don't
get me wrong by interpreting that I am not interested in seeing a solution
that does not use absolute paths.
While I think the original "higher levels in the filesystems may not be
accessible" is a rather unusual set-up, making paths absolute and relying
on being able to always do so have another drawback in a not-so-unusual
setup. A work tree that is shallow (say, has only one t/ subdirectory and
short filenames) may not be usable if it is so deep in the filesystem
hierarchy that the result of getcwd(3) exceeds PATH_MAX. The "hand roll
what getcwd(3) did in traditional UNIX while looking for the root level of
the work tree" approach I outlined in the previous message will be a way
to fix such a use case; as long as the deepest level of your work tree
relative to the root of the work tree does not exceed PATH_MAX, you'll be
Ok.
We have a few known issues in the GIT_WORK_TREE (IIRC, it has a funny
interaction with alias expansion). When we reexamine the codepath that
the introduction of the feature needed to touch, I would love to see us at
least try to see if it is feasible to redo this without calling getcwd(3)
when no GIT_WORK_TREE (or core.worktree) is set.
^ permalink raw reply
* [PATCH] Prevent git blame from segfaulting on a missing author name
From: David Reiss @ 2009-12-22 4:22 UTC (permalink / raw)
To: git
The author name should never be missing in a valid commit, but
git shouldn't segfault no matter what is in the object database.
Signed-off-by: David Reiss <dreiss@facebook.com>
---
git blame was segfaulting on a repro produced by piping mtn git_export
from the Pidgin repository to git fast-import. This was the most obvious
fix, but I'm not sure if it is the best solution.
Here's a script that reproduces the segfault.
#!/bin/sh
set -e
git init
echo line > afile
git add afile
TREE=`git write-tree`
cat >badcommit <<EOF
tree $TREE
author <noname> 1234567890 +0000
committer David Reiss <dreiss@facebook.com> 1234567890 +0000
some message
EOF
COMMIT=`git hash-object -t commit -w badcommit`
echo "git --no-pager blame $COMMIT -- afile"
git --no-pager blame $COMMIT -- afile
builtin-blame.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index d4e25a5..5e19c79 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1326,7 +1326,7 @@ static void get_ac_line(const char *inbuf, const char *what,
timepos = tmp;
*tmp = 0;
- while (*tmp != ' ')
+ while (tmp > person && *tmp != ' ')
tmp--;
mailpos = tmp + 1;
*tmp = 0;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Prevent git blame from segfaulting on a missing author name
From: Junio C Hamano @ 2009-12-22 7:25 UTC (permalink / raw)
To: David Reiss; +Cc: git
In-Reply-To: <4B304993.2040600@facebook.com>
David Reiss <dreiss@facebook.com> writes:
> The author name should never be missing in a valid commit, but
> git shouldn't segfault no matter what is in the object database.
>
> Signed-off-by: David Reiss <dreiss@facebook.com>
> ---
> git blame was segfaulting on a repro produced by piping mtn git_export
> from the Pidgin repository to git fast-import. This was the most obvious
> fix, but I'm not sure if it is the best solution.
Thanks.
While it is _unusual_ not to have a human readable name, if the commits
come from foreign systems (e.g. CVS/SVN), there often are not sufficient
information in the source to fabricate names, so we should tolerate them.
We might want to also teach fast-import to warn when asked (i.e. when we
are feeding from a foreign interface that is designed to read from a
source that is capable of recording real names), but we shouldn't prevent
it from creating such a commit.
> Here's a script that reproduces the segfault.
Please make that into a new test in an existing test suite somewhere in t/
directory.
I think we probably should prepare ourselves to be fed with even more
broken commits, perhaps like this, if we are fixing it..
builtin-blame.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index d4e25a5..14830a3 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1305,6 +1305,7 @@ static void get_ac_line(const char *inbuf, const char *what,
error_out:
/* Ugh */
*tz = "(unknown)";
+ strcpy(person, *tz);
strcpy(mail, *tz);
*time = 0;
return;
@@ -1314,20 +1315,26 @@ static void get_ac_line(const char *inbuf, const char *what,
tmp = person;
tmp += len;
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp == person)
+ goto error_out;
*tz = tmp+1;
tzlen = (person+len)-(tmp+1);
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp == person)
+ goto error_out;
*time = strtoul(tmp, NULL, 10);
timepos = tmp;
*tmp = 0;
- while (*tmp != ' ')
+ while (person < tmp && *tmp != ' ')
tmp--;
+ if (tmp <= person)
+ return;
mailpos = tmp + 1;
*tmp = 0;
maillen = timepos - tmp;
^ permalink raw reply related
* git fast-import not verifying commit author lines?
From: David Reiss @ 2009-12-22 4:22 UTC (permalink / raw)
To: git
mtn git_export produces this output on a simple repo:
blob
mark :1
data 8
content
commit refs/heads/com.example.badexport
mark :2
author <somename> 1261454209 +0000
committer <somename> 1261454209 +0000
data 8
acommit
M 100644 :1 "afile"
progress revision 9b0e11e4d66eba8a3cf26095fb573116b886cd37 (1/1)
#############################################################
The author and committer lines are missing the names (I've filed this as a
bug with monotone). git commit-tree refuses to to produce a commit object
like this, so it seems like git fast-import should detect and report this
instead of silently writing the invalid commit object to the repository.
--David
^ permalink raw reply
* Re: Huge pack file from small unpacked objects
From: B Smith-Mannschott @ 2009-12-22 8:54 UTC (permalink / raw)
To: Nick Triantos; +Cc: git@vger.kernel.org
In-Reply-To: <75B8C0BEE0AE2A44AA971D218D9FE99E3DD8C61C@VMBX125.ihostexchange.net>
On Wed, Dec 16, 2009 at 17:34, Nick Triantos <nick@perceptivepixel.com> wrote:
> Hi,
>
> I recently created a repo from SVN via git-svn. The bare repo was about ~600MB. I cloned it, and on the clone, I added 2 small files (.gitignore and .gitattributes) to a branch, merged them to master, and pushed that back to the origin. The cloned repo remains at about 600MB, while my origin repo (the one from svn) is now about 2.4GB. I found that it created a file in objects/pack which accounts for this huge size.
>
> I've tried running 'git repack -a -d' but that didn't shrink the size of this pack file.
>
> Any ideas why the pack file is so huge? Anything I can do to shrink it? My coworkers are understandably unhappy that the repo is so huge now (makes for very slow pulls)
Have you tried "git prune"?
// Ben
^ permalink raw reply
* Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
From: Tomas Carnecky @ 2009-12-22 10:04 UTC (permalink / raw)
To: Git Mailing List
$ git --version
git version 1.6.6.rc4
# Documentation/perf_counter is missing from the master branch, so first
let's find
# out what the last commit was that touched that subdirectory:
$ git log --all -1 -- Documentation/perf_counter
commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Tue Jun 2 21:02:36 2009 +0200
...
M Documentation/perf_counter/builtin-report.c
# Great, let's look in which branch that commit is
$ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
* master
# So, let's look at the log of master and limit it to that subdirectory:
$ git log master -- Documentation/perf_counter
$
# Damn, that doesn't make any sense. In commit 43622 there were files in
that subdirectory, in master they have gone missing and yet log doesn't
show any commit touching that subdirectory?
# Let's try something different:
$ git log --diff-filter=D --name-status --all -- Documentation/perf_counter
...
# Ah, now we're getting somewhere, but still no sight of a commit which
removed for example Documentation/perf_counter/.gitignore
# I'm sure I'm probably just missing a tiny little switch for git-log. I
also tried other combination of name-status, diff-filter etc, but soon
after gave up.
tom
^ permalink raw reply
* [BUG REPORT] git-svn fails to create branches if ssh+svn gets used as protocol.
From: Florian Köberle @ 2009-12-22 9:53 UTC (permalink / raw)
To: git
Hello
I haven't seen a link to a bug tracker so I am sending this bug report
to the mailing list, I hope it's okay.
If you try to run
$ git svn branch foo
in a project using a svn+ssh url, you get the following error log:
Copying svn+ssh://example.org/svn/project/trunk at r1000 to
svn+ssh://me@example.org/svn/project/branches/foo...
Trying to use an unsupported feature: Source and dest appear not to be
in the same repository (src: 'svn+ssh://example.org/svn/project/trunk';
dst: 'svn+ssh://me@example.org/svn/project/branches/foo') at
/home/florian/libexec/git-core/git-svn line 722
It fails as the username is missing in the source url. If you modify the
git-svn script and add the username it works. The bug can be reproduced
with git-svn version 1.6.5.7 (svn 1.5.1).
Best regards,
Florian
^ permalink raw reply
* following untracked parents in git-svn
From: Robert Schiele @ 2009-12-22 10:28 UTC (permalink / raw)
To: Eric Wong; +Cc: git
[-- Attachment #1.1: Type: text/plain, Size: 3680 bytes --]
Hi Eric et al.,
While using git-svn to work with a repository with a very complex history I
discovered a very unfortunate behavior:
In general when a branch was derived (copied) from somewhere else git-svn
follows this parent branch and imports it. If multiple branches do that
git-svn detects that the corresponding parrent branch already had been
imported and reuses the imported data. Unfortunately when the parent
directory in the svn repository is not tracked as a branch in the svn-remote
section of the config file (for instance when it is just a subdirectory of a
tracked branch) this situation is no longer detected and this parent branch is
imported multiple times with the same result. In a large repository this can
increase importing time drastically.
My analysis (as far as I understand the code) is that this is because the map
files in .git/svn are indexed by their ref name in the git repository.
Untracked branches are indexed by the name of their following branch ref name
followed by @XX where XX is the revision number of the branch point.
Obviously with that scheme the index name for two branches following a common
parent tree is different and thus an already imported tree is not correctly
detected.
My thoughts where now that this could potentially be fixed by not indexing
those map files by their ref name in the git repository but by their location
in the original svn repository. Given that my understanding of the git-svn
code is not good enough to decide about all the consequences of such a design
change I'd like to ask you whether you think this change would be a good idea
or whether I might have overlooked a fundamental problem that makes it
impossible (or at least hard) to implement this idea.
Since my description of the problem might be a bit confusing without an
example I created a very small svn repository that shows this problem. A svn
repository dump for it is attached. When importing this repository using the
svn-remote section
[svn-remote "svn"]
url = file:///dev/shm/x/svn1
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
you will get the following behavior during the import:
$ git svn init -s file:///dev/shm/x/svn1
Initialized empty Git repository in /dev/shm/x/git2/.git/
$ git svn fetch
r1 = 7920f3e7e70c9bb9d8a7caf28830c7ed205c20c6 (refs/remotes/trunk)
A x/alpha
r2 = db7ad1b41f1d2ad18d198b9a80d2606b27557faf (refs/remotes/trunk)
A x/beta
r3 = a35cab9c510f66d96437f21ecb738c93e0c6b793 (refs/remotes/trunk)
Found possible branch point: file:///dev/shm/x/svn1/trunk/x => file:///dev/shm/x/svn1/branches/foo1, 2
Initializing parent: refs/remotes/foo1@2
A alpha
r2 = 5584693b5216dc1fa05f56455c67dfd61093ee43 (refs/remotes/foo1@2)
Found branch parent: (refs/remotes/foo1) 5584693b5216dc1fa05f56455c67dfd61093ee43
Following parent with do_switch
A beta
Successfully followed parent
r4 = d0cb7cfc1f69e52ecd39d8eb67518abe136b53d3 (refs/remotes/foo1)
Found possible branch point: file:///dev/shm/x/svn1/trunk/x => file:///dev/shm/x/svn1/branches/foo2, 2
Initializing parent: refs/remotes/foo2@2
A alpha
r2 = 5584693b5216dc1fa05f56455c67dfd61093ee43 (refs/remotes/foo2@2)
Found branch parent: (refs/remotes/foo2) 5584693b5216dc1fa05f56455c67dfd61093ee43
Following parent with do_switch
A beta
Successfully followed parent
r5 = 181cb81070b816bef74adefa1bc4c451100a5eef (refs/remotes/foo2)
Checked out HEAD:
file:///dev/shm/x/svn1/trunk r3
As you can see file:///dev/shm/x/svn1/trunk/x is imported twice. For this
small repository this is not a big issue but when this tree had a deep history
in a large repository you wanted to avoid that.
Robert
[-- Attachment #1.2: svndump.gz --]
[-- Type: application/x-gzip, Size: 616 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
From: Tomas Carnecky @ 2009-12-22 12:23 UTC (permalink / raw)
To: Daniel, Git Mailing List
In-Reply-To: <6b08a1ab.3349a908.4b30b80f.ab91f@o2.pl>
On 12/22/09 1:14 PM, Daniel wrote:
> Dnia 22 grudnia 2009 11:04 Tomas Carnecky<tomas.carnecky@gmail.com> napisał(a):
>
>> $ git --version
>> git version 1.6.6.rc4
>>
>> # Documentation/perf_counter is missing from the master branch, so first
>> let's find
>> # out what the last commit was that touched that subdirectory:
>> $ git log --all -1 -- Documentation/perf_counter
>> commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
>> Author: Peter Zijlstra<a.p.zijlstra@chello.nl>
>> Date: Tue Jun 2 21:02:36 2009 +0200
>> ...
>> M Documentation/perf_counter/builtin-report.c
>>
>> # Great, let's look in which branch that commit is
>> $ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
>> * master
>>
>> # So, let's look at the log of master and limit it to that subdirectory:
>> $ git log master -- Documentation/perf_counter
>> $
>>
>> # Damn, that doesn't make any sense. In commit 43622 there were files in
>> that subdirectory, in master they have gone missing and yet log doesn't
>> show any commit touching that subdirectory?
>> # Let's try something different:
>> $ git log --diff-filter=D --name-status --all -- Documentation/perf_counter
>> ...
>>
>> # Ah, now we're getting somewhere, but still no sight of a commit which
>> removed for example Documentation/perf_counter/.gitignore
>> # I'm sure I'm probably just missing a tiny little switch for git-log. I
>> also tried other combination of name-status, diff-filter etc, but soon
>> after gave up.
>>
>> tom
>> --
> Try
>
> $ git log --follow -- Documentation/perf_counter
>
Ah, that did the trick:
86470930, perf_counter tools: Move from Documentation/perf_counter/ to
tools/perf/
However, that still doesn't answer my question why a simple git log
doesn't show the commits. There are commits which touch that
subdirectory, so why is a list of 'commits which touch that
subdirectory' empty? Or am I misunderstanding what 'git log -- dir/' is
supposed to do? I thought it did exactly that.
tom
^ permalink raw reply
* Re: git fast-import not verifying commit author lines?
From: Shawn O. Pearce @ 2009-12-22 15:06 UTC (permalink / raw)
To: David Reiss; +Cc: git
In-Reply-To: <4B304987.7030201@facebook.com>
David Reiss <dreiss@facebook.com> wrote:
> mtn git_export produces this output on a simple repo:
>
> blob
> mark :1
> data 8
> content
>
> commit refs/heads/com.example.badexport
> mark :2
> author <somename> 1261454209 +0000
> committer <somename> 1261454209 +0000
> data 8
> acommit
>
> M 100644 :1 "afile"
> progress revision 9b0e11e4d66eba8a3cf26095fb573116b886cd37 (1/1)
> #############################################################
>
> The author and committer lines are missing the names (I've filed this as a
> bug with monotone). git commit-tree refuses to to produce a commit object
> like this, so it seems like git fast-import should detect and report this
> instead of silently writing the invalid commit object to the repository.
Nope.
These objects can still be processed by git commands, you just can't
normally create them with Git tools. To some extent fast-import
allows the caller to import data that you wouldn't otherwise create
in Git because we know you are coming from a foreign system where
the data might not reasonably exist.
--
Shawn.
^ permalink raw reply
* Trouble with 'make prefix=/usr info'
From: Craig Moore @ 2009-12-22 15:50 UTC (permalink / raw)
To: git
Hi,
I'm getting the following error when I make the info target:
$ make prefix=/usr info
make -C Documentation info
make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
make[2]: Entering directory `/local/software/git-1.6.5.7'
make[2]: `GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory `/local/software/git-1.6.5.7'
DB2TEXI user-manual.texi
Usage: jw [<options>] <sgml_file>
where <options> are:
-f|--frontend <frontend>: Specify the frontend (source format)
(default is docbook)
-b|--backend <backend>: Specify the backend (destination format)
(default is html)
-c|--cat <file>: Specify an extra SGML open catalog
-n|--nostd: Do not use the standard SGML open catalogs
-d|--dsl <file>|default|none: Specify an alternate style sheet
(default is to use the default stylesheet)
-l|--dcl <file>: Specify an alternate SGML declaration
(usual ones like xml.dcl get detected
automatically)
-s|--sgmlbase <path>: Change base directory for SGML distribution
(usually /usr/share/sgml)
-p|--parser <program>: Specify the parser if several are installed
(jade or openjade)
-o|--output <directory>: Set output directory
-u|--nochunks: Output only one big file
(overrides the stylesheet settings)
-i|--include <section>: Specify a SGML marked section to include
(should be marked as "ignore" in the SGML text)
-w|--warning <warning_type>|list: Control warnings or display the allowed
warning types
-e|--errors <error_type>|list: Control errors or display the allowed error types
-h|--help: Print this help message and exit
-V <variable[=value]>: Set a variable
-v|--version: Print the version and exit
make[1]: *** [user-manual.texi] Error 1
make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
make: *** [info] Error 2
I can see that the error is likely related to the fact that it enters the
Documentation directing, then exits the Documentation directory, and then tries
to build the user-manual.texi file in the root directory (however, that file is
in the Documentation directory, which it just left). I've tried to track down
and change where it exits the Documentation directory, but I've had no success.
I would appreciate any recommendations you might have. I've already been able to
install git, but I couldn't install the 'info' target because of this error.
Thanks,
Craig
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Michael J Gruber @ 2009-12-22 15:58 UTC (permalink / raw)
To: Craig Moore; +Cc: git
In-Reply-To: <loom.20091222T164442-704@post.gmane.org>
Craig Moore venit, vidit, dixit 22.12.2009 16:50:
> Hi,
>
> I'm getting the following error when I make the info target:
>
> $ make prefix=/usr info
> make -C Documentation info
> make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
> make[2]: Entering directory `/local/software/git-1.6.5.7'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/local/software/git-1.6.5.7'
> DB2TEXI user-manual.texi
> Usage: jw [<options>] <sgml_file>
> where <options> are:
> -f|--frontend <frontend>: Specify the frontend (source format)
> (default is docbook)
> -b|--backend <backend>: Specify the backend (destination format)
> (default is html)
> -c|--cat <file>: Specify an extra SGML open catalog
> -n|--nostd: Do not use the standard SGML open catalogs
> -d|--dsl <file>|default|none: Specify an alternate style sheet
> (default is to use the default stylesheet)
> -l|--dcl <file>: Specify an alternate SGML declaration
> (usual ones like xml.dcl get detected
> automatically)
> -s|--sgmlbase <path>: Change base directory for SGML distribution
> (usually /usr/share/sgml)
> -p|--parser <program>: Specify the parser if several are installed
> (jade or openjade)
> -o|--output <directory>: Set output directory
> -u|--nochunks: Output only one big file
> (overrides the stylesheet settings)
> -i|--include <section>: Specify a SGML marked section to include
> (should be marked as "ignore" in the SGML text)
> -w|--warning <warning_type>|list: Control warnings or display the allowed
> warning types
> -e|--errors <error_type>|list: Control errors or display the allowed error types
> -h|--help: Print this help message and exit
> -V <variable[=value]>: Set a variable
> -v|--version: Print the version and exit
> make[1]: *** [user-manual.texi] Error 1
> make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
> make: *** [info] Error 2
>
> I can see that the error is likely related to the fact that it enters the
> Documentation directing, then exits the Documentation directory, and then tries
> to build the user-manual.texi file in the root directory (however, that file is
> in the Documentation directory, which it just left). I've tried to track down
> and change where it exits the Documentation directory, but I've had no success.
>
> I would appreciate any recommendations you might have. I've already been able to
> install git, but I couldn't install the 'info' target because of this error.
Does it work without prefix?
Also, you may want to cd into Documentation and try to make there.
Michael
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Craig Moore @ 2009-12-22 16:14 UTC (permalink / raw)
To: git
In-Reply-To: <4B30ECA1.2040508@drmicha.warpmail.net>
2009/12/22 Michael J Gruber <git@drmicha.warpmail.net>:
> Craig Moore venit, vidit, dixit 22.12.2009 16:50:
>> Hi,
>>
>> I'm getting the following error when I make the info target:
>>
>> $ make prefix=/usr info
>> make -C Documentation info
>> make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
>> make[2]: Entering directory `/local/software/git-1.6.5.7'
>> make[2]: `GIT-VERSION-FILE' is up to date.
>> make[2]: Leaving directory `/local/software/git-1.6.5.7'
>> DB2TEXI user-manual.texi
>> Usage: jw [<options>] <sgml_file>
>> where <options> are:
>> -f|--frontend <frontend>: Specify the frontend (source format)
>> (default is docbook)
>> -b|--backend <backend>: Specify the backend (destination format)
>> (default is html)
>> -c|--cat <file>: Specify an extra SGML open catalog
>> -n|--nostd: Do not use the standard SGML open catalogs
>> -d|--dsl <file>|default|none: Specify an alternate style sheet
>> (default is to use the default stylesheet)
>> -l|--dcl <file>: Specify an alternate SGML declaration
>> (usual ones like xml.dcl get detected
>> automatically)
>> -s|--sgmlbase <path>: Change base directory for SGML distribution
>> (usually /usr/share/sgml)
>> -p|--parser <program>: Specify the parser if several are installed
>> (jade or openjade)
>> -o|--output <directory>: Set output directory
>> -u|--nochunks: Output only one big file
>> (overrides the stylesheet settings)
>> -i|--include <section>: Specify a SGML marked section to include
>> (should be marked as "ignore" in the SGML text)
>> -w|--warning <warning_type>|list: Control warnings or display the allowed
>> warning types
>> -e|--errors <error_type>|list: Control errors or display the allowed error types
>> -h|--help: Print this help message and exit
>> -V <variable[=value]>: Set a variable
>> -v|--version: Print the version and exit
>> make[1]: *** [user-manual.texi] Error 1
>> make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
>> make: *** [info] Error 2
>>
>> I can see that the error is likely related to the fact that it enters the
>> Documentation directing, then exits the Documentation directory, and then tries
>> to build the user-manual.texi file in the root directory (however, that file is
>> in the Documentation directory, which it just left). I've tried to track down
>> and change where it exits the Documentation directory, but I've had no success.
>>
>> I would appreciate any recommendations you might have. I've already been able to
>> install git, but I couldn't install the 'info' target because of this error.
>
> Does it work without prefix?
> Also, you may want to cd into Documentation and try to make there.
>
> Michael
>
>
Hey Michael,
Here is what happens when I run it inside the Documentation directory
(without the prefix):
user@server: /local/software/git-1.6.5.7/Documentation
$ make info
SUBDIR ../
make[1]: `GIT-VERSION-FILE' is up to date.
DB2TEXI user-manual.texi
Usage: jw [<options>] <sgml_file>
where <options> are:
-f|--frontend <frontend>: Specify the frontend (source format)
(default is docbook)
-b|--backend <backend>: Specify the backend (destination format)
(default is html)
-c|--cat <file>: Specify an extra SGML open catalog
-n|--nostd: Do not use the standard SGML open catalogs
-d|--dsl <file>|default|none: Specify an alternate style sheet
(default is to use the default stylesheet)
-l|--dcl <file>: Specify an alternate SGML declaration
(usual ones like xml.dcl get detected
automatically)
-s|--sgmlbase <path>: Change base directory for SGML distribution
(usually /usr/share/sgml)
-p|--parser <program>: Specify the parser if several are installed
(jade or openjade)
-o|--output <directory>: Set output directory
-u|--nochunks: Output only one big file
(overrides the stylesheet settings)
-i|--include <section>: Specify a SGML marked section to include
(should be marked as "ignore" in the SGML text)
-w|--warning <warning_type>|list: Control warnings or display the
allowed warning types
-e|--errors <error_type>|list: Control errors or display the allowed
error types
-h|--help: Print this help message and exit
-V <variable[=value]>: Set a variable
-v|--version: Print the version and exit
make: *** [user-manual.texi] Error 1
The first thing it does is go to the directory above, weird.
Craig
^ permalink raw reply
* Re: git's fascination with absolute paths
From: J Chapman Flack @ 2009-12-22 17:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vy6kv4j2u.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Clarificaiton.
>
> The above, like many other messages from me, was not meant as a
> justification, but a mere explanation of the historical fact. IOW,
> don't get me wrong by interpreting that I am not interested in seeing
> a solution that does not use absolute paths.
No worries - a sense of the history is exactly the kind of response
I was hoping for. :)
> While I think the original "higher levels in the filesystems may not
> be accessible" is a rather unusual set-up, making paths absolute and
> relying on being able to always do so have another drawback in a
> not-so-unusual setup. A work tree that is shallow (say, has only one
> t/ subdirectory and short filenames) may not be usable if it is so
> deep in the filesystem hierarchy that the result of getcwd(3) exceeds
> PATH_MAX. The "hand roll
This is funny; I think in my own career I've seen applications that keep
sensitive data in subtrees restricted at the top somewhat routinely (which
might not mean "really often in absolute terms" but something more like
"whenever it made sense for the app") going back at least as far as uucp
(IIRC) ... Solaris Zones are set up that way too (when viewed from the
global zone). By the same token, while I'd never be surprised to hear
of someone with deep hierarchies that exceed PATH_MAX, I'm not sure I've
ever actually seen it happen myself.
I don't intend that as the start of a "which case is more unusual"
comparison, I think it just illustrates the difficulty in making such
judgments of usualness, as different people's career trajectories expose
them to very different things. I'd rather spend the mental effort trying
to extract whatever general principle can be used to code robustly so the
fewest judgments of usualness need to be made. Here the general principle
(which I think you've already kind of stated yourself, so I'm not trying
to preach but just to finish the thought) is that, for various reasons,
trying to transform a relative into an absolute path is not always well
defined, can't even always be done, can have implementation-dependent
side effects and race conditions, and ought to be an operation that gets
pulled out of the arsenal only with deliberation and only for specific
paths that must be made absolute if that's the only way to satisfy some
known functional requirement of the app.
It might be tied in to the principle of least astonishment, just by
assuming that whatever path the caller, user, or admin provides is
probably the path s/he wants you to use, for any number of possible
reasons that you don't need to be able to foresee.
>> By rewriting that part of the "root-level-discovery" code to do
>> something like
>>
>> - while test -d .git is not true:
>> - stat(".") to get the inum;
>> - chdir(".."); and
>> - opendir(".") and readdir() to find where we were;
>>
>> while going up every level, you should be able to construct the prefix
>> without being to able to read all the way up to the filesystem root.
You
>> only need to be able to read your work tree.
Yes, that's exactly what I would have suggested for the root level
discovery. As long as you can find .git before reaching any inaccessible
ancestor, life is good. (And if you can't it's a perfectly good reason
to give up without astonishing the user.)
It would still be better to open "." once at the beginning and
fchdir back to it, rather than trying to chdir back to the
constructed path string (an inherent race condition), just as the
Notes section in linux getcwd(3) says.
An interesting point, the chdir ../opendir/readdir algorithm you
give above is no longer necessarily what getcwd does, though it
traditionally was. These days there's often a kernel name cache
that getcwd gets at through a syscall or /proc. You can tell,
because when I tried to use 'git init' in my situation, the error
was not from getcwd but from the later access() call done on the
full path that getcwd successfully returned.
[there's a side issue: access(2) isn't for what a lot of people
think it's for. It's a rather esoteric call for testing access
by the real ids instead of the effective ones, and it's needed
in code that (a) runs set{u,g}id AND (b) wants to confirm that
a user-specified file is really something the user has rights to.
Using access() routinely just to ask "can I open this" has
a couple of problems: (1) it has a race condition and gives you
less information than just trying the open and testing errno;
(2) if anybody down the road does try to use your program or
code under set{u,g}id circumstances, astonishing failures can
result. Even for its intended purpose access() suffers from a
race; current OSes make it fairly easy to just drop to the real
user's IDs, try the open, and test errno, so access() is a bit
of a dinosaur.]
Anyway, it would also be possible to make use of the modern
optimized getcwd in the root-level-discovery algorithm. If getcwd
gives a result you can just follow it backwards until you find .git,
confirming in each step that you can stat the name of the child and
the inums match (an O(1) test instead of O(directory-size) for readdir).
Just don't follow it back past the directory containing .git. The
slower fallback code is only needed for less modern systems in case
getcwd returns EACCES. But now we're in the realm of optimization;
the traditional loop does the trick.
(well, one nice feature of the modern approach, beyond speed, is that
it only needs x on the directories up to .git and not r. but since
I'm doubtful anything else git does would actually work without r,
that's probably moot.)
>> Admittedly the code complexity got worse later when we added support
>> for GIT_WORK_TREE and also GIT_CEILING_DIRECTORIES, as they
>> fundamentally need to know where you are relative to the root of the
>> filesystem tree and need a working getcwd(3) support
That's the kind of thing I wondered about, are there particular
features that genuinely require an absolute path? I'm a git newbie
and I don't know what these features do, so I can't comment. (This
project was going to be my excuse for learning git, but rcs actually
suffices and I need to get it done.)
Do these features actually need to traverse the full path, or just
to know what it is? On a system with modern getcwd that can return
the path even if it isn't traversable, could they make use of that?
-Chap
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Michael J Gruber @ 2009-12-22 17:22 UTC (permalink / raw)
To: Craig Moore; +Cc: git
In-Reply-To: <d4133e470912220814h465175bfr8fd10942898096a1@mail.gmail.com>
Craig Moore venit, vidit, dixit 22.12.2009 17:14:
> 2009/12/22 Michael J Gruber <git@drmicha.warpmail.net>:
>> Craig Moore venit, vidit, dixit 22.12.2009 16:50:
>>> Hi,
>>>
>>> I'm getting the following error when I make the info target:
>>>
>>> $ make prefix=/usr info
>>> make -C Documentation info
>>> make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
>>> make[2]: Entering directory `/local/software/git-1.6.5.7'
>>> make[2]: `GIT-VERSION-FILE' is up to date.
>>> make[2]: Leaving directory `/local/software/git-1.6.5.7'
>>> DB2TEXI user-manual.texi
>>> Usage: jw [<options>] <sgml_file>
>>> where <options> are:
>>> -f|--frontend <frontend>: Specify the frontend (source format)
>>> (default is docbook)
>>> -b|--backend <backend>: Specify the backend (destination format)
>>> (default is html)
>>> -c|--cat <file>: Specify an extra SGML open catalog
>>> -n|--nostd: Do not use the standard SGML open catalogs
>>> -d|--dsl <file>|default|none: Specify an alternate style sheet
>>> (default is to use the default stylesheet)
>>> -l|--dcl <file>: Specify an alternate SGML declaration
>>> (usual ones like xml.dcl get detected
>>> automatically)
>>> -s|--sgmlbase <path>: Change base directory for SGML distribution
>>> (usually /usr/share/sgml)
>>> -p|--parser <program>: Specify the parser if several are installed
>>> (jade or openjade)
>>> -o|--output <directory>: Set output directory
>>> -u|--nochunks: Output only one big file
>>> (overrides the stylesheet settings)
>>> -i|--include <section>: Specify a SGML marked section to include
>>> (should be marked as "ignore" in the SGML text)
>>> -w|--warning <warning_type>|list: Control warnings or display the allowed
>>> warning types
>>> -e|--errors <error_type>|list: Control errors or display the allowed error types
>>> -h|--help: Print this help message and exit
>>> -V <variable[=value]>: Set a variable
>>> -v|--version: Print the version and exit
>>> make[1]: *** [user-manual.texi] Error 1
>>> make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
>>> make: *** [info] Error 2
>>>
>>> I can see that the error is likely related to the fact that it enters the
>>> Documentation directing, then exits the Documentation directory, and then tries
>>> to build the user-manual.texi file in the root directory (however, that file is
>>> in the Documentation directory, which it just left). I've tried to track down
>>> and change where it exits the Documentation directory, but I've had no success.
>>>
>>> I would appreciate any recommendations you might have. I've already been able to
>>> install git, but I couldn't install the 'info' target because of this error.
>>
>> Does it work without prefix?
>> Also, you may want to cd into Documentation and try to make there.
>>
>> Michael
>>
>>
>
> Hey Michael,
>
> Here is what happens when I run it inside the Documentation directory
> (without the prefix):
>
> user@server: /local/software/git-1.6.5.7/Documentation
> $ make info
> SUBDIR ../
> make[1]: `GIT-VERSION-FILE' is up to date.
> DB2TEXI user-manual.texi
> Usage: jw [<options>] <sgml_file>
> where <options> are:
> -f|--frontend <frontend>: Specify the frontend (source format)
> (default is docbook)
> -b|--backend <backend>: Specify the backend (destination format)
> (default is html)
> -c|--cat <file>: Specify an extra SGML open catalog
> -n|--nostd: Do not use the standard SGML open catalogs
> -d|--dsl <file>|default|none: Specify an alternate style sheet
> (default is to use the default stylesheet)
> -l|--dcl <file>: Specify an alternate SGML declaration
> (usual ones like xml.dcl get detected
> automatically)
> -s|--sgmlbase <path>: Change base directory for SGML distribution
> (usually /usr/share/sgml)
> -p|--parser <program>: Specify the parser if several are installed
> (jade or openjade)
> -o|--output <directory>: Set output directory
> -u|--nochunks: Output only one big file
> (overrides the stylesheet settings)
> -i|--include <section>: Specify a SGML marked section to include
> (should be marked as "ignore" in the SGML text)
> -w|--warning <warning_type>|list: Control warnings or display the
> allowed warning types
> -e|--errors <error_type>|list: Control errors or display the allowed
> error types
> -h|--help: Print this help message and exit
> -V <variable[=value]>: Set a variable
> -v|--version: Print the version and exit
> make: *** [user-manual.texi] Error 1
>
> The first thing it does is go to the directory above, weird.
>
> Craig
I think it only looks like that. SUBDIR processing is finished at that
point, and the DB2TEXI line is where user-manual.texi is actually being
processed, and that's what's causing the error. Did you set the texinfo
processor in the Makefile or using variables?
V=1 make info
will show you the exact commands being executed.
Michael
^ permalink raw reply
* Re: Huge pack file from small unpacked objects
From: Nicolas Pitre @ 2009-12-22 17:41 UTC (permalink / raw)
To: Nick Triantos; +Cc: 'git@vger.kernel.org'
In-Reply-To: <75B8C0BEE0AE2A44AA971D218D9FE99E6B06F030@VMBX125.ihostexchange.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 727 bytes --]
On Tue, 22 Dec 2009, Nick Triantos wrote:
> I recently created a repo from SVN via git-svn. The bare repo was
> about ~600MB. I cloned it, and on the clone, I added 2 small files
> (.gitignore and .gitattributes) to a branch, merged them to master,
> and pushed that back to the origin. The cloned repo remains at about
> 600MB, while my origin repo (the one from svn) is now about 2.4GB. I
> found that it created a file in objects/pack which accounts for this
> huge size.
>
> I've tried running 'git repack -a -d' but that didn't shrink the size
> of this pack file.
This is rather weird.
Any chance the original repository could be downloaded somewhere in
order to attempt reproducing this issue?
Nicolas
^ permalink raw reply
* RE: Huge pack file from small unpacked objects
From: Nick Triantos @ 2009-12-22 18:04 UTC (permalink / raw)
To: B Smith-Mannschott; +Cc: git@vger.kernel.org
In-Reply-To: <28c656e20912220054qc7b6497t79e135c913865c22@mail.gmail.com>
I've tried running 'git gc' (which should be pruning) and that hasn't helped.
Is there an easy way to unpack the pack file and see what's inside (including sizes)?
thanks,
-Nick
-----Original Message-----
From: B Smith-Mannschott [mailto:bsmith.occs@gmail.com]
Sent: Tuesday, December 22, 2009 12:55 AM
To: Nick Triantos
Cc: git@vger.kernel.org
Subject: Re: Huge pack file from small unpacked objects
On Wed, Dec 16, 2009 at 17:34, Nick Triantos <nick@perceptivepixel.com> wrote:
> Hi,
>
> I recently created a repo from SVN via git-svn. The bare repo was about ~600MB. I cloned it, and on the clone, I added 2 small files (.gitignore and .gitattributes) to a branch, merged them to master, and pushed that back to the origin. The cloned repo remains at about 600MB, while my origin repo (the one from svn) is now about 2.4GB. I found that it created a file in objects/pack which accounts for this huge size.
>
> I've tried running 'git repack -a -d' but that didn't shrink the size of this pack file.
>
> Any ideas why the pack file is so huge? Anything I can do to shrink it? My coworkers are understandably unhappy that the repo is so huge now (makes for very slow pulls)
Have you tried "git prune"?
// Ben
^ permalink raw reply
* Re: Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
From: Junio C Hamano @ 2009-12-22 18:08 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Git Mailing List
In-Reply-To: <4B3099A5.6040808@gmail.com>
Tomas Carnecky <tomas.carnecky@gmail.com> writes:
> $ git --version
> git version 1.6.6.rc4
>
> # Documentation/perf_counter is missing from the master branch, so
> first let's find
> # out what the last commit was that touched that subdirectory:
> $ git log --all -1 -- Documentation/perf_counter
> commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Tue Jun 2 21:02:36 2009 +0200
> ...
> M Documentation/perf_counter/builtin-report.c
>
> # Great, let's look in which branch that commit is
> $ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
> * master
>
> # So, let's look at the log of master and limit it to that subdirectory:
> $ git log master -- Documentation/perf_counter
> $
Add --full-history so that you would get _all_ possible explanation of the
history, perhaps?
In a history with this shape:
---A---B---C---D---E
\ /
F---G
suppose that
- commit F introduces a path;
- commit G removes the path;
- no other commit has the path in question.
Without --full-history, "log E -- path" is asked to give "_one_ possible
way to explain the current state of path in E" (iow, "why there is nothing
there right now at E?").
Two explanations are possible even in this vastly simplified toy history.
- It didn't exist in A, and none of the subsequent commits B, C, D that
lead to E did anything to change that.
- F added it, but G changed mind and removed it.
When "log" encounters a merge commit while traversing the history
backwards (in this case D) with paths limiter, if there is a commit among
its parent whose tree matches its tree with respect to the paths, side
branches leading to all the other parents are culled and only that one
history is followed to explain the history. In this case, neither C or D
has the path, so their trees with respect to the paths limiter match, and
git doesn't follow the side branch that has F and G without
--full-history.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox