* 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
* Re: [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too
From: Johannes Schindelin @ 2007-11-16 0:43 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: gitster, git
In-Reply-To: <1195146094.21076.6.camel@hinata.boston.redhat.com>
Hi,
On Thu, 15 Nov 2007, Kristian H?gsberg wrote:
> On Thu, 2007-11-15 at 16:11 +0000, Johannes Schindelin wrote:
> > Earlier, builtin commit would implicitly commit also the staged
> > changes.
> >
> > This patch fixes that.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > The function reset_index_to_head() could be moved to somewhere
> > more central and be reused in builtin-reset.c instead of
> > reset_index_file() later...
> >
> > builtin-add.c | 1 +
> > builtin-commit.c | 30 +++++++++++++++++++++++++++++-
> > t/t7500-commit.sh | 10 ++++++++++
> > 3 files changed, 40 insertions(+), 1 deletions(-)
> >
> > diff --git a/builtin-add.c b/builtin-add.c
> > index 77dcde6..017c8f2 100644
> > --- a/builtin-add.c
> > +++ b/builtin-add.c
> > @@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,
> > case DIFF_STATUS_UNMERGED:
> > case DIFF_STATUS_MODIFIED:
> > case DIFF_STATUS_TYPE_CHANGED:
> > + case DIFF_STATUS_ADDED:
> > add_file_to_cache(path, verbose);
> > break;
> > case DIFF_STATUS_DELETED:
> > diff --git a/builtin-commit.c b/builtin-commit.c
> > index 535039c..0dc6e1c 100644
> > --- a/builtin-commit.c
> > +++ b/builtin-commit.c
> > @@ -19,6 +19,7 @@
> > #include "strbuf.h"
> > #include "utf8.h"
> > #include "parse-options.h"
> > +#include "unpack-trees.h"
> >
> > static const char * const builtin_commit_usage[] = {
> > "git-commit [options] [--] <filepattern>...",
> > @@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {
> > OPT_END()
> > };
> >
> > +static int reset_index_to_head(void)
> > +{
> > + struct unpack_trees_options opts;
> > + struct tree_desc tree_desc;
> > + struct tree *tree;
> > + unsigned char sha1[20];
> > +
> > + /* ignore if it is an initial commit */
> > + if (get_sha1("HEAD", sha1))
> > + return 0;
> > + tree = parse_tree_indirect(sha1);
> > + if (!tree || parse_tree(tree))
> > + return error("Could not get HEAD's tree");
> > + init_tree_desc(&tree_desc, tree->buffer, tree->size);
> > +
> > + memset(&opts, 0, sizeof(opts));
> > + opts.index_only = 1;
> > + opts.merge = 1;
> > + opts.head_idx = 1;
> > + opts.fn = oneway_merge;
> > + if (unpack_trees(1, &tree_desc, &opts))
> > + return error("Could not reset temporary index to HEAD");
> > + return 0;
> > +}
> > +
> > static char *prepare_index(const char **files, const char *prefix)
> > {
> > int fd;
> > @@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)
> > die("failed to read HEAD tree object");
> > }
> >
> > + if (reset_index_to_head())
> > + die ("failed to reset temporary index to HEAD");
> > +
>
> If you look just above where you added these lines, there is code to
> deal with this case, except it doesn't work. I was trying to fix this
> too by adding a discard_cache() call before building the temp index, but
> then I couldn't add the files in question because the index was now
> newer than those files. Anyway, I don't know if your code is better
> that just doing read_tree(), but we should only have one or the other in
> there.
It's not only about discarding the cache. It's also about avoiding do
regenerate the index completely; this would waste time, especially for big
trees.
But the code you are referencing is only updating the index. The code I
added is to build the temporary index in a correct manner.
Unfortunately, I guess that the index as calculated by the code you are
referencing would be needed to show the correct status.
Therefore I propose to use a different struct index_state, copied from the
current one, for reset_index_to_head(), add_files_to_index() and
write_index() instead of working on the_index.
But that has to be done by somebody else than me, or wait for Tuesday, as
I will be travelling.
Ciao,
Dscho
^ permalink raw reply
* git-svn fetch failure: index.lock file exists
From: Ollie Wild @ 2007-11-16 0:07 UTC (permalink / raw)
To: git
Hi,
I've been using git-svn for a while now to work on gcc. Last night, I did a
git svn fetch
and got the following failure:
Found possible branch point: svn+ssh://aaw@gcc.gnu.org/svn/gcc/trunk =>
svn+ssh://aaw@gcc.gnu.org/svn/gcc/tags/libbid-last-merge, 128810
Found branch parent: (tags/libbid-last-merge)
789aa951bbc6a49f791bf5109136335fc33222c5
fatal: unable to create
'.git/svn/tags/libbid-last-merge/index.lock': File exists
read-tree 789aa951bbc6a49f791bf5109136335fc33222c5:
command returned error: 128
Naively, it looks to me like I've just got a stale lock file from a
previous run. However, I have no idea what the correct recovery
strategy is. Can I just delete the lock file? Do I need to do some
sort of data validation?
I'm using git version 1.5.2.5 with subversion version 1.4.5 (r25188).
Thanks,
Ollie
^ permalink raw reply
* Re: [PATCH] Fix Solaris compiler warnings
From: Junio C Hamano @ 2007-11-15 23:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Guido Ostkamp, git
In-Reply-To: <20071115230002.GA24069@steel.home>
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.
^ permalink raw reply
* Re: [PATCH] Fix Solaris compiler warnings
From: Alex Riesen @ 2007-11-15 23:00 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711152317140.7416@bianca.dialin.t-online.de>
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
> CC xdiff/xutils.o
> "xdiff/xutils.c", line 236: warning: statement not reached
This one is right. Accidentally, as it seems
^ permalink raw reply
* Re: New repo quickly corrupted
From: Linus Torvalds @ 2007-11-15 22:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jason Sewall, git, Junio C Hamano
In-Reply-To: <alpine.LFD.0.9999.0711151708470.21255@xanadu.home>
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.
Why? Becuase you end up having to create a new file *anyway*. So nobody
does modify-in-place, they literally end up doing
- create temp-file
- while (data)
read old file, write to tempfile
- rename temp-file over oldfile
and unless you *explicitly* look at the permission bits you'll never even
notice that the old file was read-only, because none of the steps above
care at all!
So marking things read-only will give only limited protection. It will
protect against most editors, and will protect against things that change
files in-place and literally try to open the original file as read-write,
but not much else.
Linus
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc.
From: Guido Ostkamp @ 2007-11-15 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Guido Ostkamp, Björn Steinbrink, raa.lkml, git
In-Reply-To: <7v640340kp.fsf@gitster.siamese.dyndns.org>
On Thu, 15 Nov 2007, Junio C Hamano wrote:
> Are there problems with the implementation in compat/ directory, we ship
> specifically to help platforms without mkdtemp()?
The Git version that I used for testing at office did not yet include your
compat fix or did not activate it automatically.
I shall check this out tomorrow and let you know. Sorry, it's already late
here in Germany (23:27h) - I need to get some sleep ;-)
Regards
Guido
^ permalink raw reply
* Re: [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
From: Steffen Prohaska @ 2007-11-15 22:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <200711152243.10229.johannes.sixt@telecom.at>
On Nov 15, 2007, at 10:43 PM, Johannes Sixt wrote:
> On Thursday 15 November 2007 21:10, Steffen Prohaska wrote:
>> On Nov 15, 2007, at 7:31 PM, Johannes Sixt wrote:
>>> On Thursday 15 November 2007 07:53, Steffen Prohaska wrote:
>>>> Now I'm wondering if we could make path relocation a bit more
>>>> explicit. How about doing something like.
>>>>
>>>> system_wide = relocate_path(ETC_GITCONFIG);
>>>>
>>>> and relocate_path(const char *) would expand a format
>>>> string in path. At this point I see only a single %s
>>>> that would be expanded with the install prefix. If
>>>> ETC_GITCONFIG is "%s/etc/gitconfig" relocate path will return
>>>> "C:/msysgit/bin/etc/gitconfig" for my above example. It is
>>>> basically a printf with the install prefix path.
>>>
>>> I don't see the problem that you are trying to solve.
>>
>> Path relocation would be more explicit:
>> 1) Paths that need to be relocated are filtered through
>> relocate_path(). That's easy to understand.
>> 2) All the code prefixing the path is in relocate_path().
>> This avoids code duplication.
>> 3) Path that should be relocated contain "%s" in the Makefile.
>> This indicates that some string expansion may take place.
>>
>> (1) and (2) would be useful even if you do not agree with (3).
>> The code in PATCH 9/11 and PATCH 11/11 looks very similar.
>> If the prefixing code went into a separate function, we'd
>> have less code. Also, relocate_path() could be useful at
>> other places. For example, I'd use it to locate the HTML
>> documentation relative to the installation directory.
>
> How is %s/foo different from ../foo? There are only 2 paths that
> need to be
> relocatable. Your proposal is over-engineering, IMHO.
fair enough. Let's take your patches.
Steffen
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Wincent Colaiuta @ 2007-11-15 22:22 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Git Mailing List
In-Reply-To: <1D7CC3C0-46C1-40D9-AAD5-B9ADFF99B58A@lrde.epita.fr>
El 15/11/2007, a las 22:13, Benoit Sigoure escribió:
> On Nov 15, 2007, at 5:11 PM, 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.
>
> Hi Wincent,
> Can you reproduce this deterministically? If yes, can you re-run
> the test with the --verbose flag and post the gzipped output (or
> send it to me if the list doesn't like this sort of attachment).
Yes, have just sent you the output of "--verbose" and also running the
script using "sh -x" (off list).
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Fix Solaris compiler warnings
From: Guido Ostkamp @ 2007-11-15 22:19 UTC (permalink / raw)
To: git
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
CC xdiff/xutils.o
"xdiff/xutils.c", line 236: warning: statement not reached
Signed-off-by: Guido Ostkamp <git@ostkamp.fastmail.fm>
---
builtin-apply.c | 1 -
utf8.c | 1 -
xdiff/xdiffi.c | 2 --
xdiff/xutils.c | 2 --
4 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 8edcc08..91f8752 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -683,7 +683,6 @@ static char *git_header_name(char *line, int llen)
}
}
}
- return NULL;
}
/* Verify that we recognize the lines following a git header */
diff --git a/utf8.c b/utf8.c
index 8095a71..9efcdb9 100644
--- a/utf8.c
+++ b/utf8.c
@@ -284,7 +284,6 @@ int print_wrapped_text(const char *text, int indent, int indent2, int width)
text++;
}
}
- return w;
}
int is_encoding_utf8(const char *name)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 5cb7171..1bad846 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -257,8 +257,6 @@ static long xdl_split(unsigned long const *ha1, long off1, long lim1,
return ec;
}
}
-
- return -1;
}
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 2ade97b..d7974d1 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -232,8 +232,6 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
return i1 >= s1 && i2 >= s2;
} else
return s1 == s2 && !memcmp(l1, l2, s1);
-
- return 0;
}
static unsigned long xdl_hash_record_with_whitespace(char const **data,
--
1.5.3.5.721.g039b
^ permalink raw reply related
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc.
From: Junio C Hamano @ 2007-11-15 22:15 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: Björn Steinbrink, gitster, raa.lkml, git
In-Reply-To: <Pine.LNX.4.64.0711152253430.4090@bianca.dialin.t-online.de>
Guido Ostkamp <git@ostkamp.fastmail.fm> writes:
> I tested it and the file in question compiled ok for the two versions
> of Sun Forte and Workshop compilers that I have available.
>
> I could also link & run the main git binary after applying my own
> mkdtemp() patch.
Are there problems with the implementation in compat/ directory,
we ship specifically to help platforms without mkdtemp()?
^ permalink raw reply
* Re: Odd .gitignore behaviour
From: Junio C Hamano @ 2007-11-15 22:13 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Linus Torvalds, git, Alex Riesen
In-Reply-To: <7vir4341ok.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Bruce Stephens <bruce.stephens@isode.com> writes:
>
>> So I think the output from git-ls-files is as expected (as I interpret
>> the manpage and your explanation). So is git-add just using some
>> different code?
>
> No, you found one of the longstanding bugs in dir.c:read_directory().
>
> The funny thing is that I just sent out a message pointing out
> bogus handling of per-directory exclude files in ls-files last
> night. Somehow people have a tendency to encounter the bugs in
> the same vicinity independently.
By the way, about the problem I described briefly last night.
I never understood the intended use of -i option to ls-files,
but in your test repository (the one that has subsubdir), you
can do:
$ git ls-files -i --exclude='a*'
to see "What paths have I already _staged_ that would have been
ignored if the exclude pattern were 'a*'". You can abuse this
to list all the staged header files with:
$ git ls-files -i --exclude='*.h'
but
$ git ls-files -- '*.h'
is much simpler for that ;-).
In any case, it appears to me that the codepath used for that
"feature", and also the codepath used for -d (show deleted
files) and -m (show modified files) makes calls to excluded()
function to consult the exclusion mechanism without setting it
up properly, and I do not think
$ git ls-files -i --exclude-per-directory=.gitignore
does what we would want.
The codepath for -o (show others) do use read_directory() which
sets up the exclusion mechanism with push/pop per-directory
exclude API, so that option should work. But I suspect even it
did not work from a subdirectory because of the problem the
message I am responding to addresses.
^ permalink raw reply
* Re: New repo quickly corrupted
From: Nicolas Pitre @ 2007-11-15 22:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jason Sewall, git, Junio C Hamano
In-Reply-To: <alpine.LFD.0.9999.0711151358180.4260@woody.linux-foundation.org>
On Thu, 15 Nov 2007, Linus Torvalds wrote:
>
>
> On Thu, 15 Nov 2007, Jason Sewall wrote:
> >
> > find . -type f -exec dos2unix {} +
>
> Oops.
>
> You just ran "dos2unix" on all the *git* files!
Does "dos2unix" override file access bits? Because the object store is
always made read-only.
Nicolas
^ permalink raw reply
* Re: New repo quickly corrupted
From: Jason Sewall @ 2007-11-15 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LFD.0.9999.0711151358180.4260@woody.linux-foundation.org>
On Nov 15, 2007 5:01 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 15 Nov 2007, Jason Sewall wrote:
> >
> > find . -type f -exec dos2unix {} +
>
> Oops.
>
> You just ran "dos2unix" on all the *git* files!
>
> Which certainly explains why all your old objects got corrupted!
>
> > What's going on?
>
> PEBKAC ;)
Yeah, Junio beat you to it. :)
I take comfort in the fact that others have suffered far worse
consequences from find misuse....
^ permalink raw reply
* Re: New repo quickly corrupted
From: Linus Torvalds @ 2007-11-15 22:01 UTC (permalink / raw)
To: Jason Sewall; +Cc: git, Junio C Hamano
In-Reply-To: <31e9dd080711151350u6c2ae40foc7c05e59496260fa@mail.gmail.com>
On Thu, 15 Nov 2007, Jason Sewall wrote:
>
> find . -type f -exec dos2unix {} +
Oops.
You just ran "dos2unix" on all the *git* files!
Which certainly explains why all your old objects got corrupted!
> What's going on?
PEBKAC ;)
To avoid this error in the future, may I suggest using
git ls-files -z | xargs -0 dos2unix
or similar. Please DO NOT write to the .git/objects directory.
Linus
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc.
From: Guido Ostkamp @ 2007-11-15 22:00 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>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 669 bytes --]
On Thu, 15 Nov 2007, Björn Steinbrink wrote:
> Some versions of SUN's cc have a bug that causes them to complain about
> a redeclared identifier when you use a function declaration that takes a
> struct with a FAM and this struct has only been declared but not yet
> defined.
> [...]
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> ---
> Guido, could you please test this patch?
I tested it and the file in question compiled ok for the two versions of
Sun Forte and Workshop compilers that I have available.
I could also link & run the main git binary after applying my own
mkdtemp() patch.
I hope your patch will get officially included.
Regards
Guido
^ permalink raw reply
* Re: New repo quickly corrupted
From: Jason Sewall @ 2007-11-15 21:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejer41ib.fsf@gitster.siamese.dyndns.org>
On Nov 15, 2007 4:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Jason Sewall" <jasonsewall@gmail.com> writes:
>
> > find . -type f -exec dos2unix {} +
> > git commit -a --amend
> > [accept same message]
> > git fsck
> > [same error message as above]
> >
> > I just built my git today, unmodified:
> > git version 1.5.3.5.721.g039b
> >
> > What's going on?
>
> Carelessness is what is going on.
>
> Notice how nicely your "find . -type f -exec dos2unix {}" goes
> down to .git/objects and eats your loose objects
>
> You probably wanted to do
>
> git ls-files | xargs dos2unix
>
> instead.
>
Sure enough. I'll chalk that one up to too many mind-numbing meetings today.
Thanks for the wake-up...
^ permalink raw reply
* Re: refining .gitignores
From: Linus Torvalds @ 2007-11-15 21:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: Bruce Stephens, git
In-Reply-To: <20071115211727.GC3552@steel.home>
On Thu, 15 Nov 2007, Alex Riesen wrote:
>
> No, I honestly believed that Git-known files can be ignored. According
> to Linus I must be wrong, but I have an excuse:
I do think we're not necessarily entirely consistent wrt ignore files.
In particular, git-ls-files itself actually is pretty special, because it
has two totally different modes:
- you can ask for "other" files (and this is where you'd be expected to
use .gitignore)
- you can just list the files git knows about (and this is where you'd
generally be expected to *not* use .gitignore)
..and to make matters more interesting, "git add" used to do the former
(it was just a thin script around "git-ls-files -o") but then was later
enhanced to also take already-known files into account, so I am not at all
surprised if we actually get confused because we used to have a fairly
clear separation of the two cases but then we started mixing them up.
So while I think that ".gitignore" *should* only affect files that we
don't already know about (ie effectively only file lists that come from
"readdir()", not from internal git data structures), I would not be at all
surprised if there are bugs.
Linus
^ permalink raw reply
* Re: New repo quickly corrupted
From: Junio C Hamano @ 2007-11-15 21:55 UTC (permalink / raw)
To: Jason Sewall; +Cc: git, Junio C Hamano
In-Reply-To: <31e9dd080711151350u6c2ae40foc7c05e59496260fa@mail.gmail.com>
"Jason Sewall" <jasonsewall@gmail.com> writes:
> find . -type f -exec dos2unix {} +
> git commit -a --amend
> [accept same message]
> git fsck
> [same error message as above]
>
> I just built my git today, unmodified:
> git version 1.5.3.5.721.g039b
>
> What's going on?
Carelessness is what is going on.
Notice how nicely your "find . -type f -exec dos2unix {}" goes
down to .git/objects and eats your loose objects
You probably wanted to do
git ls-files | xargs dos2unix
instead.
^ permalink raw reply
* Re: Odd .gitignore behaviour
From: Junio C Hamano @ 2007-11-15 21:51 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Linus Torvalds, git
In-Reply-To: <80ir43e04o.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
> So I think the output from git-ls-files is as expected (as I interpret
> the manpage and your explanation). So is git-add just using some
> different code?
No, you found one of the longstanding bugs in dir.c:read_directory().
The funny thing is that I just sent out a message pointing out
bogus handling of per-directory exclude files in ls-files last
night. Somehow people have a tendency to encounter the bugs in
the same vicinity independently.
The initial loop in read_directory() to push per-directory
exclusion elements into the stack for directories above the
given base forgets that push() does not make a copy of the path
given as its parameter but stores the pointer to it instead, so
multiple calls to push() need to use separate path buffers.
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. They
were designed to be called from the recursive directory
walking, and the path buffers are placed on the function call
stack to be reclaimed automatically upon function return;
---
dir.c | 55 ++++++++++++++++++++++++++++++++++---------------------
1 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/dir.c b/dir.c
index fa9f902..d32f437 100644
--- a/dir.c
+++ b/dir.c
@@ -651,38 +651,51 @@ static void free_simplify(struct path_simplify *simplify)
free(simplify);
}
+static int push_excludes(struct dir_struct *dir, const char *base, int len)
+{
+ /*
+ * base is like "a/b/c/" -- cause .gitignore, b/.gitignore and
+ * b/c/.gitignore to be read in this order, as if we recursed
+ * into it.
+ */
+ int stk = -1;
+ int partlen = 0;
+
+ if (!(dir->exclude_per_dir && len))
+ return stk;
+
+ while (1) {
+ char *part = xmalloc(partlen + 1);
+ memcpy(part, base, partlen);
+ part[partlen] = '\0';
+ stk = push_exclude_per_directory(dir, part, partlen);
+
+ if (len <= partlen++)
+ break;
+
+ while (partlen < len && base[partlen] != '/')
+ partlen++;
+ partlen++; /* point at one past the found '/' */
+ }
+ return stk;
+}
+
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);
+ int stk;
/*
* Make sure to do the per-directory exclude for all the
* directories leading up to our base.
*/
- if (baselen) {
- if (dir->exclude_per_dir) {
- char *p, *pp = xmalloc(baselen+1);
- memcpy(pp, base, baselen+1);
- p = pp;
- while (1) {
- char save = *p;
- *p = 0;
- push_exclude_per_directory(dir, pp, p-pp);
- *p++ = save;
- if (!save)
- break;
- p = strchr(p, '/');
- if (p)
- p++;
- else
- p = pp + baselen;
- }
- free(pp);
- }
- }
+ stk = push_excludes(dir, base, baselen);
read_directory_recursive(dir, path, base, baselen, 0, simplify);
free_simplify(simplify);
+ if (0 <= stk)
+ pop_exclude_per_directory(dir, stk);
+
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;
^ permalink raw reply related
* New repo quickly corrupted
From: Jason Sewall @ 2007-11-15 21:50 UTC (permalink / raw)
To: git, Junio C Hamano
I was working on a new repo created from a tar snapshot of an old
project, and after about a half-hour and about 5 commits for hacking,
I had fixed the problem I set out to take care of.
However, I tried to run git gc to clean it up and put it away and I
was met with the following:
[sewall@hobo SWIFT++_1.2 (master)]$ git gc
Counting objects: 227, done.
error: corrupt loose object '680aba836639d14a36b81f9e29da52bd9af69770'
fatal: object 680aba836639d14a36b81f9e29da52bd9af69770 cannot be read
error: failed to run repack
I've followed discussions on the list about corrupted repos and did
[sewall@hobo SWIFT++_1.2 (master)]$ git fsck
error: corrupt loose object '24bbb41919ef906db6f40c3c80f246b7e0cdf9f4'
error: 24bbb41919ef906db6f40c3c80f246b7e0cdf9f4: object corrupt or missing
error: corrupt loose object '680aba836639d14a36b81f9e29da52bd9af69770'
error: 680aba836639d14a36b81f9e29da52bd9af69770: object corrupt or missing
error: 8de8382bdc3cc5f936670df414b33ee63927f3a4: object corrupt or missing
error: corrupt loose object 'd186d23e87ddf344acc56f48e3cf2f61c7a47e16'
error: d186d23e87ddf344acc56f48e3cf2f61c7a47e16: object corrupt or missing
missing blob 680aba836639d14a36b81f9e29da52bd9af69770
missing blob 8de8382bdc3cc5f936670df414b33ee63927f3a4
missing blob d186d23e87ddf344acc56f48e3cf2f61c7a47e16
missing blob 24bbb41919ef906db6f40c3c80f246b7e0cdf9f4
And since these were all blobs, I looked for em with git-log:
[sewall@hobo SWIFT++_1.2 (master)]$ git log --raw --all | grep 24bbb*
[sewall@hobo SWIFT++_1.2 (master)]$ git log --raw --all | grep d186*
[sewall@hobo SWIFT++_1.2 (master)]$ git log --raw --all | grep 8de83*
[sewall@hobo SWIFT++_1.2 (master)]$ git log --raw --all | grep 680ab*
So it would assume that these are dangling objects. Given the simple
history of the repo, the only think I can think of that could have
caused it would be that my first commit was of the original files, and
I immediately remembered that I wanted to run dos2unix on the files so
I did and did a commit -a --amend.
I untarred the original snapshot again and ran git-hash-object over
all the files, and sure enough each of those missing hashes
corresponds to a blob in the original (non-dos2unix'd) file.
I copied the corrupted repo, manually deleted those objects, then
hash-object -w the appropriate originals back in. git-fsck was
mollified.
Finally, I tried repeating the process and the same error occurs.
In summary:
unzip original.zip
git init
git add .
git commit -m "Initial commit"
find . -type f -exec dos2unix {} +
git commit -a --amend
[accept same message]
git fsck
[same error message as above]
I just built my git today, unmodified:
git version 1.5.3.5.721.g039b
What's going on?
Jason
P.S. These files aren't particularly secret, so I'm happy to post them
if need be. Its actually someone else's code (a fellow student who
graduated some time before I arrived in grad school); I was asked to
modernize it enough to compile on on the latest gcc.
^ permalink raw reply
* Re: [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
From: Johannes Sixt @ 2007-11-15 21:43 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Junio C Hamano
In-Reply-To: <E652EC54-9F94-444F-AF94-2FA990355A78@zib.de>
On Thursday 15 November 2007 21:10, Steffen Prohaska wrote:
> On Nov 15, 2007, at 7:31 PM, Johannes Sixt wrote:
> > On Thursday 15 November 2007 07:53, Steffen Prohaska wrote:
> >> Now I'm wondering if we could make path relocation a bit more
> >> explicit. How about doing something like.
> >>
> >> system_wide = relocate_path(ETC_GITCONFIG);
> >>
> >> and relocate_path(const char *) would expand a format
> >> string in path. At this point I see only a single %s
> >> that would be expanded with the install prefix. If
> >> ETC_GITCONFIG is "%s/etc/gitconfig" relocate path will return
> >> "C:/msysgit/bin/etc/gitconfig" for my above example. It is
> >> basically a printf with the install prefix path.
> >
> > I don't see the problem that you are trying to solve.
>
> Path relocation would be more explicit:
> 1) Paths that need to be relocated are filtered through
> relocate_path(). That's easy to understand.
> 2) All the code prefixing the path is in relocate_path().
> This avoids code duplication.
> 3) Path that should be relocated contain "%s" in the Makefile.
> This indicates that some string expansion may take place.
>
> (1) and (2) would be useful even if you do not agree with (3).
> The code in PATCH 9/11 and PATCH 11/11 looks very similar.
> If the prefixing code went into a separate function, we'd
> have less code. Also, relocate_path() could be useful at
> other places. For example, I'd use it to locate the HTML
> documentation relative to the installation directory.
How is %s/foo different from ../foo? There are only 2 paths that need to be
relocatable. Your proposal is over-engineering, IMHO.
-- Hannes
^ permalink raw reply
* Re: refining .gitignores
From: Alex Riesen @ 2007-11-15 21:17 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git, Linus Torvalds
In-Reply-To: <80ejerdzjd.fsf@tiny.isode.net>
Bruce Stephens, Thu, Nov 15, 2007 21:28:06 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> [...]
>
> > .gitignore? Without "s"?
>
> Yes, my mistake. I added '*.c' to ".gitignore".
>
> > Maybe your .c files are already added to index? Otherwise you have to
> > use the second form. It shows known-to-Git ignored files.
>
> They are in the index. What I want is a list of files which are known
> to git, which are matched by the default rules (in particular the
> .gitignore files).
>
> So that should be this?
>
> git ls-files --exclude-per-directory=.gitignore -i
Yes, so it seems. The per-directory ignore-files don't work.
"--exclude-from=" (aka -X) still does.
> But that shows nothing at all, and it still shows nothing if I add a
> "builtin-add.c" as an argument to it (this file exists, and is in the
> index).
>
> "git add builtin-add.c" fails, complaining (correctly) that the path
> is ignored by one of my .gitignore files.
>
> We're obviously talking past one another somehow, or I have a broken
> build of git?
No, I honestly believed that Git-known files can be ignored. According
to Linus I must be wrong, but I have an excuse:
$ mkdir aaa
$ cd aaa
$ git init
Initialized empty Git repository in .git/
$ uname >abc
$ git add .
$ ls > .gitignore
$ git ls-files -X .gitignore
$ git ls-files -X .gitignore -i
abc
^ permalink raw reply
* Re: [BUG] t9101 (master) busted on Leopard
From: Benoit Sigoure @ 2007-11-15 21:13 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <041C0054-5E50-483C-9779-B2FE1AE6947C@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
On Nov 15, 2007, at 5:11 PM, 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.
Hi Wincent,
Can you reproduce this deterministically? If yes, can you re-run the
test with the --verbose flag and post the gzipped output (or send it
to me if the list doesn't like this sort of attachment).
Thanks.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: refining .gitignores
From: Bruce Stephens @ 2007-11-15 21:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, git
In-Reply-To: <alpine.LFD.0.9999.0711151237550.4260@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 15 Nov 2007, Bruce Stephens wrote:
>>
>> They are in the index. What I want is a list of files which are known
>> to git, which are matched by the default rules (in particular the
>> .gitignore files).
>
> Ahh.
>
> *All* the .gitignore rules are purely about files that git does not
> already know about. Once git tracks a pathname, the ignore rules simply
> do not matter.
>
> Files that are in the index are simply never ignored. There's no way to
> ignore them, and in fact, the whole "git add -f" thing is a way to add
> files to the index and override the exclude rules - at which point git
> then tracks them regardless of any such exclude rules.
OK. I think I sort of understood that, but it's nice to have it
clearly stated.
I'm not worried so much about files that already exist. I'm worried
that we may in the future create files that we want to store in git
and which are ignored. If we do that there's a chance we'll miss them
(because "git gui", "git status", etc., won't bring attention to
them).
So it seemed valuable to try to make the .gitignore patterns precise:
so that they ignore all the generated files that our builds produce,
while not matching any files that git knows about.
That certainly wouldn't guarantee that new files wouldn't be caught by
the patterns, but it ought to lower the probability of this, since
there's a decent chance that such files will either be not touched by
the patterns (because they're *.java or something), or they'll fit
into one of the already handled exceptions (Doxyfile.local is one:
most *.local files are build products, but Doxyfile.local aren't).
I guess if you're starting off with some project in git then this
isn't such an issue: you evolve the patterns and the build process and
so on in parallel. So maybe there's not such a demand for finding
this information, and those of us who do want to do it are best using
the "git add" loop approach?
^ 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