Eric Sunshine writes:
> I sent a patch [1] which resolves the problem, although the solution
> is not especially pretty (due to some ugliness in the existing
> implementation).
Yeah, thanks.
I tend to agree with you that fixing the "icase" callee not to rely
on having the trailing slash (which
On Thu, Aug 22, 2013 at 7:15 PM, Eric Sunshine wrote:
> On Thu, Aug 22, 2013 at 7:12 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>>> Status update: For the 'pathx' directory created by the t3010 test,
>>> directory_exists_in_index() returns false on OSX, but true is returned
>>> on Lin
Although undocumented, directory_exists_in_index_icase(dirname,len)
unconditionally assumes the presence of a '/' at dirname[len] (despite
being past the end-of-string). Callers are expected to respect this
assumption by ensuring that a '/' is present beyond the last character
of the passed path. d
2eac2a4cc4bdc8d7 (ls-files -k: a directory only can be killed if the
index has a non-directory; 2013-08-15) adds a caller of
directory_exists_in_index(dirname,len) which forgets to satisfy the
undocumented requirement that a '/' must be present at dirname[len]
(despite being past the end-of-string)
This series fixes a bug in dir.c which causes t3010 to fail [1] when
core.ignorecase is true. The problem is that
directory_exists_in_index(dirname,len) and
directory_exists_in_index_icase() behave differently if dirname[len] is
not a '/', even though this is beyond end-of-string. 2eac2a4cc4bdc8d7
Hello,
Has anyone actually gotten git-p4 to clone a large Perforce repository?
I have one codebase in particular that gets to about 67%, then
consistently gets get-fast-import (and often times a few other
processes) killed by the OOM killer.
I've found some patches out there that claim to resolve
On Thu, 22 Aug 2013, Jeff King wrote:
> On Thu, Aug 22, 2013 at 10:43:05AM -0400, Jeff King wrote:
>
> > > write_idx_file() is called after index-pack processes all delta
> > > objects. Could resolve_deltas() go cyclic with certain duplicate
> > > object setup?
> >
> > Good question. I'm not sur
We should never see duplicate objects in packs, and it is
unknown what kind of complications such packs could create
during the repacking process. The previous commit introduced
a safety valve for checking packs coming into the repository
and being indexed by index-pack.
Let's turn the safety valv
On Thu, Aug 22, 2013 at 7:12 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> Status update: For the 'pathx' directory created by the t3010 test,
>> directory_exists_in_index() returns false on OSX, but true is returned
>> on Linux.
>
> Because a regular pathx/ju is in the index at that poi
Git should never generate packs with duplicate objects.
However, we may see such packs due to bugs in Git or other
implementations (e.g., JGit had such a bug a few years ago).
In theory, such packs should not be a problem for us (we
will simply find one of the instances of the object when
looking
The previous commit added tests to show that index-pack
correctly bails in unrecoverable situations. There are some
situations where the data could be recovered, but it is not
currently:
1. If we can break the cycle using an object from another
pack via --fix-thin.
2. If we can break the
If we receive a broken or malicious pack from a remote, we
will feed it to index-pack. As index-pack processes the
objects as a stream, reconstructing and hashing each object
to get its name, it is not very susceptible to doing the
wrong with bad data (it simply notices that the data is
bogus and a
The sha1_entry_pos function tries to be smart about
selecting the middle of a range for its binary search by
looking at the value differences between the "lo" and "hi"
constraints. However, it is unable to cope with entries with
duplicate keys in the sorted list.
We may hit a point in the search w
Eric Sunshine writes:
> Status update: For the 'pathx' directory created by the t3010 test,
> directory_exists_in_index() returns false on OSX, but true is returned
> on Linux.
Because a regular pathx/ju is in the index at that point, the
correct answer directory_exists_in_index() should give fo
The test-sha1 helper program will run our internal sha1
routines over its input and output the 40-byte hex sha1.
Sometimes, however, it is useful to have the binary 20-byte
sha1 (and it's a pain to convert back in the shell). Let's
add a "-b" option to output the binary version.
Signed-off-by: Jef
On Thu, Aug 22, 2013 at 10:43:05AM -0400, Jeff King wrote:
> > write_idx_file() is called after index-pack processes all delta
> > objects. Could resolve_deltas() go cyclic with certain duplicate
> > object setup?
>
> Good question. I'm not sure. I'll check it out.
I think the answer is "no", ba
On Thu, Aug 22, 2013 at 5:59 PM, Eric Sunshine wrote:
> On Thu, Aug 22, 2013 at 5:43 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>> On Thu, Aug 22, 2013 at 5:32 PM, Junio C Hamano wrote:
Now, I am curious how it breaks on OS X.
My suspition is that "ignore_case" may have
On Thu, Aug 22, 2013 at 5:43 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> On Thu, Aug 22, 2013 at 5:32 PM, Junio C Hamano wrote:
>>> Now, I am curious how it breaks on OS X.
>>>
>>> My suspition is that "ignore_case" may have something to do with it,
>>> but what 2eac2a4c (ls-files -k: a
Eric Sunshine writes:
> On Thu, Aug 22, 2013 at 5:32 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>>> On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano wrote:
Eric Sunshine writes:
> I can confirm this failure on OS X, however,...
>>>
>>> Thanks for the explanation.
>>
>>
On Thu, Aug 22, 2013 at 5:32 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano wrote:
>>> Eric Sunshine writes:
>>>
I can confirm this failure on OS X, however,...
>>
>> Thanks for the explanation.
>
> Now, I am curious how it breaks on
Eric Sunshine writes:
> On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>>> I can confirm this failure on OS X, however,...
>
> Thanks for the explanation.
Now, I am curious how it breaks on OS X.
My suspition is that "ignore_case" may have something to do w
On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> I can confirm this failure on OS X, however, I am somewhat confused by
>> the follow-up t3010 changes in 3c56875176390eee. Are the t3010 changes
>> supposed to fail without 2eac2a4cc4bdc8d7 applied? For me, on Lin
Eric Sunshine writes:
> I can confirm this failure on OS X, however, I am somewhat confused by
> the follow-up t3010 changes in 3c56875176390eee. Are the t3010 changes
> supposed to fail without 2eac2a4cc4bdc8d7 applied? For me, on Linux,
> the tests succeed whether 2eac2a4cc4bdc8d7 is applied or
Junio C Hamano wrote:
> Stefan Beller writes:
>> The motivation of this patch is to get closer to a goal of being
>> able to have a core subset of git functionality built in to git.
>> That would mean
>>
>> * people on Windows could get a copy of at least the core parts
>>of Git without havi
wor...@alum.mit.edu (Dale R. Worley) writes:
> The error message has been updated from [PATCH]. "git diff" outside a
> repository now produces:
>
> Not a git repository
> To compare two paths outside a working tree:
> usage: git diff [--no-index]
>
> This should inform the user of h
On Wed, Aug 21, 2013 at 5:41 PM, Junio C Hamano wrote:
> Brian Gernhardt writes:
>
>> With 2eac2a4: "ls-files -k: a directory only can be killed if the index has
>> a non-directory" applied, t3010 fails test 3 "validate git ls-files -k
>> output". It ends up missing the pathx/ju/nk file.
>>
>>
Stefan Beller writes:
> @@ -41,18 +35,16 @@ static void remove_temporary_files(void)
> DIR *dir;
> struct dirent *e;
>
> + dir = opendir(packdir);
> + if (!dir)
> return;
>
> + strbuf_addstr(&buf, packdir);
> +
> + /* dirlen holds the length of the pa
Clarify documentation for git-diff: State that when not inside a
repository, --no-index is implied (and thus two arguments are
mandatory).
Clarify error message from diff-no-index to inform user that CWD is
not inside a repository and thus two arguments are mandatory.
Signed-off-by: Dale Worley
This patch is meant to be squashed into bb4335a21441a0
(repack: rewrite the shell script in C), I'll do so when rerolling
the series. For reviewing I'll just send this patch.
* Remove comments, which likely get out of date (authorship is kept in
git anyway)
* rename get_pack_filenames to get_non
Eric Sunshine writes:
> On Wed, Aug 21, 2013 at 7:25 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>>> This set of patches was meant to be a re-roll of [1] addressing Junio's
>>> comments, however [1] graduated to 'next' before I found time to work on
>>> it further, so these are instea
On Wed, Aug 21, 2013 at 7:25 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> This set of patches was meant to be a re-roll of [1] addressing Junio's
>> comments, however [1] graduated to 'next' before I found time to work on
>> it further, so these are instead incremental patches atop 'nex
Stefan Beller writes:
>> git_path is for resolving paths within GIT_DIR, such as
>> git_path("config") and git_path("COMMIT_EDITMSG").
>>
>> Jonathan
>
> Before we're doing double work, I just wrote down my understanding
> so far. Feel free to tweak it, or remove obvious parts.
> path API
> ===
On Wed, Aug 21, 2013 at 4:36 PM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Tue, Aug 13, 2013 at 8:31 AM, Matthieu Moy wrote:
>>
>>> Felipe: Is this the right fix for git-remote-mediawiki? Any better idea?
>>
>> Why not keep track of the revisions yourself? You can have file where
>>
On Thu, Aug 22, 2013 at 08:45:19PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Thu, Aug 22, 2013 at 3:52 AM, Jeff King wrote:
> > @@ -68,6 +81,16 @@ const char *write_idx_file(const char *index_name,
> > struct pack_idx_entry **objec
> > else
> > sorted_by_sha = list = last =
On Thu, Aug 22, 2013 at 3:52 AM, Jeff King wrote:
> @@ -68,6 +81,16 @@ const char *write_idx_file(const char *index_name, struct
> pack_idx_entry **objec
> else
> sorted_by_sha = list = last = NULL;
>
> + if (opts->duplicates == WRITE_IDX_DUPLICATES_REJECT) {
> +
On Thu, Aug 22, 2013 at 5:00 AM, Jeff King wrote:
> On Wed, Aug 21, 2013 at 08:45:13PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On the topic, C Git's (maybe) violations on this spec are:
>>
>> - The client does not strip trailing slashes from $GIT_URL before
>> sending to the server, as desc
Am 21.08.2013 15:07, schrieb Matthieu Moy:
Stefan Beller writes:
But as these follow up changes heavily rely on the very first patch
I will first try to get that right, meaning accepted into pu.
Then I can send patches with these proposals such as making more
functions.
I think it's better t
Am 22.08.2013 00:15, schrieb Stefan Beller:
On 08/21/2013 10:56 PM, Junio C Hamano wrote:
Stefan Beller writes:
+static int delta_base_offset = 1;
+char *packdir;
Does this have to be global?
As the path is pretty obvious (get_object_directory() + "/pack"),
we could however also construct
Am 21.08.2013 10:49, schrieb Matthieu Moy:
Stefan Beller writes:
+ for_each_string_list_item(item, &names) {
+ for (ext = 0; ext < 2; ext++) {
+ char *fname, *fname_old;
+ fname = mkpathdup("%s/%s%s", packdir, item->string,
exts[e
I've recently been forced back into using git-svn, and while I was at
it, I noticed that git-svn generally behaves a lot better when it is
initialized using the --prefix option.
For example, I make a standard-layout svn clone:
$ git svn clone -s https://svn.company.com/repos/project-foo/
.. and
40 matches
Mail list logo
