* Re: [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Johannes Schindelin @ 2007-05-09 11:04 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <0056A63A-D511-4FDD-82A6-A13B06E237E9@zib.de>
Hi,
On Wed, 9 May 2007, Steffen Prohaska wrote:
> The old implementation executed 'cvs status' for each file touched by
> the patch to be applied.
I did not follow development of that script closely, but could it be that
this is a safety valve, to make it unlikely to commit something which was
changed by somebody else in the meantime?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Git.pm: config_boolean() -> config_bool()
From: Petr Baudis @ 2007-05-09 10:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7irxko81.fsf@assigned-by-dhcp.cox.net>
On Sat, Apr 28, 2007 at 08:27:42AM CEST, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > This patch renames config_boolean() to config_bool() for consistency with
> > the commandline interface and because it is shorter but still obvious. ;-)
> > It also changes the return value from some obscure string to real Perl
> > boolean, allowing for clean user code.
>
> Doesn't this break send-email?
Oh, sorry! My grep must've been broken or something.
> > @@ -526,14 +528,16 @@ This currently wraps command('config') s
> >
> > =cut
> >
> > -sub config_boolean {
> > +sub config_bool {
> > my ($self, $var) = @_;
> > $self->repo_path()
> > or throw Error::Simple("not a repository");
> >
> > try {
> > - return $self->command_oneline('config', '--bool', '--get',
> > + my $var = $self->command_oneline('config', '--bool', '--get',
> > $var);
> > + return undef unless defined $var;
> > + return $var eq 'true';
>
> Did you mean to hide $var in the nested scope?
Hmm, I agree that having a different name for it will be more readable,
fixed.
So, I realized that I'm not sure again how to stick a mail reply and new
patch version in the same mail - originally I wanted to reply to this
mail and send the patch as another reply, but that seemed wasteful. Now
it seems that the only option is to stuff the mail reply in the diffstat
area, but I refuse to do that since that's just plainly stupid.
---
This patch renames config_boolean() to config_bool() for consistency with
the commandline interface and because it is shorter but still obvious. ;-)
It also changes the return value from some obscure string to real Perl
boolean, allowing for clean user code.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-remote.perl | 4 ++--
git-send-email.perl | 4 ++--
perl/Git.pm | 14 +++++++++-----
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl
index 52013fe..5763799 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -297,9 +297,9 @@ sub update_remote {
} elsif ($name eq 'default') {
undef @remotes;
for (sort keys %$remote) {
- my $do_fetch = $git->config_boolean("remote." . $_ .
+ my $do_fetch = $git->config_bool("remote." . $_ .
".skipDefaultUpdate");
- if (!defined($do_fetch) || $do_fetch ne "true") {
+ unless ($do_fetch) {
push @remotes, $_;
}
}
diff --git a/git-send-email.perl b/git-send-email.perl
index a6e3e02..404095f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -154,8 +154,8 @@ if ($@) {
$term = new FakeTerm "$@: going non-interactive";
}
-my $def_chain = $repo->config_boolean('sendemail.chainreplyto');
-if ($def_chain and $def_chain eq 'false') {
+my $def_chain = $repo->config_bool('sendemail.chainreplyto');
+if (defined $def_chain and not $def_chain) {
$chain_reply_to = 0;
}
diff --git a/perl/Git.pm b/perl/Git.pm
index b5b1cf5..924470a 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -516,9 +516,11 @@ sub config {
}
-=item config_boolean ( VARIABLE )
+=item config_bool ( VARIABLE )
-Retrieve the boolean configuration C<VARIABLE>.
+Retrieve the bool configuration C<VARIABLE>. The return value
+is usable as a boolean in perl (and C<undef> if it's not defined,
+of course).
Must be called on a repository instance.
@@ -526,14 +528,16 @@ This currently wraps command('config') so it is not so fast.
=cut
-sub config_boolean {
+sub config_bool {
my ($self, $var) = @_;
$self->repo_path()
or throw Error::Simple("not a repository");
try {
- return $self->command_oneline('config', '--bool', '--get',
- $var);
+ my $val = $self->command_oneline('config', '--bool', '--get',
+ $val);
+ return undef unless defined $val;
+ return $val eq 'true';
} catch Git::Error::Command with {
my $E = shift;
if ($E->value() == 1) {
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply related
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-09 10:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, bfields, junio, git
In-Reply-To: <Pine.LNX.4.64.0705091137190.4167@racer.site>
On 2007-05-09 11:38:34 +0200, Johannes Schindelin wrote:
> On Wed, 9 May 2007, Daniel Barkalow wrote:
>
> > It's kind of important to distinguish between the hex
> > representation and the octet representation, because your code
> > will not work at all if you use the wrong one. And "unsigned char
> > *" or "unsigned char[20]" is always the octets; the hex is always
> > "char *". Primarily mentioning the one that is more intuitive but
> > less frequently used doesn't help with understanding the actual
> > code.
>
> That's a really good idea, to point out that "unsigned char *"
> refers to octets, while "char *" refers to the ASCII representation.
> I will add this, together with a simple example (the initial
> commit).
That'll address my complaint nicely, I believe. It was the confusion
between these two formats that I was trying to get at.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref
From: Sven Verdoolaege @ 2007-05-09 10:33 UTC (permalink / raw)
To: Junio C Hamano, git
git-checkout is also adapted to make use of this new option
instead of the handcrafted command sequence.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
All tests pass, except the recently added cvsserver tests,
but they fail without this patch too.
Documentation/git-update-ref.txt | 5 ++++-
builtin-branch.c | 2 +-
builtin-fetch--tool.c | 2 +-
builtin-reflog.c | 2 +-
builtin-update-ref.c | 11 ++++++++---
fast-import.c | 2 +-
git-checkout.sh | 10 +---------
receive-pack.c | 2 +-
refs.c | 30 +++++++++++++++++++-----------
refs.h | 3 ++-
10 files changed, 39 insertions(+), 30 deletions(-)
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index 9424fea..f222616 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -7,7 +7,7 @@ git-update-ref - Update the object name stored in a ref safely
SYNOPSIS
--------
-'git-update-ref' [-m <reason>] (-d <ref> <oldvalue> | <ref> <newvalue> [<oldvalue>])
+'git-update-ref' [-m <reason>] (-d <ref> <oldvalue> | [--no-deref] <ref> <newvalue> [<oldvalue>])
DESCRIPTION
-----------
@@ -36,6 +36,9 @@ them and update them as a regular file (i.e. it will allow the
filesystem to follow them, but will overwrite such a symlink to
somewhere else with a regular filename).
+If --no-deref is given, <ref> itself is overwritten, rather than
+the result of following the symbolic pointers.
+
In general, using
git-update-ref HEAD "$head"
diff --git a/builtin-branch.c b/builtin-branch.c
index 7408285..6bd5843 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -462,7 +462,7 @@ static void create_branch(const char *name, const char *start_name,
die("Not a valid branch point: '%s'.", start_name);
hashcpy(sha1, commit->object.sha1);
- lock = lock_any_ref_for_update(ref, NULL);
+ lock = lock_any_ref_for_update(ref, NULL, 0);
if (!lock)
die("Failed to lock ref for update: %s.", strerror(errno));
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index 2065466..b14e78a 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -42,7 +42,7 @@ static int update_ref(const char *action,
if (!rla)
rla = "(reflog update)";
snprintf(msg, sizeof(msg), "%s: %s", rla, action);
- lock = lock_any_ref_for_update(refname, oldval);
+ lock = lock_any_ref_for_update(refname, oldval, 0);
if (!lock)
return 1;
if (write_ref_sha1(lock, sha1, msg) < 0)
diff --git a/builtin-reflog.c b/builtin-reflog.c
index 4c39f1d..ce093ca 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -249,7 +249,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
/* we take the lock for the ref itself to prevent it from
* getting updated.
*/
- lock = lock_any_ref_for_update(ref, sha1);
+ lock = lock_any_ref_for_update(ref, sha1, 0);
if (!lock)
return error("cannot lock ref '%s'", ref);
log_file = xstrdup(git_path("logs/%s", ref));
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index 5ee960b..feac2ed 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -3,16 +3,17 @@
#include "builtin.h"
static const char git_update_ref_usage[] =
-"git-update-ref [-m <reason>] (-d <refname> <value> | <refname> <value> [<oldval>])";
+"git-update-ref [-m <reason>] (-d <refname> <value> | [--no-deref] <refname> <value> [<oldval>])";
int cmd_update_ref(int argc, const char **argv, const char *prefix)
{
const char *refname=NULL, *value=NULL, *oldval=NULL, *msg=NULL;
struct ref_lock *lock;
unsigned char sha1[20], oldsha1[20];
- int i, delete;
+ int i, delete, ref_flags;
delete = 0;
+ ref_flags = 0;
git_config(git_default_config);
for (i = 1; i < argc; i++) {
@@ -30,6 +31,10 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
delete = 1;
continue;
}
+ if (!strcmp("--no-deref", argv[i])) {
+ ref_flags |= REF_NODEREF;
+ continue;
+ }
if (!refname) {
refname = argv[i];
continue;
@@ -59,7 +64,7 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
if (oldval && *oldval && get_sha1(oldval, oldsha1))
die("%s: not a valid old SHA1", oldval);
- lock = lock_any_ref_for_update(refname, oldval ? oldsha1 : NULL);
+ lock = lock_any_ref_for_update(refname, oldval ? oldsha1 : NULL, ref_flags);
if (!lock)
die("%s: cannot lock the ref", refname);
if (write_ref_sha1(lock, sha1, msg) < 0)
diff --git a/fast-import.c b/fast-import.c
index 3a2d5ed..ffa00fd 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1271,7 +1271,7 @@ static int update_branch(struct branch *b)
if (read_ref(b->name, old_sha1))
hashclr(old_sha1);
- lock = lock_any_ref_for_update(b->name, old_sha1);
+ lock = lock_any_ref_for_update(b->name, old_sha1, 0);
if (!lock)
return error("Unable to lock %s", b->name);
if (!force_update && !is_null_sha1(old_sha1)) {
diff --git a/git-checkout.sh b/git-checkout.sh
index ed7c2c5..6b6facf 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -270,15 +270,7 @@ if [ "$?" -eq 0 ]; then
fi
elif test -n "$detached"
then
- # NEEDSWORK: we would want a command to detach the HEAD
- # atomically, instead of this handcrafted command sequence.
- # Perhaps:
- # git update-ref --detach HEAD $new
- # or something like that...
- #
- git-rev-parse HEAD >"$GIT_DIR/HEAD.new" &&
- mv "$GIT_DIR/HEAD.new" "$GIT_DIR/HEAD" &&
- git-update-ref -m "checkout: moving to $arg" HEAD "$detached" ||
+ git-update-ref --no-deref -m "checkout: moving to $arg" HEAD "$detached" ||
die "Cannot detach HEAD"
if test -n "$detach_warn"
then
diff --git a/receive-pack.c b/receive-pack.c
index 26aa26b..d3c422b 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -209,7 +209,7 @@ static const char *update(struct command *cmd)
return NULL; /* good */
}
else {
- lock = lock_any_ref_for_update(name, old_sha1);
+ lock = lock_any_ref_for_update(name, old_sha1, 0);
if (!lock) {
error("failed to lock %s", name);
return "failed to lock";
diff --git a/refs.c b/refs.c
index 89876bf..2ae3235 100644
--- a/refs.c
+++ b/refs.c
@@ -736,19 +736,20 @@ static int is_refname_available(const char *ref, const char *oldref,
return 1;
}
-static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char *old_sha1, int *flag)
+static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char *old_sha1, int flags, int *type_p)
{
char *ref_file;
const char *orig_ref = ref;
struct ref_lock *lock;
struct stat st;
int last_errno = 0;
+ int type;
int mustexist = (old_sha1 && !is_null_sha1(old_sha1));
lock = xcalloc(1, sizeof(struct ref_lock));
lock->lock_fd = -1;
- ref = resolve_ref(ref, lock->old_sha1, mustexist, flag);
+ ref = resolve_ref(ref, lock->old_sha1, mustexist, &type);
if (!ref && errno == EISDIR) {
/* we are trying to lock foo but we used to
* have foo/bar which now does not exist;
@@ -761,8 +762,10 @@ static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char
error("there are still refs under '%s'", orig_ref);
goto error_return;
}
- ref = resolve_ref(orig_ref, lock->old_sha1, mustexist, flag);
+ ref = resolve_ref(orig_ref, lock->old_sha1, mustexist, &type);
}
+ if (type_p)
+ *type_p = type;
if (!ref) {
last_errno = errno;
error("unable to resolve reference %s: %s",
@@ -780,10 +783,15 @@ static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char
lock->lk = xcalloc(1, sizeof(struct lock_file));
+ if (flags & REF_NODEREF)
+ ref = orig_ref;
lock->ref_name = xstrdup(ref);
lock->orig_ref_name = xstrdup(orig_ref);
ref_file = git_path("%s", ref);
- lock->force_write = lstat(ref_file, &st) && errno == ENOENT;
+ if (lstat(ref_file, &st) && errno == ENOENT)
+ lock->force_write = 1;
+ if ((flags & REF_NODEREF) && (type & REF_ISSYMREF))
+ lock->force_write = 1;
if (safe_create_leading_directories(ref_file)) {
last_errno = errno;
@@ -806,14 +814,14 @@ struct ref_lock *lock_ref_sha1(const char *ref, const unsigned char *old_sha1)
if (check_ref_format(ref))
return NULL;
strcpy(refpath, mkpath("refs/%s", ref));
- return lock_ref_sha1_basic(refpath, old_sha1, NULL);
+ return lock_ref_sha1_basic(refpath, old_sha1, 0, NULL);
}
-struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1)
+struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
{
if (check_ref_format(ref) == -1)
return NULL;
- return lock_ref_sha1_basic(ref, old_sha1, NULL);
+ return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
}
static struct lock_file packlock;
@@ -858,7 +866,7 @@ int delete_ref(const char *refname, const unsigned char *sha1)
struct ref_lock *lock;
int err, i, ret = 0, flag = 0;
- lock = lock_ref_sha1_basic(refname, sha1, &flag);
+ lock = lock_ref_sha1_basic(refname, sha1, 0, &flag);
if (!lock)
return 1;
if (!(flag & REF_ISPACKED)) {
@@ -909,7 +917,7 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
if (!is_refname_available(newref, oldref, get_loose_refs(), 0))
return 1;
- lock = lock_ref_sha1_basic(renamed_ref, NULL, NULL);
+ lock = lock_ref_sha1_basic(renamed_ref, NULL, 0, NULL);
if (!lock)
return error("unable to lock %s", renamed_ref);
lock->force_write = 1;
@@ -963,7 +971,7 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
}
logmoved = log;
- lock = lock_ref_sha1_basic(newref, NULL, NULL);
+ lock = lock_ref_sha1_basic(newref, NULL, 0, NULL);
if (!lock) {
error("unable to lock %s for update", newref);
goto rollback;
@@ -979,7 +987,7 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
return 0;
rollback:
- lock = lock_ref_sha1_basic(oldref, NULL, NULL);
+ lock = lock_ref_sha1_basic(oldref, NULL, 0, NULL);
if (!lock) {
error("unable to lock %s for rollback", oldref);
goto rollbacklog;
diff --git a/refs.h b/refs.h
index f61f6d9..f234eb7 100644
--- a/refs.h
+++ b/refs.h
@@ -33,7 +33,8 @@ extern int get_ref_sha1(const char *ref, unsigned char *sha1);
extern struct ref_lock *lock_ref_sha1(const char *ref, const unsigned char *old_sha1);
/** Locks any ref (for 'HEAD' type refs). */
-extern struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1);
+#define REF_NODEREF 0x01
+extern struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags);
/** Release any lock taken but not written. **/
extern void unlock_ref(struct ref_lock *lock);
--
1.5.2.rc2.26.gb822e-dirty
^ permalink raw reply related
* Re: [FAQ?] Rationale for git's way to manage the index
From: Johannes Schindelin @ 2007-05-09 9:40 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Karl Hasselström, Johannes Sixt, git
In-Reply-To: <20070509034556.GC27980@fieldses.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1593 bytes --]
Hi,
On Tue, 8 May 2007, J. Bruce Fields wrote:
> On Tue, May 08, 2007 at 04:53:11PM +0200, Karl Hasselström wrote:
> > I would introduce it with a paragraph or two right where committing is
> > covered the first time. Explain that the empty file list box to the
> > left contains the changes that will be committed when you press the
> > commit button, and that the file list box on the right contains the
> > changes that won't be committed. By clicking on a file name you get to
> > see the diff to the file, and by clicking on the icon you move it to
> > the other file list box -- that is, you stage/unstage it.
> >
> > And now comes the clever part: Introduce the index, by explaining that
> > it essentially _is_ the left file list box. Explain that git-add is
> > the command-line equivalent of moving changes to the left box, and
> > that git-commit without arguments simply commits what's in the index
> > -- exactly like git-gui's Commit button.
> >
> > I think it could work. :-)
>
> Definitely, sounds fun.
>
> For the in-tree documentation, maybe I'm just my crusty text-centric
> commandline point of view, but I'd rather have the primary explanation
> continue to depend only on text and commandline examples, and then add a
> note telling people that playing with git-gui may help develop their
> intuition for the way the index works.
>
> But I think it'd be interesting to try out the above approach with
> screenshots, etc., on a web page someplace. It might also make a good
> visual aid for a talk.
Usually a wiki is a perfect place to start this...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-09 9:38 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Karl Hasselström, bfields, junio, git
In-Reply-To: <Pine.LNX.4.64.0705090015360.18541@iabervon.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 2681 bytes --]
Hi,
On Wed, 9 May 2007, Daniel Barkalow wrote:
> On Wed, 9 May 2007, Johannes Schindelin wrote:
>
> > On Tue, 8 May 2007, Karl Hasselström wrote:
> >
> > > On 2007-05-08 23:07:04 +0200, Johannes Schindelin wrote:
> > >
> > > > On Tue, 8 May 2007, Karl Hasselström wrote:
> > > >
> > > > > On 2007-05-08 17:10:47 +0200, Johannes Schindelin wrote:
> > > > >
> > > > > > + char *`, but is actually expected to be a pointer to `unsigned
> > > > > > + char[20]`. This variable will contain the big endian version of the
> > > > > > + 40-character hex string representation of the SHA-1.
> > > > >
> > > > > Either it should be "unsigned char[40]" (or possibly 41 with a
> > > > > terminating \0), or else you shouldn't be talking about
> > > > > hexadecimal since it's just a 20-byte big-endian unsigned integer.
> > > > > (A third possibility is that I'm totally confused.)
> > > >
> > > > It is 40 hex-character, but 20 _byte_. If you have any ideas how to
> > > > formulate that better than I did...
> > >
> > > I think this is less confusing:
> > >
> > > This variable will contain the 160-bit SHA-1.
> > >
> > > It avoids talking of hex, since it's not really stored in hex format
> > > any more than any other binary number with a number of bits divisible
> > > by four. And it avoids saying big-endian, which is not relevant anyway
> > > since we don't use hashes as integers.
> >
> > Well, I do not buy into that. First, we _have_ to say that it is
> > big-endian. It was utterly confusing to _me_ that the hash was not little
> > endian, as I expected on an Intel processor.
>
> SHA-1 is defined as producing a octet sequence, and to have a canonical
> hex digit sequence conversion with the high nibbles first. Internally, it
> is canonically specified using big-endian math, but the same algorithm
> could equally be specified with little-endian math and different rules for
> input and output.
>
> > And I'd rather mention the hex representation (what you see in git-log and
> > git-ls-tree). This helps debugging, believe me.
>
> It's kind of important to distinguish between the hex representation and
> the octet representation, because your code will not work at all if you
> use the wrong one. And "unsigned char *" or "unsigned char[20]" is always
> the octets; the hex is always "char *". Primarily mentioning the one that
> is more intuitive but less frequently used doesn't help with understanding
> the actual code.
That's a really good idea, to point out that "unsigned char *" refers to
octets, while "char *" refers to the ASCII representation. I will add
this, together with a simple example (the initial commit).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-09 9:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, git
In-Reply-To: <7v4pmmzivz.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 8 May 2007, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > "J. Bruce Fields" <bfields@fieldses.org> writes:
> >
> >> The organization of the next bit is slightly confusing: we're set up
> >> to expect a longer lecture on the revision walker, but instead
> >> there's just the historical note on git-rev-list, a mention of
> >> 'revision.c', 'revision.h', and 'struct rev_info', and then it
> >> rapidly digresses into discussing builtins.
> >
> > I had the same impression.
> >
> > I was meaning to write a "code walkthru for git hackers and wannabes"
> > with target audience quite different from the user-manual. My idea of
> > which areas to cover in what order seems to match with what Johannes
> > started.
>
> Having said that, I do not think the patch belongs to the "git USER'S
> manual". It is a very good introductory material for a separate "git
> hackers manual", though.
That is what I was referring to when I mentioned "no outcry". Bruce said
that he liked the idea to have something like that in the USER's manual.
And I have to agree: There might be enough room to actually go and write a
Git hacker's manual, but IMHO that takes a lot of time which has to be
found at first.
And even if we actually have such a hacker's manual one day, this "sneak
preview" in the user's manual does not hurt, but could actually entice
people to read that manual, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-09 9:27 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: junio, git
In-Reply-To: <20070509031803.GA27980@fieldses.org>
Hi,
On Tue, 8 May 2007, J. Bruce Fields wrote:
> On Tue, May 08, 2007 at 05:10:47PM +0200, Johannes Schindelin wrote:
> >
> > +If you grasp the ideas in that initial commit (it is really small and you
> > +can get into it really fast, and it will help you recognize things in the
> > +much larger code base we have now), you should go on skimming `cache.h`,
> > +`object.h` and `commit.h`.
>
> Might want to add "in a recent commit"?--it's not clear that you've
> transitioned away from talking about the initial commit.
Yes, good idea.
> > +This is just to get you into the groove for the most libified part of Git:
> > +the revision walker.
>
> Unless the reader has already been hanging out on the mailing list a
> while, "most libified" may not mean much to them yet at this point.
How about a sentence way before that, when I talk about the initial
commit, like this:
In the early days, Git (in the tradition of UNIX) was a bunch of
programs which were extremely simple, and which you used in scripts,
piping the output of one into another. This turned out to be good
for initial development, since it was easier to test new things.
However, recently many of these parts have become builtins, and
some of the core has been "libified", i.e. put into libgit.a for
performance, portability reasons, and to avoid code duplication.
> The organization of the next bit is slightly confusing: we're set up to
> expect a longer lecture on the revision walker, but instead there's just
> the historical note on git-rev-list, a mention of 'revision.c',
> 'revision.h', and 'struct rev_info', and then it rapidly digresses into
> discussing builtins.
>
> Which actually is fine, but just a few small markers of where we are in
> the discussion might be reassuring--a section header or two, maybe a
> little more emphasis on the pointers you're giving, like: "take a moment
> to go read revision.h and revision.c now, paying special attention to
> struct rev_info, which ....".
Okay. I hope I will be able to make these changes until tomorrow (I will
be gone for a few days after that).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Dana How @ 2007-05-09 9:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <alpine.LFD.0.99.0705082106590.24220@xanadu.home>
On 5/8/07, Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 8 May 2007, Dana How wrote:
> > I think it should be straightforward for me to re-submit this
> > based on current master.
> Since this patch is simpler it could be merged much faster, before the
> pack limit series.
Yes, I will do "custom compression" patch first.
> > > > + /* differing core & pack compression when loose object -> must
> > > recompress */
> > > I am not sure if that is worth it, as you do not know if the
> > > loose object you are looking at were compressed with the current
> > > settings.
> > You do not know for certain, that is correct. However, config
> > settings setting unequal compression levels signal that you
> > care differently about the two cases. (For me, I want the
> > compression investment to correspond to the expected lifetime of the file.)
> > Also, *if* we have the knobs we want in the config file,
> > I don't think we're going to be changing these settings all that often.
> >
> > If I didn't have this check forcing recompression in the pack,
> > then in the absence of deltification each object would enter the pack
> > by being copied (in the preceding code block) and pack.compression
> > would have little effect. I actually experienced this the very first
> > time I imported a large dataset into git (I was trying to achieve the
> > effect of this patch by changing core.compression dynamically, and
> > was a bit mystified for a while by the result).
> >
> > Thus, if core.loosecompression is set to speed up git-add, I should
> > take the time to recompress the object when packing if pack.compression
> > is different (of course the hit of not doing so will be lessened by
> > deltification
> > which forces a new compression).
>
> Right. And this also depends whether or not you have core.legacyheaders
> set to false or not.
>
> And the whole purpose for setting core.legacyheaders is exactly to allow
> for loose objects to be copied straight into the pack. This should have
> priority over mismatched compression levels IMHO.
OK, I got really confused here, so I looked over the code,
and figured out 2 causes for my confusion.
(1) core.legacyheaders controls use_legacy_headers, which defaults to 1.
So currently all loose objects are in legacy format and the code block
I spoke of doesn't trigger [without a config setting]. I didn't realize
legacy headers were still being produced (mislead by the name!).
(2) I read your "setting core.legacyheaders" as followed by TRUE,
but you meant FALSE, which is not the default.
I also read that 1 year after 1.4.2, the default for core.legacyheaders is going
to change to FALSE. I think our discussion should assume this has
happened. So let's assume FALSE in the following. The point of that
is that such a FALSE setting can't be assumed to have any special intent;
it will be the default.
[Everything I write here boils down to only one question,
which I repeat at the end.]
Data gets into a pack in these ways:
1. Loose object copied in;
2. Loose object newly deltified;
3. Packed object to be copied;
4. Packed object to be newly deltified;
5. Packed deltified object we can't re-use;
6. Packed deltified object we can re-use.
["copied" includes recompressed.]
In (2), (4), and (5), pack.compression will always be newly used.
If pack.compression doesn't change, this means (6)
will be using pack.compression since it comes from (2) or (4).
So if I "guarantee" that (1) uses pack.compression,
(3) will as well, meaning everything in the pack will be
at pack.compression.
Thus if pack.compression != core.loosecompression takes precedence
over core.legacyheaders = false, then for pack.compression constant
we get all 6 cases at level pack.compression. If core.legacyheaders =
false takes precedence as you suggest, then all undeltified objects
(20%?) will be stuck at core.loosecompression [since I see no way
to sensibly re-apply compression to something copied pack-to-pack].
I think this is inconsistent with what a pack.compression !=
core.loosecompression setting is telling us.
My arguments have 2 biases.
(a) I assume pack.compression stays constant, and if it changes,
I see little value in worrying about "forcing" all objects in a new pack,
some of which might be copied from an old pack, to be at the same
compression level.
(b) I focused first on packing to disk, where a constant pack.compression
makes sense. For packing to stdout (pack transfer), especially on
a popular, hence loaded, repository server, we may want to use
--compress=N to crank down on effort spent compressing new deltas [2+4]
(or loose objects [1]) (or unusable deltas [5]). This still lets
better compressed
objects flow through in the other cases [3+6]. So for one-use packs,
a mix of compression levels could be desirable and
is achievable with --compression=N if/when so.
> Also, when repacking, delta reuse does not recompress objects for the
> same reason, regardless of the compression level used when they were
> compressed initially. Same argument goes for delta depth.
Delta reuse doesn't need recompression. For pack.compression
constant, they will already be at the correct level. I think we agree
on behavior here for different reasons.
> So if you really want to ensure a compression level on the whole pack,
> you'll have to use -f with git-repack. Or leave core.legacyheaders
> unset.
-f would be needed if you were in the practice of changing
pack.compression, yes.
So, after covering all these cases, have I convinced you that
recompression takes precedence over legacyheaders = FALSE?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* quick bare clones taking longer?
From: David Miller @ 2007-05-09 9:09 UTC (permalink / raw)
To: git
master.kernel.org just upgraded to git-1.5.1.4 and I notice
that doing something like this:
git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git
is no longer an instantaneous operation, it seems to be doing a lot
of stuff now:
Initialized empty Git repository in /home/davem/git/test-2.6.git/
remote: Generating pack...
remote: Done counting 480025 objects.
remote: Deltifying 480025 objects.
remote: 100% (480025/480025) done
Indexing 480025 objects.
remote: Total 480025 (delta 385878), reused 473265 (delta 379369)
100% (480025/480025) done
Resolving 385878 deltas.
100% (385878/385878) done
Is there a new way to get a quick clone?
Thanks!
^ permalink raw reply
* Re: [PATCH] checkout: allow full refnames for local branches
From: Lars Hjemli @ 2007-05-09 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iriwfeu.fsf@assigned-by-dhcp.cox.net>
On 5/9/07, Junio C Hamano <junkio@cox.net> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
> > This teaches git-checkout to strip the prefix 'refs/heads/' from the
> > supplied <branch> argument
>
> Why is this necessary, may I ask?
>
I'm playing around with a gui frontend, and there I use
git-for-each-ref to obtain possible arguments for git-checkout. That's
how I discovered the 'problem', and solved it by stripping
'refs/heads/' in my frontend. But then I thought it would be nice if
'git-checkout' did the stripping on my behalf, since this might bite
others too :)
--
larsh
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Steven Grimm @ 2007-05-09 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Theodore Ts'o, Git Mailing List
In-Reply-To: <7v3b26xvjo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I think that sounds saner and more user friendly than specific
> knob to tune "window", "depth" and friends which are too
> technical. It has an added attraction that we can redefine what
> exactly "hard" means later.
>
On that note, has any thought been given to looking at other compression
algorithms? Gzip is a great high-speed compressor, but there are others
out there (some a bit slower, some much slower at both compression and
decompression) that produce substantially smaller output.
One could even, if one were in a particularly twisted state of mind,
envision using CPU-intensive compression for less frequently-accessed
objects and using gzip for active ones, on the theory that the best
time/space tradeoff is not uniform across all the objects in a git
repository. Presumably most of us never actually unpack the vast
majority of objects in a git repository of reasonable age, so the fact
that it'd take a little longer if we *did* want to unpack them isn't
much of a downside compared to the upside of reclaiming disk space. That
would mitigate the impact of using an algorithm that's slow at
decompression.
I think it'd be kind of neat to have my .git directory shrink by another
20+%. That's conservative; on maximumcompression.com's test of a mix of
different file types including images, gzip compresses 64% and the
best-scoring one does 80%. On English text gzip does 71% and the top
scorer does 89%. Most of the top-tier compressors are proprietary, but
there are some open-source ones that do pretty well.
Maybe not worth the added complexity, but I thought I'd toss it out
there. It probably makes more sense (if it makes any at all) after
Linus's suggestion to not unpack after cloning is in place. Once the
upstream has gone to the trouble of CPU-intensive compressing, you
certainly don't want to force clones to have to spend the time repeating
the same work.
-Steve (who suspects this is a "yes, we talked this over early in git's
history" question, but what the heck)
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.1.4
From: Junio C Hamano @ 2007-05-09 8:49 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, linux-kernel
In-Reply-To: <20070509083234.GD5294@informatik.uni-freiburg.de>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> writes:
> Hello Junio,
>
> you either overlooked my mail "Documentation Bugs"[1] or you choosed to
> ignore it :-( Note that the second issue was only me being stupid.
The best way to prod busy maintainer is to resend an applicable
patch, not sending a URL. Thanks.
^ permalink raw reply
* Re: [PATCH] checkout: allow full refnames for local branches
From: Junio C Hamano @ 2007-05-09 8:48 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <11787000032830-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> This teaches git-checkout to strip the prefix 'refs/heads/' from the
> supplied <branch> argument, to make
>
> git-checkout refs/heads/master
>
> behave like
>
> git-checkout master
>
> The former command would detach HEAD.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
>
> I'm undecided on wheter this is a bugfix or a new feature. It certainly
> introduces new behaviour, but it passes all the tests.
Why is this necessary, may I ask?
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-05-09 8:47 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
As before, there is nothing to see here, before v1.5.2 final.
* dh/repack (Tue May 8 13:05:04 2007 -0700) 5 commits
- git-repack --max-pack-size: add option parsing to enable feature
- git-repack --max-pack-size: split packs as asked by
write_{object,one}()
- git-repack --max-pack-size: write_{object,one}() respect pack
limit
- git-repack --max-pack-size: new file statics and code
restructuring
- Alter sha1close() 3rd argument to request flush only
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
- blame: show log as it goes
- git-blame: optimize get_origin() from linear search to hash-
lookup.
- git-blame: pass "struct scoreboard *" pointers around.
- blame: lift structure definitions up
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-05-09 8:46 UTC (permalink / raw)
To: git
v1.5.1.4 is out.
Thanks to HPA who installed libdbi-dbd interface to sqlite on
kernel.org machines, Frank's cvsserver tests are now in
'master', along with updates to gitweb and git-gui. I've thrown
in the diff-tree memory optimization we discussed in the OOo
thread as well.
I haven't tagged the tip of the 'master', but this is pretty
much 1.5.2-rc3 -- I may tag it tomorrow with a few more fixes I
noticed are needed while I was reviewing the list traffic (I
updated todo:TODO with them).
v1.5.2 final is scheduled for sometime late next week, hopefully
with git-gui v0.7.0 final.
----------------------------------------------------------------
* The 'maint' branch is now at 1.5.1.4, with these fixes since
the last announcement.
Amos Waterland (1):
wcwidth redeclaration
J. Bruce Fields (7):
user-manual: more discussion of detached heads, fix typos
user-manual: add section ID's
user-manual: clean up fast-forward and dangling-objects sections
user-manual: fix .gitconfig editing examples
user-manual: miscellaneous editing
user-manual: stop deprecating the manual
user-manual: fix clone and fetch typos
Jeff King (1):
Documentation: don't reference non-existent 'git-cvsapplycommit'
Junio C Hamano (1):
GIT v1.5.1.4
Paul Mackerras (1):
gitk: Allow user to choose whether to see the diff, old file, or new file
Quy Tonthat (1):
Add howto files to rpm packages.
Shawn O. Pearce (1):
git-gui: Allow spaces in path to 'wish'
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Use GIT_OBJECT_DIR for temporary files of pack-objects
Frank Lichtenheld (1):
cvsserver: Add test cases for git-cvsserver
Jakub Narebski (6):
gitweb: Add parsing of raw combined diff format to parse_difftree_raw_line
gitweb: Add combined diff support to git_difftree_body
gitweb: Add combined diff support to git_patchset_body
gitweb: Make it possible to use pre-parsed info in git_difftree_body
gitweb: Show combined diff for merge commits in 'commitdiff' view
gitweb: Show combined diff for merge commits in 'commit' view
Junio C Hamano (5):
diff: release blobs after generating textual diff.
diff.c: do not use a separate "size cache".
diff -M: release the preimage candidate blobs after rename detection.
diff -S: release the image after looking for needle in it
Update documentation links to point at 1.5.1.4
Matthieu Moy (2):
Document git add -u introduced earlier.
Added a reference to git-add in the documentation for git-update-index
Michael Spang (3):
dir.c: Omit non-excluded directories with dir->show_ignored
t7300: Basic tests for git-clean
Fix minor documentation errors
Shawn O. Pearce (17):
git-gui: Correctly handle UTF-8 encoded commit messages
git-gui: Include the subject in the status bar after commit
git-gui: Warn users before making an octopus merge
git-gui: Correct line wrapping for too many branch message
git-gui: Cleanup common font handling for font_ui
git-gui: Use option database defaults to set the font
git-gui: Refactor to use our git proc more often
git-gui: Track our own embedded values and rebuild when they change
git-gui: Refactor into multiple files to save my sanity
git-gui: Move console procs into their own namespace
git-gui: Allow vi keys to scroll the diff/blame regions
git-gui: Move merge support into a namespace
git-gui: Show all possible branches for merge
git-gui: Include commit id/subject in merge choices
git-gui: Use vi-like keys in merge dialog
Remove duplicate exports from Makefile
Use .git/MERGE_MSG in cherry-pick/revert
Theodore Ts'o (2):
Add pack.depth option to git-pack-objects.
Increase pack.depth default to 50
^ permalink raw reply
* [PATCH] checkout: allow full refnames for local branches
From: Lars Hjemli @ 2007-05-09 8:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This teaches git-checkout to strip the prefix 'refs/heads/' from the
supplied <branch> argument, to make
git-checkout refs/heads/master
behave like
git-checkout master
The former command would detach HEAD.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
I'm undecided on wheter this is a bugfix or a new feature. It certainly
introduces new behaviour, but it passes all the tests.
git-checkout.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index ed7c2c5..6ff7b6e 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -63,6 +63,7 @@ while [ "$#" != "0" ]; do
echo "unknown flag $arg"
exit 1
fi
+ arg=$(echo "$arg" | sed -e "s|^refs/heads/||")
new="$rev"
new_name="$arg"
if git-show-ref --verify --quiet -- "refs/heads/$arg"
--
1.5.2.rc2.21.g3082a
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.1.4
From: Uwe Kleine-König @ 2007-05-09 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vhcqmxyj0.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
you either overlooked my mail "Documentation Bugs"[1] or you choosed to
ignore it :-( Note that the second issue was only me being stupid.
[1] http://thread.gmane.org/gmane.comp.version-control.git/46332
--
Uwe Kleine-König
exit vi, lesson V:
o : q ! CTRL-V <CR> <Esc> " d d d @ d
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Junio C Hamano @ 2007-05-09 8:15 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Theodore Ts'o, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705090056231.18541@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Tue, 8 May 2007, Theodore Ts'o wrote:
>
>> This allows the user to regenerate the deltas in packs while doing
>> a git-gc. The user could just run git-repack -a -d -f -l after
>> running git-gc, but then the first git-repack run by git-gc is
>> a bit of waste.
>
> Maybe git-gc should have an option for "compress hard"? It seems to me
> like a two-sizes-fit-all solution would be good here; "git gc" for daily
> use, and "git gc --squeeze" for when you want to make the result as small
> as possible, with compute time not being a major factor.
I think that sounds saner and more user friendly than specific
knob to tune "window", "depth" and friends which are too
technical. It has an added attraction that we can redefine what
exactly "hard" means later.
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: Alex Riesen @ 2007-05-09 7:50 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <46413565.3090503@zytor.com>
On 5/9/07, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Mine stops already at the directory -> symlink checkin (the above is the
> symlink -> directory one), but your trick of using "git checkout" as a
> trick to resolve things helped for both... eventually :-/
>
Hmm. What Git version do you have?
> Either way, it's still a bug that it stops for either checkin, ...
Right. And because it is a bug, I'd like to have it fixed.
So, what did you do in that fixup?
^ permalink raw reply
* [PATCH (corrected)] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Steffen Prohaska @ 2007-05-09 7:45 UTC (permalink / raw)
To: git
In-Reply-To: <EC3AE084-0AB8-406A-A3C7-916CCF35BEAE@zib.de>
The old implementation executed 'cvs status' for each file touched by
the patch
to be applied. The new code calls 'cvs status' only once and parses
cvs's
output to collect status information of all files contained in the
cvs working
copy.
Runtime is now independent of the number of modified files. A
drawback is that
the new code retrieves status information for all files even if only
a few are
touched. The old implementation may be noticeably faster for small
patches to
large workingcopies. However, the old implementation doesn't scale if
more
files are touched, especially in remotely located cvs repositories.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-cvsexportcommit.perl | 48 +++++++++++++++++++++++++++++++++++
+---------
1 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 6ed4719..4d91574 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -160,36 +160,64 @@ foreach my $p (@afiles) {
}
}
+# ... check dirs,
foreach my $d (@dirs) {
if (-e $d) {
$dirty = 1;
warn "$d exists and is not a directory!\n";
}
}
+
+# ... query and store status of files by parsing output of 'cvs
status',
+# Note, we must use -n to avoid any modifications to working copy.
+# Otherwise the testsuite fails because it expects unmodfied CVS/
Entries files.
+my @cvsoutput;
+my %cvsstat;
+open CVSSTAT, "cvs -n status 2>&1 |" || die "failed to query cvs
status";
+@cvsoutput=<CVSSTAT>;
+close CVSSTAT || die "failed to query cvs status";
+my ( $dir, $status, $file );
+foreach my $f (@cvsoutput) {
+# cvs reports directories on stderr before reporting file status on
stdout
+# using basename of 'Repository revision:' should be a safe way to
deal with whitespace in filenames.
+ chomp $f;
+ if ( $f =~ /^cvs status: Examining (.*)$/ ) {
+ $dir = $1;
+ if ( $dir ne "." ) {
+ $dir .= "/";
+ } else {
+ $dir = "";
+ }
+ } elsif ( $f =~ /Status: (.*)$/ ) {
+ $status = $1;
+ } elsif ( $f =~ /^ Repository revision:/ ) {
+ $f =~ s/,v$//;
+ $f =~ /([^\/]*)$/;
+ $file = $1;
+ $cvsstat{"$dir$file"} = $status;
+ }
+}
+
+# ... validate new files,
foreach my $f (@afiles) {
# This should return only one value
if ($f =~ m,(.*)/[^/]*$,) {
my $p = $1;
next if (grep { $_ eq $p } @dirs);
}
- my @status = grep(m/^File/, safe_pipe_capture(@cvs, '-q',
'status' ,$f));
- if (@status > 1) { warn 'Strange! cvs status returned more than
one line?'};
- if (-d dirname $f and $status[0] !~ m/Status: Unknown$/
- and $status[0] !~ m/^File: no file /) {
+ if (defined ($cvsstat{$f})) {
$dirty = 1;
warn "File $f is already known in your CVS checkout --
perhaps it has been added by another user. Or this may indicate that
it exists on a different branch. If this is the case, use -f to force
the merge.\n";
- warn "Status was: $status[0]\n";
+ warn "Status was: $cvsstat{$f}\n";
}
}
-
+# ... validate known files.
foreach my $f (@files) {
next if grep { $_ eq $f } @afiles;
# TODO:we need to handle removed in cvs
- my @status = grep(m/^File/, safe_pipe_capture(@cvs, '-q',
'status' ,$f));
- if (@status > 1) { warn 'Strange! cvs status returned more than
one line?'};
- unless ($status[0] =~ m/Status: Up-to-date$/) {
+ unless (defined ($cvsstat{$f}) and $cvsstat{$f} eq "Up-to-date") {
$dirty = 1;
- warn "File $f not up to date in your CVS checkout!\n";
+ warn "File $f not up to date but has status '$cvsstat{$f}' in
your CVS checkout!\n";
}
}
if ($dirty) {
--
1.5.1.2
^ permalink raw reply related
* Re: [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Steffen Prohaska @ 2007-05-09 7:42 UTC (permalink / raw)
To: git
In-Reply-To: <0056A63A-D511-4FDD-82A6-A13B06E237E9@zib.de>
On May 9, 2007, at 1:59 AM, Steffen Prohaska wrote:
> The old implementation executed 'cvs status' for each file touched
> by the patch
> to be applied. The new code calls 'cvs status' only once and parses
> cvs's
> output to collect status information of all files contained in the
> cvs working
> copy.
>
> [...]
I didn't recognize that my modifications cause the testsuite to fail.
I'll send a corrected patch in a minute.
I apologize,
- Steffen
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Junio C Hamano @ 2007-05-09 7:13 UTC (permalink / raw)
To: Dana How; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <56b7f5510705082346m32d3c48dj987fd9b0a6118c10@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> This doesn't interact well with each variable being processed
> completely independently in git_config() and the callbacks it calls.
> The isset() value is "out-of-band"; either store it in the _seen
> variables, or some special value in used_value .
>
> Which makes the most sense:
> * Leave _seen as-is;
> * Move pack.compression recognition into config.c which means
> the _seen variables would all be local to config.c;
> * Use some special value, and if still present replace it with the default
> at the end of git_config() using extra code;
> * Change the config rule to something simpler.
>
> I like the 2nd and the 4th. You didn't like the 4th.
> Shall I change to the 2nd?
FWIW, I am Ok with (1).
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.1.4
From: Junio C Hamano @ 2007-05-09 7:10 UTC (permalink / raw)
To: git; +Cc: linux-kernel
To: git@vger.kernel.org
cc: linux-kernel@vger.kernel.org
Subject: [ANNOUNCE] GIT 1.5.1.4
The latest maintenance release GIT 1.5.1.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.1.4.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.1.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.1.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.1.4-1.$arch.rpm (RPM)
GIT v1.5.1.4 Release Notes
==========================
Fixes since v1.5.1.3
--------------------
* Bugfixes
- "git-http-fetch" did not work around a bug in libcurl
earlier than 7.16 (curl_multi_remove_handle() was broken).
- "git cvsserver" handles a file that was once removed and
then added again correctly.
- import-tars script (in contrib/) handles GNU tar archives
that contain pathnames longer than 100 bytes (long-link
extension) correctly.
- xdelta test program did not build correctly.
- gitweb sometimes tried incorrectly to apply function to
decode utf8 twice, resulting in corrupt output.
- "git blame -C" mishandled text at the end of a group of
lines.
- "git log/rev-list --boundary" did not produce output
correctly without --left-right option.
- Many documentation updates.
----------------------------------------------------------------
Changes since v1.5.1.3 are as follows:
Alex Riesen (1):
Small correction in reading of commit headers
Alexandre Julliard (1):
http-fetch: Disable use of curl multi support for libcurl < 7.16.
Amos Waterland (1):
wcwidth redeclaration
Arjen Laarhoven (1):
Document 'opendiff' value in config.txt and git-mergetool.txt
Bryan Larsen (2):
Allow PERL_PATH="/usr/bin/env perl"
posix compatibility for t4200
Carl Worth (1):
Mention version 1.5.1 in tutorial and user-manual
Daniel Barkalow (1):
Make xstrndup common
Frank Lichtenheld (1):
cvsserver: Handle re-added files correctly
Ismail Dönmez (1):
gitweb: use decode_utf8 directly
J. Bruce Fields (7):
user-manual: more discussion of detached heads, fix typos
user-manual: add section ID's
user-manual: clean up fast-forward and dangling-objects sections
user-manual: fix .gitconfig editing examples
user-manual: miscellaneous editing
user-manual: stop deprecating the manual
user-manual: fix clone and fetch typos
Jakub Narebski (1):
diff format documentation: describe raw combined diff format
James Bowes (1):
Documentation: fix typo in git-remote.txt
Jeff King (1):
Documentation: don't reference non-existent 'git-cvsapplycommit'
Johannes Schindelin (1):
Teach import-tars about GNU tar's @LongLink extension.
Junio C Hamano (5):
diff.c: fix "size cache" handling.
blame: Notice a wholesale incorporation of an existing file.
blame: -C -C -C
Add test for blame corner cases.
GIT v1.5.1.4
Karl Hasselström (2):
Fix markup in git-svn man page
Add --no-rebase option to git-svn dcommit
Linus Torvalds (1):
Fix --boundary output
Martin Koegler (1):
Fix compilation of test-delta
Paul Mackerras (1):
gitk: Allow user to choose whether to see the diff, old file, or new file
Quy Tonthat (1):
Add howto files to rpm packages.
Shawn O. Pearce (1):
git-gui: Allow spaces in path to 'wish'
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Johannes Sixt @ 2007-05-09 7:08 UTC (permalink / raw)
To: hanwen; +Cc: Marco Costalba, git
In-Reply-To: <46415106.5040401@xs4all.nl>
Han-Wen Nienhuys wrote:
> I packaged Mingw GIT using NSIS some time ago; see
>
> http://lilypond.org/git/binaries/mingw/
>
> Due various personal reasons, I haven't been able to update this, but I
> will package a new version soon. Please try it to see whether there are
> any rough edges.
I've tried this shortly after you released it. But it did not work as
expected. The symtom was (IIRC) that a simple
git init
said that 'init' is not a git-command. I tried this from CMD, not rxvt.
There are meanwhile a number of improvements in the port that support
relocation (i.e. an arbitrary installation directory). Could you please
package the latest version from the 'devel' branch?
git://repo.or.cz/git/mingw.git
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox