* Fix per-directory exclude handing for "git add"
From: Junio C Hamano @ 2007-11-16 9:15 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Linus Torvalds, git
In-Reply-To: <7vir4341ok.fsf@gitster.siamese.dyndns.org>
In "dir_struct", each exclusion element in the exclusion stack records a
base string (pointer to the beginning with length) so that we can tell
where it came from, but this pointer is just pointing at the parameter
that is given by the caller to the push_exclude_per_directory()
function.
While read_directory_recursive() runs, calls to excluded() makes use
the data in the exclusion elements, including this base string. The
caller of read_directory_recursive() is not supposed to free the
buffer it gave to push_exclude_per_directory() earlier, until it
returns.
The test case Bruce Stephens gave in the mailing list discussion
was simplified and added to the t3700 test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Here is a tentative patch. I do not think the patch is broken
> but I call it tentative because:
>
> - It is ugly -- I never get this "walking path delimited by
> slashes" loop right;
>
> - It leaks the path buffer given to push(), but it is inherent
> in the design of "push/pop exclude per-directory" API.
It turns out that a minimally invasive fix was a lot simpler
than I thought.
This still does not fix the other codepaths in ls-files that does not
use read_directory() but walks the cache.
dir.c | 6 ++++--
t/t3700-add.sh | 24 ++++++++++++++++++++++++
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index fa9f902..225fdfb 100644
--- a/dir.c
+++ b/dir.c
@@ -654,6 +654,7 @@ static void free_simplify(struct path_simplify *simplify)
int read_directory(struct dir_struct *dir, const char *path, const char *base, int baselen, const char **pathspec)
{
struct path_simplify *simplify = create_simplify(pathspec);
+ char *pp = NULL;
/*
* Make sure to do the per-directory exclude for all the
@@ -661,7 +662,8 @@ int read_directory(struct dir_struct *dir, const char *path, const char *base, i
*/
if (baselen) {
if (dir->exclude_per_dir) {
- char *p, *pp = xmalloc(baselen+1);
+ char *p;
+ pp = xmalloc(baselen+1);
memcpy(pp, base, baselen+1);
p = pp;
while (1) {
@@ -677,12 +679,12 @@ int read_directory(struct dir_struct *dir, const char *path, const char *base, i
else
p = pp + baselen;
}
- free(pp);
}
}
read_directory_recursive(dir, path, base, baselen, 0, simplify);
free_simplify(simplify);
+ free(pp);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
return dir->nr;
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index a328bf5..287e058 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -104,9 +104,33 @@ test_expect_success 'add ignored ones with -f' '
git ls-files --error-unmatch d.ig/d.if d.ig/d.ig
'
+test_expect_success 'add ignored ones with -f' '
+ rm -f .git/index &&
+ git add -f d.?? &&
+ git ls-files --error-unmatch d.ig/d.if d.ig/d.ig
+'
+
+test_expect_success '.gitignore with subdirectory' '
+
+ rm -f .git/index &&
+ mkdir -p sub/dir &&
+ echo "!dir/a.*" >sub/.gitignore &&
+ >sub/a.ig &&
+ >sub/dir/a.ig &&
+ git add sub/dir &&
+ git ls-files --error-unmatch sub/dir/a.ig &&
+ rm -f .git/index &&
+ (
+ cd sub/dir &&
+ git add .
+ ) &&
+ git ls-files --error-unmatch sub/dir/a.ig
+'
+
mkdir 1 1/2 1/3
touch 1/2/a 1/3/b 1/2/c
test_expect_success 'check correct prefix detection' '
+ rm -f .git/index &&
git add 1/2/a 1/3/b 1/2/c
'
^ permalink raw reply related
* Re: [PATCH] Fix Solaris compiler warnings
From: Junio C Hamano @ 2007-11-16 9:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: Guido Ostkamp, git
In-Reply-To: <20071116074850.GA3400@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Fri, Nov 16, 2007 00:16:25 +0100:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>
>> > Guido Ostkamp, Thu, Nov 15, 2007 23:19:11 +0100:
>> ...
>> >> CC builtin-apply.o
>> >> "builtin-apply.c", line 686: warning: statement not reached
>> >> CC utf8.o
>> >> "utf8.c", line 287: warning: statement not reached
>> >> CC xdiff/xdiffi.o
>> >> "xdiff/xdiffi.c", line 261: warning: statement not reached
>> >
>> > All these are wrong. That's a fantastically broken piece of compiler
>>
>> I've looked at builtin-apply and utf8 cases but these returns
>> are after an endless loop whose exit paths always return
>> directly, so these return statements are in fact never reached.
>> ...
>
> Hmm... Guido, I owe you an appology. Still, consider this patch
> instead (it does not fix the return in xdiff/xdiffi.c though):
If you are referring to the "xdiff/xdiffi.c:line 261" one (which
I did not say if I looked at it or not), I think there is
nothing to fix there, either. In front of itt is a big fat loop
controlled with:
for (ec = 1;; ec++) {
...
}
and only exits from there are returns. Two "break" appear but
they are breaking out of nested inner loops and would not escape
this outermost loop.
^ permalink raw reply
* Re: [PATCH] Git.pm: Don't return 'undef' in vector context.
From: Jakub Narebski @ 2007-11-16 8:43 UTC (permalink / raw)
To: git
In-Reply-To: <473D3593.9080806@zwell.net>
[Cc: Dan Zwell <dzwell@gmail.com>, Petr Baudis <pasky@suse.cz>,
git@vger.kernel.org]
Dan Zwell wrote:
> Previously, the Git->repository()->config('non-existent.key')
> evaluated to as true in a vector context. Return an empty list
> instead.
Nice.
By the way, what do you think about changing Git.pm config handling
to the 'eager' one used currently by gitweb, namely reading all the
config to hash, and later getting config values from hash instead of
calling git-config? Or at least make it an option?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-16 8:37 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: Brian Gernhardt, Git Mailing List
In-Reply-To: <8B2E66EB-22C7-4C08-9947-C0D6A755309F@pp.inet.fi>
El 16/11/2007, a las 5:25, Väinö Järvelä escribió:
> On Nov 15, 2007, at 18:11, Wincent Colaiuta wrote:
>
>> I don't use Darwin Ports or Fink, and this is a clean Leopard
>> install (ie. nothing installed in /usr/local apart from git and a
>> very small number of other tools that aren't related to Subversion).
>>
>> This is the output of "/usr/bin/svn --version":
>>
>> svn, version 1.4.4 (r25188)
>> compiled Sep 23 2007, 22:32:34
>>
>> Perhaps then it is something in the environment.
>
> I cannot reproduce this on Leopard (not yet updated to 10.5.1). I
> tested this with self-compiled GIT from commit id ca2b71c
>
> svn version is the same as yours, I do use Fink, and I have used
> Fink to install Perl SVN bindings.
Strange. I've looked in the environment and there is nothing
suspicious; in fact, running the tests with a totally clean
environment (env -i ./t9101-git-svn-props.sh) produces exactly the
same result.
This was with commit 039bc64e (HEAD of master yesterday). I just
tested the commit you mention (HEAD of next) and get the same failure;
this is the procedure I'm using to test:
git fetch
git checkout -b next_test origin/next
git describe # (v1.5.3.5-1780-gca2b71c)
git clean
make clean && make
cd t
env -i ./t9101-git-svn-props.sh
So really, not sure what could be causing this.
Cheers,
Wincent
^ permalink raw reply
* Re: [StGit RFC] A more structured way of calling git
From: Karl Hasselström @ 2007-11-16 8:36 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, Git Mailing List, Yann Dirson
In-Reply-To: <20071116074255.GA16975@diana.vm.bytemark.co.uk>
On 2007-11-16 08:42:55 +0100, Karl Hasselström wrote:
> The complete state that would have to be saved would be
>
> * (patchname, commit sha1) pairs for all patches
>
> * (branchname, branch head sha1) pair
>
> * the ordered lists of applied, unapplied, and eventually also
> hidden patches
Oh, and
* .git/config (one blob)
* the worktree (one tree object?)
* the index (one tree object per stage?)
Otherwise, we won't be able to un-clobber them. But a first
implementation could certainly skip this part.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Git.pm: Don't return 'undef' in vector context.
From: Dan Zwell @ 2007-11-16 8:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dan Zwell, Git Mailing List
In-Reply-To: <7vfxz61yox.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I did not examine the callers but my gut feeling is that it
> would be simpler and cleaner to always return () without
> checking the context. In scalar context:
>
> sub null {
> ...
> return ();
> }
> my $scalar = null();
>
> would assign undef to $scalar anyway.
>
> I generally try to stay away from functions that changes their
> return values depending on the context, because they tend to
> make reading the callers to find bugs more difficult.
> <snip>
That's reasonable. I'll resend this as part of the git-add--interactive
color patches. This can be cherry-picked out, but some of the other
stuff I want to do depends on it (a helper function that I wrote,
config_with_default($repo, $key, $default)).
Dan
^ permalink raw reply
* Re: [PATCH] Fix Solaris compiler warnings
From: Alex Riesen @ 2007-11-16 7:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Guido Ostkamp, git
In-Reply-To: <7v1war3xrq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Fri, Nov 16, 2007 00:16:25 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Guido Ostkamp, Thu, Nov 15, 2007 23:19:11 +0100:
> >> Hello,
> >>
> >> the below patch fixes some compiler warnings returned by Solaris Workshop
> >> Compilers.
> >>
> >> CC builtin-apply.o
> >> "builtin-apply.c", line 686: warning: statement not reached
> >> CC utf8.o
> >> "utf8.c", line 287: warning: statement not reached
> >> CC xdiff/xdiffi.o
> >> "xdiff/xdiffi.c", line 261: warning: statement not reached
> >
> > All these are wrong. That's a fantastically broken piece of compiler
>
> Eh?
>
> I've looked at builtin-apply and utf8 cases but these returns
> are after an endless loop whose exit paths always return
> directly, so these return statements are in fact never reached.
>
> Dumber compilers may not notice and if you remove these returns
> they may start complaining, though.
Hmm... Guido, I owe you an appology. Still, consider this patch
instead (it does not fix the return in xdiff/xdiffi.c though):
diff --git a/builtin-apply.c b/builtin-apply.c
index 8edcc08..6267396 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -668,13 +668,13 @@ static char *git_header_name(char *line, int llen)
default:
continue;
case '\n':
- return NULL;
+ goto eol;
case '\t': case ' ':
second = name+len;
for (;;) {
char c = *second++;
if (c == '\n')
- return NULL;
+ goto eol;
if (c == '/')
break;
}
@@ -683,6 +683,7 @@ static char *git_header_name(char *line, int llen)
}
}
}
+eol:
return NULL;
}
diff --git a/utf8.c b/utf8.c
index 8095a71..50c46af 100644
--- a/utf8.c
+++ b/utf8.c
@@ -262,7 +262,7 @@ int print_wrapped_text(const char *text, int indent, int indent2, int width)
print_spaces(indent);
fwrite(start, text - start, 1, stdout);
if (!c)
- return w;
+ break;
else if (c == '\t')
w |= 0x07;
space = text;
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 2ade97b..533ff76 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -230,10 +230,9 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
i2++;
}
return i1 >= s1 && i2 >= s2;
- } else
- return s1 == s2 && !memcmp(l1, l2, s1);
+ }
- return 0;
+ return s1 == s2 && !memcmp(l1, l2, s1);
}
static unsigned long xdl_hash_record_with_whitespace(char const **data,
^ permalink raw reply related
* Re: [StGit RFC] A more structured way of calling git
From: Karl Hasselström @ 2007-11-16 7:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, Git Mailing List, Yann Dirson
In-Reply-To: <b0943d9e0711151028y22b37e04y87a6bc74dc4c5031@mail.gmail.com>
On 2007-11-15 18:28:16 +0000, Catalin Marinas wrote:
> I eventually managed to have a (not so in-depth) look at this
Thanks!
> and I am OK with it (but merging after 0.14).
Yes, that seems like a good idea.
> As you said the current structure and the new one will work in
> parallel for some time.
Yes. This is a very nice property that makes the whole enterprise
feasible.
> It would even be possible to implement unit testing.
Yes. Unit testing would be easier with the new code, since it's more
modular.
> Commitdata maybe should be written as CommitData (as in the e-mail
> text).
Probably. I've alredy made that spelling error myself at least once
when writing code.
> The Repository.head property is not cached and it is probably OK to
> avoid some problems I had. We could run profiling afterwards to see
> how often it is called.
Yes. This applies to a few other things as well -- I try to be careful
to write things so that they could be cached transparently if it turns
out we need it. But I also try to not optimize prematurely.
In some cases the caching is more than just a speed optimization.
Commits and trees can be compared with regular Python object identity,
for example, because I never create duplicates.
> > I started to implement a few StGit commands on top of gitlib.py
> > and stacklib.py, and then realized something very appealing:
> >
> > Just about every StGit command can be accomplished by first
> > creating a bunch of new commit objects with gitlib.py, then
> > trying to check out the new HEAD, and then rewriting refs with
> > stacklib.py. Only the first and second steps can possibly fail,
> > and if they do, they do so without leaving any user-visible junk
> > behind. This can be used to make all commands either succeed
> > completely, or do nothing at all.
>
> As you said, that's a bit difficult for 'push' as it is made of a
> series of separate individual patch pushes. Can we not use a
> temporary index by setting GIT_INDEX_FILE during the whole
> transaction and freely update the working copy. Only if the
> transaction fails, we clean the working copy and check out the
> default index? This might slow down some operations though.
The sample code I posted does exactly this index trick. So yes, I
think it's a splendid idea. :-)
Basically, what it does (or eventually should do) is repeatedly use
the temp index to create the new commits without ever touching the
default index or the worktree. Only if a merge conflicts would we
check out one of the parents and spill the conflicts to the worktree.
(And once we're finished pushing we'd want to check out the new stack
top, obviously.)
The only problem is that while git-read-tree can do a three-way merge
in a temp index without touching the worktree, git-merge-recursive
assumes that the worktree reflects one of the trees to be merged and
can be written to. Which is _totally OK_ if there really is going to
be a conflict. But merge-recursive does fancier conflict resolution
than read-tree (I think -- I still have to look up exactly what, but I
don't think read-tree does rename detection for example), so it might
succeed even if read-tree failed.
> In the future, it would be nice to record the stack state before
> transactions in a git object (via pickle) together with HEAD id and
> provide unlimited undo.
Yes, this was exactly what I was refering to when I talked about
transaction logging. The only difference is that I'd prefer a simple
text format instead of a pickle, but we can have a fight about that
detail later. :-)
The complete state that would have to be saved would be
* (patchname, commit sha1) pairs for all patches
* (branchname, branch head sha1) pair
* the ordered lists of applied, unapplied, and eventually also
hidden patches
This is somewhat redundant (applied/unapplied could be inferred from
the commit DAG, etc.) but it would allow us to represent relevant
illegal states as well, which is needed in order to be able to undo
repairs of inconsistent stacks.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: New repo quickly corrupted
From: Andreas Ericsson @ 2007-11-16 7:35 UTC (permalink / raw)
To: Christian Couder
Cc: Linus Torvalds, Nicolas Pitre, Jason Sewall, git, Junio C Hamano
In-Reply-To: <200711160645.04352.chriscool@tuxfamily.org>
Christian Couder wrote:
> Le jeudi 15 novembre 2007, Linus Torvalds a écrit :
>> On Thu, 15 Nov 2007, Nicolas Pitre wrote:
>>> Does "dos2unix" override file access bits? Because the object store is
>>> always made read-only.
>> Almost all programs like that will entirely ignor the fact that something
>> is read-only.
>
> What if the .git/objects/ sudirectories were also read-only ?
>
Then git wouldn't be able to write to it without chmod()'ing it each time.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Marco Costalba @ 2007-11-16 7:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <18233.30098.470244.421468@cargo.ozlabs.ibm.com>
On 11/13/07, Paul Mackerras <paulus@samba.org> wrote:
> Linus Torvalds writes:
>
> > However, while the parent is now correctly rewritten, it looks like gitk
> > is confused by this. Gitk will remember the original parent information,
> > even if a replay has given new parenthood information. Since the partial
> > early-output information is triggered by timing, this means that gitk will
> > show some totally random parent that quite possibly won't even be part of
> > the final commit set at all!
>
> Yep. It will be a little complex to deal with that because there are
> bits of state that I set up for the parents, and if they're the wrong
> parents, I'll have to go back and undo that.
>
Sorry to comment on a gitk thread, but the problem of different
parents for the same sha while replaying was hitted by me also with
qgit when tring to implement --early-output
I don't know if i is suitable also for gitk but in qgit I changed the
match algorithm to check also for same parents and not only for same
sha during a replay to detect something has changed, so to catch
different parents cases early on and avoiding "going back" that is
complex.
IOW when git log print outs a replay qgit enter in a state where it
checks all the arrived sha against the already sent ones and at the
first mismatch flushes the tail at the point of mismatch.
The modified algorithm instead of chek just the sha checks also
parents info (because git log is called with --parents option this
ends up comparing the first line of the commit message).
Marco
^ permalink raw reply
* Re: [PATCH] Git.pm: Don't return 'undef' in vector context.
From: Junio C Hamano @ 2007-11-16 6:39 UTC (permalink / raw)
To: Dan Zwell; +Cc: Git Mailing List
In-Reply-To: <473D3593.9080806@zwell.net>
Dan Zwell <dzwell@gmail.com> writes:
> Previously, the Git->repository()->config('non-existent.key')
> evaluated to as true in a vector context. Return an empty list
> instead.
> ---
> I don't know whether this breaks anything, because I don't use most of
> the git perl scripts. I can't imagine that there is a script that
> relies on the fact that config('non-existent.key') actually returns
> (''), in an array context. Is this a reasonable change?
I did not examine the callers but my gut feeling is that it
would be simpler and cleaner to always return () without
checking the context. In scalar context:
sub null {
...
return ();
}
my $scalar = null();
would assign undef to $scalar anyway.
I generally try to stay away from functions that changes their
return values depending on the context, because they tend to
make reading the callers to find bugs more difficult. An
exception is a function that tries to mimic a built-in operator,
because reading the callers to such a function, as long as it is
clear which built-in the function is imitating, can apply the
same knowledge on how the callee would behave you already have
by knowing Perl itself.
The same thing can be said about functions with prototypes to
force certain context on the caller's side. Avoid it unless
there is a good reason.
Maybe it is just me, but that's my reaction.
^ permalink raw reply
* [PATCH] Git.pm: Don't return 'undef' in vector context.
From: Dan Zwell @ 2007-11-16 6:15 UTC (permalink / raw)
To: Git Mailing List
Previously, the Git->repository()->config('non-existent.key')
evaluated to as true in a vector context. Return an empty list
instead.
---
I don't know whether this breaks anything, because I don't use most of
the git perl scripts. I can't imagine that there is a script that relies
on the fact that config('non-existent.key') actually returns (''), in an
array context. Is this a reasonable change?
perl/Git.pm | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index e9dc706..ffcc541 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -508,7 +508,7 @@ sub config {
my $E = shift;
if ($E->value() == 1) {
# Key not found.
- return undef;
+ return wantarray ? () : undef;
} else {
throw $E;
}
--
1.5.3.5.565.gf0b83-dirty
^ permalink raw reply related
* (Git) PeepCode & Pizza, Tuesday 12/4
From: Rich Morin @ 2007-11-16 5:40 UTC (permalink / raw)
To: Git Mailing List
Free Food! Free Movies! Free Software!
Come watch the newly released PeepCode screencast on Git,
Linus Torvalds' distributed source-code management system.
The plan is to munch on pizza, then watch a PeepCode video,
with occasional pauses for questions, etc. Reactrix uses
Git extensively, so we can answer _some_ questions. We're
also hoping that some helpful wizards may show up...
This inaugural PeepCode & Pizza gathering is made possible
by the generosity of PeepCode and Reactrix Systems. The
meeting will be held at the Reactrix offices in Redwood City
from 6-9 pm on Tuesday, December 4.
About Git
Git is a distributed source-code management system, written
by Linus Torvalds and used since 2005 on the Linux kernel.
In his fun, opinionated Tech Talk, Linus explains why fast,
reliable, and (most of all) distributed SCM systems rock:
http://www.youtube.com/watch?v=4XpnKHJAok8
Additional information on Git can be found at:
http://en.wikipedia.org/wiki/Git_(software)
http://git.or.cz/
About PeepCode and Reactrix Systems
PeepCode (http://peepcode.com) produces economical, well-
produced screencasts on technical topics (e.g., Capistrano,
Git, httperf, Prototype.js, Rails, RJS, rSpec, TextMate).
Reactrix develops and supports video-based interactive
advertising devices. Generally, these are placed in malls,
theaters, etc. We use a variety of Open Source technologies,
including C++, Capistrano, Git, Linux, OpenGL, Perl, Rails,
and Ruby. Yes, we're hiring!
http://www.reactrix.com/
http://www.reactrix.com/index.php
http://www.reactrix.com/careers.php
When:
Tuesday, December 4, 2007
6p - 7p chat, munch pizza, etc.
Reactrix demo machines will be available.
7p - 9p watch a PeepCode screencast, with pauses
for questions, discussion, etc.
9p - ?? retire (perhaps) to a local pub
NOTE: RSVPs (rdm@cfcl.com) are greatly appreciated; help
us to know how much pizza (and what kind) to order!
Where:
Reactrix Systems, Inc. 650-980-2700
301 Chesapeake Drive
Redwood City, CA
Map: http://tinyurl.com/27b22y
Directions: http://www.reactrix.com/driving_directions.php
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
^ permalink raw reply
* Re: git-cvsimport bug with dates
From: Junio C Hamano @ 2007-11-16 6:06 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
In-Reply-To: <51419b2c0711152059q55ced86gd224310c8c4a1851@mail.gmail.com>
"Elijah Newren" <newren@gmail.com> writes:
> $ git diff @{2007-10-01}
> warning: Log for '' only goes back to Wed, 24 Oct 2007 19:31:38 +0000.
> fatal: bad object @{2007-10-01}
>
>
> It appears that passing a date to git diff on any repository imported
> by git-cvsimport will show this error, as long as the date is prior to
> when the repository was imported.
That is not a cvsimport specific issue.
When you use "branch@{date}" notation, you are not asking a
question on the project history, but a question on the local
view from _your_ repository on that project.
$ git log --since=3.days.ago master
asks "go back from the master tip and show commits until you hit
the commit made earlier than that date and stop traversing".
On the other hand,
$ git show master@{3.days.ago}
asks "show the commit that was the tip of 'master' branch in my
repository three days ago." Maybe you pulled from your upstream
5 minutes ago, and the last time before that, you pulled three
weeks ago and did not do any development on the branch. In such
a case, the latter question will give you the tip of your
'master' as of three weeks ago which is the same as of three
days ago.
^ permalink raw reply
* Re: Git User's Survey 2007 summary at GitWiki
From: Junio C Hamano @ 2007-11-16 5:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711160302.59786.jnareb@gmail.com>
Tabulating answers to questions like #5 and #8 must have been
very time consuming work. Perhaps next year's survey can be
made more "multiple choices", taking choices from this survey.
Thanks.
^ permalink raw reply
* Re: New repo quickly corrupted
From: Christian Couder @ 2007-11-16 5:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Jason Sewall, git, Junio C Hamano
In-Reply-To: <alpine.LFD.0.9999.0711151434290.4260@woody.linux-foundation.org>
Le jeudi 15 novembre 2007, Linus Torvalds a écrit :
> On Thu, 15 Nov 2007, Nicolas Pitre wrote:
> > Does "dos2unix" override file access bits? Because the object store is
> > always made read-only.
>
> Almost all programs like that will entirely ignor the fact that something
> is read-only.
What if the .git/objects/ sudirectories were also read-only ?
Christian.
^ permalink raw reply
* Re: git-fetch--tool and contrib/examples/git-fetch.sh
From: Junio C Hamano @ 2007-11-16 5:16 UTC (permalink / raw)
To: bonzini; +Cc: Git Mailing List
In-Reply-To: <473C45A8.7020903@lu.unisi.ch>
Paolo Bonzini <paolo.bonzini@lu.unisi.ch> writes:
> When git-fetch was builtin-ized the previous script was moved to
> contrib/examples. Now, it is the sole remaining user for most of
> git-parse-remote (except for get_remote_url) and for git-fetch--tool.
Yeah, moving them when they cease to be used to contrib/examples
would be a good thing to do.
^ permalink raw reply
* Re: [PATCH v2 3/3] send-pack: assign remote errors to each ref
From: Junio C Hamano @ 2007-11-16 5:05 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, git, Pierre Habouzit, Daniel Barkalow,
Alex Riesen
In-Reply-To: <20071115045414.GC9794@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 14, 2007 at 02:01:14AM +0000, Johannes Schindelin wrote:
>
>> Since when can refnames contain spaces? In my copy of git, bad_ref_char()
>> in refs.c returns 1 if ch <= ' '. It's the first error path, even.
>
> Oops, I'm clearly an idiot. I explicitly looked at bad_ref_char before
> writing the original message, and somehow read that as strictly less
> than.
>
> So the parsing problem goes away, and I think using the sort order as a
> hint takes away the potential performance problem (I don't even know if
> it was a problem -- there may be other O(n^2) behavior).
>
> I will take a look at the tests Alex has been working on, maybe add a
> few to it, and submit a cleaned-up series.
Thanks.
^ permalink raw reply
* git-cvsimport bug with dates
From: Elijah Newren @ 2007-11-16 4:59 UTC (permalink / raw)
To: git
Hi,
It appears that there's some kind of bug with git-cvsimport and dates.
In a small repository I imported on Oct 24, I'm getting:
$ git log | grep ^Date | wc -l
957
$ git log | grep ^Date | tail
Date: Tue Oct 29 21:10:17 2002 +0000
Date: Tue Oct 29 17:41:05 2002 +0000
Date: Tue Oct 29 00:43:27 2002 +0000
Date: Mon Oct 28 23:36:40 2002 +0000
Date: Mon Oct 21 21:35:57 2002 +0000
Date: Fri Sep 20 22:18:01 2002 +0000
Date: Mon Sep 16 20:05:27 2002 +0000
Date: Wed Sep 11 21:14:03 2002 +0000
Date: Tue Sep 10 16:37:16 2002 +0000
Date: Fri Aug 23 16:03:22 2002 +0000
$ git diff @{2007-10-01}
warning: Log for '' only goes back to Wed, 24 Oct 2007 19:31:38 +0000.
fatal: bad object @{2007-10-01}
It appears that passing a date to git diff on any repository imported
by git-cvsimport will show this error, as long as the date is prior to
when the repository was imported.
Elijah
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc.
From: Junio C Hamano @ 2007-11-16 4:58 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: gitster, raa.lkml, git, git
In-Reply-To: <1195089303-28085-1-git-send-email-B.Steinbrink@gmx.de>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Guido, could you please test this patch?
>
> I have no clue which versions of SUN's cc are affected, so I simply enabled
> the workaround for all versions. Someone with more knowledge about that
> should probably limit the check to only do that for the broken versions.
>
> git-compat-util.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
> diff --git a/git-compat-util.h b/git-compat-util.h
> index ede9408..c3ff4b4 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -6,6 +6,8 @@
> #ifndef FLEX_ARRAY
> #if defined(__GNUC__) && (__GNUC__ < 3)
> #define FLEX_ARRAY 0
> +#elif defined(sun) || defined(__SUN__)
> +#define FLEX_ARRAY 1
> #else
> #define FLEX_ARRAY /* empty */
> #endif
This feels a bit too narrow and too broad at the same time,
doesn't it?
As I suspect there are other compilers that do not implement
flexible array members (so you cannot use "member[]") nor older
gcc extension of zero sized member (so you cannot use
"member[0]" either), this checking specifically for Sun is too
narrow.
On the other hand, as you said, this is too broad, because not
everybody may be using the SUN compiler on Sun, nor the version
that does not understand flexible array members.
But being broad should always be safer, albeit a bit wasteful.
How about doing it this way?
# ifndef FLEX_ARRAY
# if defined(__GNUC__)
# if (__GNUC__ < 3)
# define FLEX_ARRAY 0
# else
# define FLEX_ARRAY /* empty */
# endif
# else
/* more cases we know we can use 0 or empty can come here */
# endif
# endif
/* if still undefined, default to the safe, old fashioned way */
# ifndef FLEX_ARRAY
# define FLEX_ARRAY 1
# endif
The basic idea is:
* The user (from Makefile command line, config.mak, or you
could add autoconf test) can pass -DFLEX_ARRAY=... to specify
exactly what should happen;
* Otherwise, if we happen to know for sure that we can use "0"
or "/* empty */" with the compiler, we define FLEX_ARRAY;
currently we know such things for gcc.
* For everybody else, we use safer default of "1". IOW, if you
know your compiler does not grok "/* empty */" nor "0", you
do not have to do anything special but use the default case
as everybody else.
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Väinö Järvelä @ 2007-11-16 4:25 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Brian Gernhardt, Git Mailing List
In-Reply-To: <041C0054-5E50-483C-9779-B2FE1AE6947C@wincent.com>
On Nov 15, 2007, at 18:11, Wincent Colaiuta wrote:
> El 15/11/2007, a las 17:04, Brian Gernhardt escribió:
>
>> On Nov 15, 2007, at 8:46 AM, Wincent Colaiuta wrote:
>>
>>> Was just running the test suite against the master branch and saw
>>> that t9101 is currently failing on Leopard, and a review with git-
>>> bisect indicates that it has been ever since it was first
>>> introduced (in commit 15153451). Not sure if this problem is
>>> Leopard-specific or not as I only have one machine.
>>
>> It is not a Leopard specific problem, as far as I can tell. I just
>> ran the test and had no errors on my Leopard machine. So perhaps
>> it's some other detail of your setup?
>>
>>> I'm not a git-svn user myself, but if there's anything I can do to
>>> help diagnose this problem further on Leopard please let me know.
>>
>> I just tested it using svn from fink and (after discovering it
>> exists) from Leopard. No problems. Do you have an old svn package
>> (client, admin, or perl binding) installed from Darwin Ports or
>> Fink perhaps?
>
> I don't use Darwin Ports or Fink, and this is a clean Leopard
> install (ie. nothing installed in /usr/local apart from git and a
> very small number of other tools that aren't related to Subversion).
>
> This is the output of "/usr/bin/svn --version":
>
> svn, version 1.4.4 (r25188)
> compiled Sep 23 2007, 22:32:34
>
> Perhaps then it is something in the environment.
I cannot reproduce this on Leopard (not yet updated to 10.5.1). I
tested this with self-compiled GIT from commit id ca2b71c
svn version is the same as yours, I do use Fink, and I have used Fink
to install Perl SVN bindings.
--
Väinö
^ permalink raw reply
* Re: [PATCH] user-manual.txt: fix a few mistakes
From: J. Bruce Fields @ 2007-11-16 3:54 UTC (permalink / raw)
To: Sergei Organov; +Cc: git, gitster
In-Reply-To: <87lk8z3idj.fsf@osv.gnss.ru>
On Thu, Nov 15, 2007 at 01:36:40PM +0300, Sergei Organov wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Tue, Nov 13, 2007 at 09:19:39PM +0300, Sergei Organov wrote:
> >>
> >> Signed-off-by: Sergei Organov <osv@javad.com>
> >> ---
> >> Documentation/user-manual.txt | 8 ++++----
> >> 1 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> >> index d99adc6..a169ef0 100644
> >> --- a/Documentation/user-manual.txt
> >> +++ b/Documentation/user-manual.txt
> >> @@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
> >> If you run "git branch" at this point, you'll see that git has
> >> temporarily moved you to a new branch named "bisect". This branch
> >> points to a commit (with commit id 65934...) that is reachable from
> >> -v2.6.19 but not from v2.6.18. Compile and test it, and see whether
> >> +"master" but not from v2.6.18. Compile and test it, and see whether
> >> it crashes. Assume it does crash. Then:
> >>
> >> -------------------------------------------------
> >> @@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
> >> fundamentally different ways to fix the problem:
> >>
> >> 1. You can create a new commit that undoes whatever was done
> >> - by the previous commit. This is the correct thing if your
> >> + by the old commit. This is the correct thing if your
> >> mistake has already been made public.
> >>
> >> 2. You can go back and modify the old commit. You should
> >> @@ -1567,8 +1567,8 @@ old history using, for example,
> >> $ git log master@{1}
> >> -------------------------------------------------
> >>
> >> -This lists the commits reachable from the previous version of the head.
> >> -This syntax can be used to with any git command that accepts a commit,
> >
> > I actually prefer "head" here. On something like:
> >
> > A--B--C
> > /
> > o--o--o
> > \
> > o--o--o
> >
> >
> > The term "branch" could be used to refer to the whole line of
> > development consisting of A, B, and C. The term "head", on the other
> > hand, refers to either C or a ref that points to it. We also use the
> > terms "branch head" or just "branch" for that case, but I think "head"
> > is more precise.
>
> Then I'd suggest to be precise here, e.g.:
>
> "This lists the commits reachable from the previous version of the
> "master" branch head."
That sounds sensible to me, sure.
>
> The real reason for me to replacing "head" with "branch" in the first
> place was that a few lines below there is example for HEAD, and I wanted
> to make it more obvious that those is entirely different.
OK, sure. Thanks for the thoughtful editing!
--b.
^ permalink raw reply
* Re: conversion from svn with renames
From: Väinö Järvelä @ 2007-11-16 3:49 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: Ricardo SIGNES, git
In-Reply-To: <D5A64E6F-D80B-4FCD-8184-F53812D4312E@pp.inet.fi>
Eh, sorry for replying to a old post, I had accidentally had my mail
sorted in reverse. I hope the post was still useful.
--
Väinö
On Nov 16, 2007, at 05:16, Väinö Järvelä wrote:
> Hi,
>
> I tried importing an SVN project with svn-import, and the project
> had been renamed once. It seems that git-svn is more mature tool for
> this, even if svn-import seems to be the one to use. If I remember
> correctly, there was even talk about this very same case in the
> mailing list archives.
>
> To make a complete conversion from SVN repository to GIT
> repositories, just use --no-metadata option to remove all the
> metadata git-svn normally appends to the commit messages. There will
> also be some cruft in the .git/config file, I removed those, and
> have had an working import with renames from SVN.
>
> --
> Väinö
>
> On Jul 29, 2007, at 15:23, Ricardo SIGNES wrote:
>
>>
>> I'd like to convert svn.codesimply.com/projects' contents to git.
>>
>> Right now, the content is like this:
>>
>> /projects/$PROJECTNAME/{trunk,tags,branches}
>>
>> git-svnimport does well if I specify projects/$PROJECTNAME/trunk as
>> the trunk
>> directory and that/tags as the tags directory. (I am not
>> interested in
>> bothering with branches.) The problem is this:
>>
>> For many of the projects, $PROJECTNAME was once "foo" and is now
>> "bar."
>> git-svnimport only imports the history from the current name.
>>
>> I tried to import foo, then bar, into one git repostiory, but the
>> histories
>> didn't seem to get connected. Sam V. suggested git-filter-branch,
>> but I didn't
>> quite see how to make it do what I wanted.
>>
>> I would greatly appreciate any advice or help on this conversion.
>>
>> --
>> rjbs
>> -
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: conversion from svn with renames
From: Väinö Järvelä @ 2007-11-16 3:16 UTC (permalink / raw)
To: Ricardo SIGNES; +Cc: git
In-Reply-To: <20070729122301.GA17016@knight.manxome.org>
Hi,
I tried importing an SVN project with svn-import, and the project had
been renamed once. It seems that git-svn is more mature tool for this,
even if svn-import seems to be the one to use. If I remember
correctly, there was even talk about this very same case in the
mailing list archives.
To make a complete conversion from SVN repository to GIT repositories,
just use --no-metadata option to remove all the metadata git-svn
normally appends to the commit messages. There will also be some cruft
in the .git/config file, I removed those, and have had an working
import with renames from SVN.
--
Väinö
On Jul 29, 2007, at 15:23, Ricardo SIGNES wrote:
>
> I'd like to convert svn.codesimply.com/projects' contents to git.
>
> Right now, the content is like this:
>
> /projects/$PROJECTNAME/{trunk,tags,branches}
>
> git-svnimport does well if I specify projects/$PROJECTNAME/trunk as
> the trunk
> directory and that/tags as the tags directory. (I am not interested
> in
> bothering with branches.) The problem is this:
>
> For many of the projects, $PROJECTNAME was once "foo" and is now
> "bar."
> git-svnimport only imports the history from the current name.
>
> I tried to import foo, then bar, into one git repostiory, but the
> histories
> didn't seem to get connected. Sam V. suggested git-filter-branch,
> but I didn't
> quite see how to make it do what I wanted.
>
> I would greatly appreciate any advice or help on this conversion.
>
> --
> rjbs
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Git User's Survey 2007 summary at GitWiki
From: Jakub Narebski @ 2007-11-16 2:02 UTC (permalink / raw)
To: git
I'd like to announce that summary of Git User's Survey 2007 is now
present on Git Wiki at
http://git.or.cz/gitwiki/GitSurvey2007
P.S. There are still few questions for which there are not full
analysis, or are not analized at all.
--
Jakub Narebski
Poland
^ 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