* Re: daemon.c broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-25 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86r7a9jhq4.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> Actually, you probably want this instead:
And this one too, because .gitignore is missing some files:
>From nobody Mon Sep 17 00:00:00 2001
Subject: [PATCH] fix .gitignore to add new progs
From: Charlie <root@blue.stonehenge.com>
Date: 1130283408 -0700
---
.gitignore | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
applies-to: eba31d473719d9a1f2d00b40b3011460d7af864c
c0964c0160d7b08c0b5dd28d1b9462fd2b01bd50
diff --git a/.gitignore b/.gitignore
index 52cb9e2..758aaf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -54,6 +54,7 @@ git-merge-recursive
git-merge-resolve
git-merge-stupid
git-mktag
+git-mv
git-octopus
git-pack-objects
git-parse-remote
@@ -78,6 +79,7 @@ git-revert
git-send-email
git-send-pack
git-sh-setup
+git-shell
git-shortlog
git-show-branch
git-show-index
---
0.99.8.GIT
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply related
* [PATCH 3/4] Work around missing hard links on FAT formatted media
From: Johannes Schindelin @ 2005-10-25 23:41 UTC (permalink / raw)
To: git, junkio
FAT -- like Coda -- does not like cross-directory hard links. To be
precise, FAT does not like links at all. But links are not needed either.
So get rid of them.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
clone-pack.c | 2 +-
sha1_file.c | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)
applies-to: 73c52ee93ee1d5441a4cb207287b3ba7b0d8f4ed
8ffaffc904086970c66e5e8b7dd54001a1a2c466
diff --git a/clone-pack.c b/clone-pack.c
index 4f4975b..9609219 100644
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -211,7 +211,7 @@ static int clone_without_unpack(int fd[2
ifd = fd[0];
snprintf(tmpfile, sizeof(tmpfile),
- "%s/pack-XXXXXX", get_object_directory());
+ "%s/pack/tmp-XXXXXX", get_object_directory());
ofd = mkstemp(tmpfile);
if (ofd < 0)
return error("unable to create temporary file %s", tmpfile);
diff --git a/sha1_file.c b/sha1_file.c
index e456799..7fdc469 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1239,11 +1239,14 @@ int move_temp_to_file(const char *tmpfil
* won't be able to check collisions, but that's not a
* big deal.
*
+ * The same holds for FAT formatted media.
+ *
* When this succeeds, we just return 0. We have nothing
* left to unlink.
*/
- if (ret == EXDEV && !rename(tmpfile, filename))
+ if ((ret == EXDEV || ret == ENOTSUP) && !rename(tmpfile, filename))
return 0;
+ ret = errno;
}
unlink(tmpfile);
if (ret) {
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH 4/4] Test in git-init-db if the filemode can be trusted
From: Johannes Schindelin @ 2005-10-25 23:43 UTC (permalink / raw)
To: git, junkio
... and if not, write an appropriate .git/config. Of course, that happens
only if no config file was yet created (by a template or a hook).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This might be a bit controversial, as we probably need a way to
write to .git/config anyway. Until there are such functions, I'll
live with this patch.
init-db.c | 37 +++++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
applies-to: 047019cf0b103c8350c6b4da7836b15795c69498
64ca59712d766e8264f9208d70b8f5c811dfd3ea
diff --git a/init-db.c b/init-db.c
index 2c27e18..b242fbf 100644
--- a/init-db.c
+++ b/init-db.c
@@ -196,6 +196,43 @@ static void create_default_files(const c
}
path[len] = 0;
copy_templates(path, len, template_path);
+
+ /*
+ * Find out if we can trust the executable bit.
+ */
+ safe_create_dir(path);
+ strcpy(path + len, "config");
+ if (access(path, R_OK) < 0) {
+ static const char contents[] =
+ "#\n"
+ "# This is the config file\n"
+ "#\n"
+ "\n"
+ "; core variables\n"
+ "[core]\n"
+ " ; Don't trust file modes\n"
+ " filemode = false\n"
+ "\n";
+ FILE *config = fopen(path, "w");
+ struct stat st;
+
+ if (!config)
+ die("Can not write to %s?", path);
+
+ fwrite(contents, sizeof(contents)-1, 1, config);
+
+ fclose(config);
+
+ if (!lstat(path, &st)) {
+ struct stat st2;
+ if (!chmod(path, st.st_mode ^ S_IXUSR) &&
+ !lstat(path, &st2) &&
+ st.st_mode != st2.st_mode)
+ unlink(path);
+ else
+ fprintf(stderr, "Ignoring file modes\n");
+ }
+ }
}
static const char init_db_usage[] =
---
0.99.8.GIT
^ permalink raw reply related
* Re: [PATCH] Make fetch-pack play nicer with servers which do not speak multi_ack
From: Johannes Schindelin @ 2005-10-25 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll0hcgv3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 25 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > You're right. Complete common refs are sent even if they are ancestors
> > of other complete common refs. I'll think about that.
>
> I think you should be able to do something similar to what
> git-show-branch --independent does, except that the current
> show-branch implementation sucks.
I have a patch simmering, but I hesitate to send it out, lest you go and
put it into master before I found the obvious bugs ;-)
> It wastes one-bit per ref head, which is not too bad if we deal only
> with branches (who would sanely keep more than 29 branches in a repo
> except Jeff ;-) [...]
Well, I do! I *love* topic branches. Sometimes I even interrupt my
regular work to create a random one ;-)
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Junio C Hamano @ 2005-10-26 0:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510260120260.28994@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Using dc is not really necessary, since expr understands summing 32 bit
> signed integers. Which means that git-count-objects will now fail when 2
> GB of unpacked objects have accumulated.
Sorry, but I am not very happy about this patch. "local"
bashism aside, doesn't this spawn expr for every unpacked
object?
^ permalink raw reply
* Re: git status and commit from subdirectory?
From: Linus Torvalds @ 2005-10-26 0:16 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510251735500.25300@iabervon.org>
On Tue, 25 Oct 2005, Daniel Barkalow wrote:
>
> It seems like everything that "git status" does can now be done from a
> subdirectory (giving, of course, the status of the contents of the
> subdirectory). I think the same might be true of "git commit", but I
> haven't checked on everything. Is there anything that has to be done to
> enable this properly other than removing the "|| die" part of the first
> line?
This patch _may_ work. I've not tested it a lot. Surprise surprise.
NOTE! This has some seriously far-reaching implications. One of them is
that a few programs will automagically start working inside some random
directories.
And probably others won't. Instead of saying "Not a git archive", they
might run and do strange things.
The patch is definitely a big step in the right direction: it makes the
shell scripts that include "git-sh-setup" act a lot more like the programs
that automatically find the git directory. But everybody that includes
git-sh-setup should be verified.
This fixes gitk to also work the same way, btw.
Testing needed. Lots of it.
Linus
---
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbb9884..044b0b4 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -3,7 +3,7 @@
# Set up GIT_DIR and GIT_OBJECT_DIRECTORY
# and return true if everything looks ok
#
-: ${GIT_DIR=.git}
+: ${GIT_DIR=$(git-rev-parse --git-dir)} || exit
: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
# Having this variable in your environment would break scripts because
diff --git a/gitk b/gitk
index a9d37d9..a934255 100755
--- a/gitk
+++ b/gitk
@@ -12,7 +12,7 @@ proc gitdir {} {
if {[info exists env(GIT_DIR)]} {
return $env(GIT_DIR)
} else {
- return ".git"
+ return [exec git-rev-parse --git-dir]
}
}
diff --git a/setup.c b/setup.c
index c487d7e..96085dd 100644
--- a/setup.c
+++ b/setup.c
@@ -53,11 +53,10 @@ const char **get_pathspec(const char *pr
const char **p;
int prefixlen;
- if (!prefix && !entry)
- return NULL;
-
if (!entry) {
static const char *spec[2];
+ if (!prefix || !*prefix)
+ return NULL;
spec[0] = prefix;
spec[1] = NULL;
return spec;
@@ -120,9 +119,19 @@ const char *setup_git_directory(void)
if (offset == len)
return NULL;
-
/* Make "offset" point to past the '/', and add a '/' at the end */
offset++;
+
+ /*
+ * If we're inside the ".git" directory, we have an empty prefix
+ */
+ if (!strncmp(cwd + offset, ".git", 4)) {
+ switch (cwd[offset+4]) {
+ case '\0': case '/':
+ return "";
+ }
+ }
+
cwd[len++] = '/';
cwd[len] = 0;
return cwd + offset;
^ permalink raw reply related
* Re: Towards CVS code-exchange and gateways
From: Junio C Hamano @ 2005-10-26 0:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90510251357l23886747s8024a4326ad4e392@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Is there anyone working on a git -> cvs gateway or similar scripts?
Working on, no, but I was thinking about something like that at
work (today is my non-git day but I use git on top of CVS to
track my private changes in my CVS work tree which is my git
repo there).
I maintain at 'cvs' and 'master' branch (and other git branches)
there, and always 'git-checkout cvs' before doing 'cvs update',
and do 'git-commit' to slurp in the changes to the cvs side.
Then 'git checkout master ; git pull . cvs' to sync the master
side, work on a bit, commit. Showing what I've done to the CVS
side, currently I do something like this:
$ git-checkout cvs
$ git pull . master
$ git log ORIG_HEAD.. >L
$ cvs commit -F L
This isn't that bad because I do not care much about how the
development history on the CVS side looks like. But propagating
each git commit separately to CVS side would be much better, and
what you outlined should work nicely.
^ permalink raw reply
* Re: How to clone faster via ssh ?
From: Alexander Litvinov @ 2005-10-26 2:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vbr1dh5y7.fsf@assigned-by-dhcp.cox.net>
> The time to unpack the resulting pack on this end is eliminated
> if you use git from last week, namely this commit:
>
> commit e1c7ada6dd1fdf249d0bb84f3293d3be768b9239
> Author: Junio C Hamano <junkio@cox.net>
> Date: Wed Oct 19 14:43:43 2005 -0700
>
> git-clone: always keep pack sent from remote.
>
> This deprecates --keep and -q flags and always keeps the
> pack
> sent from the remote site. Corresponding configuration
> variables are also removed.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> But you would still pay for creating a pack on the remote side.
Yeah ! Thanks.
Version for todays master branch works much faster:
lan@lan:~/tmp/git/billing> time git-clone -n
ssh://lan@lan/home/lan/tmp/git/billing/repo r1
defaulting to local storage area
lan@lan's password:
Packing 204607 objects
real 4m0.107s
user 0m11.879s
sys 0m1.717s
And it makes only one pack. Great.
^ permalink raw reply
* Re: Towards CVS code-exchange and gateways
From: Martin Langhoff @ 2005-10-26 3:35 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46a038f90510251357l23886747s8024a4326ad4e392@mail.gmail.com>
Update here: Sven sent me a cool 4 line shell script that has the
basics. Next thing I know, and I was dumped into a boring presentation
-- so I turned it into a more complete Perl script. Still incomplete &
extremely untested, but showing the basics.
Give me a couple more boring presentations and we'll be done ;-)
cheers,
martin
---
#!/usr/bin/perl -w
use strict;
use Getopt::Std;
unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
die "GIT_DIR is not defined or is unreadable";
}
our ($opt_h, $opt_p);
getopt('hp');
$opt_h && usage();
die "Need at least one commit identifier!" unless @ARGV;
# resolve target commit
my $commit;
$commit = pop @ARGV;
$commit = `git-rev-parse --verify "$commit"^0"`;
chomp $commit;
if ($?) {
die "The commit reference did not resolve!";
}
# resolve what parent we want
my $parent;
if (@ARGV) {
$parent = pop @ARGV;
$parent = `git-rev-parse --verify "$parent"^0"`;
chomp $parent;
if ($?) {
die "The parent reference did not resolve!";
}
}
# parents from the commit itself
my @parents = `git-cat-file commmit $commit | grep -E '^parent
\\w{40}\$' | sed -e 's/^parent //'`;
@parents = map { chomp } @parents;
if ($parent) {
# double check that it's a valid parent
foreach my $p (@parents) {
my $found;
if ($p eq $parent) {
$found = 1;
last;
}; # found it
die "Did not find $parent in the parents for this commit!";
}
} else { # we don't have a parent from the cmdline...
if (@parents == 1) { # it's safe to get it from the commit
$parent = $parents[0];
} else { # or perhaps not!
die "This commit has more than one parent -- please name the parent
you want to use explicitly";
}
}
# grab the commit message
`git-cat-file commit $commit | sed -e '1,/^$/d' > .msg`;
$? && die "Error extraction the commit message";
my @files = `git-diff-tree -r $parent $commit | cut -f 2`;
$? && die "Error in git-diff-tree";
@files = map { chomp } @files;
# check that the files are clean and up to date according to cvs
my $dirty;
foreach my $f (@files) {
# TODO:we need to handle removed in cvs and/or new (from git)
my $status = `cvs status $f`;
unless ($status =~ m/Up to date/) {
$dirty = 1;
warn "File $f not up to date!\n";
}
}
if ($dirty) {
die "Exiting: your CVS tree is not clean for this merge.";
}
###
### NOTE: if you are planning to die() past this point
### you MUST call cleanupcvs(@files) before die()
###
## apply changes to binary files
my @bfiles = `git-diff-tree -p $parent $commit | grep '^Binary'`;
@bfiles = map { chomp } @bfiles;
foreach my $f (@bfiles) {
# check that the file in cvs matches the "old" file
# replace with the new file
}
## apply non-binary changes
## (git-diff-tree -p $1 | patch -p1) && cvs commit -F .msg
sub usage {
print STDERR <<END;
Usage: GIT_DIR=/path/to/.gi ${\basename $0} # fetch/update GIT from CVS
[-h] [-p] [ parent ] commit
END
exit(1);
}
# ensure cvs is clean before we die
sub cleanupcvs {
my @files = @_;
foreach my $f (@files) {
`cvs -q update -C "$f"`;
if ($?) {
warn "Warning! Failed to cleanup state of $f\n";
}
}
}
^ permalink raw reply
* [PATCH] fetch-pack: avoid packing reachable objects.
From: Jan Harkes @ 2005-10-26 4:26 UTC (permalink / raw)
To: git, junkio
Mark remote commits that were found in the alternate repository as
COMPLETE and avoid unnecessary packing of already available objects.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
---
When we pull updates from a shared repository into a clone that was
created with 'git clone -l -s', we pack objects that are already
reachable. This was because we only marked local refs as COMPLETE.
diff --git a/fetch-pack.c b/fetch-pack.c
index 8566ab1..17524d8 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -169,6 +169,7 @@ static int everything_local(struct ref *
*/
if (o->type == commit_type) {
struct commit *commit = (struct commit *)o;
+ commit->object.flags |= COMPLETE;
if (!cutoff || cutoff < commit->date)
cutoff = commit->date;
}
^ permalink raw reply related
* Re: [PATCH] fetch-pack: avoid packing reachable objects.
From: Junio C Hamano @ 2005-10-26 5:07 UTC (permalink / raw)
To: Jan Harkes; +Cc: junkio, git
In-Reply-To: <20051026042632.GA3059@delft.aura.cs.cmu.edu>
Jan Harkes <jaharkes@cs.cmu.edu> writes:
> Mark remote commits that were found in the alternate repository as
> COMPLETE and avoid unnecessary packing of already available objects.
Sorry, this is wrong (we made this mistake twice already). The
mere existence of that object in the local repository does not
necessarily mean we have everything that is reachable from it.
The rule is that we only trust local refs. Anything that are
reachable from them are known to be complete. And after a
successful fetch, we update local refs. The existence of an
object is a strong _hint_ that it _might_ be complete, but
nothing more.
Think of a case where you tried to fetch via commit walker and
got things reachable from the then-current ref, and the
object you are marking as COMPLETE (maybe in pack) is a remnant
of that failed fetch, which was killed before completing. You
might have complete history starting from the then-current
commit back to that commit, but there is no guarantee that you
can further tangle the history back and find everything needed.
^ permalink raw reply
* Re: [PATCH] git_progname
From: Junio C Hamano @ 2005-10-26 6:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051025133208.GC30889@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> No, I didn't mean the oneliner at all, actually - just the notion that
> you stealthily hijack main(). We'll see what Junio thinks about it. ;)
May I just say "yuck"?
I think what you suggested makes the most sense.
>> So I'd say just add setup_progname("foo") at the start of your main().
^ permalink raw reply
* Re: [RFC] GIT paths
From: Junio C Hamano @ 2005-10-26 6:12 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <435E259D.3040701@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> About the literally named /~junio directory, it would be possible with
> this syntax;
>
> git fetch host.xz:/~junio
>
> The userdir is (with my previous patch) only expanded if the path starts
> with a tilde.
I do not necessarily consider that a feature; see next item.
> It must remove the leading slash for this syntax:
>
> ssh://host.xz/~junio/repo
>
> Otherwise it would be passed as /~junio/repo to the remote end and no
> ~user interpolation would be done.
Not necessarily. Having the remote end interpret "/~user" and
"~user" the same way might make things more consistent; in other
words, "http://host/~user" is not spelled "http://host~user".
> I'd say make it invoke the programs with the canonicalized path. As you
> say, git-daemon has to verify that it's a proper git repo and in the
> whitelist anyway so I think it would be silly to add extra complexity to
> upload-pack and receive-pack.
Yeah, I tend to agree here.
>> - Give --server-root=/path/to/root flag to programs...
>
> If we stick with canonicalized paths I suppose this can be dropped.
Sounds good.
^ permalink raw reply
* Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension
From: Alex Riesen @ 2005-10-26 6:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0510252300290.15756@wbgn013.biozentrum.uni-wuerzburg.de>
On 10/25/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > This patch concludes the series, which makes
> > > git-fetch-pack/git-upload-pack negotiate a potentially better set of
> > > common revs. It should make a difference when fetching from a repository
> > > with a few branches.
> >
> > This broke git-pull for me (the local one):
> >
> > /d/e/f.git$ git-pull
> > fatal: bad pack file
> > fatal: git-unpack-objects died with error code 128
> > Fetch failure: /a/b/c/.git
> >
> > > applies-to: 6b4b7d9acf60aa99d961b599f37d0c824be79e27
> > > 9adb6b3971e7daa79221d7dbe05b66327b266b86
> > ...
> > > diff --git a/fetch-pack.c b/fetch-pack.c
> > > index 3a903c4..57602b9 100644
> > > --- a/fetch-pack.c
> > > +++ b/fetch-pack.c
> >
> > Reverting just fetch-pack.c part of the patch helps.
>
> Could you please try the patch I sent with the subject "[PATCH]
> fetch/upload: Fix corner case with few revs"? Your output looks exactly
> like what I fixed with that patch.
>
I couldn't at the moment. Do you still need a test?
^ permalink raw reply
* Re: [PATCH 4/4] Test in git-init-db if the filemode can be trusted
From: Junio C Hamano @ 2005-10-26 7:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0510260141220.30576@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ... and if not, write an appropriate .git/config. Of course, that happens
> only if no config file was yet created (by a template or a hook).
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
>
> This might be a bit controversial, as we probably need a way to
> write to .git/config anyway. Until there are such functions, I'll
> live with this patch.
Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm. Yes, we discussed something
like this earlier. It probably is a good usability patch, but
at the same time it does not feel quite right, but I cannot
explain why. Probably because I have not suffered from FAT for
some time, lucky me, I guess.
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Johannes Schindelin @ 2005-10-26 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ltcf05.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 25 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Using dc is not really necessary, since expr understands summing 32 bit
> > signed integers. Which means that git-count-objects will now fail when 2
> > GB of unpacked objects have accumulated.
>
> Sorry, but I am not very happy about this patch. "local"
> bashism aside, doesn't this spawn expr for every unpacked
> object?
Aargh! I had the impression "expr" was a builtin... Just forget about the
patch, okay?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add git-name-rev
From: Petr Baudis @ 2005-10-26 8:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0510260103570.27364@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Wed, Oct 26, 2005 at 01:05:59AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> git-name-rev tries to find nice symbolic names for commits. It does so by
> walking the commits from the refs. When the symbolic name is ambiguous,
> the following heuristic is applied: Try to avoid too many ~'s, and if two
> ambiguous names have the same count of ~'s, take the one whose last number
> is smaller.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
I think you should either add this to git-findtags.perl or (better) add
git-findtags.perl's functionality (i.e. a switch to search only in the
tags) to this and obsolete/kill git-findtags.perl. It is pretty new
(from Oct 13) so killing it shouldn't break anything.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Petr Baudis @ 2005-10-26 8:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0510261031400.7424@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Wed, Oct 26, 2005 at 10:33:33AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Aargh! I had the impression "expr" was a builtin... Just forget about the
> patch, okay?
I think that builtin or not, $() will always spawn a subshell. ...?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension
From: Johannes Schindelin @ 2005-10-26 8:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, junkio
In-Reply-To: <81b0412b0510252346t3806892dx71f9c0dc1efe4073@mail.gmail.com>
Hi,
On Wed, 26 Oct 2005, Alex Riesen wrote:
> > Could you please try the patch I sent with the subject "[PATCH]
> > fetch/upload: Fix corner case with few revs"? Your output looks exactly
> > like what I fixed with that patch.
> >
>
> I couldn't at the moment. Do you still need a test?
If you have time and can test it, yes, please.
Ciao,
Dscho
^ permalink raw reply
* Re: Towards CVS code-exchange and gateways
From: Petr Baudis @ 2005-10-26 8:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90510252035yb4167e1w2ee54d82896e5906@mail.gmail.com>
Dear diary, on Wed, Oct 26, 2005 at 05:35:41AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> Update here: Sven sent me a cool 4 line shell script that has the
> basics. Next thing I know, and I was dumped into a boring presentation
> -- so I turned it into a more complete Perl script. Still incomplete &
> extremely untested, but showing the basics.
>
> Give me a couple more boring presentations and we'll be done ;-)
Can I then import from the CVS incrementally later? I guess from the
cvsimport code that it just tries to always import everything but the
already imported commits get the same hashes so it magically imports
"incrementally"... (The code could use some descriptive comments, it is
rather spaggetish.)
If someone really desperately needs this, BTW, you might be able to
merge two Monotone branches (.git and .cvssync) to get two-way
incremental GIT and CVS interface, and then do that through Monotone.
;-))
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [RFC] GIT paths
From: Andreas Ericsson @ 2005-10-26 8:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzkwajrv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>>
>>The userdir is (with my previous patch) only expanded if the path starts
>>with a tilde.
>
>
> I do not necessarily consider that a feature; see next item.
>
>
>>It must remove the leading slash for this syntax:
>>
>> ssh://host.xz/~junio/repo
>>
>>Otherwise it would be passed as /~junio/repo to the remote end and no
>>~user interpolation would be done.
>
>
> Not necessarily. Having the remote end interpret "/~user" and
> "~user" the same way might make things more consistent;
Except that the shell interprets ~ and /~ differently, so "consistent"
would depend on what we're consistent with.
There's also the fact that shell-scripts won't work on the remote end if
git_connect() maintains the leading slash. This doesn't matter at
present, but I think it'd be better to keep all doors open. Having the
trivial addendum on the client side also helps keeping the server-side
nice and simple.
> in other
> words, "http://host/~user" is not spelled "http://host~user".
>
True. I meant for this to be invisible to the users ofcourse, with
git_connect() having some snippet such as this.
if(use_ssh || use_git && (*path == '/' && *(path + 1) == '~')
*path++ = '\0';
else
copy_path();
>
>>I'd say make it invoke the programs with the canonicalized path. As you
>>say, git-daemon has to verify that it's a proper git repo and in the
>>whitelist anyway so I think it would be silly to add extra complexity to
>>upload-pack and receive-pack.
>
>
> Yeah, I tend to agree here.
>
>
>>> - Give --server-root=/path/to/root flag to programs...
>>
>>If we stick with canonicalized paths I suppose this can be dropped.
>
>
> Sounds good.
>
>
I'll get busy then.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Johannes Schindelin @ 2005-10-26 8:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510261031400.7424@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Wed, 26 Oct 2005, Johannes Schindelin wrote:
> On Tue, 25 Oct 2005, Junio C Hamano wrote:
>
> > Sorry, but I am not very happy about this patch. "local"
> > bashism aside, doesn't this spawn expr for every unpacked
> > object?
>
> Aargh! I had the impression "expr" was a builtin... Just forget about
> the patch, okay?
This patch should be better:
diff --git a/git-count-objects.sh b/git-count-objects.sh
index 843d2fd..ceb1ff2 100755
--- a/git-count-objects.sh
+++ b/git-count-objects.sh
@@ -2,6 +2,19 @@
. git-sh-setup
+case $SHELL in
+*bash)
+ function dc () {
+ while read a b; do
+ case $a,$b in
+ 0,) result=0;;
+ *,+) result=$(($result+$a));;
+ p,) echo $result
+ esac
+ done
+ }
+esac
+
echo $(find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null | wc -l) objects, \
$({
echo 0
^ permalink raw reply related
* Re: Towards CVS code-exchange and gateways
From: Martin Langhoff @ 2005-10-26 9:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20051026085302.GF30889@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]
On 10/26/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Oct 26, 2005 at 05:35:41AM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> > Update here: Sven sent me a cool 4 line shell script that has the
> > basics. Next thing I know, and I was dumped into a boring presentation
> > -- so I turned it into a more complete Perl script. Still incomplete &
> > extremely untested, but showing the basics.
> >
> > Give me a couple more boring presentations and we'll be done ;-)
>
> Can I then import from the CVS incrementally later? I guess from the
> cvsimport code that it just tries to always import everything but the
> already imported commits get the same hashes so it magically imports
> "incrementally"... (The code could use some descriptive comments, it is
> rather spaggetish.)
Yes -- the cvsimport script does incremental imports. If you use
cvsimport to bring in the commits from CVS, you must treat those
branches as "read only". But you can open new heads from them and do
your "local" work there.
That's what we do with Moodle, as you can see here:
http://locke.catalyst.net.nz/gitweb?p=moodle.git;a=summary the
branches in uppercase are imported from CVS by a cronjob. The branches
that begin with "mdl" open off those, and we merge the cvs updates
often.
The goal for this script that I'm drafting is to be able to push
commits back into cvs in a format that maximises the chance of
git-cherry identifying them when they are echoed back (and thus
avoiding bogus conflicts).
> If someone really desperately needs this, BTW, you might be able to
> merge two Monotone branches (.git and .cvssync) to get two-way
> incremental GIT and CVS interface, and then do that through Monotone.
> ;-))
I'm really scared by the concept ;-)
The script has moved forward quite a bit -- and I suspect it might
even work. Current (untested) version attached.
cheers,
martin
[-- Attachment #2: git-cvsapplycommmit.perl --]
[-- Type: application/octet-stream, Size: 4013 bytes --]
#!/usr/bin/perl -w
use strict;
use Getopt::Std;
use File::Temp qw(tempdir);
unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
die "GIT_DIR is not defined or is unreadable";
}
our ($opt_h, $opt_p);
getopt('hp');
$opt_h && usage();
die "Need at least one commit identifier!" unless @ARGV;
# setup a tempdir
our ($tmpdir, $tmpdirname) = tempdir('git-cvsapplycommit-XXXXXX',
TMPDIR => 1,
CLEANUP => 1);
# resolve target commit
my $commit;
$commit = pop @ARGV;
$commit = `git-rev-parse --verify "$commit"^0"`;
chomp $commit;
if ($?) {
die "The commit reference did not resolve!";
}
# resolve what parent we want
my $parent;
if (@ARGV) {
$parent = pop @ARGV;
$parent = `git-rev-parse --verify "$parent"^0"`;
chomp $parent;
if ($?) {
die "The parent reference did not resolve!";
}
}
# find parents from the commit itself
my @parents = `git-cat-file commmit $commit | grep -E '^parent \\w{40}\$' | sed -e 's/^parent //'`;
@parents = map { chomp } @parents;
if ($parent) {
# double check that it's a valid parent
foreach my $p (@parents) {
my $found;
if ($p eq $parent) {
$found = 1;
last;
}; # found it
die "Did not find $parent in the parents for this commit!";
}
} else { # we don't have a parent from the cmdline...
if (@parents == 1) { # it's safe to get it from the commit
$parent = $parents[0];
} else { # or perhaps not!
die "This commit has more than one parent -- please name the parent you want to use explicitly";
}
}
# grab the commit message
`git-cat-file commit $commit | sed -e '1,/^$/d' > .msg`;
$? && die "Error extraction the commit message";
my @files = `git-diff-tree -r $parent $commit | cut -f 2`;
$? && die "Error in git-diff-tree";
@files = map { chomp } @files;
# check that the files are clean and up to date according to cvs
my $dirty;
foreach my $f (@files) {
# TODO:we need to handle removed in cvs and/or new (from git)
my $status = `cvs -q status "$f" | grep '^File: '`;
unless ($status =~ m/Status: Up-to-date$/) {
$dirty = 1;
warn "File $f not up to date in your CVS checkout!\n";
}
}
if ($dirty) {
die "Exiting: your CVS tree is not clean for this merge.";
}
###
### NOTE: if you are planning to die() past this point
### you MUST call cleanupcvs(@files) before die()
###
print "'Patching' binary files\n";
my @bfiles = `git-diff-tree -p $parent $commit | grep '^Binary'`;
@bfiles = map { chomp } @bfiles;
foreach my $f (@bfiles) {
# check that the file in cvs matches the "old" file
# extract the file to $tmpdir and comparre with cmp
my $tree = `git-rev-parse $parent^{tree} `;
chomp $tree;
my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
chomp $blob;
`git-cat-file blob $blob > $tmp/blob`;
`cmp -q $f $tmp/blob`;
if ($?) {
warn "Binary file $f in CVS does not match parent.\n";
$dirty = 1;
next;
}
# replace with the new file
`git-cat-file blob $blob > $f`;
# TODO: something smart with file modes
}
if ($dirty) {
cleanupcvs(@files);
die "Exiting: Binary files in CVS do not match parent";
}
## apply non-binary changes
my $fuzz = $opt_p ? 0 : 2;
print "Patching non-binary files\n";
print `(git-diff-tree -p $1 | patch -p1 -F $fuzz ) 2>&1`;
if ($?) {
cleanupcvs(@files);
die "Exiting: Patch did not succeed -- you will have to apply this patch manually";
}
print "Commit to CVS\n";
my $commitfiles = join(' ', @files);
print `cvs commit -F .msg $commitfiles 2>&1`;
if ($?) {
cleanupcvs(@files);
die "Exiting: The commit did not succeed";
}
print "Committed successfully to CVS\n";
sub usage {
print STDERR <<END;
Usage: GIT_DIR=/path/to/.gi ${\basename $0} # fetch/update GIT from CVS
[-h] [-p] [ parent ] commit
END
exit(1);
}
# ensure cvs is clean before we die
sub cleanupcvs {
my @files = @_;
foreach my $f (@files) {
`cvs -q update -C "$f"`;
if ($?) {
warn "Warning! Failed to cleanup state of $f\n";
}
}
}
^ permalink raw reply
* Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension
From: Alex Riesen @ 2005-10-26 9:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0510261041100.7424@wbgn013.biozentrum.uni-wuerzburg.de>
On 10/26/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Could you please try the patch I sent with the subject "[PATCH]
> > > fetch/upload: Fix corner case with few revs"? Your output looks exactly
> > > like what I fixed with that patch.
> >
> > I couldn't at the moment. Do you still need a test?
>
> If you have time and can test it, yes, please.
>
Will try. Which patch is it?
^ permalink raw reply
* Re: git-rev-list: make --dense the default (and introduce "--sparse")
From: Junio C Hamano @ 2005-10-26 9:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510251525540.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 25 Oct 2005, Linus Torvalds wrote:
>>
>> This actually does three things:
>>
>> - make "--dense" the default for git-rev-list...
Heads up.
I have not looked closely into what exactly, but the fourth
thing this does might be to break git-send-pack.
I usually use the tip of "pu" myself, but for tonight, I am
excluding the fetch-pack/upload-pack changes from Johannes when
building git for my own use, and using somewhere in the middle
of "pu" branch. With this "--dense default" patch,
git-send-pack seems to send too few objects. With this patch
reverted, git-send-pack seems to work again.
+ [build] Revert "git-rev-list: make --dense the default (and introduce "--sparse")"
++ [pu^] Merge branch 'js-fat'
++ [pu^^2] Test in git-init-db if the filemode can be trusted
++ [pu~2] Merge branches 'cache-pack', 'lazy-subdir' and 'lt-dense'
++ [pu~2^4] git-rev-list: make --dense the default (and introduce "--sparse")
++ [pu~2^3] Create object subdirectories on demand (phase II)
++ [pu~2^2] Allow caching of generated pack for full cloning.
+++ [master] upload-pack: tighten request validation.
I'll take a look at the issue in the morning unless somebody
else beats me to it.
^ 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