* Re: [PATCH] merge-recursive: Improve the error message printed when merge(1) isn't found.
From: Roberto Nibali @ 2006-01-29 23:42 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, junkio
In-Reply-To: <20060129121608.GC4815@c165.ib.student.liu.se>
> - [out, code] = runProgram(['merge',
> - '-L', branch1Name + '/' + aPath,
> - '-L', 'orig/' + oPath,
> - '-L', branch2Name + '/' + bPath,
> - src1, orig, src2], returnCode=True)
> + try:
> + [out, code] = runProgram(['merge',
> + '-L', branch1Name + '/' + aPath,
> + '-L', 'orig/' + oPath,
> + '-L', branch2Name + '/' + bPath,
> + src1, orig, src2], returnCode=True)
> + except ProgramError, e:
> + print >>sys.stderr, e
> + die("Failed to execute 'merge'. merge(1) is used as the "
> + "file-level merge tool. Is 'merge' in your path?")
This has my vote as well.
Thanks for your support,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ permalink raw reply
* [PATCH] rev-list: omit duplicated parents.
From: Junio C Hamano @ 2006-01-29 23:30 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, torvalds
In-Reply-To: <7vmzhekcz3.fsf@assigned-by-dhcp.cox.net>
Showing the same parent more than once for a commit does not
make much sense downstream, so stop it.
This can happen with an incorrectly made merge commit that
merges the same parent twice, but can happen in an otherwise
sane development history while squishing the history by taking
into account only commits that touch specified paths.
For example,
$ git rev-list --max-count=1 --parents addafaf -- rev-list.c
would have to show this commit ancestry graph:
.---o---.
/ \
.---*---o---.
/ 93b74bc \
---*---o---o-----o---o-----o addafaf
d8f6b34 \ /
.---o---o---.
\ /
.---*---.
3815f42
where 5 independent development tracks, only two of which have
changes in the specified paths since they forked. The last
change for the other three development tracks was done by the
same commit before they forked, and we were showing that three
times.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> I think it probably is a bug...
> ...
> Let me wait for a while to hear Linus contradicts me, though...
I've considered doing this only when path is specified, but
instead decided to do so for all commits. I recall there
are commits in the kernel archive created somehow with the
same parent listed twice, and the downstream tools would
have the same trouble if we didn't.
rev-list.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
d6d9f494403a4e77d17244ece43005eec51200d3
diff --git a/rev-list.c b/rev-list.c
index 0b142c1..93ea41b 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -12,6 +12,7 @@
#define COUNTED (1u << 2)
#define SHOWN (1u << 3)
#define TREECHANGE (1u << 4)
+#define TMP_MARK (1u << 5) /* for isolated cases; clean after use */
static const char rev_list_usage[] =
"git-rev-list [OPTION] <commit-id>... [ -- paths... ]\n"
@@ -72,9 +73,21 @@ static void show_commit(struct commit *c
if (show_parents) {
struct commit_list *parents = commit->parents;
while (parents) {
- printf(" %s", sha1_to_hex(parents->item->object.sha1));
+ struct object *o = &(parents->item->object);
parents = parents->next;
+ if (o->flags & TMP_MARK)
+ continue;
+ printf(" %s", sha1_to_hex(o->sha1));
+ o->flags |= TMP_MARK;
}
+ /* TMP_MARK is a general purpose flag that can
+ * be used locally, but the user should clean
+ * things up after it is done with them.
+ */
+ for (parents = commit->parents;
+ parents;
+ parents = parents->next)
+ parents->item->object.flags &= ~TMP_MARK;
}
if (commit_format == CMIT_FMT_ONELINE)
putchar(' ');
--
1.1.5.g9843f
^ permalink raw reply related
* Re: [PATCH 0/3] Remove more parsers
From: Daniel Barkalow @ 2006-01-29 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6ciixv0.fsf@assigned-by-dhcp.cox.net>
On Sun, 29 Jan 2006, Junio C Hamano wrote:
> I do not have objections to git-tar-tree changes, but I am
> hesitant to use the tree parser in diff-tree due to its memory
> retention behaviour. We already use the commit parser in
> diff-tree but I think we currently do not ask for the tree part
> of the object to be parsed. I suspect this patch would badly
> interact with long-running "diff-tree --stdin", which is the
> workhorse of whatchanged. I haven't benched it though, and I'd
> be happy to see the impact is proven to be negligible.
I'll look into discarding the struct trees after use (since we're not
keeping flags on them, or storing references to them long-term), so we can
use the same parser without worse memory behavior. It does seem to take a
bunch more memory (and, oddly, be very slow) as I currently have it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git commit error on initial (the very first) commit
From: J. Bruce Fields @ 2006-01-29 21:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrey Borzenkov, git
In-Reply-To: <7v1wyqivx1.fsf@assigned-by-dhcp.cox.net>
On Sun, Jan 29, 2006 at 01:08:58PM -0800, Junio C Hamano wrote:
> In a freshly created repository, "git add ." would register
> everything to the index file, and a "git commit" with or without
> "-a" that immediately follows "git add ." would commit what is
> in the index. Use of "-a" would not make a difference here.
Aie, you're right of course, thanks.--b.
^ permalink raw reply
* Re: git commit error on initial (the very first) commit
From: Junio C Hamano @ 2006-01-29 21:08 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Andrey Borzenkov, git
In-Reply-To: <20060129181625.GA5540@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Sun, Jan 29, 2006 at 08:26:54PM +0300, Andrey Borzenkov wrote:
>> May be I do something wrong? What is correct procedure to initially import
>> tree? git 1.1.4
>>
>> {pts/0}% git init-db
>> defaulting to local storage area
>> {pts/0}% git add .
>> {pts/0}% git commit -m 'initial import'
>
> It needs to know which paths to update.
While I agree with you that individual developers should always
say "commit -a" after testing their changes, I do not think that
has much to do with Andrey's problem.
In a freshly created repository, "git add ." would register
everything to the index file, and a "git commit" with or without
"-a" that immediately follows "git add ." would commit what is
in the index. Use of "-a" would not make a difference here.
^ permalink raw reply
* Re: git commit error on initial (the very first) commit
From: Junio C Hamano @ 2006-01-29 21:05 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: git
In-Reply-To: <200601292026.54893.arvidjaar@mail.ru>
Andrey Borzenkov <arvidjaar@mail.ru> writes:
> May be I do something wrong? What is correct procedure to initially import
> tree? git 1.1.4
>
> {pts/0}% git init-db
> defaulting to local storage area
> {pts/0}% git add .
> {pts/0}% git commit -m 'initial import'
> usage: git-diff-index [-m] [--cached] [<common diff options>] <tree-ish>
> [<path>...]
> common diff options:
> ... etc
I suspect you have $(template_dir)/hooks/pre-commit enabled.
-- >8 --
[PATCH] pre-commit sample hook: do not barf on the initial import
The example hook barfs on the initial import. Ideally it should
produce a diff from an empty tree, but for now let's stop at
squelching the bogus error message. Often an initial import
involves tons of badly formatted files from foreign SCM, so not
complaining about them like this patch does might actually be a
better idea than enforcing the "Perfect Patch" format on them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 4bb6803..6b3a21b 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -10,8 +10,16 @@
# This is slightly modified from Andrew Morton's Perfect Patch.
# Lines you introduce should not have trailing whitespace.
# Also check for an indentation that has SP before a TAB.
+
+if git-rev-parse --verify HEAD 2>/dev/null
+then
+ git-diff-index -p -M --cached HEAD
+else
+ # NEEDSWORK: we should produce a diff with an empty tree here
+ # if we want to do the same verification for the initial import.
+ :
+fi |
perl -e '
- my $fh;
my $found_bad = 0;
my $filename;
my $reported_filename = "";
@@ -31,8 +39,7 @@ perl -e '
print STDERR "* $why (line $lineno)\n";
print STDERR "$filename:$lineno:$line\n";
}
- open $fh, "-|", qw(git-diff-index -p -M --cached HEAD);
- while (<$fh>) {
+ while (<>) {
if (m|^diff --git a/(.*) b/\1$|) {
$filename = $1;
next;
^ permalink raw reply related
* Re: [Census] So who uses git?
From: Martin Langhoff @ 2006-01-29 20:29 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Dave Jones, Junio C Hamano, Keith Packard, Linus Torvalds,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601291438251.25300@iabervon.org>
On 1/30/06, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > There's also another git usage that I doubt I'm alone in doing.
> > I regularly use git to import cvs trees from sourceforge etc for
> > random projects, because I now find browsing history of projects
> > with tools like gitk much nicer than any cvs tool I've used.
> > (cvs annotate is the only thing I really miss).
>
> I think this is the real driving factor for git adoption: it doesn't have
> to be 10x better for people to use it, because individuals can use it for
> interacting with CVS projects without causing anybody else any pain.
IMHO, this is a killer feature of GIT. From a CVS/SVN user point of
view, it has vendor branches done right. At work, we do that with
Moodle, Elgg, EPrints and GForge. And the list is growing. That's why
I'm working on the toolchain to make interop with CVS smooth so I can
land patches in upstream projects where I have cvs access.
cheers,
m
^ permalink raw reply
* Re: [PATCH 0/3] Remove more parsers
From: Junio C Hamano @ 2006-01-29 20:26 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0601291336420.25300@iabervon.org>
I do not have objections to git-tar-tree changes, but I am
hesitant to use the tree parser in diff-tree due to its memory
retention behaviour. We already use the commit parser in
diff-tree but I think we currently do not ask for the tree part
of the object to be parsed. I suspect this patch would badly
interact with long-running "diff-tree --stdin", which is the
workhorse of whatchanged. I haven't benched it though, and I'd
be happy to see the impact is proven to be negligible.
^ permalink raw reply
* Re: [PATCH] rev-{list,parse}: optionally allow -<n> as shorthand for --max-count=<n>
From: Junio C Hamano @ 2006-01-29 20:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20060129134720.GB3428@Muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> This will only be enabled if POSIX_SHMOSIX is defined at compile-time.
Maybe a better name would be POSIX_ME_HARDER ^W oops, POSIXLY_CORRECT
to disable this?
^ permalink raw reply
* Re: [PATCH] rev-{list,parse}: allow -n<n> as shorthand for --max-count=<n>
From: Junio C Hamano @ 2006-01-29 20:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20060129134056.GA3428@Muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> Both -n<n> and -n <n> are supported. POSIX versions of head(1) and
> tail(1) allow their line limits to be parsed this way. I find
> --max-count to be a commonly used option, and also similar in spirit to
> head/tail, so I decided to make life easier on my worn out (and lazy :)
> fingers with this patch.
I agree with this in principle.
> diff --git a/rev-parse.c b/rev-parse.c
> index 7abad35..3790463 100644
> --- a/rev-parse.c
> +++ b/rev-parse.c
> @@ -21,6 +21,7 @@ static char *def = NULL;
> static int show_type = NORMAL;
> static int symbolic = 0;
> static int output_sq = 0;
> +static int next_arg_is_rev = 0;
Do you need this here, or can it be made auto in main()?
^ permalink raw reply
* Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)
From: Junio C Hamano @ 2006-01-29 20:15 UTC (permalink / raw)
To: Fredrik Kuivinen
Cc: Linus Torvalds, Martin Langhoff, Git Mailing List, keithp
In-Reply-To: <20060129101225.GA4815@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> Would it make sense to add an optional
>
> mergeresult <tree>
>
> line to merge commit objects?
Two issues and a half.
(1) Not all conflicting merge cases can write a sensible
"conflicted intermediate auto-merge result". Look for cases
where we punt in git-merge-one-file.
(2) Modulo issue (1), it can be re-computed if and when needed,
so this is akin to "storing rename information in the commit
by detecting renames while merging".
(3) Depending on the direction you pull, you would have
logically the same "conflicted auto-merge result" that has
<<< === >>> delimited hunks in reverse. Which one should
you record?
And annotate would not be helped much -- if it is needed you
could recompute it at that point. Annotate needs to look at the
diff from each parent _anyway_ to assign blames.
By the way, I brought up the issue (3) because it relates to how
my latest toy "git rerere" works ;-).
^ permalink raw reply
* Re: Possible git-rev-list bug
From: Junio C Hamano @ 2006-01-29 20:15 UTC (permalink / raw)
To: Marco Costalba; +Cc: junkio, git
In-Reply-To: <43DC8DDF.6080904@yahoo.it>
Marco Costalba <mcostalba@yahoo.it> writes:
> $ git-rev-list --max-count=1 --parents addafaf92eeb86033da91323d0d3ad7a496dae83 -- rev-list.c
> addafaf92eeb86033da91323d0d3ad7a496dae83
> d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b
> 93b74bca86f59b8df410b6fd4803b88ee0f304bf
> d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b
> d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b
> 3815f423ae39bf774de3c268c6d3e3b72128a4e5
>
> We have the same parent (d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b) multiple times.
I think it probably is a bug. The commit really has five
parents that bundle five independent tracks of development. Two
of them touch the specified path since they forked. The rest do
not, and for them, the last commit that touched the specified
path is behind where they forked:
.---o---.
/ \
.---*---o---.
/ 93b74bc \
---*---o---o-----o---o------o addafaf
d8f6b34 \ /
.---o---o---.
\ /
.---*---.
3815f42
The "rev-list.c" path limiter is meant to omit "uninteresting"
commit, so in this case showing only the three parents after
filtering dups would be the right thing to do, I think.
Let me wait for a while to hear Linus contradicts me, though...
^ permalink raw reply
* Re: [Census] So who uses git?
From: Daniel Barkalow @ 2006-01-29 20:17 UTC (permalink / raw)
To: Dave Jones
Cc: Junio C Hamano, Keith Packard, Martin Langhoff, Linus Torvalds,
Git Mailing List
In-Reply-To: <20060129183731.GE19685@redhat.com>
On Sun, 29 Jan 2006, Dave Jones wrote:
> On Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:
> > Can I hear experiences from other big projects that tried to use
> > git [*1*]? I suspect there are many that have tried, and I
> > would not be surprised at all if git did not work out well for
> > them. For projects that already run on a (free) SCM, I would be
> > very surprised if the developers find the current git 10 times
> > better than the SCM they have been using (probably with an
> > exception of CVS), unless they have very specific need, such as
> > parallel development of distributed nature like the Linux
> > kernel.
>
> I've found switching from cvs->git even for small projects has
> made me more productive. In part because it's got me away from
> the 'check in to a centralised server like sourceforge' mentality,
> without the need to set up a local cvs server of my own.
> Adding changesets to a small project like x86info, now takes
> seconds, whereas it used to take minutes of thumb-twiddling whilst
> I waited for sf.net to do its thing. The ability to check in
> changesets locally whilst I'm travelling, and then push them when
> I have network connectivity again is also a massive productivity
> win over cvs.
>
> There's also another git usage that I doubt I'm alone in doing.
> I regularly use git to import cvs trees from sourceforge etc for
> random projects, because I now find browsing history of projects
> with tools like gitk much nicer than any cvs tool I've used.
> (cvs annotate is the only thing I really miss).
I think this is the real driving factor for git adoption: it doesn't have
to be 10x better for people to use it, because individuals can use it for
interacting with CVS projects without causing anybody else any pain. It
doesn't just enable distributed development, it enables a distributed
choice of SCM, which means a much lower activation energy threshold. I
think we'll see a lot more adoption when we have a CVS daemon interface
(so projects can stop having a CVS repository, and support both sorts of
users with a git repository and have better metadata), and also if someone
sets up a place for putting git imports of CVS projects, so people will
know that other people are using git.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [Census] So who uses git?
From: Junio C Hamano @ 2006-01-29 20:15 UTC (permalink / raw)
To: Morten Welinder; +Cc: git
In-Reply-To: <118833cc0601290619k1e9c6bb8gc63937f1a2d2b31e@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
> If I understand this right, that means that for a log file (in this
> case a ChangeLog file) that is appended to linearly as a
> function of revision number, we have...
>
> cvs: O(n) archive size
> git: O(n*n) archive size
>
> At least that is what we get if revision N is always deltad over
> revision N-1. A good deal could be saved if instead of dumping
> a full copy every 10 revisions, that revision would instead be
> deltad off an earlier revision, but I think it'll still be O(n*n).
I have not counted O()rders, but it is not as simple as that,
because we do not really compare "versions". If version N
reverts a change version N-1 introduced since version N-2, we
would not even store a copy for version N and version N-2
separately. We just store a single copy, which may be delta
information against version N-1 (or the other way around and N-1
might be delta against N).
For the sake of math, let's say this project keeps only one
file, append only ChangeLog, with a straight line of development
without branches ("single strand of pearls"), and has revisions
1..N.
In RCS, you would have a full copy of the revision N, and
revision J is recorded as delta from revision J+1 for 1 <= J < N.
This delta is similar to "ed" script, and going backwards in the
history for the ChangeLog example means only line deletion is
involved, so what was removed is not recorded. It records how
many lines are removed from where. This is _very_ efficient and
compact.
In git, we would have a full copy of version N (because we favor
keeping larger blob associated with newer commits as a full
copy), and essentially the same thing as RCS happens. The only
difference is that our "delta" is binary delta, but in this
case, it just records "copy N bytes from here to here" which
results in about the same amount of information to represent
each delta. As you say, if (10 < N), we would have a full copy
every once in a while. You could use depth other than the
default to make this chaining longer and if you did so, your
repository would be *very* compactly compressed.
However, retrieving cost of version 1 is quite different. RCS
format is O(n) -- you start from the tip, extract and interpret
(N-1) deltas and apply them in turn to get to what you want.
The cost of extracting an arbitrary version is bounded in git
packfile, because you need to do such an "extract, interpret and
apply" at most $depth cycles. This is primarily because we do
not store "versions" but individual objects, and do not apply
"newer revisions are far more likely to be accessed often"
heuristics, which RCS format is designed for.
^ permalink raw reply
* Re: [PATCH] diff: add --no-diff-deleted to make -p more pleasant
From: Junio C Hamano @ 2006-01-29 20:12 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060129142403.GA15482@Muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> This is a feature I've stol^Wborrowed from svn that I find very
> useful since I usually don't care to see what I've deleted.
There is a thing called --diff-filter, and
git diff -p --no-diff-deleted
is equivalent to
git diff -p --diff-filter=AM
when you are not using rename/copy detection (and a byte
shorter). Or maybe improve its syntax to also take:
--diff-filter=-D
That is, a minus followed by list of undesired change class
letters.
^ permalink raw reply
* [PATCH 3/3] Use struct tree in diff-tree
From: Daniel Barkalow @ 2006-01-29 19:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0601291336420.25300@iabervon.org>
It had been open-coding a tree parser. This updates the programs that
call diff_tree() to send it the struct tree instead of a buffer and
size.
Signed-off-by: Daniel Barkalow
---
diff-tree.c | 13 ++----
diff.h | 9 +---
rev-list.c | 13 ------
tree-diff.c | 123 ++++++++++++++++++++++++++---------------------------------
4 files changed, 63 insertions(+), 95 deletions(-)
1530551cfd7dbecfe3258cab09b01f10a9b8549d
diff --git a/diff-tree.c b/diff-tree.c
index 6593a69..d64cba0 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -49,18 +49,13 @@ static int diff_tree_sha1_top(const unsi
static int diff_root_tree(const unsigned char *new, const char *base)
{
int retval;
- void *tree;
- struct tree_desc empty, real;
+ struct tree *real;
- tree = read_object_with_reference(new, "tree", &real.size, NULL);
- if (!tree)
+ real = parse_tree_indirect(new);
+ if (!real)
die("unable to read root tree (%s)", sha1_to_hex(new));
- real.buf = tree;
- empty.buf = "";
- empty.size = 0;
- retval = diff_tree(&empty, &real, base, &diff_options);
- free(tree);
+ retval = diff_tree(NULL, real, base, &diff_options);
call_diff_flush();
return retval;
}
diff --git a/diff.h b/diff.h
index 9a0169c..9142c04 100644
--- a/diff.h
+++ b/diff.h
@@ -4,15 +4,12 @@
#ifndef DIFF_H
#define DIFF_H
+#include "tree.h"
+
#define DIFF_FILE_CANON_MODE(mode) \
(S_ISREG(mode) ? (S_IFREG | ce_permissions(mode)) : \
S_ISLNK(mode) ? S_IFLNK : S_IFDIR)
-struct tree_desc {
- void *buf;
- unsigned long size;
-};
-
struct diff_options;
typedef void (*change_fn_t)(struct diff_options *options,
@@ -51,7 +48,7 @@ struct diff_options {
};
extern void diff_tree_setup_paths(const char **paths);
-extern int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
+extern int diff_tree(struct tree *t1, struct tree *t2,
const char *base, struct diff_options *opt);
extern int diff_tree_sha1(const unsigned char *old, const unsigned char *new,
const char *base, struct diff_options *opt);
diff --git a/rev-list.c b/rev-list.c
index 0b142c1..86da74a 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -485,23 +485,12 @@ static int compare_tree(struct tree *t1,
static int same_tree_as_empty(struct tree *t1)
{
int retval;
- void *tree;
- struct tree_desc empty, real;
if (!t1)
return 0;
- tree = read_object_with_reference(t1->object.sha1, "tree", &real.size, NULL);
- if (!tree)
- return 0;
- real.buf = tree;
-
- empty.buf = "";
- empty.size = 0;
-
tree_difference = 0;
- retval = diff_tree(&empty, &real, "", &diff_opt);
- free(tree);
+ retval = diff_tree(NULL, t1, "", &diff_opt);
return retval >= 0 && !tree_difference;
}
diff --git a/tree-diff.c b/tree-diff.c
index 382092b..c3526d1 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -3,38 +3,18 @@
*/
#include "cache.h"
#include "diff.h"
+#include "tree.h"
// What paths are we interested in?
static int nr_paths = 0;
static const char **paths = NULL;
static int *pathlens = NULL;
-static void update_tree_entry(struct tree_desc *desc)
+static const unsigned char *extract(struct tree_entry_list *desc, const char **pathp, unsigned int *modep)
{
- void *buf = desc->buf;
- unsigned long size = desc->size;
- int len = strlen(buf) + 1 + 20;
-
- if (size < len)
- die("corrupt tree file");
- desc->buf = buf + len;
- desc->size = size - len;
-}
-
-static const unsigned char *extract(struct tree_desc *desc, const char **pathp, unsigned int *modep)
-{
- void *tree = desc->buf;
- unsigned long size = desc->size;
- int len = strlen(tree)+1;
- const unsigned char *sha1 = tree + len;
- const char *path = strchr(tree, ' ');
- unsigned int mode;
-
- if (!path || size < len + 20 || sscanf(tree, "%o", &mode) != 1)
- die("corrupt tree file");
- *pathp = path+1;
- *modep = DIFF_FILE_CANON_MODE(mode);
- return sha1;
+ *pathp = desc->name;
+ *modep = DIFF_FILE_CANON_MODE(desc->mode);
+ return desc->item.any->sha1;
}
static char *malloc_base(const char *base, const char *path, int pathlen)
@@ -47,9 +27,11 @@ static char *malloc_base(const char *bas
return newbase;
}
-static int show_entry(struct diff_options *opt, const char *prefix, struct tree_desc *desc, const char *base);
+static int show_entry(struct diff_options *opt, const char *prefix, struct tree_entry_list *desc, const char *base);
-static int compare_tree_entry(struct tree_desc *t1, struct tree_desc *t2, const char *base, struct diff_options *opt)
+static int compare_tree_entry(struct tree_entry_list *t1,
+ struct tree_entry_list *t2,
+ const char *base, struct diff_options *opt)
{
unsigned mode1, mode2;
const char *path1, *path2;
@@ -99,7 +81,7 @@ static int compare_tree_entry(struct tre
return 0;
}
-static int interesting(struct tree_desc *desc, const char *base)
+static int interesting(struct tree_entry_list *desc, const char *base)
{
const char *path;
unsigned mode;
@@ -153,36 +135,36 @@ static int interesting(struct tree_desc
}
/* A whole sub-tree went away or appeared */
-static void show_tree(struct diff_options *opt, const char *prefix, struct tree_desc *desc, const char *base)
+static void show_tree(struct diff_options *opt, const char *prefix,
+ struct tree *desc, const char *base)
{
- while (desc->size) {
- if (interesting(desc, base))
- show_entry(opt, prefix, desc, base);
- update_tree_entry(desc);
+ struct tree_entry_list *list;
+ parse_tree(desc);
+ list = desc->entries;
+ while (list) {
+ if (interesting(list, base))
+ show_entry(opt, prefix, list, base);
+ list = list->next;
}
}
/* A file entry went away or appeared */
-static int show_entry(struct diff_options *opt, const char *prefix, struct tree_desc *desc, const char *base)
+static int show_entry(struct diff_options *opt, const char *prefix,
+ struct tree_entry_list *desc, const char *base)
{
unsigned mode;
const char *path;
const unsigned char *sha1 = extract(desc, &path, &mode);
- if (opt->recursive && S_ISDIR(mode)) {
- char type[20];
+ if (opt->recursive && desc->directory) {
char *newbase = malloc_base(base, path, strlen(path));
- struct tree_desc inner;
- void *tree;
+ struct tree *tree;
- tree = read_sha1_file(sha1, type, &inner.size);
- if (!tree || strcmp(type, "tree"))
- die("corrupt tree sha %s", sha1_to_hex(sha1));
+ tree = desc->item.tree;
- inner.buf = tree;
- show_tree(opt, prefix, &inner, newbase);
+ parse_tree(tree);
+ show_tree(opt, prefix, tree, newbase);
- free(tree);
free(newbase);
return 0;
}
@@ -191,36 +173,46 @@ static int show_entry(struct diff_option
return 0;
}
-int diff_tree(struct tree_desc *t1, struct tree_desc *t2, const char *base, struct diff_options *opt)
+int diff_tree(struct tree *tree1, struct tree *tree2, const char *base,
+ struct diff_options *opt)
{
- while (t1->size | t2->size) {
- if (nr_paths && t1->size && !interesting(t1, base)) {
- update_tree_entry(t1);
+ struct tree_entry_list *t1 = NULL, *t2 = NULL;
+ if (tree1) {
+ parse_tree(tree1);
+ t1 = tree1->entries;
+ }
+ if (tree2) {
+ parse_tree(tree2);
+ t2 = tree2->entries;
+ }
+ while (t1 || t2) {
+ if (nr_paths && t1 && !interesting(t1, base)) {
+ t1 = t1->next;
continue;
}
- if (nr_paths && t2->size && !interesting(t2, base)) {
- update_tree_entry(t2);
+ if (nr_paths && t2 && !interesting(t2, base)) {
+ t2 = t2->next;
continue;
}
- if (!t1->size) {
+ if (!t1) {
show_entry(opt, "+", t2, base);
- update_tree_entry(t2);
+ t2 = t2->next;
continue;
}
- if (!t2->size) {
+ if (!t2) {
show_entry(opt, "-", t1, base);
- update_tree_entry(t1);
+ t1 = t1->next;
continue;
}
switch (compare_tree_entry(t1, t2, base, opt)) {
case -1:
- update_tree_entry(t1);
+ t1 = t1->next;
continue;
case 0:
- update_tree_entry(t1);
+ t1 = t1->next;
/* Fallthrough */
case 1:
- update_tree_entry(t2);
+ t2 = t2->next;
continue;
}
die("git-diff-tree: internal error");
@@ -230,21 +222,16 @@ int diff_tree(struct tree_desc *t1, stru
int diff_tree_sha1(const unsigned char *old, const unsigned char *new, const char *base, struct diff_options *opt)
{
- void *tree1, *tree2;
- struct tree_desc t1, t2;
+ struct tree *t1, *t2;
int retval;
- tree1 = read_object_with_reference(old, "tree", &t1.size, NULL);
- if (!tree1)
+ t1 = parse_tree_indirect(old);
+ if (!t1)
die("unable to read source tree (%s)", sha1_to_hex(old));
- tree2 = read_object_with_reference(new, "tree", &t2.size, NULL);
- if (!tree2)
+ t2 = parse_tree_indirect(new);
+ if (!t2)
die("unable to read destination tree (%s)", sha1_to_hex(new));
- t1.buf = tree1;
- t2.buf = tree2;
- retval = diff_tree(&t1, &t2, base, opt);
- free(tree1);
- free(tree2);
+ retval = diff_tree(t1, t2, base, opt);
return retval;
}
--
1.0.GIT
^ permalink raw reply related
* [PATCH 2/3] Use struct commit in tar-tree
From: Daniel Barkalow @ 2006-01-29 19:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0601291336420.25300@iabervon.org>
It was open-coding getting the commit date from a commit.
Signed-off-by: Daniel Barkalow <barkalow@iabervon>
---
tar-tree.c | 41 ++++++-----------------------------------
1 files changed, 6 insertions(+), 35 deletions(-)
ca523a725295fff6f1456cd7207f6b24f8c2e843
diff --git a/tar-tree.c b/tar-tree.c
index 6219754..d36baed 100644
--- a/tar-tree.c
+++ b/tar-tree.c
@@ -4,6 +4,7 @@
#include <time.h>
#include "cache.h"
#include "tree.h"
+#include "commit.h"
#define RECORDSIZE (512)
#define BLOCKSIZE (RECORDSIZE * 20)
@@ -369,39 +370,10 @@ static void traverse_tree(struct tree *t
}
}
-/* get commit time from committer line of commit object */
-static time_t commit_time(void * buffer, unsigned long size)
-{
- time_t result = 0;
- char *p = buffer;
-
- while (size > 0) {
- char *endp = memchr(p, '\n', size);
- if (!endp || endp == p)
- break;
- *endp = '\0';
- if (endp - p > 10 && !memcmp(p, "committer ", 10)) {
- char *nump = strrchr(p, '>');
- if (!nump)
- break;
- nump++;
- result = strtoul(nump, &endp, 10);
- if (*endp != ' ')
- result = 0;
- break;
- }
- size -= endp - p - 1;
- p = endp + 1;
- }
- return result;
-}
-
int main(int argc, char **argv)
{
unsigned char sha1[20];
- unsigned char commit_sha1[20];
- void *buffer;
- unsigned long size;
+ struct commit *commit;
struct tree *tree;
setup_git_directory();
@@ -418,11 +390,10 @@ int main(int argc, char **argv)
usage(tar_tree_usage);
}
- buffer = read_object_with_reference(sha1, "commit", &size, commit_sha1);
- if (buffer) {
- write_global_extended_header(commit_sha1);
- archive_time = commit_time(buffer, size);
- free(buffer);
+ commit = lookup_commit_reference(sha1);
+ if (commit) {
+ write_global_extended_header(commit->object.sha1);
+ archive_time = commit->date;
}
tree = parse_tree_indirect(sha1);
if (!tree)
--
1.0.GIT
^ permalink raw reply related
* [PATCH 1/3] Use struct tree in tar-tree
From: Daniel Barkalow @ 2006-01-29 19:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0601291336420.25300@iabervon.org>
It was using an open-coded tree parser; use a struct tree instead.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
tar-tree.c | 48 +++++++++++++++++++++++-------------------------
1 files changed, 23 insertions(+), 25 deletions(-)
d2a4152dfd1b79f32a28ca4b2deb202a4e928441
diff --git a/tar-tree.c b/tar-tree.c
index f749d4b..6219754 100644
--- a/tar-tree.c
+++ b/tar-tree.c
@@ -3,6 +3,7 @@
*/
#include <time.h>
#include "cache.h"
+#include "tree.h"
#define RECORDSIZE (512)
#define BLOCKSIZE (RECORDSIZE * 20)
@@ -334,40 +335,37 @@ static void write_header(const unsigned
write_if_needed();
}
-static void traverse_tree(void *buffer, unsigned long size,
+static void traverse_tree(struct tree *tree,
struct path_prefix *prefix)
{
struct path_prefix this_prefix;
+ struct tree_entry_list *item;
this_prefix.prev = prefix;
- while (size) {
- int namelen = strlen(buffer)+1;
+ parse_tree(tree);
+ item = tree->entries;
+
+ while (item) {
void *eltbuf;
char elttype[20];
unsigned long eltsize;
- unsigned char *sha1 = buffer + namelen;
- char *path = strchr(buffer, ' ') + 1;
- unsigned int mode;
-
- if (size < namelen + 20 || sscanf(buffer, "%o", &mode) != 1)
- die("corrupt 'tree' file");
- if (S_ISDIR(mode) || S_ISREG(mode))
- mode |= (mode & 0100) ? 0777 : 0666;
- buffer = sha1 + 20;
- size -= namelen + 20;
- eltbuf = read_sha1_file(sha1, elttype, &eltsize);
+ eltbuf = read_sha1_file(item->item.any->sha1,
+ elttype, &eltsize);
if (!eltbuf)
- die("cannot read %s", sha1_to_hex(sha1));
- write_header(sha1, TYPEFLAG_AUTO, basedir, prefix, path,
- mode, eltbuf, eltsize);
- if (!strcmp(elttype, "tree")) {
- this_prefix.name = path;
- traverse_tree(eltbuf, eltsize, &this_prefix);
- } else if (!strcmp(elttype, "blob") && !S_ISLNK(mode)) {
+ die("cannot read %s",
+ sha1_to_hex(item->item.any->sha1));
+ write_header(item->item.any->sha1, TYPEFLAG_AUTO, basedir,
+ prefix, item->name,
+ item->mode, eltbuf, eltsize);
+ if (item->directory) {
+ this_prefix.name = item->name;
+ traverse_tree(item->item.tree, &this_prefix);
+ } else if (!item->symlink) {
write_blocked(eltbuf, eltsize);
}
free(eltbuf);
+ item = item->next;
}
}
@@ -404,6 +402,7 @@ int main(int argc, char **argv)
unsigned char commit_sha1[20];
void *buffer;
unsigned long size;
+ struct tree *tree;
setup_git_directory();
@@ -425,8 +424,8 @@ int main(int argc, char **argv)
archive_time = commit_time(buffer, size);
free(buffer);
}
- buffer = read_object_with_reference(sha1, "tree", &size, NULL);
- if (!buffer)
+ tree = parse_tree_indirect(sha1);
+ if (!tree)
die("not a reference to a tag, commit or tree object: %s",
sha1_to_hex(sha1));
if (!archive_time)
@@ -434,8 +433,7 @@ int main(int argc, char **argv)
if (basedir)
write_header((unsigned char *)"0", TYPEFLAG_DIR, NULL, NULL,
basedir, 040777, NULL, 0);
- traverse_tree(buffer, size, NULL);
- free(buffer);
+ traverse_tree(tree, NULL);
write_trailer();
return 0;
}
--
1.0.GIT
^ permalink raw reply related
* [PATCH 0/3] Remove more parsers
From: Daniel Barkalow @ 2006-01-29 19:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
I found some more open-coded tree parsers and a commit parser. These
changes shouldn't affect behavior meaningfully, and all of the tests pass.
I did notice, however, that the rev-list functionality of pruning by path
isn't actually tested in the tests; I forgot to update it and it didn't
cause any tests to fail. I also couldn't figure out if
"same_tree_as_empty" has important side effects, so I updated its use of
diff_tree; in order to do what the name says, "return t1 && !t1->entries"
would suffice.
There's also a parser in convert-objects, but it may be best to keep it,
since it may want to deal with things which are now considered invalid,
and would be rejected by the normal parser.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [Census] So who uses git?
From: Dave Jones @ 2006-01-29 18:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Keith Packard, Martin Langhoff, Linus Torvalds, Git Mailing List
In-Reply-To: <7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net>
On Sat, Jan 28, 2006 at 01:08:54PM -0800, Junio C Hamano wrote:
> Can I hear experiences from other big projects that tried to use
> git [*1*]? I suspect there are many that have tried, and I
> would not be surprised at all if git did not work out well for
> them. For projects that already run on a (free) SCM, I would be
> very surprised if the developers find the current git 10 times
> better than the SCM they have been using (probably with an
> exception of CVS), unless they have very specific need, such as
> parallel development of distributed nature like the Linux
> kernel.
I've found switching from cvs->git even for small projects has
made me more productive. In part because it's got me away from
the 'check in to a centralised server like sourceforge' mentality,
without the need to set up a local cvs server of my own.
Adding changesets to a small project like x86info, now takes
seconds, whereas it used to take minutes of thumb-twiddling whilst
I waited for sf.net to do its thing. The ability to check in
changesets locally whilst I'm travelling, and then push them when
I have network connectivity again is also a massive productivity
win over cvs.
There's also another git usage that I doubt I'm alone in doing.
I regularly use git to import cvs trees from sourceforge etc for
random projects, because I now find browsing history of projects
with tools like gitk much nicer than any cvs tool I've used.
(cvs annotate is the only thing I really miss).
What would be really cool, would be a web page pointing to public
conversions of various projects cvs trees, so that everyone doesn't
have to keep hammering various repos to do the conversions themselves.
(Sort of a pseudo bkbits.net).
Dave
^ permalink raw reply
* Re: git commit error on initial (the very first) commit
From: J. Bruce Fields @ 2006-01-29 18:16 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: git
In-Reply-To: <200601292026.54893.arvidjaar@mail.ru>
On Sun, Jan 29, 2006 at 08:26:54PM +0300, Andrey Borzenkov wrote:
> May be I do something wrong? What is correct procedure to initially import
> tree? git 1.1.4
>
> {pts/0}% git init-db
> defaulting to local storage area
> {pts/0}% git add .
> {pts/0}% git commit -m 'initial import'
It needs to know which paths to update. Probably you want to include
all the files you added with the "git add", and you can do that just
with -a:
git commit -a -m "initial import"
should do the job. The default commit command for me is usually just
git commit -a.
--b.
^ permalink raw reply
* [PATCH 2/2] Add an option to "stg branch" to convert the internal format
From: Chuck Lever @ 2006-01-29 18:14 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <20060129181004.1919.92166.stgit@dexter.citi.umich.edu>
Previous patch adds support for a separate patch directory in each branch.
Let's give users an option to convert their old branches to new style ones
and back.
Signed-off-by: Chuck Lever <cel@netapp.com>
---
stgit/commands/branch.py | 11 +++++++++++
stgit/stack.py | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/branch.py b/stgit/commands/branch.py
index 6a551e4..ef44349 100644
--- a/stgit/commands/branch.py
+++ b/stgit/commands/branch.py
@@ -45,6 +45,9 @@ options = [make_option('-c', '--create',
make_option('--clone',
help = 'clone the contents of the current branch',
action = 'store_true'),
+ make_option('--convert',
+ help = 'switch between old and new format branches',
+ action = 'store_true'),
make_option('--delete',
help = 'delete an existing development branch',
action = 'store_true'),
@@ -150,6 +153,14 @@ def func(parser, options, args):
return
+ elif options.convert:
+
+ if len(args) != 0:
+ parser.error('incorrect number of arguments')
+
+ crt_series.convert()
+ return
+
elif options.delete:
if len(args) != 1:
diff --git a/stgit/stack.py b/stgit/stack.py
index 89a2413..145f93c 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -410,6 +410,42 @@ class Series:
os.makedirs(os.path.join(self.__series_dir, 'patches'))
self.__begin_stack_check()
+ def convert(self):
+ """Either convert to use a separate patch directory, or
+ unconvert to place the patches in the same directory with
+ series control files
+ """
+ if self.__patch_dir == self.__series_dir:
+ print 'Converting old-style to new-style... ',
+ sys.stdout.flush()
+
+ self.__patch_dir = os.path.join(self.__series_dir, 'patches')
+ os.makedirs(self.__patch_dir)
+
+ for p in self.get_applied() + self.get_unapplied():
+ src = os.path.join(self.__series_dir, p)
+ dest = os.path.join(self.__patch_dir, p)
+ os.rename(src, dest)
+
+ print 'done'
+
+ else:
+ print 'Converting new-style to old-style... ',
+ sys.stdout.flush()
+
+ for p in self.get_applied() + self.get_unapplied():
+ src = os.path.join(self.__patch_dir, p)
+ dest = os.path.join(self.__series_dir, p)
+ os.rename(src, dest)
+
+ if not os.listdir(self.__patch_dir):
+ os.rmdir(self.__patch_dir)
+ print 'done'
+ else:
+ print 'Patch directory %s is not empty.' % self.__name
+
+ self.__patch_dir = self.__series_dir
+
def rename(self, to_name):
"""Renames a series
"""
^ permalink raw reply related
* [PATCH 0/2] allow patches called "applied", "current", and so on
From: Chuck Lever @ 2006-01-29 18:10 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
The following patches create a separate directory for patches so that patch
names like "applied" don't collide with the patch series control files.
A new option on the "stg branch" command allows users to convert between the
old-style (all in the same series directory) and the new-style (patches in a
separate directory). "stg" should be good at detecting which type of
repository is in use and adapting to it, so this change should be entirely
invisible on legacy repositories.
-- Chuck Lever
--
corporate: <cel at netapp dot com>
personal: <chucklever at bigfoot dot com>
^ permalink raw reply
* [PATCH 1/2] Use a separate directory for patches under each branch subdir
From: Chuck Lever @ 2006-01-29 18:13 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <20060129181004.1919.92166.stgit@dexter.citi.umich.edu>
Currently you can't specify a patch name that matches the name of one of
the stgit special files under .git/patches/<branch-name>. Let's use a
new subdirectory under .git/patches/<branch-name> to contain just the
patch directories to remove this limitation.
Signed-off-by: Chuck Lever <cel@netapp.com>
---
stgit/stack.py | 41 ++++++++++++++++++++++++++---------------
1 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index b081c95..89a2413 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -122,10 +122,10 @@ def edit_file(series, line, comment, sho
class Patch:
"""Basic patch implementation
"""
- def __init__(self, name, patch_dir):
- self.__patch_dir = patch_dir
+ def __init__(self, name, series_dir):
+ self.__series_dir = series_dir
self.__name = name
- self.__dir = os.path.join(self.__patch_dir, self.__name)
+ self.__dir = os.path.join(self.__series_dir, self.__name)
def create(self):
os.mkdir(self.__dir)
@@ -143,7 +143,7 @@ class Patch:
def rename(self, newname):
olddir = self.__dir
self.__name = newname
- self.__dir = os.path.join(self.__patch_dir, self.__name)
+ self.__dir = os.path.join(self.__series_dir, self.__name)
os.rename(olddir, self.__dir)
@@ -266,14 +266,20 @@ class Series:
except git.GitException, ex:
raise StackException, 'GIT tree not initialised: %s' % ex
- self.__patch_dir = os.path.join(base_dir, 'patches',
- self.__name)
+ self.__series_dir = os.path.join(base_dir, 'patches',
+ self.__name)
self.__base_file = os.path.join(base_dir, 'refs', 'bases',
self.__name)
- self.__applied_file = os.path.join(self.__patch_dir, 'applied')
- self.__unapplied_file = os.path.join(self.__patch_dir, 'unapplied')
- self.__current_file = os.path.join(self.__patch_dir, 'current')
- self.__descr_file = os.path.join(self.__patch_dir, 'description')
+
+ self.__applied_file = os.path.join(self.__series_dir, 'applied')
+ self.__unapplied_file = os.path.join(self.__series_dir, 'unapplied')
+ self.__current_file = os.path.join(self.__series_dir, 'current')
+ self.__descr_file = os.path.join(self.__series_dir, 'description')
+
+ # where this series keeps its patches
+ self.__patch_dir = os.path.join(self.__series_dir, 'patches')
+ if not os.path.isdir(self.__patch_dir):
+ self.__patch_dir = self.__series_dir
def get_branch(self):
"""Return the branch name for the Series object
@@ -325,15 +331,15 @@ class Series:
return self.__base_file
def get_protected(self):
- return os.path.isfile(os.path.join(self.__patch_dir, 'protected'))
+ return os.path.isfile(os.path.join(self.__series_dir, 'protected'))
def protect(self):
- protect_file = os.path.join(self.__patch_dir, 'protected')
+ protect_file = os.path.join(self.__series_dir, 'protected')
if not os.path.isfile(protect_file):
create_empty_file(protect_file)
def unprotect(self):
- protect_file = os.path.join(self.__patch_dir, 'protected')
+ protect_file = os.path.join(self.__series_dir, 'protected')
if os.path.isfile(protect_file):
os.remove(protect_file)
@@ -401,6 +407,7 @@ class Series:
create_empty_file(self.__applied_file)
create_empty_file(self.__unapplied_file)
create_empty_file(self.__descr_file)
+ os.makedirs(os.path.join(self.__series_dir, 'patches'))
self.__begin_stack_check()
def rename(self, to_name):
@@ -415,8 +422,8 @@ class Series:
git.rename_branch(self.__name, to_name)
- if os.path.isdir(self.__patch_dir):
- os.rename(self.__patch_dir, to_stack.__patch_dir)
+ if os.path.isdir(self.__series_dir):
+ os.rename(self.__series_dir, to_stack.__series_dir)
if os.path.exists(self.__base_file):
os.rename(self.__base_file, to_stack.__base_file)
@@ -471,6 +478,10 @@ class Series:
if not os.listdir(self.__patch_dir):
os.rmdir(self.__patch_dir)
else:
+ print 'Patch directory %s is not empty.' % self.__name
+ if not os.listdir(self.__series_dir):
+ os.rmdir(self.__series_dir)
+ else:
print 'Series directory %s is not empty.' % self.__name
if os.path.exists(self.__base_file):
^ permalink raw reply related
* Re: [Census] So who uses git?
From: Greg KH @ 2006-01-29 18:12 UTC (permalink / raw)
To: Radoslaw Szkodzinski
Cc: Keith Packard, Junio C Hamano, cworth, Martin Langhoff,
Linus Torvalds, Git Mailing List
In-Reply-To: <43DCA495.9040301@gorzow.mm.pl>
On Sun, Jan 29, 2006 at 12:18:45PM +0100, Radoslaw Szkodzinski wrote:
>
> The only drawback is local cloning. This operation is like 4x slower
> than plain copying of the repository. Probably because it works like an
> ssh clone - creates a pack, copies it, then unpacks. This is just
> inefficient on a local machine.
Have you tried the "-l" option for cloneing locally? It's _very_ fast,
even for my tiny little old laptop.
If you add a "-n" that will not checkout the source tree, so you can
compare the time of cloning with the checkout portion.
thanks,
greg k-h
^ 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