* Re: [PATCH] Trim hint printed when gecos is empty.
From: Han-Wen Nienhuys @ 2006-11-28 10:52 UTC (permalink / raw)
To: git
In-Reply-To: <ekh2uh$nk2$1@sea.gmane.org>
Han-Wen Nienhuys escreveu:
> Trim hint printed when gecos is empty.
> Remove asterisks for readability
> Suggest use of git-config for easy cut & pasting.
> ---
and
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
is there a reason why git-format-patch doesn't add a sign-off by default?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [PATCH 1.2/2 (fixed)] git-svn: fix output reporting from the delta fetcher
From: Eric Wong @ 2006-11-28 10:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pazu
In-Reply-To: <20061128102958.GA5207@soma>
There was nothing printed in the code originally because I left
out a pair of parentheses. Nevertheless, the affected code has
been replaced with a more efficient version that respects the -q
flag as well as requiring less bandwidth.
We save some bandwidth by not requesting changed paths
information when calling get_log() since we're using the delta
fetcher.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Oops, the previous one (1.1) was broken with the the graft branches test
This one fixes it.
git-svn.perl | 35 +++++++++++++++--------------------
1 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 9b86d91..7942bba 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1152,7 +1152,7 @@ sub graft_file_copy_lib {
while (1) {
my $pool = SVN::Pool->new;
libsvn_get_log(libsvn_dup_ra($SVN), [$path],
- $min, $max, 0, 1, 1,
+ $min, $max, 0, 2, 1,
sub {
libsvn_graft_file_copies($grafts, $tree_paths,
$path, @_);
@@ -2906,7 +2906,7 @@ sub libsvn_log_entry {
}
sub process_rm {
- my ($gui, $last_commit, $f) = @_;
+ my ($gui, $last_commit, $f, $q) = @_;
# remove entire directories.
if (safe_qx('git-ls-tree',$last_commit,'--',$f) =~ /^040000 tree/) {
defined(my $pid = open my $ls, '-|') or croak $!;
@@ -2917,10 +2917,13 @@ sub process_rm {
local $/ = "\0";
while (<$ls>) {
print $gui '0 ',0 x 40,"\t",$_ or croak $!;
+ print "\tD\t$_\n" unless $q;
}
+ print "\tD\t$f/\n" unless $q;
close $ls or croak $?;
} else {
print $gui '0 ',0 x 40,"\t",$f,"\0" or croak $!;
+ print "\tD\t$f\n" unless $q;
}
}
@@ -2931,8 +2934,7 @@ sub libsvn_fetch {
sub libsvn_fetch_delta {
my ($last_commit, $paths, $rev, $author, $date, $msg) = @_;
my $pool = SVN::Pool->new;
- my $ed = SVN::Git::Fetcher->new({ c => $last_commit, ra => $SVN,
- paths => $paths });
+ my $ed = SVN::Git::Fetcher->new({ c => $last_commit, q => $_q });
my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
my (undef, $last_rev, undef) = cmt_metadata($last_commit);
@@ -2956,8 +2958,7 @@ sub libsvn_fetch_full {
$f =~ s#^/##;
}
if ($m =~ /^[DR]$/) {
- print "\t$m\t$f\n" unless $_q;
- process_rm($gui, $last_commit, $f);
+ process_rm($gui, $last_commit, $f, $_q);
next if $m eq 'D';
# 'R' can be file replacements, too, right?
}
@@ -3098,7 +3099,7 @@ sub revisions_eq {
# should be OK to use Pool here (r1 - r0) should be small
my $pool = SVN::Pool->new;
libsvn_get_log($SVN, [$path], $r0, $r1,
- 0, 1, 1, sub {$nr++}, $pool);
+ 0, 0, 1, sub {$nr++}, $pool);
$pool->clear;
} else {
my ($url, undef) = repo_path_split($SVN_URL);
@@ -3174,6 +3175,7 @@ sub libsvn_find_parent_branch {
sub libsvn_get_log {
my ($ra, @args) = @_;
+ $args[4]-- if $args[4] && $_xfer_delta && ! $_follow_parent;
if ($SVN::Core::VERSION le '1.2.0') {
splice(@args, 3, 1);
}
@@ -3187,7 +3189,7 @@ sub libsvn_new_tree {
my ($paths, $rev, $author, $date, $msg) = @_;
if ($_xfer_delta) {
my $pool = SVN::Pool->new;
- my $ed = SVN::Git::Fetcher->new({paths => $paths, ra => $SVN});
+ my $ed = SVN::Git::Fetcher->new({q => $_q});
my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
$reporter->set_path('', $rev, 1, @lock, $pool);
@@ -3382,20 +3384,14 @@ sub new {
open my $gui, '| git-update-index -z --index-info' or croak $!;
$self->{gui} = $gui;
$self->{c} = $git_svn->{c} if exists $git_svn->{c};
- if (my $p = $git_svn->{paths} && $git_svn->{ra}) {
- my $s = $git_svn->{ra}->{svn_path};
- $s = length $s ? qr#^/\Q$s\E/# : qr#^/#;
- $self->{paths} = { map { my $x = $_;
- $x =~ s/$s//;
- $x => $p->{$_} } keys %$p };
- }
+ $self->{q} = $git_svn->{q};
require Digest::MD5;
$self;
}
sub delete_entry {
my ($self, $path, $rev, $pb) = @_;
- process_rm($self->{gui}, $self->{c}, $path);
+ process_rm($self->{gui}, $self->{c}, $path, $self->{q});
undef;
}
@@ -3404,13 +3400,13 @@ sub open_file {
my ($mode, $blob) = (safe_qx('git-ls-tree',$self->{c},'--',$path)
=~ /^(\d{6}) blob ([a-f\d]{40})\t/);
{ path => $path, mode_a => $mode, mode_b => $mode, blob => $blob,
- pool => SVN::Pool->new };
+ pool => SVN::Pool->new, action => 'M' };
}
sub add_file {
my ($self, $path, $pb, $cp_path, $cp_rev) = @_;
{ path => $path, mode_a => 100644, mode_b => 100644,
- pool => SVN::Pool->new };
+ pool => SVN::Pool->new, action => 'A' };
}
sub change_file_prop {
@@ -3493,8 +3489,7 @@ sub close_file {
$fb->{pool}->clear;
my $gui = $self->{gui};
print $gui "$fb->{mode_b} $hash\t$path\0" or croak $!;
- print "\t", $self->{paths}->{$path}->action,
- "\t$path\n" if defined $self->{paths}->{$path};
+ print "\t$fb->{action}\t$path\n" if $fb->{action} && ! $self->{q};
undef;
}
--
1.4.4.1.g22a08
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-11-28 10:50 UTC (permalink / raw)
To: git
In-Reply-To: <200611281029.11918.andyparkins@gmail.com>
Andy Parkins wrote:
> How does the supermodule know which
> branch to track in the submodule? Does it simply track HEAD or when the
> submodule is added to the supermodule is it told which branch to track? I
> suppose it's got to be HEAD really hasn't it?
I think that the proper place for that would be supermodule _index_.
The supermodule tree would have commit entry, and the index would have
symbolic branch (and perhaps some infor about where to find refs for
submodule).
This I guess breaks index abstraction slightly, but on the other hand
allows for tracking non-HEAD branch of submodule, and for submodule to
not know about supermodule at all...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] "init-db" can really be just "init"
From: Han-Wen Nienhuys @ 2006-11-28 10:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz6cfsuw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> I was not sure about this for quite some time, thinking that it
> might make sense to default the behaviour of init-db for bare
> repositories and give init as a user-level wrapper to drive
> init-db to add customization suitable for repositories with
> working trees. List?
wouldn't using --bare be more consistent for bare repos?
>> Maybe that could be a good rule of thumb to have all porcelainish
>> commands not have any hyphen in their name, like "diff", "commit",
>> "add", etc. ?
>
> I was also hoping that would become the case except verify-tag,
> cherry-pick, and format-patch.
why not shorten them to "pick" and "verify"?
--
^ permalink raw reply
* [PATCH 1.1/2] git-svn: fix output reporting from the delta fetcher
From: Eric Wong @ 2006-11-28 10:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pazu
In-Reply-To: <20061128054448.GA396@soma>
There was nothing printed in the code originally because I left
out a pair of parentheses. Nevertheless, the affected code has
been replaced with a more efficient version that respects the -q
flag as well as requiring less bandwidth.
We save some bandwidth by not requesting changed paths
information when calling get_log() since we're using the delta
fetcher.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 31 +++++++++++++------------------
1 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 9b86d91..1a675c4 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2906,7 +2906,7 @@ sub libsvn_log_entry {
}
sub process_rm {
- my ($gui, $last_commit, $f) = @_;
+ my ($gui, $last_commit, $f, $q) = @_;
# remove entire directories.
if (safe_qx('git-ls-tree',$last_commit,'--',$f) =~ /^040000 tree/) {
defined(my $pid = open my $ls, '-|') or croak $!;
@@ -2917,10 +2917,13 @@ sub process_rm {
local $/ = "\0";
while (<$ls>) {
print $gui '0 ',0 x 40,"\t",$_ or croak $!;
+ print "\tD\t$_\n" unless $q;
}
+ print "\tD\t$f/\n" unless $q;
close $ls or croak $?;
} else {
print $gui '0 ',0 x 40,"\t",$f,"\0" or croak $!;
+ print "\tD\t$f\n" unless $q;
}
}
@@ -2931,8 +2934,7 @@ sub libsvn_fetch {
sub libsvn_fetch_delta {
my ($last_commit, $paths, $rev, $author, $date, $msg) = @_;
my $pool = SVN::Pool->new;
- my $ed = SVN::Git::Fetcher->new({ c => $last_commit, ra => $SVN,
- paths => $paths });
+ my $ed = SVN::Git::Fetcher->new({ c => $last_commit, q => $_q });
my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
my (undef, $last_rev, undef) = cmt_metadata($last_commit);
@@ -2956,8 +2958,7 @@ sub libsvn_fetch_full {
$f =~ s#^/##;
}
if ($m =~ /^[DR]$/) {
- print "\t$m\t$f\n" unless $_q;
- process_rm($gui, $last_commit, $f);
+ process_rm($gui, $last_commit, $f, $_q);
next if $m eq 'D';
# 'R' can be file replacements, too, right?
}
@@ -3174,6 +3175,7 @@ sub libsvn_find_parent_branch {
sub libsvn_get_log {
my ($ra, @args) = @_;
+ $args[4] = 0 if $_xfer_delta && ! $_follow_parent;
if ($SVN::Core::VERSION le '1.2.0') {
splice(@args, 3, 1);
}
@@ -3187,7 +3189,7 @@ sub libsvn_new_tree {
my ($paths, $rev, $author, $date, $msg) = @_;
if ($_xfer_delta) {
my $pool = SVN::Pool->new;
- my $ed = SVN::Git::Fetcher->new({paths => $paths, ra => $SVN});
+ my $ed = SVN::Git::Fetcher->new({q => $_q});
my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
$reporter->set_path('', $rev, 1, @lock, $pool);
@@ -3382,20 +3384,14 @@ sub new {
open my $gui, '| git-update-index -z --index-info' or croak $!;
$self->{gui} = $gui;
$self->{c} = $git_svn->{c} if exists $git_svn->{c};
- if (my $p = $git_svn->{paths} && $git_svn->{ra}) {
- my $s = $git_svn->{ra}->{svn_path};
- $s = length $s ? qr#^/\Q$s\E/# : qr#^/#;
- $self->{paths} = { map { my $x = $_;
- $x =~ s/$s//;
- $x => $p->{$_} } keys %$p };
- }
+ $self->{q} = $git_svn->{q};
require Digest::MD5;
$self;
}
sub delete_entry {
my ($self, $path, $rev, $pb) = @_;
- process_rm($self->{gui}, $self->{c}, $path);
+ process_rm($self->{gui}, $self->{c}, $path, $self->{q});
undef;
}
@@ -3404,13 +3400,13 @@ sub open_file {
my ($mode, $blob) = (safe_qx('git-ls-tree',$self->{c},'--',$path)
=~ /^(\d{6}) blob ([a-f\d]{40})\t/);
{ path => $path, mode_a => $mode, mode_b => $mode, blob => $blob,
- pool => SVN::Pool->new };
+ pool => SVN::Pool->new, action => 'M' };
}
sub add_file {
my ($self, $path, $pb, $cp_path, $cp_rev) = @_;
{ path => $path, mode_a => 100644, mode_b => 100644,
- pool => SVN::Pool->new };
+ pool => SVN::Pool->new, action => 'A' };
}
sub change_file_prop {
@@ -3493,8 +3489,7 @@ sub close_file {
$fb->{pool}->clear;
my $gui = $self->{gui};
print $gui "$fb->{mode_b} $hash\t$path\0" or croak $!;
- print "\t", $self->{paths}->{$path}->action,
- "\t$path\n" if defined $self->{paths}->{$path};
+ print "\t$fb->{action}\t$path\n" if $fb->{action} && ! $self->{q};
undef;
}
--
1.4.4.1.g22a08
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-11-28 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <456C0313.3020308@op5.se>
On Tuesday 2006 November 28 09:36, Andreas Ericsson wrote:
> I'd actually prefer the second solution here and let git print a list of
> submodules with dirty state and ask for some sort of user-response
> before creating the actual commit. As non-interactive commits should
> always be clean, requiring user intervention on non-clean state should
> be a safe thing to do.
I'd agree. However, is there a need to require user intervention? Can we not
make the following analogies to normal git operation:
file in working directory -> submodule working directory
file in index -> submodule repository
It's perfectly possible to make a commit with different contents in the index
and the working directory - it shows up in the git-status output very nicely.
Why not deal with submodules in the same way?
Now imagine the following repository:
file1
file2
submodule1/file3
Make changes to file2 and file3, but don't update-index or commit. git-status
would show:
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# modified: file2
# dirty: submodule1
#
nothing to commit
Now "git-update-index file2" and git-status
# Updated but not checked in:
# (will commit)
#
# modified: file2
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# dirty: submodule1/
#
Now do a commit in submodule1/ and git-status in the supermodule.
# Updated but not checked in:
# (will commit)
#
# modified: file2
# submodule: submodule1/
#
Obviously the detail would be different, but you get the idea. There is
almost no difference between git-with-submodules and git-as-normal.
I suppose there would actually need to be an extra step were the submodule is
added to the supermodule index. So really there would be three states from
git-status:
# Updated but not checked in:
# (will commit)
#
# modified: file2
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# modified: file1
# submodule: submodule1/
#
# Dirty submodules:
# (commit changes in the submodule to clean)
#
# dirty: submodule1/
#
Which means: since the last supermodule commit there has been
* a change to file2, which is in the index and would be committed.
* a change to file1, which is not in the index and won't be committed.
* a commit to submodule1, which won't be committed
* changes to the submodule working directory
This really reinforces Linus's interpretation that submodules are
directories - they would presumably just get a new object type and be
referenced in the tree object. git-update-index would be blind to dirty
submodules with no new commit, just as git-update-index on an unchanged file
has no effect.
Has this question been answered yet? How does the supermodule know which
branch to track in the submodule? Does it simply track HEAD or when the
submodule is added to the supermodule is it told which branch to track? I
suppose it's got to be HEAD really hasn't it?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [PATCH] Trim hint printed when gecos is empty.
From: Han-Wen Nienhuys @ 2006-11-28 10:27 UTC (permalink / raw)
To: git
Trim hint printed when gecos is empty.
Remove asterisks for readability
Suggest use of git-config for easy cut & pasting.
---
ident.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/ident.c b/ident.c
index efec97f..e415fd3 100644
--- a/ident.c
+++ b/ident.c
@@ -158,12 +158,17 @@ static int copy(char *buf, int size, int
static const char au_env[] = "GIT_AUTHOR_NAME";
static const char co_env[] = "GIT_COMMITTER_NAME";
static const char *env_hint =
-"\n*** Environment problem:\n"
+"\n"
"*** Your name cannot be determined from your system services (gecos).\n"
-"*** You would need to set %s and %s\n"
-"*** environment variables; otherwise you won't be able to perform\n"
-"*** certain operations because of \"empty ident\" errors.\n"
-"*** Alternatively, you can use user.name configuration variable.\n\n";
+"\n"
+"Run\n"
+"\n"
+" git repo-config user.email \"you@email.com\"\n"
+" git repo-config user.name \"Your Name\"\n"
+"\n"
+"To set the identity in this repository.\n"
+"Add --global to set your account\'s default\n"
+"\n";
static const char *get_ident(const char *name, const char *email,
const char *date_str, int error_on_no_name)
--
1.4.2.4
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Andy Whitcroft @ 2006-11-28 10:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7vd5786opj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Enough about "git commit -a" for tonight.
>
> I've been playing with a "private edition" git to see how it
> feels like to use "git commit" that defaults to the "-a"
> behaviour, using myself as a guinea pig, for the rest of the
> evening.
I for one would find this change confusing. Yes like most virgins I
found the -a being needed all the time left me with a bit of "huh, why
not turn it on by default" feeling. But as time goes by and you use git
more and start to rebase and merge and start to get those conflicts then
the index comes into focus, you can see why that 'stupid layer' is there
and its power. I am now finding myself using the index more and more as
you described as a staging ground for the 'commit in progres'.
I think the new wording in the tutorial really is a much better way
round to teach it, and would have saved me some mental movement. But
the index really is there and useful when you get beyond the trivial. I
am using git almost exclusivly in a contributer role and find it so.
my $0.02.
^ permalink raw reply
* Re: [PATCH] Teach git-branch howto rename a branch
From: Lars Hjemli @ 2006-11-28 9:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmac3qig.fsf@assigned-by-dhcp.cox.net>
On 11/28/06, Junio C Hamano <junkio@cox.net> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
> >
> > With two branchnames, the second name is renamed to the first.
>
> Thanks.
>
> "--rename newname oldname" feels funny, as already mentioned a
> few times on the list. rename(2) is "rename(old, new)" and
> mv(1) is "mv old new".
Ok, how about
git branch [-m|-M] [oldbranch] newbranch
where -m is 'move' and -M is 'force move'?
>
> + if (!rename_ref(oldref, newref) && !strcmp(oldname, head))
> + create_symref("HEAD", newref);
> +}
>
> Can create_symref() fail?
Yes... But what can been done if/when it fails? create_symref()
already seems to be pretty verbose about errors, so the only thing I
can think of is to return the errorcode to the caller (which I should
have done in the first place, git-branch ought to have a usable
exitcode)
>
> +int rename_ref(const char *oldref, const char *newref)
> +{
> + unsigned char sha1[20], orig_sha1[20];
> + int flag = 0, logmoved = 0;
> + struct ref_lock *lock;
> + char msg[PATH_MAX*2 + 100];
> + struct stat stat;
> + int log = !lstat(git_path("logs/%s", oldref), &stat);
>
> This is not wrong per-se, but it made me stop and wonder if we
> want to error out when we find out "logs/oldref" is a symlink; I
> do not think we care about it that much, but in that case we may
> want to say stat() here instead... Just a minor detail.
Well, it's a good point. If it's a symlink that's a pretty strong
indication that someone has been messing with the log for some reason,
so to error out is probably the right thing to do.
>
> + lock = lock_ref_sha1_basic("tmp-renamed-ref", NULL, NULL);
> + if (!lock)
> + return error("unable to lock tmp-renamed-ref");
> + lock->force_write = 1;
> + if (write_ref_sha1(lock, orig_sha1, msg))
> + return error("unable to save current sha1 in tmp-renamed-ref");
> + if (log && rename(git_path("logs/%s", oldref), git_path("tmp-renamed-log")))
> + return error("unable to move logfile logs/%s to tmp-renamed-log: %s",
> + oldref, strerror(errno));
>
> I am confused with this code. tmp-renamed-ref is not even a
> ref, you lock $GIT_DIR/tmp-renamed-ref and call write-ref_sha1()
> with an uninitialized msg[] buffer to write into a logfile. What
> is the name of that logfile? $GIT_DIR/log/tmp-renamed-ref???
My goal was to save the ref in a tmp-file before deleting the old ref,
not to log the event. I think of it as a way to get out of trouble if
rename_ref should fail badly.
Btw: I't _might_ be interesting to have $GIT_DIR/logs/tmp-renamed-ref
(or something similar) as a branch-independent log of branch renames
Anyway, I'l fix up the mentioned issues in a new patch
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-11-28 9:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Yann Dirson, Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0611260241320.20138@iabervon.org>
Daniel Barkalow wrote:
> On Sat, 25 Nov 2006, Linus Torvalds wrote:
>
>> On Sun, 26 Nov 2006, Yann Dirson wrote:
>>> Also, I'd rather expect "git-commit -a" outside of any submodule to
>>> commit everything in the supermodule, triggering submodule commits as an
>>> intermediate step when needed - just like "git-commit -a" does not
>>> require to manually specify subdirectories to inclue in the commit. I'd
>>> rather expect a special flag to exclude submodules from a commit.
>> So, how do you do commit messages? It generally doesn't make sense to
>> share the same commit message for submodules - the sub-commits generally
>> do different things.
>
> The same way you do the first commit message. Ask independantly for each
> commit message in sequence with enough context in the comment section that
> you know what you're talking about.
>
>> I'd actually suggest that "git commit -a" with non-clean submodules error
>> out for that reason, with something like
>>
>> submodule 'src/xyzzy' is not up-to-date, please commit changes to
>> that first.
>>
>> exactly because you really generally should consider the submodule commits
>> to be a separate phase.
>
> I think this is getting close to the classic usability blunder of having
> the program tell you what you should have done instead of what you did,
> and then making you do it yourself, rather than just doing it.
>
> Just have it run "git commit -a" in each dirty submodule recursively as
> part of preparing the index, since that's what the user wants to do
> anyway, and nothing already done would be affected.
>
Running "commit -a" is definitely the wrong thing to do, as it prevents
one from using the index at all. Erroring out if the submodules are
dirty, or just accepting the fact that they are and taking whatever
commit HEAD points to is *always* preferrable.
I'd actually prefer the second solution here and let git print a list of
submodules with dirty state and ask for some sort of user-response
before creating the actual commit. As non-interactive commits should
always be clean, requiring user intervention on non-clean state should
be a safe thing to do.
> "git commit -a -m <message>" should probably fail, of course.
>
Why? There's no reason to rob this command of its power just because
we're using submodules.
> -Daniel
> *This .sig left intentionally blank*
> -
> 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
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Hyphens and hiding core commands
From: Junio C Hamano @ 2006-11-28 9:15 UTC (permalink / raw)
To: Theodore Tso; +Cc: Carl Worth, git
In-Reply-To: <20061128054032.GC11122@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> Carl was saying that the totorial should be changed to do this. I
> would change "perhaps" to "DEFINITELY".
You are right.
How about doing something like this? I tried to make it neutral
to be usable whichever default we end up taking.
---
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 35af81a..5ddd2e9 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -11,6 +11,18 @@ diff" with:
$ man git-diff
------------------------------------------------
+It is a good idea to introduce yourself to git before doing any
+operation. The easiest way to do so is:
+
+------------------------------------------------
+$ cat >~/.gitconfig
+[user]
+ name = Your Name Comes Here
+ email = you@yourdomain.example.com
+^D
+------------------------------------------------
+
+
Importing a new project
-----------------------
@@ -31,7 +43,8 @@ defaulting to local storage area
You've now initialized the working directory--you may notice a new
directory created, named ".git". Tell git that you want it to track
-every file under the current directory with
+every file under the current directory with (notice the dot '.'
+that means the current directory):
------------------------------------------------
$ git add .
@@ -40,7 +53,7 @@ $ git add .
Finally,
------------------------------------------------
-$ git commit -a
+$ git commit
------------------------------------------------
will prompt you for a commit message, then record the current state
@@ -55,11 +68,17 @@ $ git diff
to review your changes. When you're done,
------------------------------------------------
-$ git commit -a
+$ git commit file1 file2...
------------------------------------------------
will again prompt your for a message describing the change, and then
-record the new versions of the modified files.
+record the new versions of the files you listed. It is cumbersome
+to list all files and you can say `-a` (which stands for 'all')
+instead.
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
A note on commit messages: Though not required, it's a good idea to
begin the commit message with a single short (less than 50 character)
@@ -75,7 +94,7 @@ $ git add path/to/new/file
------------------------------------------------
then commit as usual. No special command is required when removing a
-file; just remove it, then commit.
+file; just remove it, then tell `commit` about the file as usual.
At any point you can view the history of your changes using
^ permalink raw reply related
* Re: Git and Mozilla
From: Andy Parkins @ 2006-11-28 9:13 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910611272247y7ef8be0fh2f1436d43a57280@mail.gmail.com>
On Tuesday 2006 November 28 06:47, Jon Smirl wrote:
> It looks like git is out of the race for hosting the Mozilla repository.
> It's going to be Bazaar or Mercurial.
This is probably a good thing; Bazaar and Mercurial are both more similar in
model to git than SVN; so conversion between them and git will be far easier.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH 2/2] git-commit: make '-a' the default.
From: Jakub Narebski @ 2006-11-28 9:09 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7pw5a4d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> At the same time, stop talking about "--only" option being the
> default when given paths. It has been that way for quite some
> time.
>
> This change breaks t1400 which assumed the long tradition of not
> modifying index when not told to touch it with an explicit -a
> nor paths, so this commit includes adjustment for it as well.
Perhaps we should make it configuration option instead? I usually use
"git commit -a -s"; I add -s anyway, so adding -a is not that much more.
By the way, if I understand correctly git-resolve is meant as restricted
git-update-index, which can _only_ mark file as resolved (and probably
check for merge markers, unless --force'd).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Teach git-branch howto rename a branch
From: Junio C Hamano @ 2006-11-28 8:49 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1164679287192-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> This adds a '--rename' option to git branch. If specified, branch
> creation becomes branch renaming.
>
> With a single branchname, the current branch is renamed and .git/HEAD is
> updated.
>
> With two branchnames, the second name is renamed to the first.
Thanks.
"--rename newname oldname" feels funny, as already mentioned a
few times on the list. rename(2) is "rename(old, new)" and
mv(1) is "mv old new".
> This seems to do the right thing for both refs and reflogs, but 'make test'
> probably should be expanded with some evil test-cases to confirm my manual
> testing.
Certainly. Let's keep discipline to have tests and docs for new
features.
+static void rename_branch(const char *oldname, const char *newname, int force)
+{
+ char oldref[PATH_MAX], newref[PATH_MAX];
+ unsigned char sha1[20];
+
+ snprintf(oldref, sizeof oldref, "refs/heads/%s", oldname);
+ if (check_ref_format(oldref))
+ die("Invalid branch name: %s", oldref);
Although "sizeof type" is valid C, we tend to prefer
"sizeof(type)". If you use snprintf(), it would make sense to
check its return value.
+ if (resolve_ref(newref, sha1, 1, NULL) && !force)
+ die("A branch named '%s' already exists.\n", newname);
No trailing '\n' is necessary for die().
+ if (!rename_ref(oldref, newref) && !strcmp(oldname, head))
+ create_symref("HEAD", newref);
+}
Can create_symref() fail?
+int rename_ref(const char *oldref, const char *newref)
+{
+ unsigned char sha1[20], orig_sha1[20];
+ int flag = 0, logmoved = 0;
+ struct ref_lock *lock;
+ char msg[PATH_MAX*2 + 100];
+ struct stat stat;
+ int log = !lstat(git_path("logs/%s", oldref), &stat);
This is not wrong per-se, but it made me stop and wonder if we
want to error out when we find out "logs/oldref" is a symlink; I
do not think we care about it that much, but in that case we may
want to say stat() here instead... Just a minor detail.
+ lock = lock_ref_sha1_basic("tmp-renamed-ref", NULL, NULL);
+ if (!lock)
+ return error("unable to lock tmp-renamed-ref");
+ lock->force_write = 1;
+ if (write_ref_sha1(lock, orig_sha1, msg))
+ return error("unable to save current sha1 in tmp-renamed-ref");
+ if (log && rename(git_path("logs/%s", oldref), git_path("tmp-renamed-log")))
+ return error("unable to move logfile logs/%s to tmp-renamed-log: %s",
+ oldref, strerror(errno));
I am confused with this code. tmp-renamed-ref is not even a
ref, you lock $GIT_DIR/tmp-renamed-ref and call write-ref_sha1()
with an uninitialized msg[] buffer to write into a logfile. What
is the name of that logfile? $GIT_DIR/log/tmp-renamed-ref???
^ permalink raw reply
* Re: Possible BUG with git-rev-list --all in a StGit repository
From: Junio C Hamano @ 2006-11-28 8:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: catalin.marinas, Git Mailing List
In-Reply-To: <e5bfff550611272357w33756febud0bbbe59e2e1e140@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
>> If you (as a Porcelain) want to get all refs under refs/heads/,
>> there are (unfortunately) two ways to get that list. I would
>> suggest obtain the refs you want that way, pass them as command
>> line arguments to rev-list.
>
> Unfortunatly that does not work in case a branch and a tag have the same name.
I am not quite grokking what the problem you are trying to solve
is, so this is a shot in the dark, but
git rev-list refs/heads/test refs/tags/test
to disambiguate, perhaps?
^ permalink raw reply
* Re: [PATCH] Teach git-branch howto rename a branch
From: Jakub Narebski @ 2006-11-28 8:07 UTC (permalink / raw)
To: git
In-Reply-To: <1164679287192-git-send-email-hjemli@gmail.com>
Lars Hjemli wrote:
> This adds a '--rename' option to git branch. If specified, branch
> creation becomes branch renaming.
>
> With a single branchname, the current branch is renamed and .git/HEAD is
> updated.
>
> With two branchnames, the second name is renamed to the first.
Could you please document this new feature?
And wouldn't it be better to use <source> <target>, aka <branch> <newname>
like in git-mv and other rename/move commands? "Second name is renamed to
the first" although fits with "<branchname> [<start-point>]" is not natural
for rename.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Possible BUG with git-rev-list --all in a StGit repository
From: Marco Costalba @ 2006-11-28 7:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: catalin.marinas, Git Mailing List
In-Reply-To: <7vzmadl5b0.fsf@assigned-by-dhcp.cox.net>
On 11/27/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > Could a possible '--all-branches' new option come to rescue?
>
> I doubt it. Next thing people would start talking about is what
> to do with the remote tracking branches, and what we are talking
> about is rev-list, one of the lower level of plumbing that would
> be better left without knowing much about the Porcelain's use of
> refs/ namespaces.
>
> If you (as a Porcelain) want to get all refs under refs/heads/,
> there are (unfortunately) two ways to get that list. I would
> suggest obtain the refs you want that way, pass them as command
> line arguments to rev-list.
>
Unfortunatly that does not work in case a branch and a tag have the same name.
I was bitten by this trying to do what you now suggest, there were a
tag and a branch called 'test', and calling
git-rev-list master origin test
raised a warning.
Only among the _same_ 'family' (branches, tags, etc..) unique names
are enforced.
^ permalink raw reply
* Re: [PATCH 12/10] Teach bash about git-repo-config.
From: Shawn Pearce @ 2006-11-28 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodqscqty.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Yes, that's it. I'm finally done tinkering with bash
> > completion support for this week. Total of 12 patches.
>
> Thanks. I saw a funky behaviour when I tried this:
>
> $ git pull . ap<TAB>
>
> ==>
> $ git pull . apfatal: Not a git repository: '.'
Doh. Its the commit titled "Support bash completion of refs/remote".
The problem is I'm invoking git-for-each-ref wrong:
git --git-dir=. for-each-ref ...
Clearly "." isn't a git directory. But ./.git is. The breakage is
the switch from git-peek-remote to git-for-each-ref. git-peek-remote
nicely realized that "." wasn't a git directory but "./.git" was
and went into ./.git to get the refs. I switched to for-each-ref
to get a potential speed boost (no need to dereference tags) but
broke the damn thing in the process.
I thought I had tested this for-each-ref change out. Apparently I
missed a case.
I'll fix it tomorrow.
--
^ permalink raw reply
* Re: Git and Mozilla
From: Shawn Pearce @ 2006-11-28 7:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910611272247y7ef8be0fh2f1436d43a57280@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> It looks like git is out of the race for hosting the Mozilla repository.
> It's going to be Bazaar or Mercurial.
>
> http://weblogs.mozillazine.org/preed/2006/11/version_control_system_shootou.html#more
And entirely over the one issue we all thought it was going to be:
native win32 support. I guess nobody is surprised by that one bit.
--
^ permalink raw reply
* [PATCH 2/2] git-commit: make '-a' the default.
From: Junio C Hamano @ 2006-11-28 7:00 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <7vk61gcnzl.fsf@assigned-by-dhcp.cox.net>
At the same time, stop talking about "--only" option being the
default when given paths. It has been that way for quite some
time.
This change breaks t1400 which assumed the long tradition of not
modifying index when not told to touch it with an explicit -a
nor paths, so this commit includes adjustment for it as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-commit.sh | 13 ++++++-------
t/t1400-update-ref.sh | 4 ++--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 6c95817..655340c 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -292,13 +292,12 @@ case "$#,$also,$only,$amend" in
0,,t,)
die "No paths with --only does not make sense." ;;
0,,t,t)
- only_include_assumed="# Clever... amending the last one with dirty index." ;;
+ only_include_assumed="Clever... amending the last one with dirty index." ;;
0,,,*)
- : all=t
- only_include_assumed="# We will start assuming -a without -i; you have been warned."
+ all=t
+ only_include_assumed="No -o nor -i is given; committing --all"
;;
*,,,*)
- only_include_assumed="# Explicit paths specified without -i nor -o; assuming --only paths..."
also=
;;
esac
@@ -542,9 +541,9 @@ then
echo "# Please enter the commit message for your changes."
echo "# (Comment lines starting with '#' will not be included)"
test -z "$only_include_assumed" || {
- echo "#"
- echo "$only_include_assumed"
- echo "#"
+ echo "################################################"
+ echo "# $only_include_assumed"
+ echo "################################################"
}
run_status
} >>"$GIT_DIR"/COMMIT_EDITMSG
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 6a917f2..1580224 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -200,13 +200,13 @@ test_expect_success \
h_OTHER=$(git-rev-parse --verify HEAD) &&
echo FIXED >F &&
GIT_AUTHOR_DATE="2005-05-26 23:44" \
- GIT_COMMITTER_DATE="2005-05-26 23:44" git-commit --amend &&
+ GIT_COMMITTER_DATE="2005-05-26 23:44" git-commit --amend -i &&
h_FIXED=$(git-rev-parse --verify HEAD) &&
echo TEST+FIXED >F &&
echo Merged initial commit and a later commit. >M &&
echo $h_TEST >.git/MERGE_HEAD &&
GIT_AUTHOR_DATE="2005-05-26 23:45" \
- GIT_COMMITTER_DATE="2005-05-26 23:45" git-commit -F M &&
+ GIT_COMMITTER_DATE="2005-05-26 23:45" git-commit -F M -i &&
h_MERGED=$(git-rev-parse --verify HEAD)
rm -f M'
--
1.4.4.1.gcee8-dirty
^ permalink raw reply related
* [PATCH 1/2] git-commit: prepare to make '-a' behaviour the default.
From: Junio C Hamano @ 2006-11-28 7:00 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <7vk61gcnzl.fsf@assigned-by-dhcp.cox.net>
This makes "git commit" accept "-i" without any parameter (we
used to barf on such a command line) to mean "commit what is in
the index as-is". There is nothing surprising about this new
behaviour. "git commit -i paths..." means "in addition to the
changes I accumulated in the index, also run update-index on
these paths and then make a commit" and this new behaviour is a
natural extension to that to the case where "paths..." is empty.
"git commit" without -i, -a, nor -o still behave the same way as
it has done for a long time, but it now warns that this will be
changed to default to the "-a" behaviour.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-commit.sh | 30 ++++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..6c95817 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -11,10 +11,10 @@ git-rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t
branch=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD)
case "$0" in
-*status)
+*status|*status.sh)
status_only=t
unmerged_ok_if_status=--unmerged ;;
-*commit)
+*commit|*commit.sh)
status_only=
unmerged_ok_if_status= ;;
esac
@@ -287,11 +287,15 @@ esac
case "$#,$also,$only,$amend" in
*,t,t,*)
die "Only one of --include/--only can be used." ;;
-0,t,,* | 0,,t,)
- die "No paths with --include/--only does not make sense." ;;
+0,t,,*)
+ ;;
+0,,t,)
+ die "No paths with --only does not make sense." ;;
0,,t,t)
only_include_assumed="# Clever... amending the last one with dirty index." ;;
0,,,*)
+ : all=t
+ only_include_assumed="# We will start assuming -a without -i; you have been warned."
;;
*,,,*)
only_include_assumed="# Explicit paths specified without -i nor -o; assuming --only paths..."
@@ -304,8 +308,6 @@ t,t,*)
die "Cannot use -a and -i at the same time." ;;
t,,[1-9]*)
die "Paths with -a does not make sense." ;;
-,t,0)
- die "No paths with -i does not make sense." ;;
esac
################################################################
@@ -317,8 +319,8 @@ then
TOP=./
fi
-case "$all,$also" in
-t,)
+case "$all,$also,$#" in
+t,,*)
save_index &&
(
cd "$TOP"
@@ -328,7 +330,7 @@ t,)
git-update-index --remove -z --stdin
)
;;
-,t)
+,t,[1-9]*)
save_index &&
git-ls-files --error-unmatch -- "$@" >/dev/null || exit
@@ -340,7 +342,7 @@ t,)
git-update-index --remove -z --stdin
)
;;
-,)
+,,* | ,t,0)
case "$#" in
0)
;; # commit as-is
@@ -407,7 +409,7 @@ GIT_INDEX_FILE="$USE_INDEX" \
# If the request is status, just show it and exit.
case "$0" in
-*status)
+*status|*status.sh)
run_status
exit $?
esac
@@ -539,7 +541,11 @@ then
echo ""
echo "# Please enter the commit message for your changes."
echo "# (Comment lines starting with '#' will not be included)"
- test -z "$only_include_assumed" || echo "$only_include_assumed"
+ test -z "$only_include_assumed" || {
+ echo "#"
+ echo "$only_include_assumed"
+ echo "#"
+ }
run_status
} >>"$GIT_DIR"/COMMIT_EDITMSG
else
--
1.4.4.1.gcee8-dirty
^ permalink raw reply related
* [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Junio C Hamano @ 2006-11-28 6:59 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <7vk61gcnzl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Enough about "git commit -a" for tonight.
I've been playing with a "private edition" git to see how it
feels like to use "git commit" that defaults to the "-a"
behaviour, using myself as a guinea pig, for the rest of the
evening.
Confession time. I've had a "purist me" deep inside, who always
thought that people who play contributor role (that is to say
"99.9% of people") should make no commits other than the "-a"
kind [*1*]. So this is not only trying out the issues in the
discussion I had with you, but what that "other me" wanted to do
for quite some time.
A pair of patches will follow this message and I encourage you
to try it out, work with it for a dozen or so commits, handful
of merges, a patch application or two to get part of changes
from different commits (not a "git format-patch | git am" to get
another commit wholesale, but "git apply" followed by your own
edits that eventually result in "git commit"), a few rebases and
resets. If you have a few new people you can sacrifice their
"git virginity" for experimenting this on, I am reasonably sure
they will like it, but I do not know how their learning curve
later will be affected by this change -- it would be interesting
to know. I do not think it would flatten the learning curve of
index much. I am somewhat fearful that it might make it harder,
but I lost my git virginity long time ago, so it is just an
unsubstantiated feeling.
Judging from my experience so far, although I really wanted to
like this, I am still hesitant to recommend this for inclusion.
It does not make any difference while I am doing the simplest
operation (it is just not having to say "-a"), so I do not
foresee problems either way for new people following a saner
version of tutorial, which does not exist yet, that does not
talk much about "git commit -a".
The problem I have with the new behaviour is that it goes
against the mental model when I start doing anything nontrivial
(I would not use words as strong as "totally breaks the mental
model", but it comes close). I am not sure how well I can
express this, but the short of it is that "grokking index" is
not about understanding how the index works, but about trusting
that git does the right thing to the index and you do not have
to worry about it all the time.
For example, "git apply --index" will update the index for paths
that the patch I feed it talks about (and reminds me if I have
local changes to them by refusing to lose my changes) so after
it finishes successfully, I do not have to think about the index
at all [*2*]. After working on a few files, I can ask "git
diff" to see if the changes so far are reasonable, and mark them
with "git update-index" so that I do not have to worry about
them anymore and keep going to make matching changes to other
files. Once I tell something to git via index, I do not have to
worry about it, and this is a big relief.
The same thing can be said about "git merge" (or "git pull .").
The index is updated for cleanly merged paths so I do not have
to worry about the details -- the only thing I have to know is
that index keeps track of the state and cleanly merged paths are
taken care of for me automatically, so I do not have to worry
about them. "git diff" and "git ls-files -u" will give me
conflicting paths and I can only concentrate on them.
Once I am done, I can ask "git diff" and expect it to show my
local changes I have no intention of committing for now
(e.g. GIT-VERSION-GEN in the working tree has v1.4.5-rc1.GIT
long before I plan to start the rc1 cycle to constantly remind
me what the next version will be, which is a trick I picked up
from Linus), and "git diff --cached" would show exactly what I
will commit.
And at that point, I trust "git commit" to do the right thing --
the damn thing I just checked with "git diff --cached" _is_ what
will be committed. In that sense, I do not have to think about
the index at all, because I know git is doing appropriate things
behind the scene for me.
Coming from this perspective, having to say "git commit -i" at
the time of making the commit just makes me feel uneasy, if not
counterintuitive. Making "git commit" default to "-a" rubs this
mental model quite the wrong way.
Probably new people who are not used to the index do not have
this problem, but I suspect I am not alone among old time
gitters.
I lost about half an hour after saying "git commit --amend",
without thinking, because I wanted to amend only the commit
message, and much later I noticed that it swallowed unrelated
changes I had in the working tree because it now implied the
"-a" behaviour, and I should have said "git commit -i --amend".
I needed to redo bunch of commits, which involved having to
re-test a handful revisions (this is not git.git project but my
day job one -- I do not work on it after work, but I was doing
the guinea pig). But this is something re-training can fix and
much a smaller problem than the mental model issue.
[Footnote]
*1* The reason to favor "-a" commit is not about hiding the
index but about discipline. For the "integrator" people to be
able to coast over the changes, they need to be able to trust
the work by contributors to some degree without worrying about
small details; the changes fed to the integrators must be well
tested when they leave the hand of a contributor, and making a
commit that never existed as a whole in the working tree goes
against this discipline.
*2* It might be a good idea to make "--index" the default for
"git apply" when we know we are in a git repository ("git apply"
must be usable outside a git repository so this needs to be
handled with care if somebody wants to do it). There is no
"--no-index" option to countermand it right now, which also
needs to be added.
^ permalink raw reply
* Git and Mozilla
From: Jon Smirl @ 2006-11-28 6:47 UTC (permalink / raw)
To: Git Mailing List
It looks like git is out of the race for hosting the Mozilla repository.
It's going to be Bazaar or Mercurial.
http://weblogs.mozillazine.org/preed/2006/11/version_control_system_shootou.html#more
--
Jon Smirl
^ permalink raw reply
* [PATCH 2/2] git-svn: update tests for recent changes
From: Eric Wong @ 2006-11-28 5:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <loom.20061124T143148-286@post.gmane.org>
* Enable test for delta transfers in full-svn-test.
* Run tests against the root of the repository so we won't have
to revisit 308906fa6e98132cab839a4f42701386fba368ef and
efe4631def181d32f932672a7ea31e52ee0ab308 again.
The graft-branches test still runs as before.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/Makefile | 3 ++-
t/lib-git-svn.sh | 2 +-
t/t9100-git-svn-basic.sh | 5 +++++
t/t9103-git-svn-graft-branches.sh | 2 ++
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/t/Makefile b/t/Makefile
index 8983509..0abe66d 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -27,8 +27,9 @@ clean:
# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
full-svn-test:
+ $(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_DELTA_FETCH=1 \
+ GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
$(MAKE) $(TSVN) GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
- $(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
$(MAKE) $(TSVN) GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \
LC_ALL=en_US.UTF-8
$(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 29a1e72..63c6703 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -45,6 +45,6 @@ else
svnadmin create "$svnrepo"
fi
-svnrepo="file://$svnrepo/test-git-svn"
+svnrepo="file://$svnrepo"
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 34a3ccd..f9de232 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -228,6 +228,11 @@ tree 56a30b966619b863674f5978696f4a3594f
tree d667270a1f7b109f5eb3aaea21ede14b56bfdd6e
tree 8f51f74cf0163afc9ad68a4b1537288c4558b5a4
EOF
+
+if test -z "$GIT_SVN_NO_LIB" || test "$GIT_SVN_NO_LIB" -eq 0; then
+ echo tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 >> expected
+fi
+
test_expect_success "$name" "diff -u a expected"
test_done
diff --git a/t/t9103-git-svn-graft-branches.sh b/t/t9103-git-svn-graft-branches.sh
index cc62d4e..293b98f 100755
--- a/t/t9103-git-svn-graft-branches.sh
+++ b/t/t9103-git-svn-graft-branches.sh
@@ -1,6 +1,8 @@
test_description='git-svn graft-branches'
. ./lib-git-svn.sh
+svnrepo="$svnrepo/test-git-svn"
+
test_expect_success 'initialize repo' "
mkdir import &&
cd import &&
--
1.4.4.1.g22a08
^ permalink raw reply related
* [PATCH 1/2] git-svn: enable delta transfers during fetches when using SVN:: libs
From: Eric Wong @ 2006-11-28 5:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pazu
In-Reply-To: <loom.20061124T143148-286@post.gmane.org>
This should drastically reduce bandwidth used for network
transfers. This is not enabled for file:// repositories by
default because of the increased CPU usage and I/O needed.
GIT_SVN_DELTA_FETCH may be set to a true value to enable or
false (0) to disable delta transfers regardless of the
repository type.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 194 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 189 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d5d9c49..9b86d91 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -68,7 +68,7 @@ my ($_revision,$_stdin,$_no_ignore_ext,$
$_limit, $_verbose, $_incremental, $_oneline, $_l_fmt, $_show_commit,
$_version, $_upgrade, $_authors, $_branch_all_refs, @_opt_m,
$_merge, $_strategy, $_dry_run, $_ignore_nodate, $_non_recursive,
- $_username, $_config_dir, $_no_auth_cache);
+ $_username, $_config_dir, $_no_auth_cache, $_xfer_delta);
my (@_branch_from, %tree_map, %users, %rusers, %equiv);
my ($_svn_co_url_revs, $_svn_pg_peg_revs);
my @repo_path_split_cache;
@@ -2675,6 +2675,9 @@ sub libsvn_load {
require SVN::Ra;
require SVN::Delta;
push @SVN::Git::Editor::ISA, 'SVN::Delta::Editor';
+ push @SVN::Git::Fetcher::ISA, 'SVN::Delta::Editor';
+ *SVN::Git::Fetcher::process_rm = *process_rm;
+ *SVN::Git::Fetcher::safe_qx = *safe_qx;
my $kill_stupid_warnings = $SVN::Node::none.$SVN::Node::file.
$SVN::Node::dir.$SVN::Node::unknown.
$SVN::Node::none.$SVN::Node::file.
@@ -2827,6 +2830,13 @@ sub libsvn_connect {
config => $config,
pool => SVN::Pool->new,
auth_provider_callbacks => $callbacks);
+
+ my $df = $ENV{GIT_SVN_DELTA_FETCH};
+ if (defined $df) {
+ $_xfer_delta = $df;
+ } else {
+ $_xfer_delta = ($url =~ m#^file://#) ? undef : 1;
+ }
$ra->{svn_path} = $url;
$ra->{repos_root} = $ra->get_repos_root;
$ra->{svn_path} =~ s#^\Q$ra->{repos_root}\E/*##;
@@ -2915,6 +2925,24 @@ sub process_rm {
}
sub libsvn_fetch {
+ $_xfer_delta ? libsvn_fetch_delta(@_) : libsvn_fetch_full(@_);
+}
+
+sub libsvn_fetch_delta {
+ my ($last_commit, $paths, $rev, $author, $date, $msg) = @_;
+ my $pool = SVN::Pool->new;
+ my $ed = SVN::Git::Fetcher->new({ c => $last_commit, ra => $SVN,
+ paths => $paths });
+ my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
+ my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
+ my (undef, $last_rev, undef) = cmt_metadata($last_commit);
+ $reporter->set_path('', $last_rev, 0, @lock, $pool);
+ $reporter->finish_report($pool);
+ $pool->clear;
+ libsvn_log_entry($rev, $author, $date, $msg, [$last_commit]);
+}
+
+sub libsvn_fetch_full {
my ($last_commit, $paths, $rev, $author, $date, $msg) = @_;
open my $gui, '| git-update-index -z --index-info' or croak $!;
my @amr;
@@ -3133,7 +3161,11 @@ sub libsvn_find_parent_branch {
unlink $GIT_SVN_INDEX;
print STDERR "Found branch parent: ($GIT_SVN) $parent\n";
sys(qw/git-read-tree/, $parent);
- return libsvn_fetch($parent, $paths, $rev,
+ # I can't seem to get do_switch() to work correctly with
+ # the SWIG interface (TypeError when passing switch_url...),
+ # so we'll unconditionally bypass the delta interface here
+ # for now
+ return libsvn_fetch_full($parent, $paths, $rev,
$author, $date, $msg);
}
print STDERR "Nope, branch point not imported or unknown\n";
@@ -3153,9 +3185,19 @@ sub libsvn_new_tree {
return $log_entry;
}
my ($paths, $rev, $author, $date, $msg) = @_;
- open my $gui, '| git-update-index -z --index-info' or croak $!;
- libsvn_traverse($gui, '', $SVN->{svn_path}, $rev);
- close $gui or croak $?;
+ if ($_xfer_delta) {
+ my $pool = SVN::Pool->new;
+ my $ed = SVN::Git::Fetcher->new({paths => $paths, ra => $SVN});
+ my $reporter = $SVN->do_update($rev, '', 1, $ed, $pool);
+ my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
+ $reporter->set_path('', $rev, 1, @lock, $pool);
+ $reporter->finish_report($pool);
+ $pool->clear;
+ } else {
+ open my $gui, '| git-update-index -z --index-info' or croak $!;
+ libsvn_traverse($gui, '', $SVN->{svn_path}, $rev);
+ close $gui or croak $?;
+ }
return libsvn_log_entry($rev, $author, $date, $msg);
}
@@ -3325,6 +3367,148 @@ sub copy_remote_ref {
"refs/remotes/$GIT_SVN on $origin\n";
}
}
+package SVN::Git::Fetcher;
+use vars qw/@ISA/;
+use strict;
+use warnings;
+use Carp qw/croak/;
+use IO::File qw//;
+
+# file baton members: path, mode_a, mode_b, pool, fh, blob, base
+sub new {
+ my ($class, $git_svn) = @_;
+ my $self = SVN::Delta::Editor->new;
+ bless $self, $class;
+ open my $gui, '| git-update-index -z --index-info' or croak $!;
+ $self->{gui} = $gui;
+ $self->{c} = $git_svn->{c} if exists $git_svn->{c};
+ if (my $p = $git_svn->{paths} && $git_svn->{ra}) {
+ my $s = $git_svn->{ra}->{svn_path};
+ $s = length $s ? qr#^/\Q$s\E/# : qr#^/#;
+ $self->{paths} = { map { my $x = $_;
+ $x =~ s/$s//;
+ $x => $p->{$_} } keys %$p };
+ }
+ require Digest::MD5;
+ $self;
+}
+
+sub delete_entry {
+ my ($self, $path, $rev, $pb) = @_;
+ process_rm($self->{gui}, $self->{c}, $path);
+ undef;
+}
+
+sub open_file {
+ my ($self, $path, $pb, $rev) = @_;
+ my ($mode, $blob) = (safe_qx('git-ls-tree',$self->{c},'--',$path)
+ =~ /^(\d{6}) blob ([a-f\d]{40})\t/);
+ { path => $path, mode_a => $mode, mode_b => $mode, blob => $blob,
+ pool => SVN::Pool->new };
+}
+
+sub add_file {
+ my ($self, $path, $pb, $cp_path, $cp_rev) = @_;
+ { path => $path, mode_a => 100644, mode_b => 100644,
+ pool => SVN::Pool->new };
+}
+
+sub change_file_prop {
+ my ($self, $fb, $prop, $value) = @_;
+ if ($prop eq 'svn:executable') {
+ if ($fb->{mode_b} != 120000) {
+ $fb->{mode_b} = defined $value ? 100755 : 100644;
+ }
+ } elsif ($prop eq 'svn:special') {
+ $fb->{mode_b} = defined $value ? 120000 : 100644;
+ }
+ undef;
+}
+
+sub apply_textdelta {
+ my ($self, $fb, $exp) = @_;
+ my $fh = IO::File->new_tmpfile;
+ $fh->autoflush(1);
+ # $fh gets auto-closed() by SVN::TxDelta::apply(),
+ # (but $base does not,) so dup() it for reading in close_file
+ open my $dup, '<&', $fh or croak $!;
+ my $base = IO::File->new_tmpfile;
+ $base->autoflush(1);
+ if ($fb->{blob}) {
+ defined (my $pid = fork) or croak $!;
+ if (!$pid) {
+ open STDOUT, '>&', $base or croak $!;
+ print STDOUT 'link ' if ($fb->{mode_a} == 120000);
+ exec qw/git-cat-file blob/, $fb->{blob} or croak $!;
+ }
+ waitpid $pid, 0;
+ croak $? if $?;
+
+ if (defined $exp) {
+ seek $base, 0, 0 or croak $!;
+ my $md5 = Digest::MD5->new;
+ $md5->addfile($base);
+ my $got = $md5->hexdigest;
+ die "Checksum mismatch: $fb->{path} $fb->{blob}\n",
+ "expected: $exp\n",
+ " got: $got\n" if ($got ne $exp);
+ }
+ }
+ seek $base, 0, 0 or croak $!;
+ $fb->{fh} = $dup;
+ $fb->{base} = $base;
+ [ SVN::TxDelta::apply($base, $fh, undef, $fb->{path}, $fb->{pool}) ];
+}
+
+sub close_file {
+ my ($self, $fb, $exp) = @_;
+ my $hash;
+ my $path = $fb->{path};
+ if (my $fh = $fb->{fh}) {
+ seek($fh, 0, 0) or croak $!;
+ my $md5 = Digest::MD5->new;
+ $md5->addfile($fh);
+ my $got = $md5->hexdigest;
+ die "Checksum mismatch: $path\n",
+ "expected: $exp\n got: $got\n" if ($got ne $exp);
+ seek($fh, 0, 0) or croak $!;
+ if ($fb->{mode_b} == 120000) {
+ read($fh, my $buf, 5) == 5 or croak $!;
+ $buf eq 'link ' or die "$path has mode 120000",
+ "but is not a link\n";
+ }
+ defined(my $pid = open my $out,'-|') or die "Can't fork: $!\n";
+ if (!$pid) {
+ open STDIN, '<&', $fh or croak $!;
+ exec qw/git-hash-object -w --stdin/ or croak $!;
+ }
+ chomp($hash = do { local $/; <$out> });
+ close $out or croak $!;
+ close $fh or croak $!;
+ $hash =~ /^[a-f\d]{40}$/ or die "not a sha1: $hash\n";
+ close $fb->{base} or croak $!;
+ } else {
+ $hash = $fb->{blob} or die "no blob information\n";
+ }
+ $fb->{pool}->clear;
+ my $gui = $self->{gui};
+ print $gui "$fb->{mode_b} $hash\t$path\0" or croak $!;
+ print "\t", $self->{paths}->{$path}->action,
+ "\t$path\n" if defined $self->{paths}->{$path};
+ undef;
+}
+
+sub abort_edit {
+ my $self = shift;
+ close $self->{gui};
+ $self->SUPER::abort_edit(@_);
+}
+
+sub close_edit {
+ my $self = shift;
+ close $self->{gui} or croak;
+ $self->SUPER::close_edit(@_);
+}
package SVN::Git::Editor;
use vars qw/@ISA/;
--
1.4.4.1.g22a08
^ 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