* RE: linux-2.6.git mirror
From: Linus Torvalds @ 2007-10-18 23:24 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1, Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270168517F@az33exm24.fsl.freescale.net>
On Thu, 18 Oct 2007, Medve Emilian-EMMEDVE1 wrote:
>
> > > Is this something I should be worried about?
> >
> > No, but if it still happens with a newer git, holler.
>
> I tested this with Junio's latest master and a couple of stable releases
> from the maint branch with the same result.
Ok, what is going on is:
- append_fetch_head() looks up the SHA1 for all heads (including tags):
if (get_sha1(head, sha1))
return error("Not a valid object name: %s", head);
- it then wants to check if it's a candidate for merging (because
fetching also does the whole "list which heads to merge" in case it is
going to be part of a "pull"):
commit = lookup_commit_reference(sha1);
if (!commit)
not_for_merge = 1;
- and that "lookup_commit_reference()" is just very vocal about the case
where it fails. It really shouldn't be, and it shouldn't affect the
actual end result, but that basically explains why you get that scary
warning.
In short, the warning is just bogus, and should be harmless, but I agree
that it's ugly. I think the appended patch should fix it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
And yes, I think this should go into Shawns tree of fixes, assuming that
Emil confirms that it fixes it for him.
Linus
builtin-fetch--tool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index 1e43d79..e26817d 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -131,7 +131,7 @@ static int append_fetch_head(FILE *fp,
if (get_sha1(head, sha1))
return error("Not a valid object name: %s", head);
- commit = lookup_commit_reference(sha1);
+ commit = lookup_commit_reference_gently(sha1, 1);
if (!commit)
not_for_merge = 1;
^ permalink raw reply related
* Re: Problem with git-svnimport
From: Steven Grimm @ 2007-10-18 23:06 UTC (permalink / raw)
To: Jan Hudec; +Cc: VAUCHER Laurent, git
In-Reply-To: <20071018180916.GK26127@efreet.light.src>
Jan Hudec wrote:
> git-svnimport is obsoleted (or mostly so) by git-svn. Look at that, please.
>
This has been asked before, but I don't think there was a good answer:
What remaining features does git-svnimport have that git-svn doesn't? It
would be nice to not have two such tools if one of them doesn't actually
add any value. Can we safely deprecate git-svnimport in the next release?
-Steve
^ permalink raw reply
* Re: git-svn help for authorsfile
From: Sam Vilain @ 2007-10-18 22:53 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git
In-Reply-To: <4b3406f0710172326y29c73a79x648ef98208adba78@mail.gmail.com>
Dongsheng Song wrote:
> In general, all svn projects share the same authorsfile, e.g.
>
> [svn]
> authorsfile=/path/to/authorsfile
>
> [svn-remote "project-a"]
> url = http://server.org/svn
> branches = branches/*/project-a:refs/remotes/project-a/branches/*
> tags = tags/*/project-a:refs/remotes/project-a/tags/*
> trunk = trunk/project-a:refs/remotes/project-a/trunk
>
> [svn-remote "project-b"]
> url = http://server.org/svn
> branches = branches/*/project-b:refs/remotes/project-b/branches/*
> tags = tags/*/project-b:refs/remotes/project-b/tags/*
> trunk = trunk/project-b:refs/remotes/project-b/trunk
>
> But if project-a and project-b has same svn id, map to different
> user/email, how do I do?
>
> Can we move authorsfile from svn to svn-remote section ?
Dongsheng,
If you come up with a patch that allows this, then I'm sure it can be
considered; below is what I imagine it would minimally require. However,
I haven't tested this at all so please treat with caution.
Subject: [PATCH] git-svn: allow per-remote authors map
Allow the authors map to be overridden on a per-remote basis.
---
git-svn.perl | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index c015ea8..47f524d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5,7 +5,7 @@ use warnings;
use strict;
use vars qw/ $AUTHOR $VERSION
$sha1 $sha1_short $_revision
- $_q $_authors %users/;
+ $_q %users/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '@@GIT_VERSION@@';
@@ -65,7 +65,7 @@ my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache );
my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
- 'authors-file|A=s' => \$_authors,
+ 'authors-file|A=s' => \$Git::SVN::_authors,
'repack:i' => \$Git::SVN::_repack,
'noMetadata' => \$Git::SVN::_no_metadata,
'useSvmProps' => \$Git::SVN::_use_svm_props,
@@ -142,7 +142,7 @@ my %cmd = (
'oneline' => \$Git::SVN::Log::oneline,
'show-commit' => \$Git::SVN::Log::show_commit,
'non-recursive' => \$Git::SVN::Log::non_recursive,
- 'authors-file|A=s' => \$_authors,
+ 'authors-file|A=s' => \$Git::SVN::authors,
'color' => \$Git::SVN::Log::color,
'pager=s' => \$Git::SVN::Log::pager,
} ],
@@ -187,7 +187,6 @@ exit 1 if (!$rv && $cmd && $cmd ne 'log');
usage(0) if $_help;
version() if $_version;
usage(1) unless defined $cmd;
-load_authors() if $_authors;
# make sure we're always running
unless ($cmd =~ /(?:clone|init|multi-init)$/) {
@@ -748,6 +747,7 @@ sub file_to_s {
# '<svn username> = real-name <email address>' mapping based on git-svnimport:
sub load_authors {
+ my $_authors = shift;
open my $authors, '<', $_authors or die "Can't open $_authors $!\n";
my $log = $cmd eq 'log';
while (<$authors>) {
@@ -891,7 +891,7 @@ package Git::SVN;
use strict;
use warnings;
use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
- $_repack $_repack_flags $_use_svm_props $_head
+ $_repack $_repack_flags $_use_svm_props $_head $_authors
$_use_svnsync_props $no_reuse_existing $_minimize_url/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
@@ -993,6 +993,8 @@ sub fetch_all {
$remotes ||= read_all_remotes();
my $remote = $remotes->{$repo_id} or
die "[svn-remote \"$repo_id\"] unknown\n";
+ my $authors = $remote->{authors} || $_authors;
+ load_authors($authors) if $authors;
my $fetch = $remote->{fetch};
my $url = $remote->{url} or die "svn-remote.$repo_id.url not defined\n";
my (@gs, @globs);
@@ -1050,6 +1052,8 @@ sub read_all_remotes {
die "The '*' glob character must be the last ",
"character of '$g'\n";
}
+ } elsif (m!^(.+)\.authors=\s*(.*)\s*$!) {
+ $r->{$1}->{authors} = $2;
}
}
$r;
--
1.5.3.2.3.g2f2dcc-dirty
^ permalink raw reply related
* Re: [PATCH] Remove link to the survey from the git home page.
From: Petr Baudis @ 2007-10-18 22:51 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Jonas Fonseca, git
In-Reply-To: <4d8e3fd30710180830l30e2e371r4cadee0c8ff2e82f@mail.gmail.com>
Hi,
On Thu, Oct 18, 2007 at 05:30:58PM +0200, Paolo Ciarrocchi wrote:
> On 10/18/07, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> > On 10/16/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > > As far as I know the survey is close so it makes sense to remove the link/text from the home page.
> >
> > Pasky has provided me with write access to git-homepage.git and to test
> > the setup I have applied this change, which seemed to have been overlooked.
> >
> > Pasky, maybe you can update git.or.cz and perhaps also remove the link
> > from the front page of repo.or.cz? :)
>
> Pasky, Jonas,
> I cannot enter IRC at the moment so I'm sending here a note with my proposal.
>
> I recently got interested in drupal and I wondered whether it would a
> good idea to try to play in a sandbox with a drupal installation and
> somehow compare the actual static homepage with an alternative drupal
> based portal.
>
> What do you think?
to be honest, I'm kinda sceptical. It's not really clear at all to me
what added value would drupal bring, and there're plenty of downsides
(mainly around various additional maintenance costs) to balance out.
I probably wouldn't be able to tend for a drupal installation
personally, since I barely get time to maintain even the current
simplistic web page.
(But it isn't required that *I* run the homepage. :-) And I certainly
wouldn't want to stifle "innovation".)
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: git on afs (fwd)
From: Brandon Casey @ 2007-10-18 22:48 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; format=flowed; charset=X-UNKNOWN, Size: 1077 bytes --]
Added the mailing list back in.
On Thu, 18 Oct 2007, Todd T. Fries wrote:
> link() returns -1 errno 17 File exists on afs.
>
> To further muddy the waters, linking within the same dir is ok,
> linking outside the same dir is not:
>
> todd@ispdesk/p6 ~/tmp¦61$ mkdir dir
> todd@ispdesk/p6 ~/tmp¦62$ touch a
> todd@ispdesk/p6 ~/tmp¦63$ ln a b
> todd@ispdesk/p6 ~/tmp¦64$ ls -l a b
> -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 a
> -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 b
> todd@ispdesk/p6 ~/tmp¦65$ ls -li a b
> 2068032 -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 a
> 2068032 -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 b
> todd@ispdesk/p6 ~/tmp¦66$ ln a dir/b
> ln: dir/b: File exists
> todd@ispdesk/p6 ~/tmp¦67$ echo $?
That error is just bogus on afs. If it returned a sane
error, things would just work.
But, looks like afs only supports linking within the same
directory: http://www.angelfire.com/hi/plutonic/afs-faq.html
So, you could look into whether the temp file can be sanely
created in the same directory as the final filename.
-brandon
^ permalink raw reply
* Re: git on afs
From: Linus Torvalds @ 2007-10-18 22:47 UTC (permalink / raw)
To: Todd T. Fries; +Cc: git
In-Reply-To: <20071018203106.GA13518@fries.net>
On Thu, 18 Oct 2007, Todd T. Fries wrote:
>
> 2) git presumes that DTYPE(de) != DT_DIR .. means the dirent is not a dir
> this is not true for afs
That's a major bug, and has nothing to do with AFS. Oops.
If you look just a bit lower, you'll see that just a few lines down, git
handles DT_UNKNOWN correctly, and just does a lstat() on it as required. I
guess that logic should be moved up, or alternatively the exclude logic
should be moved down.
Your patch looks ok, but at the same time, I don't think it's really the
right thing to do, since it now does that lstat() twice.
Linus
^ permalink raw reply
* RE: linux-2.6.git mirror
From: Medve Emilian-EMMEDVE1 @ 2007-10-18 22:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710181518120.26902@woody.linux-foundation.org>
Hi Linus,
> > Is this something I should be worried about?
>
> No, but if it still happens with a newer git, holler.
I tested this with Junio's latest master and a couple of stable releases
from the maint branch with the same result. In my ignorance I suspected
the build infrastructure so I tried different gcc versions (4.x and 3.x)
and optimization levels (including -O0) different libraries, etc. that I
had on a few machines around here. The result was the same.
What worried me is that I think I traced the source of the error message
in commit.c and in both two possible places from where the message could
come the processing flow seems to be cut shorter because of this.
Thanks for your reply,
Emil.
^ permalink raw reply
* Re: Subversion developer: svn is for dumb people
From: Sam Vilain @ 2007-10-18 22:40 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <47176CE0.7030609@midwinter.com>
Steven Grimm wrote:
> some of his specific arguments
> about DVCS are on the bogus side. "Centralized systems encourage code
> reviews," for one --
I heard this from the core Subversion team too. The hypothesis is that
by forcing groups to be unable to proceed without continually rebasing
to each other's work, that collaboration is enhanced.
I think any argument which states that a restrictive system is better
than a non-restrictive system, when the non-restrictive system can be
used in the same way as the restrictive system (either with
configuration, or agreement with the committers) is quite bizarre.
Sam.
^ permalink raw reply
* Re: [PATCH] git-blame shouldn't crash if run in an unmerged tree
From: Linus Torvalds @ 2007-10-18 22:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, B.Steinbrink
In-Reply-To: <20071018063407.GA28861@spearce.org>
On Thu, 18 Oct 2007, Shawn O. Pearce wrote:
>
> I'm applying this patch to my maint tree tonight as it does resolve
> the issue for now. What surprised me was the file that we were
> crashing out on wasn't even the file we wanted to get the blame
> data for. :-\
Please feel free to add a Signed-off-by: there. I guess I didn't add it in
the original email, because I wasn't sure if I'd have the energy to see if
I could just remove the clearing of "ce_mode". I never did.
That whole "ce->ce_mode = 0" thing is really hacky, and we use it for two
totally different things ("git read-tree" uses it for "delete this entry",
and reading the index uses it when you ask for only merged entries). Bad
form, and not very logical.
Linus
^ permalink raw reply
* Re: linux-2.6.git mirror
From: Linus Torvalds @ 2007-10-18 22:26 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2701684C77@az33exm24.fsl.freescale.net>
On Tue, 16 Oct 2007, Medve Emilian-EMMEDVE1 wrote:
>
> $ git remote update
> Updating origin
> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
Interesting. Something seems to be assuming that all tags are commits.
Which is not true. You can have (and the kernel repo does this) a tag
pointing to a pure tree state (with no history), or as in the case of git
itself, there's a tag pointing to a blob that contains Junio's public key.
> The situation is similar with the git tree:
>
> error: Object a0e7d36193b96f552073558acf5fcc1f10528917 is a blob, not a commit
Yeah, same thing.
> Is this something I should be worried about?
No, but if it still happens with a newer git, holler.
Linus
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: Sam Vilain @ 2007-10-18 22:04 UTC (permalink / raw)
To: cho; +Cc: git
In-Reply-To: <ff7m2j$2eu$2@ger.gmane.org>
cho wrote:
> I've surprised myself but yes, there is a simple testcase.
>
> svnadmin create repo
> svn checkout file://$PWD/repo checkout
> cd checkout/
> svn mkdir trunk tags branches
> svn ci -m 'Standard svn layout.'
> cd trunk/
> svn mkdir doc
> touch doc/README
> svn add doc/README
> svn ci -m 'Add README.'
> cd ..
> svn mv trunk/ branches/oldtrunk
> svn ci -m 'Moved trunk.'
> svn mkdir trunk
> svn ci -m 'New trunk.'
> cd trunk/
> touch THIS_IS_THE_NEW_TRUNK
> svn add THIS_IS_THE_NEW_TRUNK
> svn ci -m 'Add marker.'
> cd ../..
> git svn clone file://$PWD/repo --stdlayout git-clone
> cd git-clone/
> tree
>
> So the testcase basically involves moving the trunk.
> git-svn gets very confused and keeps a mixture of the old and new trunk.
Were you using --follow-parent or not?
Sam.
^ permalink raw reply
* Re: git push bug?
From: Johannes Schindelin @ 2007-10-18 22:00 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Steffen Prohaska, git
In-Reply-To: <1192725116.4954.7.camel@gentoo-jocke.transmode.se>
Hi,
On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> On Thu, 2007-10-18 at 17:21 +0100, Johannes Schindelin wrote:
>
> > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> >
> > > Seems like it is a bit too easy to make mistakes here. Why can I
> > > delete a branch with :linus but not create one with linus:linus?
> >
> > I wonder why you bother with the colon at all. Just
> >
> > git push <remote> linus
> >
> > and be done with it. The colon is only there to play interesting
> > games, not something as simple as "push this branch" or "push this
> > tag".
>
> First, I didn't know that I could do that. Secondly, I was also looking
> do v2.6.23:linus refspecs
First, then our documentation could be better. How?
Second, why not "git checkout -b linus v2.6.23 && git push origin linus"?
Ciao,
Dscho
^ permalink raw reply
* Re: git push bug?
From: Johannes Schindelin @ 2007-10-18 21:58 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Joakim Tjernlund, git
In-Reply-To: <9EEDF284-22BE-44BF-A9B8-116407784BEB@zib.de>
Hi,
On Thu, 18 Oct 2007, Steffen Prohaska wrote:
> On Oct 18, 2007, at 6:21 PM, Johannes Schindelin wrote:
>
> > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> >
> > > Seems like it is a bit too easy to make mistakes here. Why can I delete
> > > a branch with :linus but not create one with linus:linus?
> >
> > I wonder why you bother with the colon at all. Just
> >
> > git push <remote> linus
> >
> > and be done with it. The colon is only there to play interesting games,
> > not something as simple as "push this branch" or "push this tag".
>
> But you need a full refspec starting with 'refs/heads/' if you want to
> create a new branch on the remote side.
No. Not if the name is the same on the local side.
Ciao,
Dscho
^ permalink raw reply
* Re: git on afs
From: Brandon Casey @ 2007-10-18 21:57 UTC (permalink / raw)
To: Todd T. Fries; +Cc: git
In-Reply-To: <20071018203106.GA13518@fries.net>
On Thu, 18 Oct 2007, Todd T. Fries wrote:
> 2) git presumes that DTYPE(de) != DT_DIR .. means the dirent is not a dir
> this is not true for afs
>
> I have been using this to sync several git trees, including linux-2.6 for the
> past week without issues writing to a local afs server.
>
> What do you guys think?
>
> diff --git a/dir.c b/dir.c
> index eb6c3ab..a3e53a5 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -487,9 +487,19 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
> && in_pathspec(fullname, baselen + len, simplify))
> dir_add_ignored(dir, fullname, baselen + len);
> if (exclude != dir->show_ignored) {
> - if (!dir->show_ignored || DTYPE(de) != DT_DIR) {
> + if (!dir->show_ignored)
you're missing an open bracket ^^^
> continue;
> }
or delete this one ^^^
> + if (DTYPE(de) == DT_UNKNOWN) {
> + struct stat st;
> + if (lstat(fullname, &st))
> + continue;
> + if (!S_ISDIR(st.st_mode))
> + continue;
> + } else {
> + if (DTYPE(de) != DT_DIR)
> + continue;
> + }
> }
>
> switch (DTYPE(de)) {
seems sane to me.
If no one else brings up any issues, you should retest and submit
a signed patch with a good comment. Use -s with git-commit.
Then git-format-patch will produce the proper output.
-brandon
^ permalink raw reply
* Re: git on afs
From: Brandon Casey @ 2007-10-18 21:28 UTC (permalink / raw)
To: Todd T. Fries; +Cc: git
In-Reply-To: <20071018203106.GA13518@fries.net>
On Thu, 18 Oct 2007, Todd T. Fries wrote:
> 1) git presumes that link() works fine across subdirs; in afs land,
> hardlinks do not succeed ever
I think this already falls back to rename() on failure.
Take a look at move_temp_to_file(), this is the only
place that calls link_temp_to_file().
link() on afs returns non-zero? and not EEXIST right?
-brandon
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.
From: Robin Rosenberg @ 2007-10-18 21:12 UTC (permalink / raw)
To: Marco Costalba
Cc: pete, piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <e5bfff550710171626h733228aw7a251746d2b43c63@mail.gmail.com>
torsdag 18 oktober 2007 skrev Marco Costalba:
> On 10/17/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> >
> > You could avoid the temporary files if you just pipe the diff to kompare. That
> > would require an option to tell qgit that the external viewer can read a git diff.
> >
> > At the time qgit 1.5 was written, kompare could not handle git diffs.
> >
>
> So does the other tools I have checked at that time.
>
> But I don't know if this fixes the problem of slowness reported. A
> little test Pete may do is just as I have written in the former email:
> try to save the big files that cause troubles where he prefers and run
> Kompare on them directly from the command line.
>
> Is kompare faster? If no probably the 'pipe' technique will not solve
> the problem and shrinks the applicability of the external diff
> launcher to tools that handle diffs directly.
kompare is pretty fast. Obviously not as fast as less.
"git diff HEAD HEAD~1000|kompare -" takes less than two seconds (hot cache)
on my machine. With small diffs it is almost instantaneous.
-- robin
^ permalink raw reply
* git on afs
From: Todd T. Fries @ 2007-10-18 20:31 UTC (permalink / raw)
To: git
I have always been frustrated by trying git on afs.
The other day I finally decided to look into why.
Looks like two reasons caused my frustrations.
1) git presumes that link() works fine across subdirs; in afs land,
hardlinks do not succeed ever
2) git presumes that DTYPE(de) != DT_DIR .. means the dirent is not a dir
this is not true for afs
I have been using this to sync several git trees, including linux-2.6 for the
past week without issues writing to a local afs server.
What do you guys think?
diff --git a/dir.c b/dir.c
index eb6c3ab..a3e53a5 100644
--- a/dir.c
+++ b/dir.c
@@ -487,9 +487,19 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
&& in_pathspec(fullname, baselen + len, simplify))
dir_add_ignored(dir, fullname, baselen + len);
if (exclude != dir->show_ignored) {
- if (!dir->show_ignored || DTYPE(de) != DT_DIR) {
+ if (!dir->show_ignored)
continue;
}
+ if (DTYPE(de) == DT_UNKNOWN) {
+ struct stat st;
+ if (lstat(fullname, &st))
+ continue;
+ if (!S_ISDIR(st.st_mode))
+ continue;
+ } else {
+ if (DTYPE(de) != DT_DIR)
+ continue;
+ }
}
switch (DTYPE(de)) {
diff --git a/sha1_file.c b/sha1_file.c
index 83a06a7..1b93322 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1961,7 +1961,7 @@ static int link_temp_to_file(const char *tmpfile, const char *filename)
int ret;
char *dir;
- if (!link(tmpfile, filename))
+ if (!rename(tmpfile, filename))
return 0;
/*
@@ -1980,7 +1980,7 @@ static int link_temp_to_file(const char *tmpfile, const char *filename)
return -2;
}
*dir = '/';
- if (!link(tmpfile, filename))
+ if (!rename(tmpfile, filename))
return 0;
ret = errno;
}
--
Todd Fries .. todd@fries.net
_____________________________________________
| \ 1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX)
| "..in support of free software solutions." \ 250797 (FWD)
| \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt
^ permalink raw reply related
* [PATCH] attr: fix segfault in gitattributes parsing code
From: Steffen Prohaska @ 2007-10-18 20:02 UTC (permalink / raw)
To: spearce; +Cc: git, Steffen Prohaska
git may segfault if gitattributes contains an invalid
entry. A test is added to t0020 that triggers the segfault.
The parsing code is fixed to avoid the crash.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
attr.c | 5 ++++-
t/t0020-crlf.sh | 7 +++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/attr.c b/attr.c
index 92704a3..741db3b 100644
--- a/attr.c
+++ b/attr.c
@@ -209,8 +209,11 @@ static struct match_attr *parse_attr_line(const char *line, const char *src,
num_attr = 0;
cp = name + namelen;
cp = cp + strspn(cp, blank);
- while (*cp)
+ while (*cp) {
cp = parse_attr(src, lineno, cp, &num_attr, res);
+ if (!cp)
+ return NULL;
+ }
if (pass)
break;
res = xcalloc(1,
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 0807d9f..62bc4bb 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -371,4 +371,11 @@ test_expect_success 'in-tree .gitattributes (4)' '
}
'
+test_expect_success 'invalid .gitattributes (must not crash)' '
+
+ echo "three +crlf" >>.gitattributes &&
+ git diff
+
+'
+
test_done
--
1.5.3.4.1261.g626eb
^ permalink raw reply related
* Application to install man pages.
From: Evan Carroll @ 2007-10-18 18:59 UTC (permalink / raw)
To: git
This is a one liner but might help for simply a quick install of the
git manpages.
>From f5797d786fd4a6f9633054bb0f0ce894a06d6650 Mon Sep 17 00:00:00 2001
From: root <root@x60s.(none)>
Date: Thu, 18 Oct 2007 13:45:16 -0500
Subject: [PATCH] install_man.sh script which installs the man pages
---
install_man.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
create mode 100755 install_man.sh
diff --git a/install_man.sh b/install_man.sh
new file mode 100755
index 0000000..b722425
--- /dev/null
+++ b/install_man.sh
@@ -0,0 +1,2 @@
+#/bin/sh
+ cp -R --copy-contents ./man* /usr/local/man
--
1.5.3.4.206.g58ba4
I was also wondering if it might be useful to have a command in the
master branch of the git repo that switches branches and installs the
man pages.. possibly as run in the makefile if .git exists then switch
branches, and run install_man.sh. Just an idea.
--
Evan Carroll
System Lord of the Internets
me@evancarroll.com
832-445-8877
^ permalink raw reply related
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Jan Hudec @ 2007-10-18 18:54 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Morten Welinder, git, spearce
In-Reply-To: <DC3D43FD-F03D-4E0A-9C2B-DE56F9C16D60@silverinsanity.com>
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
On Wed, Oct 17, 2007 at 11:16:34 -0400, Brian Gernhardt wrote:
>
> On Oct 17, 2007, at 10:39 AM, Morten Welinder wrote:
>
>>> made it into your repo. It fixes test failures on my machine that have
>>> been plauging me for months.
>>
>> That sounds more like a reason to fix the test. "die" is the perl
>> standard way of reporting an error. It will print the error message
>> on stderr, not on stdout like your version does.
>>
>> IMHO, of course.
>
> The problem is that die can exit with varying exit codes, and exit codes >=
> 128 make the test suite assume something has gone wrong with the test. In
> particular, because $! (errcode) and $? (previous shell command return) are
> both 0, it returns 255. Or at least that's how it works out on my system.
> I'm not sure why it doesn't do that on others.
>
> But the test is expecting a failure here and it appears to be failing in
> the correct way, just with an error code test-lib.sh doesn't like. I asked
> on list the best way to fix it and Frank Lichtenheld said (and nobody
> objected until now) that this was the best way to fix it.
>
> Also, the not printing on STRERR is identical to another section of code
> just below mine:
>
>> unless ($line eq 'anonymous') {
>> print "E Only anonymous user allowed via pserver\n";
>> print "I HATE YOU\n";
>> exit 1;
>> }
>
> However, amending my patch to print to STDERR is not difficult.
Hm. There are two kinds of errors in git-cvsserver and they should be handled
differently.
If the error is an invalid request (like the quoted one), there should be
normal print, to STDOUT, starting with "E", because it's an error message
that should be sent to the client.
On the other hand if the error is internal error in the script or it's
configuration, than the error should probably be reported via die, *without*
E at the begining (it will be prefixed with location anyway). Such message
will probably end up in the log rather than sent to the client.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Subversion developer: svn is for dumb people
From: Jeff King @ 2007-10-18 18:33 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <47176CE0.7030609@midwinter.com>
On Thu, Oct 18, 2007 at 07:25:36AM -0700, Steven Grimm wrote:
> Okay, my summary is slightly facetious, but that's basically the gist of
> what he's saying: you should choose Subversion rather than a DVCS because
> most of your users won't be smart enough to use the better tool.
An interesting point he brings up (which I think is totally bogus) is
(paraphrased): "DVCS systems encourage people to work in isolation and
then patch-bomb the upstream."
But I think it's quite the opposite. He compares two scenarios: in
$DVCS, the user forks, works quietly in their cave for a few weeks, and
then produces a result. With a centralized VCS, the user gets a private
branch, and people keep up with their work as it progresses.
This isn't realistic for two reasons:
1. Contributors to projects now using DVCS systems _weren't_ using SVN
or CVS in this way before (presumably because the effort in getting
private branches set up in a central repository was too much -- if
I want to hack on a project, I want to do it _now_, not after I
have gotten approval to use the VCS by the maintainer). Instead,
they sat in their cave using primitive tools like 'diff' and
'patch' until they patch-bombed the upstream.
2. DVCS systems (well, git, at least) focus on workflows that allow
for quick communication and code review. Patches are a first-class
item in git, which means that
- every change is on the mailing list for review
- work-in-progress patches are easy to post, easy for reviewers
to read, easy for reviewers to apply, and, if accepted,
easy for the maintainer to apply
-Peff
^ permalink raw reply
* Re: Problem with git-svnimport
From: Jan Hudec @ 2007-10-18 18:09 UTC (permalink / raw)
To: VAUCHER Laurent; +Cc: git
In-Reply-To: <55DDB08CC9CD2941A70E8D626789A2C906A4031A@ec8l7ljvo9h5dde.hosting.exch>
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]
On Tue, Oct 16, 2007 at 14:30:30 +0200, VAUCHER Laurent wrote:
> Hi.
>
> Trying to convert a svn repository to git, I encountered the following
> error:
>
> Use of uninitialized value in hash element at /usr/bin/git-svnimport
> line 534.
>
> Line 534 reads:
> my $gitrev = $branches{$srcbranch}{$therev};
>
> I have installed packages git-core and git-svn on Ubuntu. These
> package have versions: "1:1.5.2.5-2-feisty1"
>
> The tool seems to choke on tags or branches with special characters
> (underscore, for instance).
git-svnimport is obsoleted (or mostly so) by git-svn. Look at that, please.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Jeff King @ 2007-10-18 18:08 UTC (permalink / raw)
To: Steven Grimm
Cc: Brian Gernhardt, Linus Torvalds, Luke Lu, Christer Weinigel,
Tom Tobin, git
In-Reply-To: <47176AB9.7010409@midwinter.com>
On Thu, Oct 18, 2007 at 07:16:25AM -0700, Steven Grimm wrote:
>> installed in the first place. Perhaps a message more along the lines of
>> "To avoid this, run "git gc" manually on a regular basis. See 'git help
>> gc' for more information."
>
> That's a good point. Jeff / Shawn, do you agree with that? I'll come up with
> an alternate patch if so.
Yes, that seems reasonable. I think the most important thing is that
they realize that "git-gc" is responsible for what is happening. That
should allow them to find more information in the documentation if they
want (and Brian's suggestion points directly to the documentation, which
is great).
-Peff
^ permalink raw reply
* Re: git push bug?
From: Joakim Tjernlund @ 2007-10-18 16:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, git
In-Reply-To: <Pine.LNX.4.64.0710181720010.25221@racer.site>
On Thu, 2007-10-18 at 17:21 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
>
> > Seems like it is a bit too easy to make mistakes here. Why can I delete
> > a branch with :linus but not create one with linus:linus?
>
> I wonder why you bother with the colon at all. Just
>
> git push <remote> linus
>
> and be done with it. The colon is only there to play interesting games,
> not something as simple as "push this branch" or "push this tag".
First, I didn't know that I could do that.
Secondly, I was also looking do v2.6.23:linus refspecs
Jocke
^ permalink raw reply
* NI_MAXSERV trivial patch
From: Patrick Welche @ 2007-10-18 17:17 UTC (permalink / raw)
To: git
I found I needed
--- daemon.c.orig 2007-09-02 06:57:44.000000000 +0100
+++ daemon.c 2007-10-18 16:04:00.000000000 +0100
@@ -9,6 +9,10 @@
#define HOST_NAME_MAX 256
#endif
+#ifndef NI_MAXSERV
+#define NI_MAXSERV 32
+#endif
+
static int log_syslog;
static int verbose;
static int reuseaddr;
to compile git, as for me NI_MAXSERV is defined in netdb.h, and it
doesn't seem worthwhile to include the whole header.
Cheers,
Patrick
^ 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