* [PATCH] git-apply tests need to be portable
From: Don Zickus @ 2008-07-03 16:00 UTC (permalink / raw)
To: git; +Cc: Don Zickus
When I created the tests for my git-apply patch, I accidently used the '-i'
flag for sed. Not all versions of sed handle this flag, so I converted
those instances to output to a temp file and move that temp file back to the
original file.
Thanks to Jim Meyering for noticing this!
---
Junio, I am not sure if you want me to resend the whole patch again or is a
small update like this preferred. I am indifferent either way.
Cheers,
Don
---
t/t4127-apply-same-fn.sh | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/t/t4127-apply-same-fn.sh b/t/t4127-apply-same-fn.sh
index 2a6ed77..2726a29 100755
--- a/t/t4127-apply-same-fn.sh
+++ b/t/t4127-apply-same-fn.sh
@@ -14,10 +14,12 @@ test_expect_success setup '
git commit -m initial
'
test_expect_success 'apply same filename with independent changes' '
- sed -i -e "s/^d/z/" same_fn &&
+ sed -e "s/^d/z/" same_fn > f &&
+ mv f same_fn &&
git diff > patch0 &&
git add same_fn &&
- sed -i -e "s/^i/y/" same_fn &&
+ sed -e "s/^i/y/" same_fn > f &&
+ mv f same_fn &&
git diff >> patch0 &&
cp same_fn same_fn2 &&
git reset --hard &&
@@ -27,10 +29,12 @@ test_expect_success 'apply same filename with independent changes' '
test_expect_success 'apply same filename with overlapping changes' '
git reset --hard
- sed -i -e "s/^d/z/" same_fn &&
+ sed -e "s/^d/z/" same_fn > f &&
+ mv f same_fn &&
git diff > patch0 &&
git add same_fn &&
- sed -i -e "s/^e/y/" same_fn &&
+ sed -e "s/^e/y/" same_fn > f &&
+ mv f same_fn &&
git diff >> patch0 &&
cp same_fn same_fn2 &&
git reset --hard &&
@@ -41,10 +45,12 @@ test_expect_success 'apply same filename with overlapping changes' '
test_expect_success 'apply same new filename after rename' '
git reset --hard
git mv same_fn new_fn
- sed -i -e "s/^d/z/" new_fn &&
+ sed -e "s/^d/z/" new_fn > f &&
+ mv f new_fn &&
git add new_fn &&
git diff -M --cached > patch1 &&
- sed -i -e "s/^e/y/" new_fn &&
+ sed -e "s/^e/y/" new_fn > f &&
+ mv f new_fn &&
git diff >> patch1 &&
cp new_fn new_fn2 &&
git reset --hard &&
@@ -55,11 +61,13 @@ test_expect_success 'apply same new filename after rename' '
test_expect_success 'apply same old filename after rename -- should fail.' '
git reset --hard
git mv same_fn new_fn
- sed -i -e "s/^d/z/" new_fn &&
+ sed -e "s/^d/z/" new_fn > f &&
+ mv f new_fn &&
git add new_fn &&
git diff -M --cached > patch1 &&
git mv new_fn same_fn
- sed -i -e "s/^e/y/" same_fn &&
+ sed -e "s/^e/y/" same_fn > f &&
+ mv f same_fn &&
git diff >> patch1 &&
git reset --hard &&
test_must_fail git apply patch1
@@ -68,15 +76,18 @@ test_expect_success 'apply same old filename after rename -- should fail.' '
test_expect_success 'apply A->B (rename), C->A (rename), A->A -- should pass.' '
git reset --hard
git mv same_fn new_fn
- sed -i -e "s/^d/z/" new_fn &&
+ sed -e "s/^d/z/" new_fn > f &&
+ mv f new_fn &&
git add new_fn &&
git diff -M --cached > patch1 &&
git commit -m "a rename" &&
git mv other_fn same_fn
- sed -i -e "s/^e/y/" same_fn &&
+ sed -e "s/^e/y/" same_fn > f &&
+ mv f same_fn &&
git add same_fn &&
git diff -M --cached >> patch1 &&
- sed -i -e "s/^g/x/" same_fn &&
+ sed -e "s/^g/x/" same_fn > f &&
+ mv f same_fn &&
git diff >> patch1 &&
git reset --hard HEAD^ &&
git apply patch1
--
1.5.6.rc2.48.g13da
^ permalink raw reply related
* Re: [PATCH 0/3] Making remote tracking statistics available to other tools
From: Olivier Marin @ 2008-07-03 16:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, Bruce Stephens, git
In-Reply-To: <7v3amsg1wx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> The one I sent out was a bit hacky as the existing implementation inside
> git-checkout was not designed to be cleanly reusable.
>
> Here is a cleaned up series that could be applied.
>
> [PATCH 1/3] Refactor "tracking statistics" code used by "git checkout"
> [PATCH 2/3] git-status: show the remote tracking statistics
> [PATCH 3/3] git-branch -v: show the remote tracking statistics
Sorry, but the third patch does not work for me. FWIU, the problem comes from
the revision walking code that is not reentrant because of the object cache.
IOW, calling stats_tracking_info() more than once does not work: objects
states changed after first call.
I do not understand the code enough yet and I failed to fix it. The only way
I found is by clearing obj_hash (object.c) but this seems the wrong thing to
do.
Ideas?
This test case should trigger the bug:
$ for i in a b c; do echo $i>$i && git add $i && git commit -m $i; done
$ git clone . clone1
$ cd clone1
$ git checkout -b b1 origin/master
$ git reset --hard HEAD~
$ echo d>d && git add d && git commit -m d
$ git checkout -b b2 origin/master
$ git reset --hard HEAD~
$ git merge b1
$ git branch -v
b1 c07015a [ahead 1, behind 1] d
* b2 c07015a d
master 08ca18b c
b1 and b2 are both 1 commit ahead and 1 commit behind.
$ git branch -D b1
$ git branch -v
* b2 c07015a [ahead 1, behind 1] d
master 08ca18b c
deleting b1 show us the side effect.
Olivier.
^ permalink raw reply
* [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
From: Jakub Narebski @ 2008-07-03 16:24 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Lea Wiemann
Add get_config([PREFIX]) method, taken from current gitweb, which
parses whole (or selected part) config file into hash (reading
"git config -z -l" output). This means that we do not have to call
one git command per config variable... but it also means that
conversion to boolean, to integer, or to color must be done from
within Perl; you can use config_val_to_* functions for that.
NOTE: Currently config_val_to_color and config_val_to_colorbool
are lacking; error checking is more relaxed in config_val_to_bool().
One advantage of ->get_config() over ->config(VARIABLE) is that it can
deal correctly with "no value" variables: they are !defined(), but
they do exists().
Tests are included; while at it add some more tests for generic
->config*() methods.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Cc-ed Petr "Pasky" Baudis, who is author of Git.pm, and Lea Wiemann,
who is author of Git.pm test t/t9700-perl-git.sh. Lea is also
working on object interface to git in Perl (Git::Repo etc.); I hope
I am not repeating her work.
This is WIP (Work In Progress) as much as an RFC (Request For Comments)
patch, as there are a few things which are not finished or not cleaned
up:
* there is no config_val_to_*() equivalent of ->get_colorbool() and
->get_color() methods to convert config values to ANSI color escape
sequences.
* config_val_to_bool() and config_val_to_int() does not error out
on values which are not boolean or not integer, contrary to what
usage of "git config --bool" and "git config --int" does in
->config_bool() and ->config_int() methods, respectively.
This should be fairly easy to add by manually throwing Error...
the minor trouble would be to follow what ->config_bool etc. does.
* neither config_val_to_bool nor config_val_to_int are exported.
* tests contain some cruft in 'set up test repository' stage, which
was inspected manually that is correct (by examining Data::Dumper
output of new ->get_config() method against tested config file),
but for which actual tests were written.
There are also a few things which I'd like some comments about:
* Do config_val_to_bool and config_val_to_int should be exported
by default?
* Should config_val_to_bool and config_val_to_int throw error or
just return 'undef' on invalid values? One can check if variable
is defined using "exists($config_hash{'varname'})".
* How config_val_to_bool etc. should be named? Perhaps just
config_to_bool, like in gitweb?
* Is "return wantarray ? %config : \%config;" DWIM-mery good style?
I am _not_ a Perl hacker...
* Should ->get_config() use ->command_output_pipe, or simpler
->command() method, reading whole config into array?
* What should ->get_config() method be named? ->get_config()
or perhaps ->config_hash(), or ->config_hashref()?
* What should ->get_config() have as an optional parameter:
PREFIX (/^$prefix/o), or simply SECTION (/^(?:$section)\./o)?
* Should config_val_to_* be tested against ->config_* output?
* Should we perltie hash?
As this is an RFC I have not checked if manpage (generated from
embedded POD documentation) renders correctly.
perl/Git.pm | 107 +++++++++++++++++++++++++++++++++++++++++++++++++++
t/t9700-perl-git.sh | 10 ++++-
t/t9700/test.pl | 32 +++++++++++++++
3 files changed, 148 insertions(+), 1 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 97e61ef..2f4a306 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -668,6 +668,113 @@ sub get_color {
return $color;
}
+=item get_config ( [ PREFIX ] )
+
+Return hash (in list context) or hashref of the whole configuration,
+in the similar manner that C<config --list>, optionally limited
+to config entries which fully qualified key (variable) name begins
+with C<PREFIX> (usually name of section).
+
+The keys of returned hash are fully qualified value names (section,
+optional subsection, and variable name joined using '.'). If variable
+is set only once its value is used as hash value, if variable is set
+multiple times array reference of all values is used as hash value
+for given key.
+
+Please remember that section names and key names in config hash keys
+(in fully qualified config variable name) are normalized, which means
+that they are in lowercase.
+
+=cut
+
+sub get_config {
+ my ($self, $prefix) = _maybe_self(@_);
+
+ my @cmd = ('config');
+ unshift @cmd, $self if $self;
+ my ($fh, $ctx) = command_output_pipe(@cmd, '-z', '--list');
+
+ my %config;
+ local $/ = "\0";
+ $prefix = quotemeta($prefix) if defined($prefix);
+ while (my $keyval = <$fh>) {
+ chomp $keyval;
+ my ($key, $value) = split(/\n/, $keyval, 2);
+
+ if (!defined $prefix || $key =~ /^$prefix/o) {
+ # store multiple values for single key as anonymous array reference
+ # single values stored directly in the hash, not as [ <value> ]
+ if (!exists $config{$key}) {
+ $config{$key} = $value;
+ } elsif (!ref $config{$key}) {
+ $config{$key} = [ $config{$key}, $value ];
+ } else {
+ push @{$config{$key}}, $value;
+ }
+ }
+ }
+ my @ctx = ($fh, $ctx);
+ unshift @ctx, $self if $self;
+ command_close_pipe(@ctx);
+
+ return wantarray ? %config : \%config;
+}
+
+=item config_val_to_bool ( VALUE )
+
+Convert config value C<VALUE> to boolean; no value, number > 0, 'true'
+and 'yes' values are true, rest of values are treated as false (never
+as error, at least for now).
+
+This function is meant to be used on values in hash returned by
+C<get_config>.
+
+=cut
+
+sub config_val_to_bool {
+ my $val = shift;
+
+ # strip leading and trailing whitespace
+ $val =~ s/^\s+//;
+ $val =~ s/\s+$//;
+
+ return (!defined $val || # section.key
+ ($val =~ /^\d+$/ && $val) || # section.key = 1
+ ($val =~ /^(?:true|yes)$/i)); # section.key = true
+}
+
+=item config_val_to_int ( VALUE )
+
+Convert config value C<VALUE> to simple decimal number; an optional
+value suffix of 'k', 'm', or 'g' will cause the value to be multiplied
+by 1024, 1048576 (1024 x 1024), or 1073741824 (1024 x 1024 x 1024),
+respectively (unknown unit is treated as 1, at least for now).
+
+It does not throw error on argument which is not integer.
+
+This function is meant to be used on values in hash returned by
+C<get_config>.
+
+=cut
+
+sub config_val_to_int {
+ my $val = shift;
+
+ # strip leading and trailing whitespace
+ $val =~ s/^\s+//;
+ $val =~ s/\s+$//;
+
+ if (my ($num, $unit) = ($val =~ /^([0-9]*)([kmg])$/i)) {
+ $unit = lc($unit);
+ # unknown unit is treated as 1
+ return $num * ($unit eq 'g' ? 1073741824 :
+ $unit eq 'm' ? 1048576 :
+ $unit eq 'k' ? 1024 : 1);
+ }
+ return $val;
+}
+
+
=item ident ( TYPE | IDENTSTR )
=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index 9706ee5..af6ac58 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -34,9 +34,17 @@ test_expect_success \
git-config --add test.booltrue true &&
git-config --add test.boolfalse no &&
git-config --add test.boolother other &&
- git-config --add test.int 2k
+ git-config --add test.int 2k &&
+ git-config --add teSt.duP val1 &&
+ git-config --add tesT.Dup val2 &&
+ git-config --add test.subsection.noDup val &&
+ git-config --add test.subSection.nodup val &&
+ git-config --add "test.sub # \\ \" '\'' section.key" val &&
+ echo "[test] noval" >> .git/config
'
+test_debug 'cat .git/config'
+
test_external_without_stderr \
'Perl API' \
perl ../t9700/test.pl
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 4d23125..4dd8bbf 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -11,6 +11,8 @@ use Cwd;
use File::Basename;
use File::Temp;
+use Data::Dumper;
+
BEGIN { use_ok('Git') }
# set up
@@ -30,11 +32,36 @@ is($r->config_int("test.int"), 2048, "config_int: integer");
is($r->config_int("test.nonexistent"), undef, "config_int: nonexistent");
ok($r->config_bool("test.booltrue"), "config_bool: true");
ok(!$r->config_bool("test.boolfalse"), "config_bool: false");
+ok($r->config_bool("test.noval"), "config_bool: true (noval)");
our $ansi_green = "\x1b[32m";
is($r->get_color("color.test.slot1", "red"), $ansi_green, "get_color");
# Cannot test $r->get_colorbool("color.foo")) because we do not
# control whether our STDOUT is a terminal.
+# testing get_config() and related functions/subroutines/methods
+is_deeply(scalar($r->get_config('color.')), {'color.test.slot1' => 'green'},
+ "get_config('color.')");
+my %config;
+ok(%config = $r->get_config(), "get_config(): list context");
+is($config{"test.string"}, "value",
+ "\%config scalar: string");
+is_deeply($config{"test.dupstring"}, ["value1", "value2"],
+ "\%config array: string");
+is($config{"test.nonexistent"}, undef,
+ "\%config scalar: nonexistent (undef)");
+ok(!exists($config{"test.nonexistent"}),
+ "\%config scalar: nonexistent (!exists)");
+is(Git::config_val_to_int($config{"test.int"}), 2048,
+ "config_val_to_int: integer");
+is(Git::config_val_to_int($config{"test.nonexistent"}), undef,
+ "config_val_to_int: nonexistent");
+ok( Git::config_val_to_bool($config{"test.booltrue"}),
+ "config_val_to_bool: true");
+ok(!Git::config_val_to_bool($config{"test.boolfalse"}),
+ "config_val_to_bool: false");
+ok( Git::config_val_to_bool($config{"test.noval"}),
+ "config_val_to_bool: true (noval)");
+
# Failure cases for config:
# Save and restore STDERR; we will probably extract this into a
# "dies_ok" method and possibly move the STDERR handling to Git.pm.
@@ -43,6 +70,11 @@ eval { $r->config("test.dupstring") };
ok($@, "config: duplicate entry in scalar context fails");
eval { $r->config_bool("test.boolother") };
ok($@, "config_bool: non-boolean values fail");
+TODO: {
+ $TODO = "config_val_to_bool returns false on non-bool values";
+ eval { Git::config_val_to_bool($config{"test.boolother"}) };
+ ok($@, "config_val_to_bool: non-boolean values fail");
+}
open STDERR, ">&", $tmpstderr or die "cannot restore STDERR";
# ident
--
1.5.6.1
^ permalink raw reply related
* Re: Question about git-merge-stupid
From: Linus Torvalds @ 2008-07-03 17:08 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <20080703123314.GS4729@genesis.frugalware.org>
On Thu, 3 Jul 2008, Miklos Vajna wrote:
>
> I'm trying to understand what is the difference between different merge
> strategies. git-merge-stupid is something I failed to understand from
> the git history/code/documentation, so I'm asking here.
>
> 1) From git history:
>
> It seems git-merge-stupid was created by 2276aa6 when Junio renamed
> -resolve to -stupid and let -resolve use read-tree. Actually
>
> git show 2276aa6:git-merge-stupid.sh
>
> says -stupid uses read-tree as well.
I think -stupid should probably be removed.
The history of -stupid is from doing the simple single-tree resolve that
git-read-tree can do, but then doing the obvious hack of just trying to
pick the base that gives the least number of conflicts.
HOWEVER.
- in practice, there's seldom any actual point to it. In 99% of all
cases, you only have a single merge base anyway.
- if you have a workflow that encourages criss-cross merges (which makes
the above "in practice" not be true), the common case will be that the
merge base doesn't much matter.
- Counting conflicts by looking at the numbe of files that conflict is a
pretty stupid metric anyway. Yes, it's obvious, and yes, I bet there
are cases where it does the right thing, but I also bet there are cases
where it does the _wrong_ thing - it might pick a merge base with fewer
files conflicting, but with harder conflicts.
- the "recursive" merge strategy simply handles things better. There's
not really any reason to use a "pick random merge base that happens to
give least conflicts", when the recursive strategy does something much
more natural.
So you shouldn't really compare -stupid to -resolve. You should compare
-stupid to -recursive, and the latter is simply much better.
> 2) From code:
>
> It seems -stupid is better than -resolve when there are multiple bases.
Maybe. And maybe not.
> $ git merge -s resolve c
> Trying simple merge.
> Merge made by resolve.
>
> So it seems resolve does not completely fail if there are multiple
> bases, either.
I think -resolve can handle up to 6 bases, or something like that. After
that it should fail with a "I cannot read more than 8 trees" or something
(eight being the two trees to be merged, plus the six bases).
And with multiple bases, it will already pick the best one on a per-file
basis (I think - I should know the threeway merge, but it is pretty
confusing code) rather than trying to pick one globally. Not pretty, but
it's yet another reason why -stupid is actually stupid, and not worth it.
So -stupid in _theory_ can handle cases that -resolve cannot (more than
six bases), but (a) that doesn't happen and (b) you'd be better off with
-recursive anyway.
> 3) From documentation:
>
> Actually -stupid is missing from Documentation/merge-strategies.txt. I
> plan to send a patch to add it, once I understnad what it does. :-)
Well, see above. I think there's a reason why -stupid isn't even worth
documenting. It might be better off just removed.
Linus
^ permalink raw reply
* [PATCH/RFC] Fix some warnings (on cygwin) to allow -Werror
From: Ramsay Jones @ 2008-07-03 15:52 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Junio C Hamano
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Despite the subject line, this should be useful on any system for
which uint32_t is defined to be unsigned long rather than
unsigned int. (and where the return type of htonl() is similarly
defined).
Note that this was built on the v1.5.6 tarball, so will probably
not apply cleanly to the git repo! (hey, it's been more than a
few days). Hence, the RFC in the subject line. (is there a better
TLA for "so old it won't apply" ;-)
Also, note that git-compat-compat-util.h contains an #ifdef'ed
definition of PRIuMAX despite an unconditional #include of
inttypes.h; this seems a bit odd. This seems to imply a system
with a pre-standard header file, missing the PRIuMAX #define.
If so, then similar definitions for PRIu32 and PRIx32 may need
to be added.
ATB,
Ramsay
builtin-fast-export.c | 4 ++--
builtin-fetch-pack.c | 3 ++-
builtin-pack-objects.c | 15 ++++++++++-----
builtin-unpack-objects.c | 3 ++-
index-pack.c | 6 ++++--
pack-check.c | 4 ++--
receive-pack.c | 3 ++-
sha1_file.c | 12 ++++++------
show-index.c | 3 ++-
9 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index d0a462f..3500ff0 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -102,7 +102,7 @@ static void handle_object(const unsigned char *sha1)
mark_object(object);
- printf("blob\nmark :%d\ndata %lu\n", last_idnum, size);
+ printf("blob\nmark :%"PRIu32"\ndata %lu\n", last_idnum, size);
if (size && fwrite(buf, size, 1, stdout) != 1)
die ("Could not write blob %s", sha1_to_hex(sha1));
printf("\n");
@@ -190,7 +190,7 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)
reencoded = reencode_string(message, "UTF-8", encoding);
if (!commit->parents)
printf("reset %s\n", (const char*)commit->util);
- printf("commit %s\nmark :%d\n%.*s\n%.*s\ndata %u\n%s",
+ printf("commit %s\nmark :%"PRIu32"\n%.*s\n%.*s\ndata %u\n%s",
(const char *)commit->util, last_idnum,
(int)(author_end - author), author,
(int)(committer_end - committer), committer,
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index de1e8d1..e094e2d 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -519,7 +519,8 @@ static int get_pack(int xd[2], char **pack_lockfile)
if (read_pack_header(demux.out, &header))
die("protocol error: bad pack header");
- snprintf(hdr_arg, sizeof(hdr_arg), "--pack_header=%u,%u",
+ snprintf(hdr_arg, sizeof(hdr_arg),
+ "--pack_header=%"PRIu32",%"PRIu32,
ntohl(header.hdr_version), ntohl(header.hdr_entries));
if (ntohl(header.hdr_entries) < unpack_limit)
do_keep = 0;
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 447d492..5e97355 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -590,7 +590,8 @@ static void write_pack_file(void)
free(written_list);
stop_progress(&progress_state);
if (written != nr_result)
- die("wrote %u objects while expecting %u", written, nr_result);
+ die("wrote %"PRIu32" objects while expecting %"PRIu32,
+ written, nr_result);
/*
* We have scanned through [0 ... i). Since we have written
* the correct number of objects, the remaining [i ... nr_objects)
@@ -602,7 +603,8 @@ static void write_pack_file(void)
j += !e->idx.offset && !e->preferred_base;
}
if (j)
- die("wrote %u objects as expected but %u unwritten", written, j);
+ die("wrote %"PRIu32" objects as expected but %"PRIu32
+ " unwritten", written, j);
}
static int locate_object_entry_hash(const unsigned char *sha1)
@@ -1718,7 +1720,8 @@ static int add_ref_tag(const char *path, const unsigned char *sha1, int flag, vo
static void prepare_pack(int window, int depth)
{
struct object_entry **delta_list;
- uint32_t i, n, nr_deltas;
+ uint32_t i, nr_deltas;
+ unsigned n;
get_object_details();
@@ -1809,7 +1812,8 @@ static int git_pack_config(const char *k, const char *v, void *cb)
if (!strcmp(k, "pack.indexversion")) {
pack_idx_default_version = git_config_int(k, v);
if (pack_idx_default_version > 2)
- die("bad pack.indexversion=%d", pack_idx_default_version);
+ die("bad pack.indexversion=%"PRIu32,
+ pack_idx_default_version);
return 0;
}
if (!strcmp(k, "pack.packsizelimit")) {
@@ -2243,7 +2247,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
prepare_pack(window, depth);
write_pack_file();
if (progress)
- fprintf(stderr, "Total %u (delta %u), reused %u (delta %u)\n",
+ fprintf(stderr, "Total %"PRIu32" (delta %"PRIu32"),"
+ " reused %"PRIu32" (delta %"PRIu32")\n",
written, written_delta, reused, reused_delta);
return 0;
}
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 85043d1..a891866 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -471,7 +471,8 @@ static void unpack_all(void)
if (ntohl(hdr->hdr_signature) != PACK_SIGNATURE)
die("bad pack file");
if (!pack_version_ok(hdr->hdr_version))
- die("unknown pack file version %d", ntohl(hdr->hdr_version));
+ die("unknown pack file version %"PRIu32,
+ ntohl(hdr->hdr_version));
use(sizeof(struct pack_header));
if (!quiet)
diff --git a/index-pack.c b/index-pack.c
index 5ac91ba..25db5db 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -190,7 +190,8 @@ static void parse_pack_header(void)
if (hdr->hdr_signature != htonl(PACK_SIGNATURE))
die("pack signature mismatch");
if (!pack_version_ok(hdr->hdr_version))
- die("pack version %d unsupported", ntohl(hdr->hdr_version));
+ die("pack version %"PRIu32" unsupported",
+ ntohl(hdr->hdr_version));
nr_objects = ntohl(hdr->hdr_entries);
use(sizeof(struct pack_header));
@@ -771,7 +772,8 @@ static int git_index_pack_config(const char *k, const char *v, void *cb)
if (!strcmp(k, "pack.indexversion")) {
pack_idx_default_version = git_config_int(k, v);
if (pack_idx_default_version > 2)
- die("bad pack.indexversion=%d", pack_idx_default_version);
+ die("bad pack.indexversion=%"PRIu32,
+ pack_idx_default_version);
return 0;
}
return git_default_config(k, v, cb);
diff --git a/pack-check.c b/pack-check.c
index f489873..98a6d56 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -146,11 +146,11 @@ static void show_pack_info(struct packed_git *p)
for (i = 0; i <= MAX_CHAIN; i++) {
if (!chain_histogram[i])
continue;
- printf("chain length = %d: %d object%s\n", i,
+ printf("chain length = %"PRIu32": %"PRIu32" object%s\n", i,
chain_histogram[i], chain_histogram[i] > 1 ? "s" : "");
}
if (chain_histogram[0])
- printf("chain length > %d: %d object%s\n", MAX_CHAIN,
+ printf("chain length > %d: %"PRIu32" object%s\n", MAX_CHAIN,
chain_histogram[0], chain_histogram[0] > 1 ? "s" : "");
}
diff --git a/receive-pack.c b/receive-pack.c
index b26f2e3..fa653b4 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -370,7 +370,8 @@ static const char *unpack(void)
hdr_err = parse_pack_header(&hdr);
if (hdr_err)
return hdr_err;
- snprintf(hdr_arg, sizeof(hdr_arg), "--pack_header=%u,%u",
+ snprintf(hdr_arg, sizeof(hdr_arg),
+ "--pack_header=%"PRIu32",%"PRIu32,
ntohl(hdr.hdr_version), ntohl(hdr.hdr_entries));
if (ntohl(hdr.hdr_entries) < unpack_limit) {
diff --git a/sha1_file.c b/sha1_file.c
index 191f814..7610c43 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -471,7 +471,7 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)
version = ntohl(hdr->idx_version);
if (version < 2 || version > 2) {
munmap(idx_map, idx_size);
- return error("index file %s is version %d"
+ return error("index file %s is version %"PRIu32
" and is not supported by this binary"
" (try upgrading GIT to a newer version)",
path, version);
@@ -682,14 +682,14 @@ static int open_packed_git_1(struct packed_git *p)
if (hdr.hdr_signature != htonl(PACK_SIGNATURE))
return error("file %s is not a GIT packfile", p->pack_name);
if (!pack_version_ok(hdr.hdr_version))
- return error("packfile %s is version %u and not supported"
- " (try upgrading GIT to a newer version)",
+ return error("packfile %s is version %"PRIu32" and not"
+ " supported (try upgrading GIT to a newer version)",
p->pack_name, ntohl(hdr.hdr_version));
/* Verify the pack matches its index. */
if (p->num_objects != ntohl(hdr.hdr_entries))
- return error("packfile %s claims to have %u objects"
- " while index indicates %u objects",
+ return error("packfile %s claims to have %"PRIu32" objects"
+ " while index indicates %"PRIu32" objects",
p->pack_name, ntohl(hdr.hdr_entries),
p->num_objects);
if (lseek(p->pack_fd, p->pack_size - sizeof(sha1), SEEK_SET) == -1)
@@ -1719,7 +1719,7 @@ off_t find_pack_entry_one(const unsigned char *sha1,
}
if (debug_lookup)
- printf("%02x%02x%02x... lo %u hi %u nr %u\n",
+ printf("%02x%02x%02x... lo %u hi %u nr %"PRIu32"\n",
sha1[0], sha1[1], sha1[2], lo, hi, p->num_objects);
if (use_lookup < 0)
diff --git a/show-index.c b/show-index.c
index 7253991..45bb535 100644
--- a/show-index.c
+++ b/show-index.c
@@ -68,7 +68,8 @@ int main(int argc, char **argv)
ntohl(off64[1]);
off64_nr++;
}
- printf("%" PRIuMAX " %s (%08x)\n", (uintmax_t) offset,
+ printf("%" PRIuMAX " %s (%08"PRIx32")\n",
+ (uintmax_t) offset,
sha1_to_hex(entries[i].sha1),
ntohl(entries[i].crc));
}
--
1.5.6
^ permalink raw reply related
* "make test" works again (sort-of) on cygwin.
From: Ramsay Jones @ 2008-07-03 17:44 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Junio C Hamano
Hi *,
Having upgraded to version 1.5.6 (via tarball), I can "make test" once
again, without crashing my machine. (well, it grinds to a halt, so that
I have to pull the power cord, followed by the battery!) I have been
unable to do that since v1.5.3!
I spent many hours (not recently) trying to determine the reason for
the crash, but it seems to be essentially "random gremlins" :-)
However, since I mostly use Linux, I've not been very motivated to
find a solution, particularly when git works fine (touch wood) when
used for real work. (i.e. only "make test" crashes my machine).
Also, as Alex and Shawn have not reported problems, I have assumed
it is something specific to my environment. Dunno.
Anyhow, the "sort-of" in the subject line, relates to the fact that
I am seeing some test failures. In particular, all tests in
t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
tests involve chmod/permissions ...
I haven't spent too long trying to debug this, but looking at the
first (actually second) test in t0004, I did an strace on git-write-tree.
After wading through the output, it seems that cygwin allows mkdir()
to succeed in the (un-writable) .git/object directory; eg. when
writing the tree object 47d832... it succeeds in making the 47 directory
(which does have write permission) followed by the d832... file.
So I tried this by hand:
$ mkdir obj
$ chmod a-w obj
$ echo file >obj/file
bash: obj/file: Permission denied
$ mkdir obj/dir
$
OK.
[Junio, in the tarball, the test files t5304-prune.sh and
t7610-mergetool.sh do not have the executable bit set]
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 3/7] Documentation: complicate example of "man git-command"
From: J. Bruce Fields @ 2008-07-03 18:18 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, git, Christian Couder, Nguyen Thai Ngoc Duy,
Jon Loeliger
In-Reply-To: <Pine.GSO.4.62.0807022010280.10323@harper.uchicago.edu>
On Wed, Jul 02, 2008 at 08:45:59PM -0500, Jonathan Nieder wrote:
> J. Bruce Fields wrote:
>
> > On Tue, Jul 01, 2008 at 04:54:53PM -0700, Junio C Hamano wrote:
> >
> >> We would want to mention the typesetting convention early in the manuals
> >> (git(7), gittutorial(7) and user-manual.html) as well, so how about...
> >>
> >> Conventions used in this document
> >> ---------------------------------
> >>
> >> When talking about a git subcommand 'cmd', this documentation
> >> typesets the name of it like 'git-cmd', and that is the name you
> >> ask for its manual page.
> >>
> >> Examples are typeset like this: `$ git cmd` (`$` is your command
> >> prompt, do not actually type it to your shell). Note that a
> >> subcommand is specified as the first parameter to the 'git'
> >> program when you actually run it from the command line.
> >
> > I'm not convinced this last sentence is necessary.
>
> I agree, but I think it doesn't hurt. I think the point was to
> establish the word and concept "subcommand".
We don't need to define it. (The word "subcommand" is pretty intuitive,
especially for anyone with some commandline experience, which we do
assume throughout.)
> > > [example showing typographical conventions]
> >
> > Typographical conventions shouldn't need so much explanation.
>
> Yes, I suppose. I'm used to printed manuals having a page on
> the meaning of different typefaces inside, but that's a bit
> of a different situation.
Yes.
> > I'm curious: Jonathan, was this the original patch the result of a
> > real-life instance of confusion? What happened?
>
> No, I'm actually a bit ashamed to have sent the patch... I was just
> changing `git subcommand` to `git-subcommand` wherever it was the name
> of a command, rather than the command line to run it, that was in
> question. Consistency would have made the old example awkward, so I
> looked around for alternatives.
That being the case, I'd rather leave the text as is; I'm uncomfortable
adding new text to address something that isn't in practice a problem.
--b.
>
> Why worry about whether the man pages have no consistent rule about
> dashes? Since it is not obvious why the man pages use the dashed form
> when they do, I think a fraction of people will naturally use the
> dashed form by default. That means trouble once Git 1.6.0 comes out
> (e.g. see Ingo's recent post
> <http://thread.gmane.org/gmane.comp.version-control.git/87012/focus=87020>).
>
> Here's a patch implementing Junio's suggestion, because I do like it.
> Please let me know what you think (especially ideas for making it
> shorter).
>
> Thanks for all your thoughts so far. Sorry I took so long to get back.
>
> --- %< --- %< --- %< ----
> Subject: gittutorial(7): add "Conventions used in this document" section
>
> The manual page for the git subcommand invoked as "git clone" is
> named git-clone(1), and similarly for the rest of the git
> subcommands. This patch should make the convention a little
> clearer when it is introduced at the beginning of gittutorial(7).
>
> Thanks to Junio C Hamano for the idea and wording.
>
> It remains to make an analogous change for user-manual.html
> and maybe git(1).
>
> Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
> ---
> Documentation/gittutorial.txt | 35 ++++++++++++++++++++++++++++++-----
> 1 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/gittutorial.txt
> b/Documentation/gittutorial.txt
> index 036a27c..51ad814 100644
> --- a/Documentation/gittutorial.txt
> +++ b/Documentation/gittutorial.txt
> @@ -19,12 +19,37 @@ If you are instead primarily interested in using
> git to fetch a project,
> for example, to test the latest version, you may prefer to start with
> the first two chapters of link:user-manual.html[The Git User's Manual].
>
> -First, note that you can get documentation for a command such as
> -`git log --graph` with:
> +Conventions used in this document
> +---------------------------------
>
> -------------------------------------------------
> -$ man git-log
> -------------------------------------------------
> +When discussing a git subcommand 'cmd', this documentation
> +typesets the name of it like 'git-cmd', and that is the name you
> +ask for its manual page by.
> +
> +Examples are typeset like this: `$ git cmd`. (`$` is your command
> +prompt; do not actually type it to your shell.) A subcommand
> +is specified as the first parameter to the 'git' program
> +when you actually run it from the command line.
> +
> +So a typical command description may go like this:
> +
> +To propagate the changes you made back to the original subversion
> +repository, you would use the 'git-svn dcommit' command. It does
> +these things (long description here). Some examples:
> +
> +------------
> +$ ... some example command sequence ...
> +$ git svn dcommit
> +------------
> +
> +For full details, type:
> +
> +------------
> +$ man git-svn
> +------------
> +
> +Introducing yourself to git
> +---------------------------
>
> It is a good idea to introduce yourself to git with your name and
> public email address before doing any operation. The easiest
> --
> 1.5.5.GIT
>
^ permalink raw reply
* Cherry picking instead of merges.
From: David Brown @ 2008-07-03 18:26 UTC (permalink / raw)
To: git
We have a branch coming from "company B" who is also doing development on
the same tree as us. We would like to do regular merges with them, but
unfortunately, there are quite a few changes in between.
First we tried a git-merge and resolved the conflicts. The problem here is
that the resultant code didn't work. git-bisect wasn't very useful because
the intermediate versions don't have resolved conflicts.
Yesterday, one developer cherry picked company B's changes into a branch.
It appears he resolved the conflicts for each commit, which should make
bisecting easier.
The problem is that we now have very divergent history.
Any advice on how to make use of how he resolved conflicts in order to
merge company B's changes in using git-merge. I could always use the
"ours" strategy to just kind of force the merge, so at least future merges
would work, but it'd kind of be nice to have the proper history.
There are about 110 commits in question.
Thanks,
David Brown
^ permalink raw reply
* Re: ':/<oneline prefix>' notation doesn't support full file syntax
From: Dana How @ 2008-07-03 18:27 UTC (permalink / raw)
To: Eric Raible; +Cc: Junio C Hamano, git, Johannes.Schindelin, danahow
In-Reply-To: <279b37b20807030150t2e9cbcc8wf099a5872568af8@mail.gmail.com>
On Thu, Jul 3, 2008 at 1:50 AM, Eric Raible <raible@gmail.com> wrote:
> On Thu, Jul 3, 2008 at 1:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> "Eric Raible" <raible@gmail.com> writes:
>>
>> Is there anything to fix? In that example, you are looking for a commit
>> that talks about "object name:sha1_name.c" in the comment.
>
> Yes. What if I'm looking for specific file (i.e. sha1_name.c) in the commit
> described by ":/object name:", just like I can do with 28a4d9404:sha1_name.c?
>
> This is not ambiguous if we first consider the entire string as the prefix.
> If that fails we look for a filename after the final ':'.
In part you are proposing this because it is a consistent extension.
But a problem with the current :/string is that it adds 2nd meanings
to both : and / ,
which is not all that consistent to start with.
Last year Junio proposed that :/ be changed to ?
to eliminate the overloading; thus your proposal becomes:
?string:filename
He chose ? because it results in a search backwards through commits.
(You could make that ?string?:filename if you prefer, where the 2nd ?
is only needed if you include a filename.)
I was surprised to see Dscho advocating removing this feature altogether.
Others proposed other command sequences which avoided :/ .
If :/ is now going to be extended and thus perhaps more likely to
appear in scripts,
is now the time to change it to ? which has no other special meaning to git?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* [BUG] git-svn failure with python repository
From: Gabriel @ 2008-07-03 19:00 UTC (permalink / raw)
To: git
I got an error importing the python repository with git-svn.
The error could be due to a funky branch name.
git --version
git version 1.5.6.1.89.gd5446
LANG= git svn clone -s http://svn.python.org/projects/python
…
r5002 = 8aa67da1bc987c02661b5331eae7c349be2da0ef (trunk)
Found possible branch point: http://svn.python.org/projects/python/trunk => http://svn.python.org/projects/python/tags/Beta_14-Mar-1995-#2, 5002
Found branch parent: (tags/Beta_14-Mar-1995-#2) 8aa67da1bc987c02661b5331eae7c349be2da0ef
Following parent with do_switch
Invalid filesystem path syntax: REPORT request failed on '/projects/!svn/vcc/default': Target path does not exist at /home/g2p/bin/git-svn line 3892
^ permalink raw reply
* Re: [PATCH 0/3] Making remote tracking statistics available to other tools
From: Junio C Hamano @ 2008-07-03 19:07 UTC (permalink / raw)
To: Olivier Marin; +Cc: Ingo Molnar, Bruce Stephens, git
In-Reply-To: <486CFDA3.9070704@free.fr>
Olivier Marin <dkr+ml.git@free.fr> writes:
> Junio C Hamano a écrit :
>> The one I sent out was a bit hacky as the existing implementation inside
>> git-checkout was not designed to be cleanly reusable.
>>
>> Here is a cleaned up series that could be applied.
>>
>> [PATCH 1/3] Refactor "tracking statistics" code used by "git checkout"
>> [PATCH 2/3] git-status: show the remote tracking statistics
>> [PATCH 3/3] git-branch -v: show the remote tracking statistics
>
> Sorry, but the third patch does not work for me. FWIU, the problem comes from
> the revision walking code that is not reentrant because of the object cache.
> IOW, calling stats_tracking_info() more than once does not work: objects
> states changed after first call.
>
> I do not understand the code enough yet and I failed to fix it. The only way
> I found is by clearing obj_hash (object.c) but this seems the wrong thing to
> do.
>
> Ideas?
Thanks.
remote.c | 4 +++
revision.h | 1 +
t/t6040-tracking-info.sh | 52 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index bd5c3be..df8bd72 100644
--- a/remote.c
+++ b/remote.c
@@ -1295,6 +1295,10 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
else
(*num_theirs)++;
}
+
+ /* clear object flags smudged by the above traversal */
+ clear_commit_marks(ours, ALL_REV_FLAGS);
+ clear_commit_marks(theirs, ALL_REV_FLAGS);
return 1;
}
diff --git a/revision.h b/revision.h
index abce500..e8bac6d 100644
--- a/revision.h
+++ b/revision.h
@@ -11,6 +11,7 @@
#define ADDED (1u<<7) /* Parents already parsed and added? */
#define SYMMETRIC_LEFT (1u<<8)
#define TOPOSORT (1u<<9) /* In the active toposort list.. */
+#define ALL_REV_FLAGS ((1u<<10)-1)
struct rev_info;
struct log_info;
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
new file mode 100755
index 0000000..960db2d
--- /dev/null
+++ b/t/t6040-tracking-info.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+test_description='remote tracking stats'
+
+. ./test-lib.sh
+
+advance () {
+ echo "$1" >"$1" &&
+ git add "$1" &&
+ test_tick &&
+ git commit -m "$1"
+}
+
+test_expect_success setup '
+ for i in a b c;
+ do
+ advance $i || break
+ done &&
+ git clone . test &&
+ (
+ cd test &&
+ git checkout -b b1 origin &&
+ git reset --hard HEAD^ &&
+ advance d &&
+ git checkout -b b2 origin &&
+ git reset --hard b1 &&
+ git checkout -b b3 origin &&
+ git reset --hard HEAD^ &&
+ git checkout -b b4 origin &&
+ advance e &&
+ advance f
+ )
+'
+
+script='s/^..\(b.\)[ 0-9a-f]*\[\([^]]*\)\].*/\1 \2/p'
+cat >expect <<\EOF
+b1 ahead 1, behind 1
+b2 ahead 1, behind 1
+b3 behind 1
+b4 ahead 2
+EOF
+
+test_expect_success 'branch -v' '
+ (
+ cd test &&
+ git branch -v
+ ) |
+ sed -n -e "$script" >actual &&
+ test_cmp expect actual
+'
+
+test_done
^ permalink raw reply related
* Re: about c8af1de9 (git status uses pager)
From: Jeff King @ 2008-07-03 19:08 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Johannes Schindelin, Tim Stoakes, Junio C Hamano, git
In-Reply-To: <08353871-5C94-4E97-9589-DC3980C47CD4@wincent.com>
On Thu, Jul 03, 2008 at 03:37:30PM +0200, Wincent Colaiuta wrote:
>>> This [changing git status to use the pager automatically] was quite a
>>> nasty change to sneak on people I think.
>>
>> Well, I think that a command producing pages and pages of output
>> without stopping is useless. Therefore, _I_ maintain that it makes
>> tons of sense.
>
> Ditto. For me, the change was very welcome. Sure, usually the status
> output is short, but on those occasions where it isn't (big file
> reorganizations etc) I was quite sick of doing the "git status, oops
> that output was too long let's try again, git -p status" dance. It was
> also incongruous with my very first experiences with Git, where I had
> been pleasantly surprised that "git log" automatically invoked the
> pager whereas "svn log" just spewed output into my console until ^C.
I think there is not much point in discussing whether "git status"
should use a pager. It is obvious at this point that some people love
it, and some people despise it, and it seems to be a matter of personal
preference. The only sane way forward seems to be configurable paging.
So the next steps are:
- getting a configurable paging patch that is good enough; I just
posted another trial, but there are still a few caveats. I would
love to hear commentary on whether people find it acceptable.
- once there is a patch, there is still the matter of "on by default,
make people configure off" versus "off by default, make people
configure on". And then you can make arguments about how the default
changes the new user experience, but hopefully there will be a
little less vehemence on both sides, since it is "here's what new
users should see" and not "here's what I am forced to see every
day".
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing
From: Thomas Rast @ 2008-07-03 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod5f7w3f.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
Junio C Hamano wrote:
>
> > Blindly concatenating the above two and feeding them to "git apply" *may*
> > happen to work by accident, not by design. This very much feels like a
> > hack of "This works most of the time for me, your mileage may vary" kind,
> > which we would want to avoid when we can.
>
> Well, I changed my mind. Let's run with this and see what happens.
In support of this being a feature of git-apply, notice that it even
handles the situation correctly where the context of a hunk has been
influenced by previous hunks, as in
@@ -1,2 +1,3 @@
foo
+quux
bar
@@ -1,3 +1,4 @@
foo
quux
+abc
bar
With Don Zickus' recent patch, it also handles patches that go over
the same file twice.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Making remote tracking statistics available to other tools
From: Olivier Marin @ 2008-07-03 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, Bruce Stephens, git
In-Reply-To: <7v8wwi23dr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
>
> remote.c | 4 +++
> revision.h | 1 +
> t/t6040-tracking-info.sh | 52 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 57 insertions(+), 0 deletions(-)
Tested: it works. Thanks.
Olivier.
^ permalink raw reply
* Re: [BUG] Git looks for repository in wrong directory
From: Junio C Hamano @ 2008-07-03 19:28 UTC (permalink / raw)
To: David ‘Bombe’ Roden; +Cc: git
In-Reply-To: <200807030305.17767.bombe@pterodactylus.net>
David ‘Bombe’ Roden <bombe@pterodactylus.net> writes:
>> If you have both, you already have found the way to disambiguate ;-)
>
> Yes, _now_ I know. In my opinion it’s very unintuitive and should be changed.
I'm of mixed mind about this.
I am guessing that the original motivation was that people can have
unversioned "project/" that perhaps is an extract from the tarball and
"project.git/" that is version-controlled by git, and when they want to
talk about the repository they can say either "project.git" and "project"
to get to the git-managed one, even if "project/" directory exists.
It may be an improvement if we checked to see if the original name does
refer to a git repository and use that without falling back. Even though
I do not personally care so deeply about this, I won't be opposed to such
an improvement.
^ permalink raw reply
* Re: finding deleted file names
From: Junio C Hamano @ 2008-07-03 19:41 UTC (permalink / raw)
To: Jeff King; +Cc: Geoff Russell, Shawn O. Pearce, git
In-Reply-To: <20080703103658.GA11571@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jul 03, 2008 at 09:31:55AM +0930, Geoff Russell wrote:
>
>> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
>>
>> finds files deleted during the last 7 days, but if my repository is
>> only 6 days old I get a
>> fatal error.
>>
>> fatal: bad object HEAD@{7 days ago}
>
> This should issue a warning, but use the oldest reflog entry. However,
> there is a slight problem with that. See below for details.
I think your patch is a sane thing to do.
Once reflog entries begin expiring, we won't have the null_sha1 on the
previous side of them, and after that we will keep returning the
oldest-known one, so nobody should be expecting to find out when a ref was
first created in this repository by checking with what timestamp that
syntax breaks in the existing interface.
Sorry for not being Shawn ;-)
^ permalink raw reply
* Re: finding deleted file names
From: Jeff King @ 2008-07-03 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geoff Russell, Shawn O. Pearce, git
In-Reply-To: <7vzloyzrew.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 03, 2008 at 12:41:43PM -0700, Junio C Hamano wrote:
> Once reflog entries begin expiring, we won't have the null_sha1 on the
> previous side of them, and after that we will keep returning the
> oldest-known one, so nobody should be expecting to find out when a ref was
> first created in this repository by checking with what timestamp that
> syntax breaks in the existing interface.
Right, that was my thought: though perhaps not technically as precise,
it is much more DWIM.
My other concern, which I failed to voice in the original mail was:
should we do this magic for other reflog entries besides the first one?
It is possible to end up with a null sha1 in any other entry? Branch
creation shouldn't do it, because we will have deleted any previous
reflog when killing off the branch before, so we always end up putting
in the "oldest" reflog entry. Cloning shouldn't do it for obvious
reasons.
> Sorry for not being Shawn ;-)
Heh.
-Peff
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jeff King @ 2008-07-03 19:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Adam Brewster, git
In-Reply-To: <200807021144.46423.jnareb@gmail.com>
On Wed, Jul 02, 2008 at 11:44:45AM +0200, Jakub Narebski wrote:
> Well, there is one situation where either separate git-bases program
> (which is a good start; it can be named git-bundle--bases; there are
> some precedents for that ;-)), or allowing to create 'bases' file
> without creating bundle would be good to have. Namely situation
> where two computers are _sometimes off-line (disconnected)_. If you
> want to transfer new commits from machine B to machine A, you would
> generate 'bases' file on machine A, then transfer this file using some
> off-line medium, then generate bundle on machine B using those bases,
> etc.
Yes, certainly it is more flexible to have them split. I find Adam's
argument the most compelling, though. Think about moving commits as a
multi-step protocol:
1. Local -> Remote: Here are some new commits, basis..current
2. Remote -> Local: OK, I am now at current.
3. Local: update basis to current
git-push has the luxury of asking for "basis" each time, so we know it
is correct. But with bundles, we can't do that. And failing to update
"basis" means we will send some extra commits next time. But updating
"basis" when we shouldn't means that the next bundle will be broken.
So I think even if people _do_ want to update "basis" when they create
the bundle (because it is more convenient, and they are willing to
accept the possibility of losing sync), it is trivial to create that
workflow on top of the separate components. But I can see why somebody
might prefer the separate components, and it is hard to create them if
the feature is lumped into "git-bundle" (meaning in such a way that you
cannot perform the steps separately; obviously git-bundle --basis would
be equivalent).
But I am not a bundle user, so that is just my outsider perspective.
-Peff
^ permalink raw reply
* Re: about c8af1de9 (git status uses pager)
From: Wincent Colaiuta @ 2008-07-03 20:10 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Tim Stoakes, Junio C Hamano, git
In-Reply-To: <20080703190829.GA18205@sigill.intra.peff.net>
El 3/7/2008, a las 21:08, Jeff King escribió:
> On Thu, Jul 03, 2008 at 03:37:30PM +0200, Wincent Colaiuta wrote:
>
>>>> This [changing git status to use the pager automatically] was
>>>> quite a
>>>> nasty change to sneak on people I think.
>>>
>>> Well, I think that a command producing pages and pages of output
>>> without stopping is useless. Therefore, _I_ maintain that it makes
>>> tons of sense.
>>
>> Ditto. For me, the change was very welcome. Sure, usually the status
>> output is short, but on those occasions where it isn't (big file
>> reorganizations etc) I was quite sick of doing the "git status, oops
>> that output was too long let's try again, git -p status" dance. It
>> was
>> also incongruous with my very first experiences with Git, where I had
>> been pleasantly surprised that "git log" automatically invoked the
>> pager whereas "svn log" just spewed output into my console until ^C.
>
> I think there is not much point in discussing whether "git status"
> should use a pager. It is obvious at this point that some people love
> it, and some people despise it, and it seems to be a matter of
> personal
> preference. The only sane way forward seems to be configurable paging.
I completely agree. I just don't like it when people use words like
"nasty" and "sneak" to describe a change that was discussed in one
short and one long thread prior to being incorporated. But you're
right; there's no sense in discussing the "whether" any more.
Cheers,
Wincent
^ permalink raw reply
* Re: Cherry picking instead of merges.
From: Alex Riesen @ 2008-07-03 20:13 UTC (permalink / raw)
To: git
In-Reply-To: <20080703182650.GA11166@old.davidb.org>
David Brown, Thu, Jul 03, 2008 20:26:50 +0200:
> Yesterday, one developer cherry picked company B's changes into a branch.
> It appears he resolved the conflicts for each commit, which should make
> bisecting easier.
>
> The problem is that we now have very divergent history.
...and have absolutely no idea on what were the changes of the company
B were made.
> Any advice on how to make use of how he resolved conflicts in order to
> merge company B's changes in using git-merge. ...
Let that developer do the merge next time? Or let the B do a merge
with a commonly accepted base?
^ permalink raw reply
* Re: Cherry picking instead of merges.
From: Avery Pennarun @ 2008-07-03 20:15 UTC (permalink / raw)
To: git
In-Reply-To: <20080703182650.GA11166@old.davidb.org>
On 7/3/08, David Brown <git@davidb.org> wrote:
> First we tried a git-merge and resolved the conflicts. The problem here is
> that the resultant code didn't work. git-bisect wasn't very useful because
> the intermediate versions don't have resolved conflicts.
>
> Yesterday, one developer cherry picked company B's changes into a branch.
> It appears he resolved the conflicts for each commit, which should make
> bisecting easier.
>
> The problem is that we now have very divergent history.
>
> Any advice on how to make use of how he resolved conflicts in order to
> merge company B's changes in using git-merge. [...]
Unfortunately, since your mismerged branches are already published,
rewriting history would cause a lot of pain for everyone. It would be
better to avoid doing that entirely. However, I can see why you'd
want to do that in order to make future git-bisect easier.
Basically, if you're going to try to fix the git-bisect intermediate
versions, you're going to have to rewrite history anyway; in which
case, why not just make your developer's cherry-picked branch the
official one? Then your problems are solved, other than getting all
your developers onto the new history.
Alternatively, if you just want to fix your main development tree so
that it's "correct", then you could do this:
- Go to a point in time where both branches (main and developer) have
exactly the same set of patches: that is, your company + company B.
The exact history (ie. commit ids) will look different, because the
two branches took different paths to get there, but the code *should*
have been identical at those two times, since you have the same set of
patches. Call the two points X and Y.
- X (on the main branch) is actually different from Y (on your
developer's branch) because someone mis-resolved the conflicts on X.
However, the only difference between X and Y should be the mis-merge.
Thus:
- git diff X..Y >fix-mis-merge.patch
- git checkout HEAD
- git apply fix-mis-merge.patch
This will apply the correct conflict resolution to the tip of your
newest branch. All the revisions between X and HEAD will still be
broken, but that's usually better than trying to rewrite history and
pretend the broken revisions never existed. You can always use "git
bisect skip" for cases like that.
Have fun,
Avery
^ permalink raw reply
* Re: "make test" works again (sort-of) on cygwin.
From: Alex Riesen @ 2008-07-03 20:26 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list, Junio C Hamano
In-Reply-To: <486D0FFC.5090308@ramsay1.demon.co.uk>
Ramsay Jones, Thu, Jul 03, 2008 19:44:28 +0200:
> I spent many hours (not recently) trying to determine the reason for
> the crash, but it seems to be essentially "random gremlins" :-)
> However, since I mostly use Linux, I've not been very motivated to
> find a solution, particularly when git works fine (touch wood) when
> used for real work. (i.e. only "make test" crashes my machine).
> Also, as Alex and Shawn have not reported problems, I have assumed
> it is something specific to my environment. Dunno.
I haven't tried to run the test on XP recently (it is a production
workstation, after all), but the last time I risked it was locked up
hard. Win2k runs (and I even can work, well, browse, on it)
> Anyhow, the "sort-of" in the subject line, relates to the fact that
> I am seeing some test failures. In particular, all tests in
> t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
> tests involve chmod/permissions ...
Don't run "make test" as root (or "backup operator" on windows).
OTOH, a windows machine is almost useless, unless you're a member of
local administrators group (which includes "backup" permission).
^ permalink raw reply
* Re: [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
From: Lea Wiemann @ 2008-07-03 20:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis
In-Reply-To: <200807031824.55958.jnareb@gmail.com>
Jakub Narebski wrote:
> Add get_config([PREFIX]) method [...]
>
> I hope I am not repeating [Lea's] work.
No, you're not. (You could've checked my repo at
<http://repo.or.cz/w/git/gitweb-caching.git> ;-).)
FWIW, I don't think it'll make much of a difference for gitweb, since
the 'git config -l' output is cached anyway, but it's good someone's
extracting this. Do you have any user for that function besides gitweb?
> * Should config_val_to_bool and config_val_to_int throw error or
> just return 'undef' on invalid values?
I suspect that if you have, say, command line tools, throwing an error
is better UI behavior than silently ignoring the entry. And developers
can always catch errors if they want to.
> * Is "return wantarray ? %config : \%config;" DWIM-mery good style?
Gitweb uses it as well, and it seems reasonable IMVHO.
> * Should ->get_config() use ->command_output_pipe, or simpler
> ->command() method, reading whole config into array?
Does it make a difference? If you're worried about performance, config
files are so short that it won't matter; use the easier path.
> * What should ->get_config() method be named? ->get_config()
> or perhaps ->config_hash(), or ->config_hashref()?
Regarding the method naming, how about making this an object oriented
interface? Bless the hash, and allow calls like
$config_hash->get('key'). I'm not sure how to name the constructor, but
if you can wait a week or so, you could maybe integrate this into the
Git::Repo interface (under Git/Config.pm), so you'd end up with ...
Git::Repo->new(directory => 'repo.git')->config->get('key')
... where config() transparently parses the config file if it hasn't
been read already. (The Git.pm API admittedly seems a little messy --
I'll post about that later -- so adding it to Git::Repo might be better
indeed.)
> * What should ->get_config() have as an optional parameter:
> PREFIX (/^$prefix/o), or simply SECTION (/^(?:$section)\./o)?
Off the top of my head, I don't see much need for a prefix parameter, so
I'd go for 'section'.
I haven't been able to answer all of the questions, but I hope this helps.
-- Lea
^ permalink raw reply
* Re: finding deleted file names
From: Shawn O. Pearce @ 2008-07-03 20:32 UTC (permalink / raw)
To: Jeff King; +Cc: Geoff Russell, git
In-Reply-To: <20080703103658.GA11571@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Jul 03, 2008 at 09:31:55AM +0930, Geoff Russell wrote:
>
> > git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
> >
> > finds files deleted during the last 7 days, but if my repository is
> > only 6 days old I get a
> > fatal error.
> >
> > fatal: bad object HEAD@{7 days ago}
>
> This should issue a warning, but use the oldest reflog entry. However,
> there is a slight problem with that. See below for details.
>
> Shawn, does this seem sane to you?
Yea, this is the only reasonable thing to do here. Ack.
--
Shawn.
^ permalink raw reply
* Re: Cherry picking instead of merges.
From: David Brown @ 2008-07-03 20:53 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130807031315j3d9b7d77y277e3cb994ab0964@mail.gmail.com>
On Thu, Jul 03, 2008 at 04:15:22PM -0400, Avery Pennarun wrote:
>Unfortunately, since your mismerged branches are already published,
>rewriting history would cause a lot of pain for everyone. It would be
>better to avoid doing that entirely. However, I can see why you'd
>want to do that in order to make future git-bisect easier.
It's only sitting in a private developer's branch. I want to do the merge
properly, but I'm just trying to figure out how to get the conflict
resolution out of his work.
>Basically, if you're going to try to fix the git-bisect intermediate
>versions, you're going to have to rewrite history anyway; in which
>case, why not just make your developer's cherry-picked branch the
>official one? Then your problems are solved, other than getting all
>your developers onto the new history.
Once we start cherry picking the changes from Company B, we have a
different set of changes from them, and future merges will get harder and
harder.
>This will apply the correct conflict resolution to the tip of your
>newest branch. All the revisions between X and HEAD will still be
>broken, but that's usually better than trying to rewrite history and
>pretend the broken revisions never existed. You can always use "git
>bisect skip" for cases like that.
Except we already know that the broken change is inside of the broken
revisions.
It turns out that things are more messed up than I thought. This developer
had done a 'git push' with some manual refs and pushed what was supposed to
be a merge into an unmerged branch.
I've spoken with all of the developers who use this tree, and everyone
agrees that rewinding the tree is the best way to go. Now just time to
trudge forward and learn.
But, it makes for a good new rule: no cherry-picking other people's
changes.
David
^ 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