* [PATCH] Extend testing git-mv for renaming of subdirectories
From: Josef Weidendorfer @ 2006-07-26 13:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607260348130.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
On Wednesday 26 July 2006 03:52, Johannes Schindelin wrote:
> There is no test for it, and I am quite certain the old script
> doesn't do it either: git-mv some_tracked_dir/ there/ will
> not work. t7001-mv passes, though.
Hmm... Renaming full subtrees worked since the old git-rename days.
I just checked it, and it works fine.
My bad, that there was no test for this, so what about this?
Josef
t/t7001-mv.sh | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 811a479..9270a41 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -38,4 +38,28 @@ test_expect_success \
'git-diff-tree -r -M --name-status HEAD^ HEAD | \
grep -E "^R100.+path1/COPYING.+path0/COPYING"'
+test_expect_success \
+ 'adding another file' \
+ 'cp ../../README path0/README &&
+ git-add path0/README &&
+ git-commit -m add2 -a'
+
+test_expect_success \
+ 'moving whole subdirectory' \
+ 'git-mv path0 path2'
+
+test_expect_success \
+ 'commiting the change' \
+ 'git-commit -m dir-move -a'
+
+test_expect_success \
+ 'checking the commit' \
+ 'git-diff-tree -r -M --name-status HEAD^ HEAD | \
+ grep -E "^R100.+path0/COPYING.+path2/COPYING" &&
+ git-diff-tree -r -M --name-status HEAD^ HEAD | \
+ grep -E "^R100.+path0/README.+path2/README"'
+
test_done
+
--
1.4.2.rc1.g791e
^ permalink raw reply related
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Jakub Narebski @ 2006-07-26 13:35 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0607260416070.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Seriously, I still believe that proof-of-concepts in Bash or Perl or even
> Python are fine. But they are not for real work, so one of my long-term
> goals for git is to get rid of them.
I don't think that we would want to rewrite gitweb in C, for example.
And Perl for porcelanish commands is all right, IMVVHO.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Make git-mv a builtin
From: Johannes Schindelin @ 2006-07-26 10:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk660udcn.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 25 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This also moves add_file_to_index() to read-cache.c. Oh, and while
> > touching builtin-add.c, it also removes a duplicate git_config() call.
>
> I'd have preferred to see this not depend on uncooked
> merge-recur infrastructure, since it is very likely that this
> would be ready to graduate to "master" before merge-recur.
I use "next" to base all my work (git or otherwise) on, and forgot that
path-list did not yet make it into "master". Sorry.
> I've branched from "master" and placed the path-list stuff which
> was split out of the merge-recur WIP, and applied this patch
> with some trivial adjustment, and will place it on "pu", so I'd
> appreciate if you can double check the result.
Looks good from what I see. BTW do you have any indent command line you
prefer? I see that all changes but in the usage string (which was my
fault: thank you), and in Makefile (putting path-list into libgit.a rather
than linking it specifically), are white space changes.
> > diff --git a/builtin.h b/builtin.h
> > index 5339d86..6f3a439 100755
>
> Huh -- 100755?
A mistake introduced on cygwin. Again, sorry.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git wrapper: add --git-path=<path> and --bare options
From: Junio C Hamano @ 2006-07-26 7:12 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: Johannes Schindelin, Linus Torvalds, git, junkio
In-Reply-To: <20060726061825.GA3638@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> Johannes Schindelin wrote:
>> > Since "--git-dir" makes more sense than "--git-path", I'd suggest just
>> > fixing the OPTIONS section ;)
>>
>> Will do. Thanks.
>
> When you're at it, you may want to change the Subject, too.
>
> Oh, you already sent out a new patch with the old Subject :-)
I've fixed things up to replace all --git-path with --git-dir, I
think.
^ permalink raw reply
* Re: [RFC/PATCH] git wrapper: add --git-path=<path> and --bare options
From: Uwe Zeisberger @ 2006-07-26 6:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git, junkio
In-Reply-To: <Pine.LNX.4.63.0607251952000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Johannes Schindelin wrote:
> > Since "--git-dir" makes more sense than "--git-path", I'd suggest just
> > fixing the OPTIONS section ;)
>
> Will do. Thanks.
When you're at it, you may want to change the Subject, too.
Oh, you already sent out a new patch with the old Subject :-)
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=sin%28pi%2F2%29
^ permalink raw reply
* Re: [PATCH] Make git-mv a builtin
From: Junio C Hamano @ 2006-07-26 5:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607260348130.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This also moves add_file_to_index() to read-cache.c. Oh, and while
> touching builtin-add.c, it also removes a duplicate git_config() call.
I'd have preferred to see this not depend on uncooked
merge-recur infrastructure, since it is very likely that this
would be ready to graduate to "master" before merge-recur.
I've branched from "master" and placed the path-list stuff which
was split out of the merge-recur WIP, and applied this patch
with some trivial adjustment, and will place it on "pu", so I'd
appreciate if you can double check the result.
> diff --git a/builtin.h b/builtin.h
> index 5339d86..6f3a439 100755
Huh -- 100755?
^ permalink raw reply
* Re: git-clone failures abound
From: Junio C Hamano @ 2006-07-26 5:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git, David S. Miller, Linus Torvalds
In-Reply-To: <44C6F1D6.5020208@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> I've been seeing several reports lately, from different users on
> various Linux platforms, with the same basic bug report
>
> * "git:// clone of linus's repo times out after 10 minutes"
>
> * someone says, "use rsync:// for the initial clone"
>
> * "it works, thanks!"
>
> People seems to note that this behavior only started recently. I
> wonder if linux-2.6.git crossed some sort of size threshold that's too
> much for kernel.org CPU load to bear? I wonder if git-clone is
> attempting to delta-ify, when it really should just be sending the
> objects in bulk?
No, this was all my fault, and sorry about the confusion.
GIT 1.4.1 contains commit 583b7ea3 which implemented a side-band
communication for the upload-pack protocol to give progress bar
output to the client downloaders, and in order to do so it
changed the pipe structure of the process. It used to just fork
two processes piped together that exec rev-list and
pack-objects, and exec cleared alarm(). I mistakenly rewrote
that part to have an extra process that oversees these two
processes but the overseer does not exec and got killed by
alarm(). This bug affects the server side.
GIT 1.4.1 was installed on public kernel.org machines and the
problem started happening after that.
A fix was relatively simple, and I've issued GIT 1.4.1.1 with it
last night -- the master branch also has the same fix. So when
the kernel.org public machines are updated to 1.4.1.1 it should
solve the problem.
^ permalink raw reply
* git-clone failures abound
From: Jeff Garzik @ 2006-07-26 4:38 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Linus Torvalds; +Cc: David S. Miller
I've been seeing several reports lately, from different users on various
Linux platforms, with the same basic bug report
* "git:// clone of linus's repo times out after 10 minutes"
* someone says, "use rsync:// for the initial clone"
* "it works, thanks!"
People seems to note that this behavior only started recently. I wonder
if linux-2.6.git crossed some sort of size threshold that's too much for
kernel.org CPU load to bear? I wonder if git-clone is attempting to
delta-ify, when it really should just be sending the objects in bulk?
Jeff
^ permalink raw reply
* Your money, ox warble
From: Sheena Kimball @ 2006-07-26 9:11 UTC (permalink / raw)
To: git-commits-head-owner
Genuine Swiss made Role8x repilcas are as close to the real thing
as a repilca watch can be. Sometimes even the professional jewelers
are unable to tell the difference from the real Role5x watch.
Why spend thousands of dollars on the real deal when
a repilca watch looks so much alike that only an expert could tell the difference...
And you only pay a fractoin of the price.
VISIT US, AND GET OUR SPECIL 370% DIS1COUNT OFER!
http://KVOTA2jp7eorpv727uk11h6jjz6jj1.viscidlyln.com/
==========
of the Flock?"
good long tug, and replaced the flask. I can't do it without that. I've been
profoundly serious work, since every bent line illuminates a straight one,
I started undressing slowly. I took off my watch, and saw that we had
were strong and calm. "We've come to take you higher, to take you home."
"Sam Douglas," he said dryly. "He died last year."
on the surface of the ocean. His wings were ragged bars of lead, but the
in the Plague Quarter and only on the antennas. And most important, it was
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Johannes Schindelin @ 2006-07-26 2:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060726021145.GW13776@pasky.or.cz>
Hi,
On Wed, 26 Jul 2006, Petr Baudis wrote:
> Dear diary, on Wed, Jul 26, 2006 at 04:03:32AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > On Wed, 26 Jul 2006, Johannes Schindelin wrote:
> >
> > > - private_Error.pm is not used. I had to rename it for Error.pm to be
> > > picked up.
> >
> > Never mind. After I finally got the GITPERLLIB thing right, it did pick
> > Error.pm up.
>
> cool. How did you tweak it?
I did not. You did. According to 5c4082fd687bd0784d3a4d96550e8afab332b63a.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Johannes Schindelin @ 2006-07-26 2:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060726021058.GV13776@pasky.or.cz>
Hi,
On Wed, 26 Jul 2006, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Wed, Jul 26, 2006 at 04:01:03AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
>
> > - It is not at all easy to run git (Perl scripts) in-place. At least for
> > Python, you can set a variable in config.mak and be done with it.
>
> Does setting prefix to the same directory as where your Git tree is
> help?
Nope. The culprit is
use lib (split(/:/, $ENV{GITPERLLIB} || "/Library/Perl/darwin"));
The latter, /Library/Perl/darwin comes from making "instlibdir" in perl/,
which in turn is generated by "perl Makefile.PL". Calling the latter with
PREFIX set does not change the output of "instlibdir" in any way.
> > - private_Error.pm is not used. I had to rename it for Error.pm to be
> > picked up.
>
> Hmm, yes, I guess it is copied in place only during the installation.
> We might add something like
>
> all:
> cp private-Error.pm blib/lib/Error.pm
>
> to the perl/Makefile. Opinions?
This (from Makefile.PL) is already sufficient:
# We come with our own bundled Error.pm. It's not in the set of default
# Perl modules so install it if it's not available on the system yet.
eval { require Error };
if ($@) {
$pm{'private-Error.pm'} = '$(INST_LIBDIR)/Error.pm';
}
> > - It even passes t7001 now. _After_ I spent two hours rewriting it in C.
>
> Thanks for the patience - I hope we will finally get all the remaining
> Perl problems sorted out.
What patience? Ah yes, I understand: irony.
Seriously, I still believe that proof-of-concepts in Bash or Perl or even
Python are fine. But they are not for real work, so one of my long-term
goals for git is to get rid of them.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Petr Baudis @ 2006-07-26 2:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Randal L.Schwartz
In-Reply-To: <7vhd15cfaj.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Jul 26, 2006 at 03:42:44AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > diff --git a/perl/private-Error.pm b/perl/private-Error.pm
> > index ebd0749..8fff866 100644
> > --- a/perl/private-Error.pm
> > +++ b/perl/private-Error.pm
> > @@ -290,6 +288,14 @@ use vars qw(@EXPORT_OK @ISA %EXPORT_TAGS
> >
> > @ISA = qw(Exporter);
> >
> > +
> > +sub blessed {
> > + my $item = shift;
> > + local $@; # don't kill an outer $@
> > + ref $item and eval { $item->can('can') };
> > +}
>
> Hmmm. I wonder how this relates to what Merlyn actually said?
>
> From: merlyn@stonehenge.com (Randal L. Schwartz)
> Subject: Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
> Date: 10 Jul 2006 18:42:35 -0700
> Message-ID: <863bd8nchg.fsf@blue.stonehenge.com>
> Cc: Junio C Hamano <junkio@cox.net>, <git@vger.kernel.org>
> To: Petr Baudis <pasky@suse.cz>
>
> >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
> Randal> sub blessed {
> Randal> my $item = shift;
> Randal> local $@; # don't kill an outer $@
> Randal> ref $item and eval { $item->can('can') };
> Randal> }
>
> Randal> Oops, lose the local $@ line. Just found out this is a
> Randal> broken thing in current Perls. The rest is good though.
>
> And thirdly, ignore what I *just* said, and concentrate on what
> I *previously* said, becaused my testing was off.
>
> My reading is that (1) the part of the patch should read
> something like this:
>
> sub blessed {
> my $item = shift;
> ref $item and eval { $item->can('can') };
> }
I don't know, from my late-night understanding it should have the local
line... :-)
> and (2) Merlyn thinks there is a bigger problem than using Scalar::Util
> which should be dealt with first. Was the use of try{}catch{}
> syntax sugar (and it is easy to leak memory) the issue? How was
> that resolved?
We never got to producing anything that could trigger the memleak, at
least I wasn't able to reproduce it based on the rather vague
description.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Petr Baudis @ 2006-07-26 2:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607260402460.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Wed, Jul 26, 2006 at 04:03:32AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Wed, 26 Jul 2006, Johannes Schindelin wrote:
>
> > - private_Error.pm is not used. I had to rename it for Error.pm to be
> > picked up.
>
> Never mind. After I finally got the GITPERLLIB thing right, it did pick
> Error.pm up.
cool. How did you tweak it?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Petr Baudis @ 2006-07-26 2:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607260356480.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Wed, Jul 26, 2006 at 04:01:03AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> After a lot of fiddling, it works here. Remarks:
thanks for the testing!
> - It is not at all easy to run git (Perl scripts) in-place. At least for
> Python, you can set a variable in config.mak and be done with it.
Does setting prefix to the same directory as where your Git tree is
help? (If so, we might want to document it.)
> - private_Error.pm is not used. I had to rename it for Error.pm to be
> picked up.
Hmm, yes, I guess it is copied in place only during the installation.
We might add something like
all:
cp private-Error.pm blib/lib/Error.pm
to the perl/Makefile. Opinions?
> - It even passes t7001 now. _After_ I spent two hours rewriting it in C.
Thanks for the patience - I hope we will finally get all the remaining
Perl problems sorted out.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Johannes Schindelin @ 2006-07-26 2:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607260356480.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Wed, 26 Jul 2006, Johannes Schindelin wrote:
> - private_Error.pm is not used. I had to rename it for Error.pm to be
> picked up.
Never mind. After I finally got the GITPERLLIB thing right, it did pick
Error.pm up.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Johannes Schindelin @ 2006-07-26 2:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060726010358.20964.80443.stgit@machine>
Hi,
On Wed, 26 Jul 2006, Petr Baudis wrote:
> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
>
> This is a newer much saner blessed() version by Randal L. Schwarz.
After a lot of fiddling, it works here. Remarks:
- It is not at all easy to run git (Perl scripts) in-place. At least for
Python, you can set a variable in config.mak and be done with it.
- private_Error.pm is not used. I had to rename it for Error.pm to be
picked up.
- It even passes t7001 now. _After_ I spent two hours rewriting it in C.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Make git-mv a builtin
From: Johannes Schindelin @ 2006-07-26 1:52 UTC (permalink / raw)
To: git, junkio
This also moves add_file_to_index() to read-cache.c. Oh, and while
touching builtin-add.c, it also removes a duplicate git_config() call.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
There is no test for it, and I am quite certain the old script
doesn't do it either: git-mv some_tracked_dir/ there/ will
not work. t7001-mv passes, though.
I cannot test, because the script still fails to work here.
Makefile | 7 +-
builtin-add.c | 40 ---------
builtin-mv.c | 221 +++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1
cache.h | 1
git-mv.perl | 246 ---------------------------------------------------------
git.c | 1
read-cache.c | 39 +++++++++
8 files changed, 267 insertions(+), 289 deletions(-)
diff --git a/Makefile b/Makefile
index 1069810..baed711 100644
--- a/Makefile
+++ b/Makefile
@@ -165,7 +165,7 @@ SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
git-shortlog.perl git-rerere.perl \
git-annotate.perl git-cvsserver.perl \
- git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
+ git-svnimport.perl git-cvsexportcommit.perl \
git-send-email.perl git-svn.perl
SCRIPT_PYTHON = \
@@ -207,7 +207,7 @@ BUILT_INS = git-log$X git-whatchanged$X
git-read-tree$X git-commit-tree$X git-write-tree$X \
git-apply$X git-show-branch$X git-diff-files$X git-update-index$X \
git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \
- git-fmt-merge-msg$X git-prune$X
+ git-fmt-merge-msg$X git-prune$X git-mv$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -263,7 +263,8 @@ BUILTIN_OBJS = \
builtin-apply.o builtin-show-branch.o builtin-diff-files.o \
builtin-diff-index.o builtin-diff-stages.o builtin-diff-tree.o \
builtin-cat-file.o builtin-mailsplit.o builtin-stripspace.o \
- builtin-update-ref.o builtin-fmt-merge-msg.o builtin-prune.o
+ builtin-update-ref.o builtin-fmt-merge-msg.o builtin-prune.o \
+ builtin-mv.o path-list.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
EXTLIBS = -lz
diff --git a/builtin-add.c b/builtin-add.c
index 2d25698..111d8f5 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -83,45 +83,6 @@ static void fill_directory(struct dir_st
prune_directory(dir, pathspec, baselen);
}
-static int add_file_to_index(const char *path, int verbose)
-{
- int size, namelen;
- struct stat st;
- struct cache_entry *ce;
-
- if (lstat(path, &st))
- die("%s: unable to stat (%s)", path, strerror(errno));
-
- if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode))
- die("%s: can only add regular files or symbolic links", path);
-
- namelen = strlen(path);
- size = cache_entry_size(namelen);
- ce = xcalloc(1, size);
- memcpy(ce->name, path, namelen);
- ce->ce_flags = htons(namelen);
- fill_stat_cache_info(ce, &st);
-
- ce->ce_mode = create_ce_mode(st.st_mode);
- if (!trust_executable_bit) {
- /* If there is an existing entry, pick the mode bits
- * from it.
- */
- int pos = cache_name_pos(path, namelen);
- if (pos >= 0)
- ce->ce_mode = active_cache[pos]->ce_mode;
- }
-
- if (index_path(ce->sha1, path, &st, 1))
- die("unable to index file %s", path);
- if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD))
- die("unable to add %s to index",path);
- if (verbose)
- printf("add '%s'\n", path);
- cache_tree_invalidate_path(active_cache_tree, path);
- return 0;
-}
-
static struct lock_file lock_file;
int cmd_add(int argc, const char **argv, char **envp)
@@ -160,7 +121,6 @@ int cmd_add(int argc, const char **argv,
}
die(builtin_add_usage);
}
- git_config(git_default_config);
pathspec = get_pathspec(prefix, argv + i);
fill_directory(&dir, pathspec);
diff --git a/builtin-mv.c b/builtin-mv.c
new file mode 100644
index 0000000..973bb29
--- /dev/null
+++ b/builtin-mv.c
@@ -0,0 +1,221 @@
+/*
+ * "git mv" builtin command
+ *
+ * Copyright (C) 2006 Johannes Schindelin
+ */
+#include <fnmatch.h>
+
+#include "cache.h"
+#include "builtin.h"
+#include "dir.h"
+#include "cache-tree.h"
+#include "path-list.h"
+
+static const char builtin_mv_usage[] =
+"git-mv [-n] [-f] { <source> <destination> | [-k] <source>... <destination> }";
+
+static const char **copy_pathspec(const char *prefix, const char **pathspec,
+ int count, int base_name)
+{
+ const char **result = xmalloc((count + 1) * sizeof(const char *));
+ memcpy(result, pathspec, count * sizeof(const char *));
+ result[count] = NULL;
+ if (base_name) {
+ int i;
+ for (i = 0; i < count; i++) {
+ const char *last_slash = strrchr(result[i], '/');
+ if (last_slash)
+ result[i] = last_slash + 1;
+ }
+ }
+ return get_pathspec(prefix, result);
+}
+
+static void show_list(const char *label, struct path_list *list)
+{
+ if (list->nr > 0) {
+ int i;
+ printf("%s", label);
+ for (i = 0; i < list->nr; i++)
+ printf("%s%s", i > 0 ? ", " : "", list->items[i].path);
+ putchar('\n');
+ }
+}
+
+static struct lock_file lock_file;
+
+int cmd_mv(int argc, const char **argv, char **envp)
+{
+ int i, newfd, count;
+ int verbose = 0, show_only = 0, force = 0, ignore_errors = 0;
+ const char *prefix = setup_git_directory();
+ const char **source, **destination, **dest_path;
+ struct stat st;
+ struct path_list overwritten = {NULL, 0, 0, 0};
+ struct path_list src_for_dst = {NULL, 0, 0, 0};
+ struct path_list added = {NULL, 0, 0, 0};
+ struct path_list deleted = {NULL, 0, 0, 0};
+ struct path_list changed = {NULL, 0, 0, 0};
+
+ git_config(git_default_config);
+
+ newfd = hold_lock_file_for_update(&lock_file, get_index_file());
+ if (newfd < 0)
+ die("unable to create new index file");
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-n")) {
+ show_only = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-f")) {
+ force = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-k")) {
+ ignore_errors = 1;
+ continue;
+ }
+ die(builtin_mv_usage);
+ }
+ count = argc - i - 1;
+ if (count < 1)
+ usage(builtin_mv_usage);
+
+ source = copy_pathspec(prefix, argv + i, count, 0);
+ dest_path = copy_pathspec(prefix, argv + argc - 1, 1, 0);
+
+ if (lstat(dest_path[0], &st) == 0 &&
+ S_ISDIR(st.st_mode))
+ destination = copy_pathspec(dest_path[0], argv + i, count, 1);
+ else {
+ if (count != 1)
+ usage(builtin_mv_usage);
+ destination = dest_path;
+ }
+
+ /* Checking */
+ for (i = 0; i < count; i++) {
+ const char *bad = NULL;
+
+ if (show_only)
+ printf("Checking rename of '%s' to '%s'\n",
+ source[i], destination[i]);
+
+ if (lstat(source[i], &st) < 0)
+ bad = "bad source";
+ else if (lstat(destination[i], &st) == 0) {
+ bad = "destination exists";
+ if (force) {
+ /*
+ * only files can overwrite each other:
+ * check both source and destination
+ */
+ if (S_ISREG(st.st_mode)) {
+ fprintf(stderr, "Warning: %s;"
+ " will overwrite!\n",
+ bad);
+ bad = NULL;
+ path_list_insert(destination[i],
+ &overwritten);
+ } else
+ bad = "Cannot overwrite";
+ }
+ }
+
+ if (!bad && !strncmp(destination[i], source[i],
+ strlen(source[i])))
+ bad = "can not move directory into itself";
+
+ if (!bad && cache_name_pos(source[i], strlen(source[i])) < 0)
+ bad = "not under version control";
+
+ if (!bad) {
+ if (path_list_has_path(&src_for_dst, destination[i]))
+ bad = "multiple sources for the same target";
+ else
+ path_list_insert(destination[i], &src_for_dst);
+ }
+
+ if (bad) {
+ if (ignore_errors) {
+ if (--count > 0) {
+ memmove(source + i, source + i + 1,
+ (count - i) * sizeof(char *));
+ memmove(destination + i,
+ destination + i + 1,
+ (count - i) * sizeof(char *));
+ }
+ } else
+ die ("Error: %s, source=%s, destination=%s",
+ bad, source[i], destination[i]);
+ }
+ }
+
+ for (i = 0; i < count; i++) {
+ if (show_only || verbose)
+ printf("Renaming %s to %s\n",
+ source[i], destination[i]);
+ if (!show_only && rename(source[i], destination[i]) < 0
+ && !ignore_errors)
+ die ("renaming %s failed: %s",
+ source[i], strerror(errno));
+
+ if (cache_name_pos(source[i], strlen(source[i])) >= 0) {
+ path_list_insert(source[i], &deleted);
+
+ /* destination can be a directory with 1 file inside */
+ if (path_list_has_path(&overwritten, destination[i]))
+ path_list_insert(destination[i], &changed);
+ else
+ path_list_insert(destination[i], &added);
+ } else
+ path_list_insert(destination[i], &added);
+ }
+
+ if (show_only) {
+ show_list("Changed : ", &changed);
+ show_list("Adding : ", &added);
+ show_list("Deleting : ", &deleted);
+ } else {
+ for (i = 0; i < changed.nr; i++) {
+ const char *path = changed.items[i].path;
+ int i = cache_name_pos(path, strlen(path));
+ struct cache_entry *ce = active_cache[i];
+
+ if (i < 0)
+ die ("Huh? Cache entry for %s unknown?", path);
+ refresh_cache_entry(ce, 0);
+ }
+
+ for (i = 0; i < added.nr; i++) {
+ const char *path = added.items[i].path;
+ add_file_to_index(path, verbose);
+ }
+
+ for (i = 0; i < deleted.nr; i++) {
+ const char *path = deleted.items[i].path;
+ remove_file_from_cache(path);
+ }
+
+ if (active_cache_changed) {
+ if (write_cache(newfd, active_cache, active_nr) ||
+ close(newfd) ||
+ commit_lock_file(&lock_file))
+ die("Unable to write new index file");
+ }
+ }
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 5339d86..6f3a439 100755
--- a/builtin.h
+++ b/builtin.h
@@ -52,6 +52,7 @@ extern int cmd_rev_parse(int argc, const
extern int cmd_update_index(int argc, const char **argv, char **envp);
extern int cmd_update_ref(int argc, const char **argv, char **envp);
extern int cmd_fmt_merge_msg(int argc, const char **argv, char **envp);
+extern int cmd_mv(int argc, const char **argv, char **envp);
extern int cmd_write_tree(int argc, const char **argv, char **envp);
extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
diff --git a/cache.h b/cache.h
index 457d1d0..3288b11 100644
--- a/cache.h
+++ b/cache.h
@@ -158,6 +158,7 @@ extern int add_cache_entry(struct cache_
extern struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really);
extern int remove_cache_entry_at(int pos);
extern int remove_file_from_cache(const char *path);
+extern int add_file_to_index(const char *path, int verbose);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
extern int ce_match_stat(struct cache_entry *ce, struct stat *st, int);
extern int ce_modified(struct cache_entry *ce, struct stat *st, int);
diff --git a/git-mv.perl b/git-mv.perl
deleted file mode 100755
index 322b9fd..0000000
--- a/git-mv.perl
+++ /dev/null
@@ -1,246 +0,0 @@
-#!/usr/bin/perl
-#
-# Copyright 2005, Ryan Anderson <ryan@michonline.com>
-# Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
-#
-# This file is licensed under the GPL v2, or a later version
-# at the discretion of Linus Torvalds.
-
-use warnings;
-use strict;
-use Getopt::Std;
-use Git;
-
-sub usage() {
- print <<EOT;
-$0 [-f] [-n] <source> <destination>
-$0 [-f] [-n] [-k] <source> ... <destination directory>
-EOT
- exit(1);
-}
-
-our ($opt_n, $opt_f, $opt_h, $opt_k, $opt_v);
-getopts("hnfkv") || usage;
-usage() if $opt_h;
-@ARGV >= 1 or usage;
-
-my $repo = Git->repository();
-
-my (@srcArgs, @dstArgs, @srcs, @dsts);
-my ($src, $dst, $base, $dstDir);
-
-# remove any trailing slash in arguments
-for (@ARGV) { s/\/*$//; }
-
-my $argCount = scalar @ARGV;
-if (-d $ARGV[$argCount-1]) {
- $dstDir = $ARGV[$argCount-1];
- @srcArgs = @ARGV[0..$argCount-2];
-
- foreach $src (@srcArgs) {
- $base = $src;
- $base =~ s/^.*\///;
- $dst = "$dstDir/". $base;
- push @dstArgs, $dst;
- }
-}
-else {
- if ($argCount < 2) {
- print "Error: need at least two arguments\n";
- exit(1);
- }
- if ($argCount > 2) {
- print "Error: moving to directory '"
- . $ARGV[$argCount-1]
- . "' not possible; not existing\n";
- exit(1);
- }
- @srcArgs = ($ARGV[0]);
- @dstArgs = ($ARGV[1]);
- $dstDir = "";
-}
-
-my $subdir_prefix = $repo->wc_subdir();
-
-# run in git base directory, so that git-ls-files lists all revisioned files
-chdir $repo->wc_path();
-$repo->wc_chdir('');
-
-# normalize paths, needed to compare against versioned files and update-index
-# also, this is nicer to end-users by doing ".//a/./b/.//./c" ==> "a/b/c"
-for (@srcArgs, @dstArgs) {
- # prepend git prefix as we run from base directory
- $_ = $subdir_prefix.$_;
- s|^\./||;
- s|/\./|/| while (m|/\./|);
- s|//+|/|g;
- # Also "a/b/../c" ==> "a/c"
- 1 while (s,(^|/)[^/]+/\.\./,$1,);
-}
-
-my (@allfiles,@srcfiles,@dstfiles);
-my $safesrc;
-my (%overwritten, %srcForDst);
-
-{
- local $/ = "\0";
- @allfiles = $repo->command('ls-files', '-z');
-}
-
-
-my ($i, $bad);
-while(scalar @srcArgs > 0) {
- $src = shift @srcArgs;
- $dst = shift @dstArgs;
- $bad = "";
-
- for ($src, $dst) {
- # Be nicer to end-users by doing ".//a/./b/.//./c" ==> "a/b/c"
- s|^\./||;
- s|/\./|/| while (m|/\./|);
- s|//+|/|g;
- # Also "a/b/../c" ==> "a/c"
- 1 while (s,(^|/)[^/]+/\.\./,$1,);
- }
-
- if ($opt_v) {
- print "Checking rename of '$src' to '$dst'\n";
- }
-
- unless (-f $src || -l $src || -d $src) {
- $bad = "bad source '$src'";
- }
-
- $safesrc = quotemeta($src);
- @srcfiles = grep /^$safesrc(\/|$)/, @allfiles;
-
- $overwritten{$dst} = 0;
- if (($bad eq "") && -e $dst) {
- $bad = "destination '$dst' already exists";
- if ($opt_f) {
- # only files can overwrite each other: check both source and destination
- if (-f $dst && (scalar @srcfiles == 1)) {
- print "Warning: $bad; will overwrite!\n";
- $bad = "";
- $overwritten{$dst} = 1;
- }
- else {
- $bad = "Can not overwrite '$src' with '$dst'";
- }
- }
- }
-
- if (($bad eq "") && ($dst =~ /^$safesrc\//)) {
- $bad = "can not move directory '$src' into itself";
- }
-
- if ($bad eq "") {
- if (scalar @srcfiles == 0) {
- $bad = "'$src' not under version control";
- }
- }
-
- if ($bad eq "") {
- if (defined $srcForDst{$dst}) {
- $bad = "can not move '$src' to '$dst'; already target of ";
- $bad .= "'".$srcForDst{$dst}."'";
- }
- else {
- $srcForDst{$dst} = $src;
- }
- }
-
- if ($bad ne "") {
- if ($opt_k) {
- print "Warning: $bad; skipping\n";
- next;
- }
- print "Error: $bad\n";
- exit(1);
- }
- push @srcs, $src;
- push @dsts, $dst;
-}
-
-# Final pass: rename/move
-my (@deletedfiles,@addedfiles,@changedfiles);
-$bad = "";
-while(scalar @srcs > 0) {
- $src = shift @srcs;
- $dst = shift @dsts;
-
- if ($opt_n || $opt_v) { print "Renaming $src to $dst\n"; }
- if (!$opt_n) {
- if (!rename($src,$dst)) {
- $bad = "renaming '$src' failed: $!";
- if ($opt_k) {
- print "Warning: skipped: $bad\n";
- $bad = "";
- next;
- }
- last;
- }
- }
-
- $safesrc = quotemeta($src);
- @srcfiles = grep /^$safesrc(\/|$)/, @allfiles;
- @dstfiles = @srcfiles;
- s/^$safesrc(\/|$)/$dst$1/ for @dstfiles;
-
- push @deletedfiles, @srcfiles;
- if (scalar @srcfiles == 1) {
- # $dst can be a directory with 1 file inside
- if ($overwritten{$dst} ==1) {
- push @changedfiles, $dstfiles[0];
-
- } else {
- push @addedfiles, $dstfiles[0];
- }
- }
- else {
- push @addedfiles, @dstfiles;
- }
-}
-
-if ($opt_n) {
- if (@changedfiles) {
- print "Changed : ". join(", ", @changedfiles) ."\n";
- }
- if (@addedfiles) {
- print "Adding : ". join(", ", @addedfiles) ."\n";
- }
- if (@deletedfiles) {
- print "Deleting : ". join(", ", @deletedfiles) ."\n";
- }
-}
-else {
- if (@changedfiles) {
- my ($fd, $ctx) = $repo->command_input_pipe('update-index', '-z', '--stdin');
- foreach my $fileName (@changedfiles) {
- print $fd "$fileName\0";
- }
- git_cmd_try { $repo->command_close_pipe($fd, $ctx); }
- 'git-update-index failed to update changed files with code %d';
- }
- if (@addedfiles) {
- my ($fd, $ctx) = $repo->command_input_pipe('update-index', '--add', '-z', '--stdin');
- foreach my $fileName (@addedfiles) {
- print $fd "$fileName\0";
- }
- git_cmd_try { $repo->command_close_pipe($fd, $ctx); }
- 'git-update-index failed to add new files with code %d';
- }
- if (@deletedfiles) {
- my ($fd, $ctx) = $repo->command_input_pipe('update-index', '--remove', '-z', '--stdin');
- foreach my $fileName (@deletedfiles) {
- print $fd "$fileName\0";
- }
- git_cmd_try { $repo->command_close_pipe($fd, $ctx); }
- 'git-update-index failed to remove old files with code %d';
- }
-}
-
-if ($bad ne "") {
- print "Error: $bad\n";
- exit(1);
-}
diff --git a/git.c b/git.c
index e4b2174..bd58885 100644
--- a/git.c
+++ b/git.c
@@ -261,6 +261,7 @@ static void handle_internal_command(int
{ "update-ref", cmd_update_ref },
{ "fmt-merge-msg", cmd_fmt_merge_msg },
{ "prune", cmd_prune },
+ { "mv", cmd_mv },
};
int i;
diff --git a/read-cache.c b/read-cache.c
index 9c0a9fc..c375e91 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -319,6 +319,45 @@ int remove_file_from_cache(const char *p
return 0;
}
+int add_file_to_index(const char *path, int verbose)
+{
+ int size, namelen;
+ struct stat st;
+ struct cache_entry *ce;
+
+ if (lstat(path, &st))
+ die("%s: unable to stat (%s)", path, strerror(errno));
+
+ if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode))
+ die("%s: can only add regular files or symbolic links", path);
+
+ namelen = strlen(path);
+ size = cache_entry_size(namelen);
+ ce = xcalloc(1, size);
+ memcpy(ce->name, path, namelen);
+ ce->ce_flags = htons(namelen);
+ fill_stat_cache_info(ce, &st);
+
+ ce->ce_mode = create_ce_mode(st.st_mode);
+ if (!trust_executable_bit) {
+ /* If there is an existing entry, pick the mode bits
+ * from it.
+ */
+ int pos = cache_name_pos(path, namelen);
+ if (pos >= 0)
+ ce->ce_mode = active_cache[pos]->ce_mode;
+ }
+
+ if (index_path(ce->sha1, path, &st, 1))
+ die("unable to index file %s", path);
+ if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD))
+ die("unable to add %s to index",path);
+ if (verbose)
+ printf("add '%s'\n", path);
+ cache_tree_invalidate_path(active_cache_tree, path);
+ return 0;
+}
+
int ce_same_name(struct cache_entry *a, struct cache_entry *b)
{
int len = ce_namelen(a);
--
1.4.2.rc2.g39be8
^ permalink raw reply related
* [PATCH] Eliminate Scalar::Util usage from private-Error.pm
From: Petr Baudis @ 2006-07-26 1:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607251809340.29667@wbgn013.biozentrum.uni-wuerzburg.de>
We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
(Unfortunately, Scalar::Util is not bundled with older Perl versions.)
This is a newer much saner blessed() version by Randal L. Schwarz.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/private-Error.pm | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/perl/private-Error.pm b/perl/private-Error.pm
index ebd0749..8fff866 100644
--- a/perl/private-Error.pm
+++ b/perl/private-Error.pm
@@ -43,8 +43,6 @@ sub throw_Error_Simple
# Exported subs are defined in Error::subs
-use Scalar::Util ();
-
sub import {
shift;
local $Exporter::ExportLevel = $Exporter::ExportLevel + 1;
@@ -290,6 +288,14 @@ use vars qw(@EXPORT_OK @ISA %EXPORT_TAGS
@ISA = qw(Exporter);
+
+sub blessed {
+ my $item = shift;
+ local $@; # don't kill an outer $@
+ ref $item and eval { $item->can('can') };
+}
+
+
sub run_clauses ($$$\@) {
my($clauses,$err,$wantarray,$result) = @_;
my $code = undef;
@@ -312,7 +318,7 @@ sub run_clauses ($$$\@) {
$i -= 2;
next CATCHLOOP;
}
- elsif(Scalar::Util::blessed($err) && $err->isa($pkg)) {
+ elsif(blessed($err) && $err->isa($pkg)) {
$code = $catch->[$i+1];
while(1) {
my $more = 0;
@@ -421,7 +427,7 @@ sub try (&;$) {
if (defined($err))
{
- if (Scalar::Util::blessed($err) && $err->can('throw'))
+ if (blessed($err) && $err->can('throw'))
{
throw $err;
}
^ permalink raw reply related
* Re: Handling very large numbers of symbolic references?
From: Linus Torvalds @ 2006-07-25 23:20 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87psftb7v8.fsf@hades.wkstn.nix>
On Wed, 26 Jul 2006, Nix wrote:
>
> Well, actually I was considering trying a combination of two things:
>
> - a new type of multi-entry ref (as you suggested), perhaps in a file
> refs/inactive-heads, which is merged with the heads list by lookup
> operations only (so merge would see them, but ls-remote would not:
> `invisible heads' if you will)
Yes, that should work. Make sure that you tell git-fsck-objects and
git-prune that those heads are reachable, though.
Of course, if you end up having one "master" head (that is the "merge" of
all branches), that would take care of the reachability issue too: you
don't actually need to create a _real_ merge, you can just make sure that
there is a commit that points to all new heads you create. It could even
have a totally dummy tree node, ie you could do
oldhead=$(git-rev-parse HEAD^0) || exit
newhead=$(git commit-tree $oldhead -p $oldhead -p new-bug-head < changelog) || exit
git update-ref HEAD $newhead $oldhead
which would just update the commit list with a fake "merge" commit merging
"new-bug-head" into the stream of top commits (using the same tree as the
previous "HEAD" commit had) so that it's always reachable.
Something like that, anyway. That way you can do a "git clone" and you get
all the bug commits through a single HEAD.
Linus
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Nix @ 2006-07-25 23:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607251508540.29649@g5.osdl.org>
On Tue, 25 Jul 2006, Linus Torvalds noted:
> That said, you can certainly use a hierarchy of refs, and just have them
> as
>
> .git/refs/heads/00/000-999
> 01/000-999
> 02/000-999
> ...
>
> if you want to avoid the dreaded filesystem meltdown.
That's what I was hoping would work, but...
> I suspect it would suck, though. You'd still end up with tens of thousands
> of small files, with no good way to pack them together.
... that is, indeed, the problem.
>> - the vast majority of these bugs are closed. They still need to be got
>> at now and again for branch merges, but they could be got out of
>> .refs/heads at delete_branch time, and pushed into a tree consisting
>> entirely of deleted branches, which would in turn be pointed at from
>> some new place under .refs; perhaps .refs/heads/heavy (by analogy to
>> non-lightweight tags). The problem here is that whenever we delete
>> a tag, we'll leak that tree (at least we will if it's in a pack), and
>> that leakage really could add up in the end.
>
> Well, the problem to some degree is that a number of git routines will
> look up all heads (eg things like "git pull" and "git ls-remote" and "git
> push", not to mention all the visualizers that want to show all the heads.
Ick. Yes, that would be a bit of a sod. git-ls-remote showing >30,000 heads
is... not ideal. Not at all. (It's growing by ~50 a day...)
It's a sort of `hidden head' I meant. Hm. I think I see a way: see below.
> So so if you really en dup doing them as individual heads, I'm afraid that
> performance will suck big-time. And it wouldn't really help to put them
> under .git/refs/heads/heavy, you'd still be in trouble.
OK, so it has to go somewhere else.
>> I'm not sure which way is preferable. Suggestions? Is the entire idea
>> lunatic?
>
> I think you _can_ use git in the way you propose, but it's going to be
> fundamentally pretty inefficient. The diskspace usage will be inefficient
> (tens of thousands of files, all just 41 characters in size), but even
> more importantly, as mentioned, you'll have things like cloning or pulling
> a repository always havign to get tens of thousands of references, and
> that's just going to be very very slow.
>
> So yes, I think it's a bit lunatic.
It's perhaps unusual, but, well, the version control system we're
switching from takes over an *hour* just to check out some classes of
files! (SCCS's handling of large binary files is... inefficient if
naively kludged by uuencoding everything before committing it; we have
some s-files whose size is approaching a gigabyte as a result, being
accessed over very slow NFS. git, of course, doesn't need such crud,
although I may need to teach the deltifier about xdelta or something of
that nature to keep sizes down in the long run.)
> Git scales much better in _other_ ways. For example, one thing you could
> do is to have each bug-report be described as a _file_ instead of as a
> tag, and then have just one (or a few branches), and you'd have nice
> naming of bugs just because the filenames can be nice. That would allow
> git to shine because it scales well in things git is good at, ie the
> database itself.
>
> You'd probably want to introduce the notion of a nice specialized "merge"
> for those files (assuming you really want to do _distributed_ reporting,
> and actually merge two different databases that have the same bugs), but
That's the sort of unlikely thing which is *certain* to happen :) but in
practice until those database merges actually take place I can't be sure
how the renumbering would be done :/ but no, the heaps-of-refs seems
like the only practical way, because in practice people treat these bugs
as little sets of changed files that they can merge all over the place,
and, well, that's a branch as far as I can see. Of course, the
difference between a branch and a `tree of commits which has a ref-like
thing pointing to it' is minimal: I'd have to teach git-fsck-objects
about it anyway to stop it ditching things as unreachable when they
weren't...
> git should actually be quite good at supporting something like that, even
> if you might have to do some infrastructure yourself.
>
> OR, you could actually teach git about other ways of looking up names. So
This is what I was thinking of doing.
> if you decide that you do want to have one branch per bug, you might want
> to teach git about a new "ref" file format that has multiple name/ref
> translations in the same file. That would solve the disk usage problem,
> even if it would _not_ solve the ineffiency of tools that might be
> slightly unhappy to see thousands and thousands of refs.
Well, actually I was considering trying a combination of two things:
- a new type of multi-entry ref (as you suggested), perhaps in a file
refs/inactive-heads, which is merged with the heads list by lookup
operations only (so merge would see them, but ls-remote would not:
`invisible heads' if you will); git-branch moves head refs there upon
deletion; so even deleted head refs are referenceable by name
forever. The merging for lookup would scale as O(n), of course, but
that can probably be ignored until we have hundreds of thousands of
them (whereupon the right thing to do is probably to change the
inactive-heads file format and lookup code and keep the general idea).
(This might mean rejigging code that assumes that looking up a ref is
an open() away, but that shouldn't be all that terribly hard, one new
tool, `git-lookup-ref', sort of like git-symbolic-ref only applying
to refs that aren't symbolic).
- dependency information could be handled by rebasing the depending
branch on the heads of the branches which it depends upon, but, well,
that seems extremely icky to me, especially if those branches are
still changing: we'd have to re-rebase all the time to stay up to
date. I suspect that a new object type, or perhaps a new type of ref,
would be right here. The idea is that you express a mapping from one
branch ref to another set of branch refs (*not* sha1 id, because there
is no fixed sha1 id that corresponds to a given branch in the presence
of commit and git-rebase).
A new object type seems ideal for this (sort of like a commit only
with ref names instead of sha1 ids), but I'm under the impression
that adding new object types to git is quite tricky and introduces
inter-repository incompatibilities, so I might just make it a
refs/dependencies directory with one file per depending bug, containing
many ref names for the bugs it depends on. (There will likely be many
fewer dependencies than inactive bug branches, anyway.)
This should be fun!
> Anyway, whatever approach you select, send patches to Junio. I'm sure that
> we can try to make git support even some rather strange models.
Yeah, I'm planning to make this general enough that anyone can use it:
there'll be an outer layer of glaze around the porcelain which is
specifically to change the command-line syntax to be similar to the tool
that the poor sods at work are moving from, but I'll maintain that in a
branch that nobody sane will pull and that I won't push to anyone, and
keep it out of the tree meant for sane people. (I'm not sure if `local
branch' is really the right term for it: I mean, this is git, *all*
branches are local, or none are...)
--
`We're sysadmins. We deal with the inconceivable so often I can clearly
see the need to define levels of inconceivability.' --- Rik Steenwinkel
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Linus Torvalds @ 2006-07-25 22:23 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87psfteb4l.fsf@hades.wkstn.nix>
On Tue, 25 Jul 2006, Nix wrote:
>
> However, this causes a potential problem. There are tens of thousands of
> these bugs, and the .git/refs/heads directory gets *enormous* and thus
> the system gets terribly terribly slow (crappy old Solaris filesystem
> syndrome).
I would really suggest you use some lookup logic of your own to handle
this, because having that many refs will slow down a lot of things.
That said, you can certainly use a hierarchy of refs, and just have them
as
.git/refs/heads/00/000-999
01/000-999
02/000-999
...
if you want to avoid the dreaded filesystem meltdown.
I suspect it would suck, though. You'd still end up with tens of thousands
of small files, with no good way to pack them together.
> It seems to me there are two ways to fix this:
>
> - restructure .git/refs/* in a similar way to .git/objects, i.e. as a
> one- or two-level tree.
So this work already.
> - the vast majority of these bugs are closed. They still need to be got
> at now and again for branch merges, but they could be got out of
> .refs/heads at delete_branch time, and pushed into a tree consisting
> entirely of deleted branches, which would in turn be pointed at from
> some new place under .refs; perhaps .refs/heads/heavy (by analogy to
> non-lightweight tags). The problem here is that whenever we delete
> a tag, we'll leak that tree (at least we will if it's in a pack), and
> that leakage really could add up in the end.
Well, the problem to some degree is that a number of git routines will
look up all heads (eg things like "git pull" and "git ls-remote" and "git
push", not to mention all the visualizers that want to show all the heads.
So so if you really en dup doing them as individual heads, I'm afraid that
performance will suck big-time. And it wouldn't really help to put them
under .git/refs/heads/heavy, you'd still be in trouble.
> I'm not sure which way is preferable. Suggestions? Is the entire idea
> lunatic?
I think you _can_ use git in the way you propose, but it's going to be
fundamentally pretty inefficient. The diskspace usage will be inefficient
(tens of thousands of files, all just 41 characters in size), but even
more importantly, as mentioned, you'll have things like cloning or pulling
a repository always havign to get tens of thousands of references, and
that's just going to be very very slow.
So yes, I think it's a bit lunatic.
Git scales much better in _other_ ways. For example, one thing you could
do is to have each bug-report be described as a _file_ instead of as a
tag, and then have just one (or a few branches), and you'd have nice
naming of bugs just because the filenames can be nice. That would allow
git to shine because it scales well in things git is good at, ie the
database itself.
You'd probably want to introduce the notion of a nice specialized "merge"
for those files (assuming you really want to do _distributed_ reporting,
and actually merge two different databases that have the same bugs), but
git should actually be quite good at supporting something like that, even
if you might have to do some infrastructure yourself.
OR, you could actually teach git about other ways of looking up names. So
if you decide that you do want to have one branch per bug, you might want
to teach git about a new "ref" file format that has multiple name/ref
translations in the same file. That would solve the disk usage problem,
even if it would _not_ solve the ineffiency of tools that might be
slightly unhappy to see thousands and thousands of refs.
Anyway, whatever approach you select, send patches to Junio. I'm sure that
we can try to make git support even some rather strange models.
Linus
^ permalink raw reply
* This means you can still eat all the burgers, pizza you want without and gains in weight, infact you will lose weight.
From: Fischer @ 2006-07-25 21:57 UTC (permalink / raw)
To: glenda
Good day dear Sir,
Fatblaster is a thermogenic weight loss formula designed to naturally assist the body in burning more calories by efficiently using stored body fat for energy. The ingredients in Fatblaster assist in the thermogenic processes allowing you to naturally and safely burn fat and loose unwanted weight. Fatblaster remains a top seller among competitive brands, making it the #1 choice for those seeking safe and effective weight loss solution. Find what you need: http://ufonulun.com/gall/fb/
Any port in a storm Take your time and time will take you
It nah good to shove yuh foot in every stocking. Distance lends enchantment to the view Knowing is not enough; We must Apply Willing is not enough; We must Do
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Nix @ 2006-07-25 21:52 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <44C68D52.6030107@lsrfire.ath.cx>
On Tue, 25 Jul 2006, Rene Scharfe said:
> Nix schrieb:
>> However, this causes a potential problem. There are tens of thousands of
>> these bugs, and the .git/refs/heads directory gets *enormous* and thus
>> the system gets terribly terribly slow (crappy old Solaris filesystem
>> syndrome).
>>
>> It seems to me there are two ways to fix this:
>>
>> - restructure .git/refs/* in a similar way to .git/objects, i.e. as a
>> one- or two-level tree.
>
> Branch names are allowed to contain slashes, thus your porcelain is free
> to implement such a tree. Add a slash after every two bug ID digits and
> your directories will never contain more than 100 objects.
Oh, lovely! I was *sure* I'd need to make git core changes for this, but
no, the precognitive powers of the git hackers had anticipated my needs
before I knew what they were!
(Now the only downside is gitweb's treatment of such heads: but looking
at the code, making it skip suitably formatted heads when displaying the
heads list is an utterly trivial one-liner.)
--
`We're sysadmins. We deal with the inconceivable so often I can clearly
see the need to define levels of inconceivability.' --- Rik Steenwinkel
^ permalink raw reply
* Re: Handling very large numbers of symbolic references?
From: Rene Scharfe @ 2006-07-25 21:29 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87psfteb4l.fsf@hades.wkstn.nix>
Nix schrieb:
> However, this causes a potential problem. There are tens of thousands of
> these bugs, and the .git/refs/heads directory gets *enormous* and thus
> the system gets terribly terribly slow (crappy old Solaris filesystem
> syndrome).
>
> It seems to me there are two ways to fix this:
>
> - restructure .git/refs/* in a similar way to .git/objects, i.e. as a
> one- or two-level tree.
Branch names are allowed to contain slashes, thus your porcelain is free
to implement such a tree. Add a slash after every two bug ID digits and
your directories will never contain more than 100 objects.
René
^ permalink raw reply
* Re: [PATCH] git wrapper: add --git-path=<path> and --bare options
From: Junio C Hamano @ 2006-07-25 21:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607252022370.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With this, you can say
>
> git --bare repack -a -d
>
> inside a bare repository, and it will actually work. While at it,
> also move the --version, --help and --exec-path options to the
> handle_options() function.
Thanks. Took a liberty cleaning up a few stuff, but will have
both alias-p and this patch in "next" shortly.
^ 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