* Re: [PATCH] Allow git-repack to optionally run git-prune-packed.
From: Alex Riesen @ 2006-03-09 14:48 UTC (permalink / raw)
To: Alex Riesen, git
In-Reply-To: <20060309102419.GA9961@igloo.ds.co.ug>
On 3/9/06, Martin Atukunda <matlads@dsmagic.com> wrote:
> Your suggestion has merit, though it's different from the behaviour I
> desired. I _sometimes_ need the pruning, and it felt appropriate to make
> it an option as opposed to default behaviour.
>
> What do you think?
>
I think that my patch didn't change the default. git-prune-packed is called
only if -d is given, which is not the default.
^ permalink raw reply
* Re: [PATCH] Add git-imap-send.
From: Johannes Schindelin @ 2006-03-09 13:47 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne10b8c.fr9.mdw@metalzone.distorted.org.uk>
Hi,
On Thu, 9 Mar 2006, Mark Wooding wrote:
> There are reasons for which it'd be desirable that memcmp really compare
> all the bytes, even if it can in theory stop early: in particular, there
> are cases where early exit can leak timing information which makes it
> possible to attack cryptographic protocols.
I would be astonished if memcmp has to be timing proof for *all*
applications, just to keep crypto people happy. I don't *want* a slow-down
in my super-duper 3d shooter.
> I'd have to recommend strncmp for this job.
Fully agree.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add git-imap-send.
From: Mark Wooding @ 2006-03-09 13:26 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0603091243001.20908@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Sorry, I was unclear. Of course, memcmp() does not stop on NUL. But it
> stops when that NUL is different from what the other pointer has. Which is
> the case here.
Does it really? My copy of the spec doesn't say that. It says only
this:
: 7.21.4.1 The memcmp function
:
: Synopsis
:
: #include <string.h>
: int memcmp(const void *s1, const void *s2, size_t n);
:
: Description
:
: The memcmp() function compares the first n characters of the object
: pointed to by s1 to the first n characters of the object pointed to by
: s2.262)
:
: Returns
:
: The memcmp function returns an integer greater than, equal to, or less
: than zero, accordingly as the object pointed to by s1 is greater than,
: equal to, or less than the object pointed to by s2.
:
: 262) The contents of ``holes'' used as padding for purposes of
: alignment within structure objects are indeterminate. Strings shorter
: than their allocated space and unions may also cause problems in
: comparison.
There are reasons for which it'd be desirable that memcmp really compare
all the bytes, even if it can in theory stop early: in particular, there
are cases where early exit can leak timing information which makes it
possible to attack cryptographic protocols.
I'd have to recommend strncmp for this job.
-- [mdw]
^ permalink raw reply
* [PATCH] clone: add refs/remotes/* to Pull: targets when cloning
From: Eric Wong @ 2006-03-09 11:55 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20060309115452.GA13369@localdomain>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-clone.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
be2db2344099b3713c1136e84bab7390b6198895
diff --git a/git-clone.sh b/git-clone.sh
index 4ed861d..a8ab7fd 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -249,6 +249,12 @@ Pull: $head_points_at:$origin" &&
test "$origin" = "$head" ||
echo "Pull: ${head}:${head}"
done >>"$GIT_DIR/remotes/origin"
+ (test -d "$GIT_DIR"/refs/remotes && cd "$GIT_DIR" &&
+ find "refs/remotes" -type f -print | sed -e 's|^refs/||') |
+ while read ref
+ do
+ echo "Pull: $ref:$ref"
+ done >>"$GIT_DIR/remotes/origin"
esac
case "$no_checkout" in
--
1.2.4.ga2910
^ permalink raw reply related
* [PATCH] fetch/parse-remote: refs/remotes/* support
From: Eric Wong @ 2006-03-09 11:54 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-fetch.sh | 5 ++++-
git-parse-remote.sh | 8 ++++----
2 files changed, 8 insertions(+), 5 deletions(-)
34f9d6c64bd686f29db4cd410882aab607e1b628
diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..2748573 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -103,6 +103,9 @@ append_fetch_head () {
refs/tags/*)
note_="$(expr "$remote_name_" : 'refs/tags/\(.*\)')"
note_="tag '$note_' of " ;;
+ refs/remotes/*)
+ note_="$(expr "$remote_name_" : 'refs/remotes/\(.*\)')"
+ note_="remote branch '$note_' of " ;;
*)
note_="$remote_name of " ;;
esac
@@ -150,7 +153,7 @@ fast_forward_local () {
git-update-ref "$1" "$2"
;;
- refs/heads/*)
+ refs/heads/* | refs/remotes/*)
# $1 is the ref being updated.
# $2 is the new value for the ref.
local=$(git-rev-parse --verify "$1^0" 2>/dev/null)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 5f158c6..63f2281 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -86,14 +86,14 @@ canon_refs_list_for_fetch () {
local=$(expr "$ref" : '[^:]*:\(.*\)')
case "$remote" in
'') remote=HEAD ;;
- refs/heads/* | refs/tags/*) ;;
- heads/* | tags/* ) remote="refs/$remote" ;;
+ refs/heads/* | refs/tags/* | refs/remotes/*) ;;
+ heads/* | tags/* | remotes/* ) remote="refs/$remote" ;;
*) remote="refs/heads/$remote" ;;
esac
case "$local" in
'') local= ;;
- refs/heads/* | refs/tags/*) ;;
- heads/* | tags/* ) local="refs/$local" ;;
+ refs/heads/* | refs/tags/* | refs/remotes/*) ;;
+ heads/* | tags/* | remotes/* ) local="refs/$local" ;;
*) local="refs/heads/$local" ;;
esac
--
1.2.4.ga2910
^ permalink raw reply related
* [PATCH] contrib/git-svn: fix a harmless warning on rebuild (with old repos)
From: Eric Wong @ 2006-03-09 11:52 UTC (permalink / raw)
To: Junio C Hamano, git
It's only for repositories that were imported with very early
versions of git-svn. Unfortunately, some of those repos are out
in the wild already, so fix this warning.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3c3753ad761d1802cc79418ae337ee4a3110a109
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 43b50ec..cf233ef 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -155,7 +155,7 @@ sub rebuild {
# if we merged or otherwise started elsewhere, this is
# how we break out of it
next if (defined $SVN_UUID && ($uuid ne $SVN_UUID));
- next if (defined $SVN_URL && ($url ne $SVN_URL));
+ next if (defined $SVN_URL && defined $url && ($url ne $SVN_URL));
print "r$rev = $c\n";
unless (defined $latest) {
--
1.2.4.ga2910
^ permalink raw reply related
* [PATCH] contrib/git-svn: remove the --no-stop-on-copy flag
From: Eric Wong @ 2006-03-09 11:50 UTC (permalink / raw)
To: Yann Dirson, Junio C Hamano; +Cc: GIT list
In-Reply-To: <20060308014207.GA31137@localdomain>
Output a big warning if somebody actually has a pre-1.0 version
of svn that doesn't support it.
Thanks to Yann Dirson for reminding me it still existed
and attempting to re-enable it :)
I think I subconciously removed support for it earlier...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 11 +++++++++++
contrib/git-svn/git-svn.txt | 13 -------------
2 files changed, 11 insertions(+), 13 deletions(-)
0ec45e489232fad4f1aa3d2c648fa53295efd7ec
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index dca4e5c..43b50ec 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -1019,6 +1019,17 @@ sub svn_compat_check {
if (grep /usage: checkout URL\[\@REV\]/,@co_help) {
$_svn_co_url_revs = 1;
}
+
+ # I really, really hope nobody hits this...
+ unless (grep /stop-on-copy/, (safe_qx(qw(svn log -h)))) {
+ print STDERR <<'';
+W: The installed svn version does not support the --stop-on-copy flag in
+ the log command.
+ Lets hope the directory you're tracking is not a branch or tag
+ and was never moved within the repository...
+
+ $_no_stop_copy = 1;
+ }
}
# *sigh*, new versions of svn won't honor -r<rev> without URL@<rev>,
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index 5fb5b7c..7a6e0c4 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -162,19 +162,6 @@ COMPATIBILITY OPTIONS
Otherwise, do not enable this flag unless you know what you're
doing.
---no-stop-on-copy::
- Only used with the 'fetch' command.
-
- By default, git-svn passes --stop-on-copy to avoid dealing with
- the copied/renamed branch directory problem entirely. A
- copied/renamed branch is the result of a <SVN_URL> being created
- in the past from a different source. These are problematic to
- deal with even when working purely with svn if you work inside
- subdirectories.
-
- Do not use this flag unless you know exactly what you're getting
- yourself into. You have been warned.
-
Basic Examples
~~~~~~~~~~~~~~
--
1.2.4.ga2910
^ permalink raw reply related
* [PATCH] contrib/git-svn: fix svn compat and fetch args
From: Eric Wong @ 2006-03-09 11:48 UTC (permalink / raw)
To: Junio C Hamano, Yann Dirson; +Cc: git
In-Reply-To: <7vacc07wwp.fsf@assigned-by-dhcp.cox.net>
'svn info' doesn't work with URLs in svn <= 1.1. Now we
only run svn info in local directories.
As a side effect, this should also work better for 'init' off
directories that are no longer in the latest revision of the
repository.
svn checkout -r<revision> arguments are fixed.
Newer versions of svn (1.2.x) seem to need URL@REV as well as
-rREV to checkout a particular revision...
Add an example in the manpage of how to track directory that has
been moved since its initial revision.
A huge thanks to Yann Dirson for the bug reporting and testing
my original patch. Thanks also to Junio C Hamano for suggesting
a safer way to use git-rev-parse.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Junio: please don't apply this patch to git.git just yet. It seems fine
> > to me, but I haven't tested it heavily yet (Yann can help me, I hope :)
> > I hardly slept the past few days and I may have broken something badly
> > (it pasts all the tests, though).
>
> I won't be applying it then.
You can apply this one :)
> I think this part is wrong.
Cool, thanks for the example.
contrib/git-svn/git-svn.perl | 63 ++++++++++++++++++++++++++++++------------
contrib/git-svn/git-svn.txt | 32 ++++++++++++++++++++-
2 files changed, 75 insertions(+), 20 deletions(-)
1e07c915bbc3ff06967a85a71c0cbad82fa40cf6
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 3c860e4..dca4e5c 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -30,6 +30,7 @@ my $sha1_short = qr/[a-f\d]{4,40}/;
my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
$_find_copies_harder, $_l, $_version, $_upgrade, $_authors);
my (@_branch_from, %tree_map, %users);
+my $_svn_co_url_revs;
my %fc_opts = ( 'no-ignore-externals' => \$_no_ignore_ext,
'branch|b=s' => \@_branch_from,
@@ -77,7 +78,7 @@ usage(0) if $_help;
version() if $_version;
usage(1) unless defined $cmd;
load_authors() if $_authors;
-svn_check_ignore_externals();
+svn_compat_check();
$cmd{$cmd}->[0]->(@ARGV);
exit 0;
@@ -162,7 +163,8 @@ sub rebuild {
croak "SVN repository location required: $url\n";
}
$SVN_URL ||= $url;
- $SVN_UUID ||= setup_git_svn();
+ $SVN_UUID ||= $uuid;
+ setup_git_svn();
$latest = $rev;
}
assert_revision_eq_or_unknown($rev, $c);
@@ -171,9 +173,7 @@ sub rebuild {
}
close $rev_list or croak $?;
if (!chdir $SVN_WC) {
- my @svn_co = ('svn','co',"-r$latest");
- push @svn_co, '--ignore-externals' unless $_no_ignore_ext;
- sys(@svn_co, $SVN_URL, $SVN_WC);
+ svn_cmd_checkout($SVN_URL, $latest, $SVN_WC);
chdir $SVN_WC or croak $!;
}
@@ -222,14 +222,14 @@ sub fetch {
my $base = shift @$svn_log or croak "No base revision!\n";
my $last_commit = undef;
unless (-d $SVN_WC) {
- my @svn_co = ('svn','co',"-r$base->{revision}");
- push @svn_co,'--ignore-externals' unless $_no_ignore_ext;
- sys(@svn_co, $SVN_URL, $SVN_WC);
+ svn_cmd_checkout($SVN_URL,$base->{revision},$SVN_WC);
chdir $SVN_WC or croak $!;
+ read_uuid();
$last_commit = git_commit($base, @parents);
assert_svn_wc_clean($base->{revision}, $last_commit);
} else {
chdir $SVN_WC or croak $!;
+ read_uuid();
$last_commit = file_to_s("$REV_DIR/$base->{revision}");
}
my @svn_up = qw(svn up);
@@ -275,7 +275,9 @@ sub commit {
fetch();
chdir $SVN_WC or croak $!;
- my $svn_current_rev = svn_info('.')->{'Last Changed Rev'};
+ my $info = svn_info('.');
+ read_uuid($info);
+ my $svn_current_rev = $info->{'Last Changed Rev'};
foreach my $c (@revs) {
my $mods = svn_checkout_tree($svn_current_rev, $c);
if (scalar @$mods == 0) {
@@ -314,6 +316,14 @@ sub show_ignore {
########################### utility functions #########################
+sub read_uuid {
+ return if $SVN_UUID;
+ my $info = shift || svn_info('.');
+ $SVN_UUID = $info->{'Repository UUID'} or
+ croak "Repository UUID unreadable\n";
+ s_to_file($SVN_UUID,"$GIT_DIR/$GIT_SVN/info/uuid");
+}
+
sub setup_git_svn {
defined $SVN_URL or croak "SVN repository location required\n";
unless (-d $GIT_DIR) {
@@ -323,14 +333,10 @@ sub setup_git_svn {
mkpath(["$GIT_DIR/$GIT_SVN/info"]);
mkpath([$REV_DIR]);
s_to_file($SVN_URL,"$GIT_DIR/$GIT_SVN/info/url");
- $SVN_UUID = svn_info($SVN_URL)->{'Repository UUID'} or
- croak "Repository UUID unreadable\n";
- s_to_file($SVN_UUID,"$GIT_DIR/$GIT_SVN/info/uuid");
open my $fd, '>>', "$GIT_DIR/$GIT_SVN/info/exclude" or croak $!;
print $fd '.svn',"\n";
close $fd or croak $!;
- return $SVN_UUID;
}
sub assert_svn_wc_clean {
@@ -860,7 +866,6 @@ sub git_commit {
my ($log_msg, @parents) = @_;
assert_revision_unknown($log_msg->{revision});
my $out_fh = IO::File->new_tmpfile or croak $!;
- $SVN_UUID ||= svn_info('.')->{'Repository UUID'};
map_tree_joins() if (@_branch_from && !%tree_map);
@@ -922,7 +927,16 @@ sub git_commit {
}
my @update_ref = ('git-update-ref',"refs/remotes/$GIT_SVN",$commit);
if (my $primary_parent = shift @exec_parents) {
- push @update_ref, $primary_parent;
+ $pid = fork;
+ defined $pid or croak $!;
+ if (!$pid) {
+ close STDERR;
+ close STDOUT;
+ exec 'git-rev-parse','--verify',
+ "refs/remotes/$GIT_SVN^0";
+ }
+ waitpid $pid, 0;
+ push @update_ref, $primary_parent unless $?;
}
sys(@update_ref);
sys('git-update-ref',"$GIT_SVN/revs/$log_msg->{revision}",$commit);
@@ -995,13 +1009,26 @@ sub safe_qx {
return wantarray ? @ret : join('',@ret);
}
-sub svn_check_ignore_externals {
- return if $_no_ignore_ext;
- unless (grep /ignore-externals/,(safe_qx(qw(svn co -h)))) {
+sub svn_compat_check {
+ my @co_help = safe_qx(qw(svn co -h));
+ unless (grep /ignore-externals/,@co_help) {
print STDERR "W: Installed svn version does not support ",
"--ignore-externals\n";
$_no_ignore_ext = 1;
}
+ if (grep /usage: checkout URL\[\@REV\]/,@co_help) {
+ $_svn_co_url_revs = 1;
+ }
+}
+
+# *sigh*, new versions of svn won't honor -r<rev> without URL@<rev>,
+# (and they won't honor URL@<rev> without -r<rev>, too!)
+sub svn_cmd_checkout {
+ my ($url, $rev, $dir) = @_;
+ my @cmd = ('svn','co', "-r$rev");
+ push @cmd, '--ignore-externals' unless $_no_ignore_ext;
+ $url .= "\@$rev" if $_svn_co_url_revs;
+ sys(@cmd, $url, $dir);
}
sub check_upgrade_needed {
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index 8e9a971..5fb5b7c 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -175,8 +175,8 @@ COMPATIBILITY OPTIONS
Do not use this flag unless you know exactly what you're getting
yourself into. You have been warned.
-Examples
-~~~~~~~~
+Basic Examples
+~~~~~~~~~~~~~~
Tracking and contributing to an Subversion managed-project:
@@ -234,6 +234,34 @@ This allows you to tie unfetched SVN rev
git-svn fetch 375=$(git-rev-parse HEAD)
+Advanced Example: Tracking a Reorganized Repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you're tracking a directory that has moved, or otherwise been
+branched or tagged off of another directory in the repository and you
+care about the full history of the project, then you can read this
+section.
+
+This is how Yann Dirson tracked the trunk of the ufoai directory when
+the /trunk directory of his repository was moved to /ufoai/trunk and
+he needed to continue tracking /ufoai/trunk where /trunk left off.
+
+ # This log message shows when the repository was reorganized::
+ r166 | ydirson | 2006-03-02 01:36:55 +0100 (Thu, 02 Mar 2006) | 1 line
+ Changed paths:
+ D /trunk
+ A /ufoai/trunk (from /trunk:165)
+
+ # First we start tracking the old revisions::
+ GIT_SVN_ID=git-oldsvn git-svn init \
+ https://svn.sourceforge.net/svnroot/ufoai/trunk
+ GIT_SVN_ID=git-oldsvn git-svn fetch -r1:165
+
+ # And now, we continue tracking the new revisions::
+ GIT_SVN_ID=git-newsvn git-svn init \
+ https://svn.sourceforge.net/svnroot/ufoai/ufoai/trunk
+ GIT_SVN_ID=git-newsvn git-svn fetch \
+ 166=`git-rev-parse refs/remotes/git-oldsvn`
+
BUGS
----
If somebody commits a conflicting changeset to SVN at a bad moment
--
1.2.4.ga2910
^ permalink raw reply related
* Re: [PATCH] Add git-imap-send.
From: Johannes Schindelin @ 2006-03-09 11:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Mike McCormack, git
In-Reply-To: <4410140E.2000609@op5.se>
Hi,
On Thu, 9 Mar 2006, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 9 Mar 2006, Junio C Hamano wrote:
> >
> >
> > > Mike McCormack <mike@codeweavers.com> writes:
> > >
> > >
> > > > + if (!memcmp( "imaps:", val, 6 )) {
> > > > + if (!memcmp( "imap:", val, 5 ))
> > >
> > > Is val always longer than 5 or 6 bytes here?
> >
> >
> > That does not matter, since they are strings, and the memcmp should not look
> > further if they are shorter (because the comparison to '\0' failed already).
> >
>
> That's what strcmp() does. memcmp() walks the lenghth even if it encounters
> nul bytes. Perhaps you confuse it with strncmp()?
Sorry, I was unclear. Of course, memcmp() does not stop on NUL. But it
stops when that NUL is different from what the other pointer has. Which is
the case here.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add git-imap-send.
From: Andreas Ericsson @ 2006-03-09 11:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Mike McCormack, git
In-Reply-To: <Pine.LNX.4.63.0603091227560.20277@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 9 Mar 2006, Junio C Hamano wrote:
>
>
>>Mike McCormack <mike@codeweavers.com> writes:
>>
>>
>>>+ if (!memcmp( "imaps:", val, 6 )) {
>>>+ if (!memcmp( "imap:", val, 5 ))
>>
>>Is val always longer than 5 or 6 bytes here?
>
>
> That does not matter, since they are strings, and the memcmp should not
> look further if they are shorter (because the comparison to '\0' failed
> already).
>
That's what strcmp() does. memcmp() walks the lenghth even if it
encounters nul bytes. Perhaps you confuse it with strncmp()?
> However, if !memcmp("imaps:", val, 6), it means that val starts with
> the string "imaps:", right? Then !memcmp("imap:", val, 5) must always
> fail, no?
>
Yes. Recent gcc's will recognize it as dead code and remove it. It's
still ugly though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Add git-imap-send.
From: Johannes Schindelin @ 2006-03-09 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike McCormack, git
In-Reply-To: <7vacbz7vod.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 9 Mar 2006, Junio C Hamano wrote:
> Mike McCormack <mike@codeweavers.com> writes:
>
> > + if (!memcmp( "imaps:", val, 6 )) {
> > + if (!memcmp( "imap:", val, 5 ))
>
> Is val always longer than 5 or 6 bytes here?
That does not matter, since they are strings, and the memcmp should not
look further if they are shorter (because the comparison to '\0' failed
already).
However, if !memcmp("imaps:", val, 6), it means that val starts with
the string "imaps:", right? Then !memcmp("imap:", val, 5) must always
fail, no?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] fsck-objects: Remove --standalone
From: Junio C Hamano @ 2006-03-09 10:37 UTC (permalink / raw)
To: git; +Cc: Ming Lei
In-Reply-To: <7v7j74fgsh.fsf@assigned-by-dhcp.cox.net>
The fsck-objects command (back then it was called fsck-cache)
used to complain if objects referred to by files in .git/refs/
or objects stored in files under .git/objects/??/ were not found
as stand-alone SHA1 files (i.e. found in alternate object pools
or packed archives stored under .git/objects/pack). Back then,
packs and alternates were new curiosity and having everything as
loose objects were the norm.
When we adjusted the behaviour of fsck-cache to consider objects
found in packs are OK, we introduced the --standalone flag as a
backward compatibility measure.
It still correctly checks if your repository is complete and
consists only of loose objects, so in that sense it is doing the
"right" thing, but checking that is pointless these days. This
commit removes --standalone flag.
See also:
23676d407c63a6f67f8ce3ff192199bda03e6a03
8a498a05c3c6b2f53db669b24f36257ab213eb4c
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* The flag itself is harmless and it still is working as
advertized and documented, but I think it outlived its
usefulness. I do not expect any objections against the
removal but just in case...
Documentation/git-fsck-objects.txt | 15 ++++-----------
fsck-objects.c | 18 ++++--------------
2 files changed, 8 insertions(+), 25 deletions(-)
8f9c5c27d9d5dfe0a5f26646e39ebc48df0eb25c
diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt
index 387b435..93ce9dc 100644
--- a/Documentation/git-fsck-objects.txt
+++ b/Documentation/git-fsck-objects.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache]
- [--standalone | --full] [--strict] [<object>*]
+ [--full] [--strict] [<object>*]
DESCRIPTION
-----------
@@ -38,21 +38,14 @@ index file and all SHA1 references in .g
Consider any object recorded in the index also as a head node for
an unreachability trace.
---standalone::
- Limit checks to the contents of GIT_OBJECT_DIRECTORY
- ($GIT_DIR/objects), making sure that it is consistent and
- complete without referring to objects found in alternate
- object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
- nor packed git archives found in $GIT_DIR/objects/pack;
- cannot be used with --full.
-
--full::
Check not just objects in GIT_OBJECT_DIRECTORY
($GIT_DIR/objects), but also the ones found in alternate
- object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
+ object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
+ or $GIT_DIR/objects/info/alternates,
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
- object pools; cannot be used with --standalone.
+ object pools.
--strict::
Enable more strict checking, namely to catch a file mode
diff --git a/fsck-objects.c b/fsck-objects.c
index 4ddd676..9cc8572 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -14,7 +14,6 @@
static int show_root = 0;
static int show_tags = 0;
static int show_unreachable = 0;
-static int standalone = 0;
static int check_full = 0;
static int check_strict = 0;
static int keep_cache_objects = 0;
@@ -68,7 +67,7 @@ static void check_connectivity(void)
continue;
if (!obj->parsed) {
- if (!standalone && has_sha1_file(obj->sha1))
+ if (has_sha1_file(obj->sha1))
; /* it is in pack */
else
printf("missing %s %s\n",
@@ -82,7 +81,7 @@ static void check_connectivity(void)
for (j = 0; j < refs->count; j++) {
struct object *ref = refs->ref[j];
if (ref->parsed ||
- (!standalone && has_sha1_file(ref->sha1)))
+ (has_sha1_file(ref->sha1)))
continue;
printf("broken link from %7s %s\n",
obj->type, sha1_to_hex(obj->sha1));
@@ -390,7 +389,7 @@ static int fsck_handle_ref(const char *r
obj = lookup_object(sha1);
if (!obj) {
- if (!standalone && has_sha1_file(sha1)) {
+ if (has_sha1_file(sha1)) {
default_refs++;
return 0; /* it is in a pack */
}
@@ -464,10 +463,6 @@ int main(int argc, char **argv)
keep_cache_objects = 1;
continue;
}
- if (!strcmp(arg, "--standalone")) {
- standalone = 1;
- continue;
- }
if (!strcmp(arg, "--full")) {
check_full = 1;
continue;
@@ -477,14 +472,9 @@ int main(int argc, char **argv)
continue;
}
if (*arg == '-')
- usage("git-fsck-objects [--tags] [--root] [[--unreachable] [--cache] [--standalone | --full] [--strict] <head-sha1>*]");
+ usage("git-fsck-objects [--tags] [--root] [[--unreachable] [--cache] [--full] [--strict] <head-sha1>*]");
}
- if (standalone && check_full)
- die("Only one of --standalone or --full can be used.");
- if (standalone)
- putenv("GIT_ALTERNATE_OBJECT_DIRECTORIES=");
-
fsck_head_link();
fsck_object_dir(get_object_directory());
if (check_full) {
--
1.2.4.g2acc
^ permalink raw reply related
* Re: [PATCH] Add git-imap-send.
From: Junio C Hamano @ 2006-03-09 10:35 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <440C3499.9080000@codeweavers.com>
Mike McCormack <mike@codeweavers.com> writes:
> This probably needs a bit more work, but I'll solicit comments and
> flames anyway...
OK, then please work a bit more ;-)
I kind of like this approach and even wish my e-mail workflow
involved an imap server with draft folders. Currently I do
everything in Gnus and my drafts are on local disk.
> The target IMAP folder:
>
> [imap]
> Folder = "INBOX.Drafts"
>
> A command to open an ssh tunnel to the imap mail server.
The .git/config file is a good choice for storing this
information, because you might even use different draft folders
for different projects, i.e. the configuration is
per-repository.
> [imap]
> Tunnel = "ssh -q user@imap.server.com /usr/bin/imapd ./Maildir
> 2> /dev/null"
> [imap]
> Host = imap.server.com
> User = bob
> Password = pwd
> Port = 143
These I am not so sure. It _might_ make sense to have something
like this under $HOME/. Isn't there an established convention
for storing something like this for existing MUAs?
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *...
> + * As a special exception, mbsync may be linked with the OpenSSL library,
> + * despite that library's more restrictive license.
Hmmm.
> +#include <sys/types.h>
>...
> +#include <pwd.h>
> +
> +#include "cache.h"
If you are including "cache.h", you probably do not need to
include many of the standard include files.
> +#define as(ar) (sizeof(ar)/sizeof(ar[0]))
We have something like this in apply.c, exec_cmd.c and git.c;
probably we would want a macro in "cache.h".
git.c:326:#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
> +static int
> +git_imap_config(const char *key, const char *val)
> +{
>...
> + if (!strcasecmp( "Folder", key )) {
git_config calls you after downcasing the keys, so you do not
need to do strcasecmp. Just spell things out in lowercase.
> + if (!memcmp( "imaps:", val, 6 )) {
> + if (!memcmp( "imap:", val, 5 ))
Is val always longer than 5 or 6 bytes here?
^ permalink raw reply
* Re: [PATCH] Don't recurse into parents marked uninteresting.
From: smurf @ 2006-03-09 10:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603082144450.32577@g5.osdl.org>
Hi,
Linus Torvalds:
> So what was it that triggered this "parents had already been parsed"
> situation? Is it because we've generated a huge list of "I have it"
> objects when pulling? That would explain it..
>
Something like that. I've converted a large number of older heads
(ranging from a few months to a few years) from $EVIL_SCM to git,
and tried to push them up to our main repository, which contains the
current development.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
:read-only user: n. Describes a {luser} who uses computers almost
exclusively for reading Usenet, bulletin boards, and/or email, rather
than writing code or purveying useful information. See {twink},
{terminal junkie}, {lurker}.
^ permalink raw reply
* Re: [PATCH] Allow git-repack to optionally run git-prune-packed.
From: Martin Atukunda @ 2006-03-09 10:24 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060307212918.GA9474@steel.home>
Your suggestion has merit, though it's different from the behaviour I
desired. I _sometimes_ need the pruning, and it felt appropriate to make
it an option as opposed to default behaviour.
What do you think?
- Martin -
On Tue, Mar 07, 2006 at 10:29:18PM +0100, Alex Riesen wrote:
> Martin Atukunda, Tue, Mar 07, 2006 16:16:12 +0100:
> > +-p::
> > + Run `git-prune-packed` after packing, see
> > + gitlink:git-prune-packed[1]
> > +
>
> Maybe just make "-d" work? I.e. "git repack -a -d" repacks and prunes
> everything, and "git repack -d" prunes just what was packed
> incrementally.
> Something like this:
>
> diff --git a/git-repack.sh b/git-repack.sh
> index 3d6fec1..be6c7ab 100755
> --- a/git-repack.sh
> +++ b/git-repack.sh
> @@ -74,6 +74,8 @@ then
> esac
> done
> )
> + else
> + git-prune-packed
> fi
> fi
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Girl on cell: Can you hear me when I roll my eyes?
-- www.overheardinnewyourk.com
^ permalink raw reply
* Re: git-unpack-objects < pack file in repository doesn't work!
From: Junio C Hamano @ 2006-03-09 10:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060307040255.GA29544@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I wanted to explode a pack because I'm starting work on an Eclipse
> plugin for GIT. I thought I'd try going down the road of letting
> the plugin read the repository directly, and write loose objects
> directly, but leave pack construction to the native C code. So I
> tried to clone my local GIT repository to a new directory (thus
> had no loose objects at all) and unpack it to get loose objects.
> That didn't go so well. :-)
Before "git-repack -a" was invented, I used to do this by hand:
$ mkdir ./++preserve
$ mv .git/objects/pack/pack-*.pack ./++preserve
$ for p in ./++preserve/pack-*.pack
do git-unpack-objects <$p; done
^ permalink raw reply
* Re: [PATCH] contrib/git-svn: fix UUID reading w/pre-1.2 svn; fetch args
From: Junio C Hamano @ 2006-03-09 10:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060308015730.GA28056@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> Junio: please don't apply this patch to git.git just yet. It seems fine
> to me, but I haven't tested it heavily yet (Yann can help me, I hope :)
> I hardly slept the past few days and I may have broken something badly
> (it pasts all the tests, though).
I won't be applying it then.
I think this part is wrong.
> @@ -922,7 +930,9 @@ sub git_commit {
> }
> my @update_ref = ('git-update-ref',"refs/remotes/$GIT_SVN",$commit);
> if (my $primary_parent = shift @exec_parents) {
> - push @update_ref, $primary_parent;
> + if (!system('git-rev-parse',"refs/remotes/$GIT_SVN")){
> + push @update_ref, $primary_parent;
> + }
I think you are trying to see if you have .git/refs/remotes/foo,
and I think you actually have tried it to determine that is the
case.
But "git-rev-parse refs/remotes/foo" dies not because there is
no valid file .git/refs/remotes/foo that records SHA1 of an
existing commit. If there is refs/remotes/foo file, it thinks
you have asked for it and gives it back happily.
A demonstration:
$ cd /var/tmp/ && rm -fr junk && mkdir junk && cd junk
$ git init-db
defaulting to local storage area
$ git-rev-parse refs/remotes/foo ; echo $?
refs/remotes/foo
fatal: 'refs/remotes/foo': No such file or directory
128
$ mkdir -p refs/remotes/foo
$ ls -a
./ ../ .git/ refs/
$ git-rev-parse refs/remotes/foo; echo $?
refs/remotes/foo
0
If you are trying to see if there is such a ref, I would do
this:
$ git-rev-parse --verify refs/remotes/foo^0
git-rev-parse --verify refs/remotes/foo^0
fatal: Needed a single revision
128
The --verify flag makes sure that the argument resolves to a
valid 40-hexadigit string (note that it does not verify if that
object actually exists), so asking for zeroth parent makes sure
you are dealing with a ref that actually points at a commit
object that exists.
^ permalink raw reply
* Re: [PATCH 0/3] Teach git-blame about renames
From: Fredrik Kuivinen @ 2006-03-09 7:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7v4q28h38p.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 08, 2006 at 04:27:02PM -0800, Junio C Hamano wrote:
> > -static int compare_tree(struct tree *t1, struct tree *t2)
> > +int compare_tree(struct tree *t1, struct tree *t2)
> > ...
> > -static int same_tree_as_empty(struct tree *t1)
> > +int same_tree_as_empty(struct tree *t1)
>
> Maybe the names are a bit too generic to be used as a global?
>
Yes.. maybe. They are quite general though. Any suggestions for better
names? We could prefix everything in revision.h with "rev_" or
something like that.
Thanks for the comments. I will send an updated patch series soon.
- Fredrik
^ permalink raw reply
* Re: [PATCH] Don't recurse into parents marked uninteresting.
From: Linus Torvalds @ 2006-03-09 5:48 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2006.03.09.04.04.34.617873@smurf.noris.de>
On Thu, 9 Mar 2006, Matthias Urlichs wrote:
>
> revision.c:make_parents_uninteresting() is exponential with the number
> of merges in the tree. That's fine -- unless some other part of git
> already has pulled the whole commit tree into memory ...
Good call.
However, I would have expected the normal case to be that we haven't even
parsed the parent yet (as per the comment), so the parent normally
shouldn't even have the parent pointer (due to not having been parsed).
So what was it that triggered this "parents had already been parsed"
situation? Is it because we've generated a huge list of "I have it"
objects when pulling? That would explain it..
Linus
^ permalink raw reply
* [stgit] [PATCH] common: parse 'email (name)' correctly
From: Sam Vilain @ 2006-03-09 5:29 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
Currently only e-mails of the form "Name <email>" are accepted by
stgit import etc, however some people use "email (Name)". Accept this
alternate form.
---
Note: the function just below it might need consideration, too.
stgit/commands/common.py | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 2985379..4bfa4dd 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -175,12 +175,15 @@ def push_patches(patches, check_merged =
def name_email(address):
"""Return a tuple consisting of the name and email parsed from a
- standard 'name <email>' string
+ standard 'name <email>' or 'email (name)' string
"""
address = re.sub('[\\\\"]', '\\\\\g<0>', address)
str_list = re.findall('^(.*)\s*<(.*)>\s*$', address)
if not str_list:
- raise CmdException, 'Incorrect "name <email>" string: %s' % address
+ str_list = re.findall('^(.*)\s*\((.*)\)\s*$', address)
+ if not str_list:
+ raise CmdException, 'Incorrect "name <email>"/"email
(name)" string: %s' % address
+ return ( str_list[0][1], str_list[0][0] )
return str_list[0]
^ permalink raw reply related
* [PATCH] Don't recurse into parents marked uninteresting.
From: Matthias Urlichs @ 2006-03-09 4:04 UTC (permalink / raw)
To: git
In-Reply-To: <pan.2006.03.08.20.04.24.62170@smurf.noris.de>
revision.c:make_parents_uninteresting() is exponential with the number
of merges in the tree. That's fine -- unless some other part of git
already has pulled the whole commit tree into memory ...
---
... or, in other words, "Don't do that, please."
With this patch, all tests still succeed, and the "git push" which
triggered the problem takes 5min instead of an estimated 10mio years.
---
revision.c | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
32c9750691d1ef225ca1641fdf6902e53c25fe5b
diff --git a/revision.c b/revision.c
index 2a33637..713f27e 100644
--- a/revision.c
+++ b/revision.c
@@ -82,18 +82,20 @@ void mark_parents_uninteresting(struct c
while (parents) {
struct commit *commit = parents->item;
- commit->object.flags |= UNINTERESTING;
+ if (!(commit->object.flags & UNINTERESTING)) {
+ commit->object.flags |= UNINTERESTING;
- /*
- * Normally we haven't parsed the parent
- * yet, so we won't have a parent of a parent
- * here. However, it may turn out that we've
- * reached this commit some other way (where it
- * wasn't uninteresting), in which case we need
- * to mark its parents recursively too..
- */
- if (commit->parents)
- mark_parents_uninteresting(commit);
+ /*
+ * Normally we haven't parsed the parent
+ * yet, so we won't have a parent of a parent
+ * here. However, it may turn out that we've
+ * reached this commit some other way (where it
+ * wasn't uninteresting), in which case we need
+ * to mark its parents recursively too..
+ */
+ if (commit->parents)
+ mark_parents_uninteresting(commit);
+ }
/*
* A missing commit is ok iff its parent is marked
--
Matthias Urlichs
^ permalink raw reply related
* Re: fsck-object --standalone got errors
From: Junio C Hamano @ 2006-03-09 3:17 UTC (permalink / raw)
To: Ming Lei; +Cc: git
In-Reply-To: <440F945C.2010401@brocade.com>
Ming Lei <mlei@brocade.com> writes:
> I have a repository created by GIT itself(not cognito, etc). It has
> branches called base, master and origin. When I did git-fsck-objects
> --full there is nothing shown, but when I did git-fsck-objects
> --standalone, it displayed following:
That is really an artifact from a distant past. Please do not
worry about that error -- as long as --full does not see
anything long, there is nothing wrong with your repository.
The fsck-object command (back then it was called fsck-cache)
complained if objects referred to by files in .git/refs/ or
objects stored in files under .git/objects/??/ are not found as
stand-alone SHA1 files (i.e. found in alternate object pools or
packed archives stored under .git/objects/pack). Back then,
packs and alternates were curiosity and having everything as
loose objects were the norm.
When we adjusted the behaviour of fsck-cache to consider objects
found in packs are OK, we introduced the --standalone flag as a
backward compatibility measure.
It still correctly checks if your repository is complete and
consists only of loose objects, so in that sense it is doing the
"right" thing, but checking that is pointless these days. We
probably should remove that flag.
^ permalink raw reply
* fsck-object --standalone got errors
From: Ming Lei @ 2006-03-09 2:35 UTC (permalink / raw)
To: git
I have a repository created by GIT itself(not cognito, etc). It has
branches called base, master and origin. When I did git-fsck-objects
--full there is nothing shown, but when I did git-fsck-objects
--standalone, it displayed following:
error: refs/heads/master: invalid sha1 pointer
ea51c414519ffe78c5bf95c488e94e82d3603472
error: refs/heads/base: invalid sha1 pointer
4b75aaeb5af2dc69374ad080020758e4de6a45d2
error: refs/heads/origin: invalid sha1 pointer
f4c9503abb2ad52752004e8e9b77b72e23d18d3e
fatal: No default references
The question is:
what's the purpose for this standalone check? what's these errors about?
Do I need to care these errors?
what's the step to ensure my repository always be in a good shape? Is
running fsck-objects --full sufficient?
Thanks
Ming
^ permalink raw reply
* Re: git-fmt-merge-msg cleanup
From: Junio C Hamano @ 2006-03-09 2:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603081753270.32577@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Since I've started using the "merge.summary" flag in my repo, my merge
> messages look nicer, but I dislike how I get notifications of merges
> within merges.
>
> So I'd suggest this trivial change..
Makes sense. Thanks.
^ permalink raw reply
* git-fmt-merge-msg cleanup
From: Linus Torvalds @ 2006-03-09 1:56 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Since I've started using the "merge.summary" flag in my repo, my merge
messages look nicer, but I dislike how I get notifications of merges
within merges.
So I'd suggest this trivial change..
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index dae383f..afe80e6 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -47,7 +47,7 @@ sub current_branch {
sub shortlog {
my ($tip) = @_;
my @result;
- foreach ( qx{git-log --topo-order --pretty=oneline $tip ^HEAD} ) {
+ foreach ( qx{git-log --no-merges --topo-order --pretty=oneline $tip ^HEAD} ) {
s/^[0-9a-f]{40}\s+//;
push @result, $_;
}
^ permalink raw reply related
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