* Re: [PATCH] Fix PPC SHA1 routine for large input buffers
From: Linus Torvalds @ 2006-06-19 5:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Martin Langhoff, Nicolas Pitre, Jon Smirl, git
In-Reply-To: <17557.57564.267469.561683@cargo.ozlabs.ibm.com>
On Mon, 19 Jun 2006, Paul Mackerras wrote:
>
> The PPC SHA1 routine had an overflow which meant that it gave
> incorrect results for input buffers >= 512MB. This fixes it by
> ensuring that the update of the total length in bits is done using
> 64-bit arithmetic.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Linus Torvalds <torvalds@osdl.org>
This fixes git-fsck-objects for me on the mozilla archive, no more
complaints about bad SHA1's.
And yeah, now it's taking me 14 minutes too, so the 7-minute fsck was just
because it didn't actually check the SHA1 of the large pack fully.
(Which is actually good news - half of the time is literally checking the
pack integrity. That implies that the individual object integrity isn't as
dominating as I thought it would be, and that things like hw-accelerated
SHA1 engines will help with fsck. I'd not be surprised to see things like
that in a couple of years).
Linus
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Junio C Hamano @ 2006-06-19 3:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <4495DB3B.10403@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> But if what Ryan says is true, about simply needing to ditch
> the "-f" argument I habitually pass to 'git checkout', would that
> alleviate the need for a patch?
To a certain degree, yes.
But I suspect (I am not a kernel person so I can only speculate)
in the kernel workflow you would often pick up a patch from the
list, apply it to your working tree (without applying it to your
index, IOW with "patch -p1" or "git apply", not with "git apply
--index"), and then decide to pull from somewhere else while
your working tree is dirty (but index is not). The patch might
have created a new file or two, and the pull may also contain a
commit that applied the same patch in question. The no-clobber
check would trigger in such a case preventing you from pulling,
and neither "checkout" nor "checkout -f" would clean these new
files that you have not told git about.
> FWIW, my workflow is
>
> cd /repos
> cd linux-2.6
> git pull
> cd ../libata-dev
> git checkout -f master # guarantee any WIP goes away
We kept saying "with checkout -f any dirty state goes away from
your working tree". It is true only with respect to the files
git knows about. The trouble you experienced was about
untracked files -- files git does not know about, and they will
be left behind.
So if path F is in test branch head and linus branch head, but
not in your master branch head, and you have checked out test in
your working tree, even if path F in the working tree is clean:
git checkout -f master
will leave F behind. If you pull from linus at this point, the
check would trigger. Running "git checkout master" without -f
would however remove it and you would not have the problem.
That is what Ryan's suggestion is about.
However, if you have a patch you got from somebody on the net
that creates F (maybe it is the same patch linus accepted
recently) while on your master branch, and you tried to examine
it by applying it to your working tree with "patch -p1" or "git
apply", your working tree will have F that is not in index (and
in your branch head). In that state if you pull from linus, the
no-clobber check triggers. In this case, neither "git checkout
master", "git checkout -f master", nor "git reset --hard master"
would remove F, because git does not even know about it, so
pulling from linus would fail. "git clean" would removes F, so
it may not be a big deal, but it is rather a heavy-handed
operation that removes all crufts, so you may find it a
not-so-useful workaround (I certainly would, and that is the
primary reason I rarely use "git clean" myself).
It's a bit sad situation. One of the useful feature of git is
that you can continue working in a dirty working tree as long as
your index is clean and your local changes do not interfere with
a merge, patch application, or branch switching. Strictly
speaking, this no-clobber check _is_ about a local change that
does interfere with the operation, so from theoretical point of
view it is a good safety measure, but at the same time we did
not consider untracked files as precious until recently, and I
suspect that "the same patch applied elsewhere to create the
same file" pattern is reasonably common that this safety valve
may interfere the work more often than it may help avoiding
mistakes.
^ permalink raw reply
* [PATCH] Fix PPC SHA1 routine for large input buffers
From: Paul Mackerras @ 2006-06-18 23:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, Nicolas Pitre, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606181543270.5498@g5.osdl.org>
The PPC SHA1 routine had an overflow which meant that it gave
incorrect results for input buffers >= 512MB. This fixes it by
ensuring that the update of the total length in bits is done using
64-bit arithmetic.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Linus Torvalds writes:
> Paul - I think the ppc SHA1_Update() overflows in 32 bits, when the length
> of the memory area to be checksummed is huge.
Yep. I checked the assembly output of this, and it looks right, but I
haven't actually tested it by running it...
Paul.
diff --git a/ppc/sha1.c b/ppc/sha1.c
index 5ba4fc5..0820398 100644
--- a/ppc/sha1.c
+++ b/ppc/sha1.c
@@ -30,7 +30,7 @@ int SHA1_Update(SHA_CTX *c, const void *
unsigned long nb;
const unsigned char *p = ptr;
- c->len += n << 3;
+ c->len += (uint64_t) n << 3;
while (n != 0) {
if (c->cnt || n < 64) {
nb = 64 - c->cnt;
^ permalink raw reply related
* Re: git 1.4.0 usability problem
From: Jeff Garzik @ 2006-06-18 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson
In-Reply-To: <7vbqsqdru0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jeff Garzik <jeff@garzik.org> writes:
>
>> Here is how to reproduce:
>
> This is not related to the "not clobbering untracked files"
> safety valve under discussion, but one thing I noticed.
>
>> git clone -l $url/torvalds/linux-2.6.git tmp-2.6
>> cd tmp-2.6
>> cp .git/refs/tags/v2.6.12 .git/refs/heads/tmp
>> git checkout -f tmp
>
> This should never have been supported. At this point tmp is a
> tag object that is under heads/ -- a definite no-no. We should
> make checkout more careful to complain about it.
>
> Doing
>
> git update-ref refs/heads/tmp $(git rev-parse v2.6.12^0)
>
> instead of "cp" is kosher, and
>
> git-rev-parse v2.6.12^0 >.git/refs/heads/tmp
>
> is OK under the current implementation of refs.
Sorry about that. The contrived example produced the same results as
the real-world example (updating jgarzik/{libata-dev,scsilun-2.6}.git
branches).
>> git pull . master
>> # watch OBVIOUS FAST-FORWARD MERGE complain about untracked
>> # working tree files
>
> In any case, here is a patch I think would alleviate your
> original problem.
>
> Sorry for the trouble. I really did not want to disrupt the
> workflow of old timers in the name of making it safer for new
> people. Could you comment on whether this is an acceptable
> approach?
>
> -- >8 --
> [PATCH] Conditionally loosen "no clobber untracked files" safety valve.
>
> This introduces a new configuration item "core.oktoclobber" to
> control how untracked working tree file is handled during branch
> switching.
>
> The safety valve introduced during 1.4.0 development cycle
> refrains from checking out a file that exists in the working
> tree, not in the current HEAD tree and exists in the branch we
> are switching to, in order to prevent accidental and
> irreversible lossage of user data. This can be controlled by
> having core.oktoclobber configuration item:
I'm a bit under the weather today, so I must defer thinking about this.
:) But if what Ryan says is true, about simply needing to ditch the
"-f" argument I habitually pass to 'git checkout', would that alleviate
the need for a patch?
FWIW, my workflow is
cd /repos
cd linux-2.6
git pull
cd ../libata-dev
git checkout -f master # guarantee any WIP goes away
git pull ../linux-2.6 # update vanilla branch
git checkout -f upstream# switch to working branch,
# guarantee any WIP goes away.
git pull . master # pull latest upstream updates
build/test/etc.
git checkout -f sii-m15w # switch to topic-specific branch,
# whose parent is always #upstream
git pull . upstream
build/test/etc.
repeat for several topics (on-going devel branches)
git checkout -f -b ALL upstream # create everything-together
# test branch
git pull . sii-m15w
git pull . topicB
git pull . topicC
build/test/etc.
git checkout -f master
./push # calls 'git push --force --all $url'
More tomorrow,
Jeff
^ permalink raw reply
* Broken PPC sha1.. (Re: Figured out how to get Mozilla into git)
From: Linus Torvalds @ 2006-06-18 22:51 UTC (permalink / raw)
To: Martin Langhoff, Paul Mackerras; +Cc: Nicolas Pitre, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606181532130.5498@g5.osdl.org>
On Sun, 18 Jun 2006, Linus Torvalds wrote:
>
> On Mon, 19 Jun 2006, Martin Langhoff wrote:
> >
> > No problems here with my latest import run. fsck-objects --full comes
> > clean, takes 14m:
> >
> > /usr/bin/time git-fsck-objects --full
> > 737.22user 38.79system 14:09.40elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (20807major+19483471minor)pagefaults 0swaps
>
> It takes much less than that for me:
>
> 408.40user 32.56system 7:22.07elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (145major+13455672minor)pagefaults 0swaps
Ok, re-building the thing with MOZILLA_SHA1=1 rather than my default
PPC_SHA1=1 fixes the problem. I no longer get that "SHA1 mismatch with
itself" on the pack-file.
Sadly, it also takes a _lot_ longer to fsck.
Paul - I think the ppc SHA1_Update() overflows in 32 bits, when the length
of the memory area to be checksummed is huge.
In particular, the pack-file is 535MB in size, and the way we check the
SHA1 checksum is by just mapping it all, doing a single SHA1_Update() over
the whole pack-file, and comparing the end result with the internal SHA1
at the end of the pack-file.
The PPC SHA1_Update() function starts off with:
int SHA1_Update(SHA_CTX *c, const void *ptr, unsigned long n)
{
...
c->len += n << 3;
which will obviously overflow if "n" is bigger than 29 bits, ie 512MB.
So doing the length in bits (or whatever that "<<3" is there for) doesn't
seem to be such a great idea.
I guess we could make the caller just always chunk it up, but wouldn't it
be nice to fix the PPC SHA1 implementation instead?
That said, the _only_ thing this will ever trigger on in practice is
exactly this one case: a large packfile whose checksum was _correctly_
generated - because pack-file generation does it in IO chunks using the
csum-file interfaces - but that will be incorrectly checked because we
check it all at once.
So as bugs go, it's a fairly benign one.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-18 22:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Nicolas Pitre, Jon Smirl, git
In-Reply-To: <46a038f90606181440q4fd03bebl9495ace131eb958@mail.gmail.com>
On Mon, 19 Jun 2006, Martin Langhoff wrote:
>
> No problems here with my latest import run. fsck-objects --full comes
> clean, takes 14m:
>
> /usr/bin/time git-fsck-objects --full
> 737.22user 38.79system 14:09.40elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (20807major+19483471minor)pagefaults 0swaps
It takes much less than that for me:
408.40user 32.56system 7:22.07elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (145major+13455672minor)pagefaults 0swaps
and in particular note the much lower minor pagefaults number (which is a
very good approximation of total RSS). Mine is with all the memory
optimizations in place, but I didn't see _that_ big of a difference, so
there's something else in addition.
However, the fact that I get "SHA1 mismatch with itself" is strange. The
re-pack will always re-generate the SHA1, so I worry that this is perhaps
some PPC-specific bug in SHA1 handling (and it's entirely possible that
it's triggered by doing a SHA1 over a 500+MB area).
The fact that you don't see it is indicative that it's somehow specific to
my setup.
> BTW, that import (with the latest code Junio has) took 37hs even with
> the aggressive repack -a -d. I want to bench it dropping the -a from
> the recurrring repack, and doing a final repack -a -d.
Yeah, that's probably the right thing to do. The "-a" is ok with tons of
memory, and I'm trying to make it ok with _less_ memory, but it's probably
just not worth it.
Linus
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Ryan Anderson @ 2006-06-18 22:27 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Jeff Garzik, Git Mailing List
In-Reply-To: <20060618164300.GI25520@h4x0r5.com>
On Sun, Jun 18, 2006 at 09:43:00AM -0700, Ryan Anderson wrote:
>
> The fix is to drop the "-f" from git checkout, and things should work
> correctly. ("-f" should really not be a normal thing to use. For
> switching branches, "git checkout" should be sufficient, and should
> result ina working tree that doesn't contain nearly as many potential
> conflict sources.
I wrote all of that from memory, but I figured I should really test it:
$ git branch tmp v2.6.12
$ git checkout tmp
$ git pull . master
Updating from 9ee1c939d1cb936b1f98e8d81aeffab57bae46ab to
553698f944ed715dfe023b4cef07601f0ce735f0
Checking files out...
100% (14284/14284) done
Fast forward
(Watch insanely large diffstat blow by)
$ git status
# On branch refs/heads/tmp
nothing to commit
$ git branch
master
origin
ryan
* tmp
So, I think all you need to do is drop the "-f" from the call to
checkout, and the issues will be fixed, for your particular use case.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Junio C Hamano @ 2006-06-18 22:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git, Ryan Anderson
In-Reply-To: <449557B6.1080907@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> Here is how to reproduce:
This is not related to the "not clobbering untracked files"
safety valve under discussion, but one thing I noticed.
> git clone -l $url/torvalds/linux-2.6.git tmp-2.6
> cd tmp-2.6
> cp .git/refs/tags/v2.6.12 .git/refs/heads/tmp
> git checkout -f tmp
This should never have been supported. At this point tmp is a
tag object that is under heads/ -- a definite no-no. We should
make checkout more careful to complain about it.
Doing
git update-ref refs/heads/tmp $(git rev-parse v2.6.12^0)
instead of "cp" is kosher, and
git-rev-parse v2.6.12^0 >.git/refs/heads/tmp
is OK under the current implementation of refs.
> git pull . master
> # watch OBVIOUS FAST-FORWARD MERGE complain about untracked
> # working tree files
In any case, here is a patch I think would alleviate your
original problem.
Sorry for the trouble. I really did not want to disrupt the
workflow of old timers in the name of making it safer for new
people. Could you comment on whether this is an acceptable
approach?
-- >8 --
[PATCH] Conditionally loosen "no clobber untracked files" safety valve.
This introduces a new configuration item "core.oktoclobber" to
control how untracked working tree file is handled during branch
switching.
The safety valve introduced during 1.4.0 development cycle
refrains from checking out a file that exists in the working
tree, not in the current HEAD tree and exists in the branch we
are switching to, in order to prevent accidental and
irreversible lossage of user data. This can be controlled by
having core.oktoclobber configuration item:
- When core.oktoclobber is set to "false" (the default),
untracked working tree files are never overwritten.
- When core.oktoclobber is set to "true", the check is
disabled.
- When core.oktoclobber is set to "ask", and both standard
input and standard error streams are connected to the
terminal, we ask the user if it is OK to clobber. You can
answer:
y: to allow clobbering only one path; the question is
asked again for other paths.
n: to stop the operation.
a: to allow clobbering any untracked files; the question
is not asked again.
If the configuration item is set to "ask" but the program is
not talking to a terminal, it refrains from clobbering the
untracked files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-read-tree.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
cache.h | 6 ++++++
config.c | 20 ++++++++++++++++++++
environment.c | 1 +
4 files changed, 69 insertions(+), 1 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 04506da..7a7018c 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -477,6 +477,46 @@ static void invalidate_ce_path(struct ca
cache_tree_invalidate_path(active_cache_tree, ce->name);
}
+static int ok_to_clobber_untracked(const char *path, const char *action)
+{
+ switch (ok_to_clobber_untracked_files) {
+ case NEVER_CLOBBER:
+ return 0;
+ case OK_TO_CLOBBER:
+ return 1;
+ case ASK_TO_CLOBBER:
+ if (isatty(0) && isatty(2)) {
+ char answer[1024];
+ while (1) {
+ answer[0] = '\0';
+ fprintf(stderr,
+ "Untracked working tree file '%s' is"
+ " about to be %s. Is it OK "
+ "[y]es/[n]o/yes to [a]ll? ",
+ path, action);
+ fgets(answer, sizeof(answer), stdin);
+ switch (answer[0]) {
+ case 'y': case 'Y':
+ return 1;
+ case 'n': case 'N':
+ return 0;
+ case 'a': case 'A':
+ ok_to_clobber_untracked_files =
+ OK_TO_CLOBBER;
+ return 1;
+ default:
+ fprintf(stderr,
+ "I do not understand.\n");
+ }
+ }
+ }
+ else {
+ ok_to_clobber_untracked_files = NEVER_CLOBBER;
+ return 0;
+ }
+ }
+}
+
/*
* We do not want to remove or overwrite a working tree file that
* is not tracked.
@@ -485,7 +525,8 @@ static void verify_absent(const char *pa
{
struct stat st;
- if (index_only || reset || !update)
+ if (index_only || reset || !update ||
+ ok_to_clobber_untracked(path, action))
return;
if (!lstat(path, &st))
die("Untracked working tree file '%s' "
diff --git a/cache.h b/cache.h
index f630cf4..7468440 100644
--- a/cache.h
+++ b/cache.h
@@ -183,6 +183,12 @@ extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
extern int diff_rename_limit_default;
extern int shared_repository;
+enum ok_to_clobber {
+ NEVER_CLOBBER = 0,
+ OK_TO_CLOBBER,
+ ASK_TO_CLOBBER
+};
+extern enum ok_to_clobber ok_to_clobber_untracked_files;
extern const char *apply_default_whitespace;
#define GIT_REPO_VERSION 0
diff --git a/config.c b/config.c
index 984c75f..13f5f4f 100644
--- a/config.c
+++ b/config.c
@@ -251,6 +251,21 @@ int git_config_bool(const char *name, co
return git_config_int(name, value) != 0;
}
+static enum ok_to_clobber git_config_clobber(const char *var, const char *value)
+{
+ if (!strcasecmp(value, "ask"))
+ return ASK_TO_CLOBBER;
+ if (!strcasecmp(value, "yes"))
+ return OK_TO_CLOBBER;
+ if (!strcasecmp(value, "ok"))
+ return NEVER_CLOBBER;
+ if (!strcasecmp(value, "no"))
+ return NEVER_CLOBBER;
+ if (git_config_bool(var, value))
+ return OK_TO_CLOBBER;
+ return NEVER_CLOBBER;
+}
+
int git_default_config(const char *var, const char *value)
{
/* This needs a better name */
@@ -279,6 +294,11 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.oktoclobber")) {
+ ok_to_clobber_untracked_files = git_config_clobber(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "user.name")) {
safe_strncpy(git_default_name, value, sizeof(git_default_name));
return 0;
diff --git a/environment.c b/environment.c
index 2e79eab..c388b5b 100644
--- a/environment.c
+++ b/environment.c
@@ -19,6 +19,7 @@ int warn_ambiguous_refs = 1;
int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
int shared_repository = 0;
+extern enum ok_to_clobber ok_to_clobber_untracked_files = NEVER_CLOBBER;
const char *apply_default_whitespace = NULL;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
^ permalink raw reply related
* Re: [PATCH] Make t8001-annotate and t8002-blame more portable
From: Junio C Hamano @ 2006-06-18 22:21 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060618220654.G4a2f724@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
>> It would have been more obvious if it were written like this:
>>
>> $_ = "" if ($. == 1);
>>
>> but probably it is just me.
>
> I have no strong preference...
Nah, don't worry -- I've already applied your version to my
tree.
^ permalink raw reply
* Re: [PATCH] Make t8001-annotate and t8002-blame more portable
From: Dennis Stosberg @ 2006-06-18 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3be218ri.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> > + 'perl -pi -e "s/^1A.*\n$//; s/^3A/99/" file &&
> > GIT_AUTHOR_NAME="D" git commit -a -m "edit"'
>
> The first line in the original is removed while the perl version
> seems to just makes it empty -- ah, you remove the trailing LF
> as well there. I've never seen this done like this, but OK.
>
> It would have been more obvious if it were written like this:
>
> $_ = "" if ($. == 1);
>
> but probably it is just me.
I have no strong preference. Sometimes I find all those magic perl
variables like $. $| $, $" and so on hard to distinguish without
looking in the manual...
Regards,
Dennis
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Martin Langhoff @ 2006-06-18 21:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606181223580.5498@g5.osdl.org>
On 6/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Or is it just me?
No problems here with my latest import run. fsck-objects --full comes
clean, takes 14m:
/usr/bin/time git-fsck-objects --full
737.22user 38.79system 14:09.40elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (20807major+19483471minor)pagefaults 0swaps
BTW, that import (with the latest code Junio has) took 37hs even with
the aggressive repack -a -d. I want to bench it dropping the -a from
the recurrring repack, and doing a final repack -a -d.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 1/7] Remove ranges from switch statements.
From: Timo Hirvonen @ 2006-06-18 21:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveqyyxyj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Sorry for bringing up an old topic again, but wouldn't people
> agree that this is easier to read if it were written this way ;-)?
>
> if ( (('A' <= ch) && (ch <= 'Z'))
> || (('a' <= ch) && (ch <= 'z'))
> || (('0' <= ch) && (ch <= '9'))
> ...
Yes, but isalnum(ch) even better ;)
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH 1/7] Remove ranges from switch statements.
From: Junio C Hamano @ 2006-06-18 21:07 UTC (permalink / raw)
To: git
In-Reply-To: <1150643889264-git-send-email-octo@verplant.org>
Florian Forster <octo@verplant.org> writes:
> - switch (ch) {
> - case '/': case '-': case '.':
> - case 'A'...'Z': case 'a'...'z': case '0'...'9':
> + if (((ch >= 'A') && (ch <= 'Z'))
> + || ((ch >= 'a') && (ch <= 'z'))
> + || ((ch >= '0') && (ch <= '9'))
> + ...
Sorry for bringing up an old topic again, but wouldn't people
agree that this is easier to read if it were written this way ;-)?
if ( (('A' <= ch) && (ch <= 'Z'))
|| (('a' <= ch) && (ch <= 'z'))
|| (('0' <= ch) && (ch <= '9'))
...
^ permalink raw reply
* Re: [PATCH] Make t8001-annotate and t8002-blame more portable
From: Junio C Hamano @ 2006-06-18 20:58 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060618203321.G2e8b0080@leonov.stosberg.net>
Dennis Stosberg <dennis@stosberg.net> writes:
> These two tests assume that "sed" will not modify the final line of a
> stream if it does not end with a newline character. The assumption is
> not true at least for FreeBSD and Solaris 9. FreeBSD's "sed" appends
> a newline character; "sed" in Solaris 9 even removes the incomplete
> final line.
Gaaah.
> - 'mv file file1 &&
> - sed -e 1d -e "5s/3A/99/" file1 >file &&
> - rm -f file1 &&
> + 'perl -pi -e "s/^1A.*\n$//; s/^3A/99/" file &&
> GIT_AUTHOR_NAME="D" git commit -a -m "edit"'
The first line in the original is removed while the perl version
seems to just makes it empty -- ah, you remove the trailing LF
as well there. I've never seen this done like this, but OK.
It would have been more obvious if it were written like this:
$_ = "" if ($. == 1);
but probably it is just me.
Thanks for the patch.
^ permalink raw reply
* [PATCH] Make t8001-annotate and t8002-blame more portable
From: Dennis Stosberg @ 2006-06-18 20:33 UTC (permalink / raw)
To: git
These two tests assume that "sed" will not modify the final line of a
stream if it does not end with a newline character. The assumption is
not true at least for FreeBSD and Solaris 9. FreeBSD's "sed" appends
a newline character; "sed" in Solaris 9 even removes the incomplete
final line. This patch makes the test use perl instead.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
t/annotate-tests.sh | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
index 114938c..71d0f30 100644
--- a/t/annotate-tests.sh
+++ b/t/annotate-tests.sh
@@ -111,9 +111,7 @@ test_expect_success \
test_expect_success \
'some edit' \
- 'mv file file1 &&
- sed -e 1d -e "5s/3A/99/" file1 >file &&
- rm -f file1 &&
+ 'perl -pi -e "s/^1A.*\n$//; s/^3A/99/" file &&
GIT_AUTHOR_NAME="D" git commit -a -m "edit"'
test_expect_success \
--
1.4.0
^ permalink raw reply related
* Re: git 1.4.0 usability problem
From: Junio C Hamano @ 2006-06-18 19:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <449557B6.1080907@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> Now that kernel 2.6.17 is out, I updated all my repositories to be
> based against that kernel. And for each repository I updated, my
> merge was rejected, due to an error similar to:
>
>> fatal: Untracked working tree file '.gitignore' would be overwritten by merge.
>
> I am only able to merge if I delete files in the working directory, so
> that git stops complaining on merge.
>
> This behavior is new with git 1.4.0, which Fedora Extras just added.
> I verified that merges work as expected in git 1.3.3, the last version
> Fedora Extras shipped prior to 1.4.0.
>
> This behavior is a definite regression, that impacts workflow :(
>
> Here is how to reproduce:
>
> git clone -l $url/torvalds/linux-2.6.git tmp-2.6
> cd tmp-2.6
> cp .git/refs/tags/v2.6.12 .git/refs/heads/tmp
> git checkout -f tmp
> git pull . master
I was not happy with this change myself when I saw the extent of
damage it caused to the existing testsuite that was loosely
written (fcc387db9bc453dc7e07a262873481af2ee9e5c8 introduced
this change, and the needed changes to the testsuite can be seen
in the same commit).
This was done in response to this problem report:
From: Santi <sbejar@gmail.com>
Subject: Merge with local conflicts in new files
Date: Wed, 17 May 2006 00:00:10 +0200
Message-ID: <8aa486160605161500m1dd8428cj@mail.gmail.com>
Hi *,
In the case of:
- You merge from a branch with new files
- You have these files in the working directory
- You do not have these files in the HEAD.
The end result is that you lose the content of these files.
It is an improvement not to lose untracked files, and this is
consistent with how "read-tree -m -u" tries to protect your
changes to tracked files. When moving around in the history of
the same project without using "git checkout" (sans -f),
however, it is bound to cause the above trouble whenever your
version switching involves created/deleted files.
I am open to suggestions to make this check easily overridable.
I suspect it should be sufficient to disable verify_absent()
check in builtin-read-tree.c when the user tells us to do so,
but the issue is how. I can think of a few ways:
(1) define an environment variable, return from verify_absent()
without checking when that variable is set, and have the
user run
$ GIT_UNTRACKED_CLOBBER_OK=t git pull
when clobbering is desired.
(2) In addition to the above, modify Porcelainish commands such
as checkout, pull, and merge to set the environment variable
when --clobber-ok flag is given to them.
(3) define a new flag --clobber-ok to git-read-tree, pass it
around from Porcelainish commands that would eventually
call "read-tree -m -u".
I suspect the last one would be quite intrusive. Independent of
the above, we could have a configuration item "core.clobberok = true"
to always disable the check for the repository.
It might be better to give the user a way to recover from the
situation while keeping things still safer than before by not
giving the above "clobber-ok" flag. For example, "read-tree -m
-u" currently dies on the first "refraining from clobbering
untracked file" message, but there is not an obvious way to list
all untracked files that will be clobbered by the operation so
that you can make sure they are something you do not care about
and remove them yourself before retrying.
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-18 19:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Martin Langhoff, Jon Smirl, git
In-Reply-To: <Pine.LNX.4.64.0606111747110.2703@localhost.localdomain>
On Sun, 11 Jun 2006, Nicolas Pitre wrote:
>
> Then I used git-repack -a -f --window=20 --depth=20 which produced a
> nice 468MB pack file along with the invariant 45MB index file for a
> grand total of 535MB for the whole repo (the .git/refs/ directory alone
> still occupies 17MB on disk).
Btw, can others with that mozilla repo confirm that a mozilla repository
that has been repacked seems to be entirely fine, but git-fsck-objects
(with "--full", of course) will report
error: Packfile .git/objects/pack/pack-06389c21fc3c4312cbc9a4ddde087c907c1a840b.pack SHA1 mismatch with itself
for me (the fsck then completes with no other errors what-so-ever, so the
contents are actually fine).
Or is it just me?
Linus
^ permalink raw reply
* Re: Remove "refs" field from "struct object"
From: Linus Torvalds @ 2006-06-18 18:57 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606181137380.5498@g5.osdl.org>
On Sun, 18 Jun 2006, Linus Torvalds wrote:
>
> The "refs" field, which is really needed only for fsck, is maintained in
> a separate hashed lookup-table, allowing all normal users to totally
> ignore it.
Btw, in case people wondered: the cost to git-fsck-objects seems to be
zero and sometimes apparently even negative.
In order to remove "refs" from "struct object", I had to add it to the
object_refs structure instead, and so you'd think that the memory usage
for git-fsck-objects (which needs the object refs) should be unchanged,
while the hashed lookup should be more expensive than just the direct
pointer lookup.
Actually testing it, though, implies that isn't the case. Lots of objects
(every single blob object, in fact) have no refs at all, and for that case
we don't create any "object_refs" structure at all, so we don't actually
end up with a 1:1 relationship, and we win a small amount of memory.
And the hashing seems to be effective enough that it's no costlier than
looking up the ref pointer directly from the object. There's probably
some bad cache behaviour from the hashing, but it didn't show up in the
benchmarking I did (ie fsck took as long before as it did afterwards,
both for git and for the kernel archive).
It may be (probably is) that the reachability analysis is just a very
small portion of the overall costs, and it's just not very noticeable. It
may also be that whatever bad cache behaviours you get from the extra hash
lookup are just balanced out by the objects themselves being slightly
denser and better in the cache (although that is probably partly hidden
again by the extra malloc padding).
Regardless, there doesn't really seem to be any downsides, but I didn't
test it _that_ exhaustively.
Linus
^ permalink raw reply
* Remove "refs" field from "struct object"
From: Linus Torvalds @ 2006-06-18 18:45 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This shrinks "struct object" to the absolutely minimal size possible.
It now contains /only/ the object flags and the SHA1 hash name of the
object.
The "refs" field, which is really needed only for fsck, is maintained in
a separate hashed lookup-table, allowing all normal users to totally
ignore it.
This helps memory usage, although not as much as I hoped: it looks like
the allocation overhead of malloc (and the alignment constraints in
particular) means that while the structure size shrinks, the actual
allocation overhead mostly does not.
[ That said: memory usage is actually down, but not as much as it should
be: I suspect just one of the object types actually ended up shrinking
its effective allocation size.
To get to the next level, we probably need specialized allocators that
don't pad the allocation more than necessary. ]
The separation makes for some code cleanup, though, and makes the ref
tracking that fsck wants a clearly separate thing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
It turns out that removing the refs member wasn't as hard as I
anticipated: the refs usage by git-fsck-objects was very well defined, and
the actual patch to do this all is mostly the addition of the hashed
lookup and insertion (same logic as for the objects themselves), and some
very small cosmetic changes to anything that set/read the object->refs
field.
Half of the patch is moving the refs-related code to a file of its own.
I'd like to clean up some things later (make the object re-hashing be as
clean and simple as the refs re-hashing is), but wanted to keep this patch
fairly minimal and do just the refs-related changes.
The alignment problem is because the objects actually need just 4-byte
alignment on 32-bit architectures, but "malloc()" will return 8- or
16-byte aligned allocations, so we will have totally unnecessary overhead
there.
This patch will be necessary regardless - the alloction alignment is a
separate issue that just hides much of the shrinkage win.
Makefile | 2 -
fsck-objects.c | 5 +-
object-refs.c | 142 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
object.c | 70 ----------------------------
object.h | 4 +-
5 files changed, 149 insertions(+), 74 deletions(-)
diff --git a/Makefile b/Makefile
index 2a1e639..244a4d1 100644
--- a/Makefile
+++ b/Makefile
@@ -212,7 +212,7 @@ LIB_OBJS = \
blob.o commit.o connect.o csum-file.o cache-tree.o base85.o \
date.o diff-delta.o entry.o exec_cmd.o ident.o lockfile.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
- quote.o read-cache.o refs.o run-command.o dir.o \
+ quote.o read-cache.o refs.o run-command.o dir.o object-refs.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
diff --git a/fsck-objects.c b/fsck-objects.c
index 2b1aab4..769bb2a 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -64,6 +64,7 @@ static void check_connectivity(void)
/* Look up all the requirements, warn about missing objects.. */
for (i = 0; i < obj_allocs; i++) {
+ const struct object_refs *refs;
struct object *obj = objs[i];
if (!obj)
@@ -78,8 +79,8 @@ static void check_connectivity(void)
continue;
}
- if (obj->refs) {
- const struct object_refs *refs = obj->refs;
+ refs = lookup_object_refs(obj);
+ if (refs) {
unsigned j;
for (j = 0; j < refs->count; j++) {
struct object *ref = refs->ref[j];
diff --git a/object-refs.c b/object-refs.c
new file mode 100644
index 0000000..8afa227
--- /dev/null
+++ b/object-refs.c
@@ -0,0 +1,142 @@
+#include "cache.h"
+#include "object.h"
+
+int track_object_refs = 0;
+
+static unsigned int refs_hash_size, nr_object_refs;
+static struct object_refs **refs_hash;
+
+static unsigned int hash_obj(struct object *obj, unsigned int n)
+{
+ unsigned int hash = *(unsigned int *)obj->sha1;
+ return hash % n;
+}
+
+static void grow_refs_hash(void)
+{
+ int i;
+ int new_hash_size = (refs_hash_size + 1000) * 3 / 2;
+ struct object_refs **new_hash;
+
+ new_hash = calloc(new_hash_size, sizeof(struct object_refs *));
+ for (i = 0; i < refs_hash_size; i++) {
+ int j;
+ struct object_refs *ref = refs_hash[i];
+ if (!ref)
+ continue;
+ j = hash_obj(ref->base, new_hash_size);
+ new_hash[j] = ref;
+ }
+ free(refs_hash);
+ refs_hash = new_hash;
+ refs_hash_size = new_hash_size;
+}
+
+static void insert_ref_hash(struct object_refs *ref)
+{
+ int j = hash_obj(ref->base, refs_hash_size);
+
+ while (refs_hash[j]) {
+ j++;
+ if (j >= refs_hash_size)
+ j = 0;
+ }
+ refs_hash[j] = ref;
+}
+
+static void add_object_refs(struct object *obj, struct object_refs *ref)
+{
+ int nr = nr_object_refs + 1;
+
+ if (nr > refs_hash_size * 2 / 3)
+ grow_refs_hash();
+ ref->base = obj;
+ insert_ref_hash(ref);
+ nr_object_refs = nr;
+}
+
+struct object_refs *lookup_object_refs(struct object *obj)
+{
+ int j = hash_obj(obj, refs_hash_size);
+ struct object_refs *ref;
+
+ while ((ref = refs_hash[j]) != NULL) {
+ if (ref->base == obj)
+ break;
+ j++;
+ if (j >= refs_hash_size)
+ j = 0;
+ }
+ return ref;
+}
+
+struct object_refs *alloc_object_refs(unsigned count)
+{
+ struct object_refs *refs;
+ size_t size = sizeof(*refs) + count*sizeof(struct object *);
+
+ refs = xcalloc(1, size);
+ refs->count = count;
+ return refs;
+}
+
+static int compare_object_pointers(const void *a, const void *b)
+{
+ const struct object * const *pa = a;
+ const struct object * const *pb = b;
+ if (*pa == *pb)
+ return 0;
+ else if (*pa < *pb)
+ return -1;
+ else
+ return 1;
+}
+
+void set_object_refs(struct object *obj, struct object_refs *refs)
+{
+ unsigned int i, j;
+
+ /* Do not install empty list of references */
+ if (refs->count < 1) {
+ free(refs);
+ return;
+ }
+
+ /* Sort the list and filter out duplicates */
+ qsort(refs->ref, refs->count, sizeof(refs->ref[0]),
+ compare_object_pointers);
+ for (i = j = 1; i < refs->count; i++) {
+ if (refs->ref[i] != refs->ref[i - 1])
+ refs->ref[j++] = refs->ref[i];
+ }
+ if (j < refs->count) {
+ /* Duplicates were found - reallocate list */
+ size_t size = sizeof(*refs) + j*sizeof(struct object *);
+ refs->count = j;
+ refs = xrealloc(refs, size);
+ }
+
+ for (i = 0; i < refs->count; i++)
+ refs->ref[i]->used = 1;
+ add_object_refs(obj, refs);
+}
+
+void mark_reachable(struct object *obj, unsigned int mask)
+{
+ const struct object_refs *refs;
+
+ if (!track_object_refs)
+ die("cannot do reachability with object refs turned off");
+ /* If we've been here already, don't bother */
+ if (obj->flags & mask)
+ return;
+ obj->flags |= mask;
+ refs = lookup_object_refs(obj);
+ if (refs) {
+ unsigned i;
+ for (i = 0; i < refs->count; i++)
+ mark_reachable(refs->ref[i], mask);
+ }
+}
+
+
diff --git a/object.c b/object.c
index 0f70890..e26e319 100644
--- a/object.c
+++ b/object.c
@@ -13,8 +13,6 @@ const char *type_names[] = {
"none", "blob", "tree", "commit", "bad"
};
-int track_object_refs = 0;
-
static int hashtable_index(const unsigned char *sha1)
{
unsigned int i;
@@ -55,7 +53,6 @@ void created_object(const unsigned char
obj->parsed = 0;
memcpy(obj->sha1, sha1, 20);
obj->type = TYPE_NONE;
- obj->refs = NULL;
obj->used = 0;
if (obj_allocs - 1 <= nr_objs * 2) {
@@ -84,73 +81,6 @@ void created_object(const unsigned char
nr_objs++;
}
-struct object_refs *alloc_object_refs(unsigned count)
-{
- struct object_refs *refs;
- size_t size = sizeof(*refs) + count*sizeof(struct object *);
-
- refs = xcalloc(1, size);
- refs->count = count;
- return refs;
-}
-
-static int compare_object_pointers(const void *a, const void *b)
-{
- const struct object * const *pa = a;
- const struct object * const *pb = b;
- if (*pa == *pb)
- return 0;
- else if (*pa < *pb)
- return -1;
- else
- return 1;
-}
-
-void set_object_refs(struct object *obj, struct object_refs *refs)
-{
- unsigned int i, j;
-
- /* Do not install empty list of references */
- if (refs->count < 1) {
- free(refs);
- return;
- }
-
- /* Sort the list and filter out duplicates */
- qsort(refs->ref, refs->count, sizeof(refs->ref[0]),
- compare_object_pointers);
- for (i = j = 1; i < refs->count; i++) {
- if (refs->ref[i] != refs->ref[i - 1])
- refs->ref[j++] = refs->ref[i];
- }
- if (j < refs->count) {
- /* Duplicates were found - reallocate list */
- size_t size = sizeof(*refs) + j*sizeof(struct object *);
- refs->count = j;
- refs = xrealloc(refs, size);
- }
-
- for (i = 0; i < refs->count; i++)
- refs->ref[i]->used = 1;
- obj->refs = refs;
-}
-
-void mark_reachable(struct object *obj, unsigned int mask)
-{
- if (!track_object_refs)
- die("cannot do reachability with object refs turned off");
- /* If we've been here already, don't bother */
- if (obj->flags & mask)
- return;
- obj->flags |= mask;
- if (obj->refs) {
- const struct object_refs *refs = obj->refs;
- unsigned i;
- for (i = 0; i < refs->count; i++)
- mark_reachable(refs->ref[i], mask);
- }
-}
-
struct object *lookup_object_type(const unsigned char *sha1, const char *type)
{
if (!type) {
diff --git a/object.h b/object.h
index f4ee2e5..c537b4b 100644
--- a/object.h
+++ b/object.h
@@ -9,6 +9,7 @@ struct object_list {
struct object_refs {
unsigned count;
+ struct object *base;
struct object *ref[FLEX_ARRAY]; /* more */
};
@@ -28,7 +29,6 @@ struct object {
unsigned type : TYPE_BITS;
unsigned flags : FLAG_BITS;
unsigned char sha1[20];
- struct object_refs *refs;
};
extern int track_object_refs;
@@ -41,6 +41,8 @@ static inline const char *typename(unsig
return type_names[type > TYPE_TAG ? TYPE_BAD : type];
}
+extern struct object_refs *lookup_object_refs(struct object *);
+
/** Internal only **/
struct object *lookup_object(const unsigned char *sha1);
^ permalink raw reply related
* Re: What's in git.git
From: Johannes Schindelin @ 2006-06-18 18:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060618130837.GN2609@pasky.or.cz>
Hi,
On Sun, 18 Jun 2006, Petr Baudis wrote:
> Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > There is one thing I don't like about Pasky's approach: You can change the
> > config file name to whatever you like, even if no program will read it.
> > That is why I decided to have a flag instead of an option: to prevent
> > pilot-errors.
>
> I'm lost here, admittelly not getting your argument. :-(
Okay, the point I was driving at:
GIT_CONFIG_FILE=~/.gitrc git repo-config blabla.blibli bloblo
_will_ succeed, but to the user it will be non-obvious that the git
commands do not pick up on it (because ~/.gitconfig is read instead of
~/.gitrc), whereas
git repo-config --user blabla.blibli bloblo
is pretty obvious, and _has_ the intended effect.
> > I cobbled together a patch, which turned out to be rather messy,
> > introducing "--config-file <file>" to git-repo-config. If people are
> > interested, I'll clean it up and post it. But then, if you already know
> > you want to use another config file, you are probably better of just
> > exporting GIT_CONFIG_FILE and be done with it.
>
> $GIT_CONFIG_FILE feels nicer since any other git tool can use it as
> well, it's not git-repo-config-specific. But the current intent indeed
> is to simply override the location for git-repo-config, thus for the
> current purposes if we will have --config-file instead of
> GIT_CONFIG_FILE, I will not weep; whatever does the job.
Yes, that is true. Forget about my --config-file patch, please.
> > Note that this issue is orthogonal to the need for a user-specific config
> > file. I still think that this one should go in.
>
> I agree as well.
Ciao,
Dscho
^ permalink raw reply
* Re: Is there such a thing as a git:// proxy?
From: Linus Torvalds @ 2006-06-18 17:02 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060618124250.15471.qmail@science.horizon.com>
On Sun, 18 Jun 2006, linux@horizon.com wrote:
>
> Has anyone put together something that can automatically check
> upstream for updates when someone fetches from it?
Well, there's actually a much easier solution: just add a "pre-pull" hook
to "git-send-objects", and then have that hook check the real remote.
Does anybody see any problems with that?
Linus
^ permalink raw reply
* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Linus Torvalds @ 2006-06-18 16:50 UTC (permalink / raw)
To: Florian Forster; +Cc: git
In-Reply-To: <1150609831500-git-send-email-octo@verplant.org>
On Sun, 18 Jun 2006, Florian Forster wrote:
>
> Using this patch I was able to build git with
> $ make CFLAGS="-Wall -Werror -ansi -pedantic -std=c99 -D_XOPEN_SOURCE=500 -D_BSD_SOURCE"
"-ansi -pedantic" is really not useful.
> While most of this patch fixes void-pointer arithmetic
This one I disagree with. Doing arithmetic on "void *" is _really_ useful,
and I think most compilers end up supporting it either to be compatible
with gcc, or just because it's hard to not do it.
It makes code a _lot_ cleaner.
In general, explicit casts are a sign of bad programming, and "void *" is
there exactly to avoid it. And doing arithmetic on pointers is useful and
fairly common, and if you accept void-pointer arithmetic, it avoids a lot
of ugly and useless casts.
> @@ -301,9 +301,9 @@ static void fill_line_map(struct commit
> if (DEBUG)
> printf("map: i1: %d %d %p i2: %d %d %p\n",
> i1, map[i1],
> - i1 != -1 ? blame_lines[map[i1]] : NULL,
> + (void *) (i1 != -1 ? blame_lines[map[i1]] : NULL),
> i2, map2[i2],
> - i2 != -1 ? blame_lines[map2[i2]] : NULL);
> + (void *) (i2 != -1 ? blame_lines[map2[i2]] : NULL));
Gaah. This is another case of casting that I'm sure is technically
correct, but that I wonder whether there is any machine that actually
cares..
But at least in that case I suspect the cast _may_ be required due to
different pointer representations.
Linus
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Ryan Anderson @ 2006-06-18 16:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <449557B6.1080907@garzik.org>
On Sun, Jun 18, 2006 at 09:40:06AM -0400, Jeff Garzik wrote:
> Now that kernel 2.6.17 is out, I updated all my repositories to be based
> against that kernel. And for each repository I updated, my merge was
> rejected, due to an error similar to:
>
> >fatal: Untracked working tree file '.gitignore' would be overwritten by
> >merge.
>
> I am only able to merge if I delete files in the working directory, so
> that git stops complaining on merge.
>
> This behavior is new with git 1.4.0, which Fedora Extras just added. I
> verified that merges work as expected in git 1.3.3, the last version
> Fedora Extras shipped prior to 1.4.0.
>
> This behavior is a definite regression, that impacts workflow :(
>
> Here is how to reproduce:
>
> git clone -l $url/torvalds/linux-2.6.git tmp-2.6
At this point you have master checked out, and recorded properly in the
index.
> cd tmp-2.6
> cp .git/refs/tags/v2.6.12 .git/refs/heads/tmp
> git checkout -f tmp
Here, you throw that index away, ignore the contents of the working
tree, and checkout tmp.
> git pull . master
> # watch OBVIOUS FAST-FORWARD MERGE complain about untracked
> # working tree files
At this point, you have a working tree containing files leftover from
the checkout of master, but which are totally unknown to the 2.6.12
tree, and so are untracked. The fast-forward is trying hard not to
overwrite things it shouldn't be messing with, and so complains.
The fix is to drop the "-f" from git checkout, and things should work
correctly. ("-f" should really not be a normal thing to use. For
switching branches, "git checkout" should be sufficient, and should
result ina working tree that doesn't contain nearly as many potential
conflict sources.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH 3/7] Don't instantiate structures with FAMs.
From: Florian Forster @ 2006-06-18 15:18 UTC (permalink / raw)
To: git; +Cc: Florian Forster
In-Reply-To: <11506438893796-git-send-email-octo@verplant.org>
Since structures with `flexible array members' are an incomplete datatype ANSI
C99 forbids creating instances of them. This patch removes such an instance
from `diff-lib.c' and replaces it with a pointer to a `struct
combine_diff_path'. Since all neccessary memory is allocated at once the number
of calls to `xmalloc' is not increased.
Signed-off-by: Florian Forster <octo@verplant.org>
---
diff-lib.c | 41 ++++++++++++++++++++++-------------------
1 files changed, 22 insertions(+), 19 deletions(-)
c163a36f0bd0e07ffb9ee7d4bfb22f1cbb38eef8
diff --git a/diff-lib.c b/diff-lib.c
index 2183b41..fdc1173 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -34,21 +34,23 @@ int run_diff_files(struct rev_info *revs
continue;
if (ce_stage(ce)) {
- struct {
- struct combine_diff_path p;
- struct combine_diff_parent filler[5];
- } combine;
+ struct combine_diff_path *dpath;
int num_compare_stages = 0;
+ size_t path_len;
- combine.p.next = NULL;
- combine.p.len = ce_namelen(ce);
- combine.p.path = xmalloc(combine.p.len + 1);
- memcpy(combine.p.path, ce->name, combine.p.len);
- combine.p.path[combine.p.len] = 0;
- combine.p.mode = 0;
- memset(combine.p.sha1, 0, 20);
- memset(&combine.p.parent[0], 0,
- sizeof(combine.filler));
+ path_len = ce_namelen(ce);
+
+ dpath = xmalloc (combine_diff_path_size (5, path_len));
+ dpath->path = (char *) &(dpath->parent[5]);
+
+ dpath->next = NULL;
+ dpath->len = path_len;
+ memcpy(dpath->path, ce->name, path_len);
+ dpath->path[path_len] = '\0';
+ dpath->mode = 0;
+ memset(dpath->sha1, 0, 20);
+ memset(&(dpath->parent[0]), 0,
+ sizeof(struct combine_diff_parent)*5);
while (i < entries) {
struct cache_entry *nce = active_cache[i];
@@ -64,11 +66,11 @@ int run_diff_files(struct rev_info *revs
if (2 <= stage) {
int mode = ntohl(nce->ce_mode);
num_compare_stages++;
- memcpy(combine.p.parent[stage-2].sha1,
+ memcpy(dpath->parent[stage-2].sha1,
nce->sha1, 20);
- combine.p.parent[stage-2].mode =
+ dpath->parent[stage-2].mode =
canon_mode(mode);
- combine.p.parent[stage-2].status =
+ dpath->parent[stage-2].status =
DIFF_STATUS_MODIFIED;
}
@@ -83,13 +85,14 @@ int run_diff_files(struct rev_info *revs
i--;
if (revs->combine_merges && num_compare_stages == 2) {
- show_combined_diff(&combine.p, 2,
+ show_combined_diff(dpath, 2,
revs->dense_combined_merges,
revs);
- free(combine.p.path);
+ free(dpath);
continue;
}
- free(combine.p.path);
+ free(dpath);
+ dpath = NULL;
/*
* Show the diff for the 'ce' if we found the one
--
1.3.3
^ permalink raw reply related
* [PATCH 6/7] Change types used in bitfields to be `int's.
From: Florian Forster @ 2006-06-18 15:18 UTC (permalink / raw)
To: git; +Cc: Florian Forster
In-Reply-To: <11506438893544-git-send-email-octo@verplant.org>
According to ANSI C99 bitfields are only defined for `signed int' and `unsigned
int'. This patch corrects the bitfield in the `msg_data_t' type from
`imap-send.c'.
Signed-off-by: Florian Forster <octo@verplant.org>
---
imap-send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
471838c5e32b83bc8b84584343daeb1174d0e968
diff --git a/imap-send.c b/imap-send.c
index 285ad29..94e39cd 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -93,7 +93,7 @@ typedef struct {
char *data;
int len;
unsigned char flags;
- unsigned char crlf:1;
+ unsigned int crlf:1;
} msg_data_t;
#define DRV_OK 0
--
1.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox