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
Am 22.08.2013 00:15, schrieb Stefan Beller:
On 08/21/2013 10:56 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com 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
Am 21.08.2013 10:49, schrieb Matthieu Moy:
Stefan Beller stefanbel...@googlemail.com writes:
+ for_each_string_list_item(item, names) {
+ for (ext = 0; ext 2; ext++) {
+ char *fname, *fname_old;
+ fname = mkpathdup(%s/%s%s,
Am 21.08.2013 15:07, schrieb Matthieu Moy:
Stefan Beller stefanbel...@googlemail.com 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
On Thu, Aug 22, 2013 at 5:00 AM, Jeff King p...@peff.net 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
On Thu, Aug 22, 2013 at 3:52 AM, Jeff King p...@peff.net 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 08:45:19PM +0700, Nguyen Thai Ngoc Duy wrote:
On Thu, Aug 22, 2013 at 3:52 AM, Jeff King p...@peff.net wrote:
@@ -68,6 +81,16 @@ const char *write_idx_file(const char *index_name,
struct pack_idx_entry **objec
else
sorted_by_sha = list =
On Wed, Aug 21, 2013 at 4:36 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Aug 13, 2013 at 8:31 AM, Matthieu Moy matthieu@imag.fr wrote:
Felipe: Is this the right fix for git-remote-mediawiki? Any better idea?
Why not
On Wed, Aug 21, 2013 at 7:25 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
Eric Sunshine sunsh...@sunshineco.com writes:
On Wed, Aug 21, 2013 at 7:25 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
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
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
Stefan Beller stefanbel...@googlemail.com 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
On Wed, Aug 21, 2013 at 5:41 PM, Junio C Hamano gits...@pobox.com wrote:
Brian Gernhardt br...@gernhardtsoftware.com 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
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] path path
This should inform the user of
Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com 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
Eric Sunshine sunsh...@sunshineco.com 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
On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
On Thu, Aug 22, 2013 at 5:32 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
I can confirm this failure on OS X, however,...
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Aug 22, 2013 at 5:32 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
I can
On Thu, Aug 22, 2013 at 5:43 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Aug 22, 2013 at 5:32 PM, Junio C Hamano gits...@pobox.com wrote:
Now, I am curious how it breaks on OS X.
My suspition is that ignore_case may have something to do
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, based on
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: Jeff
Eric Sunshine sunsh...@sunshineco.com 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
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
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
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
On Thu, Aug 22, 2013 at 7:12 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
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 sure. I'll check
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
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 (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
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.
On Thu, Aug 22, 2013 at 7:15 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Thu, Aug 22, 2013 at 7:12 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
Status update: For the 'pathx' directory created by the t3010 test,
directory_exists_in_index()
Eric Sunshine sunsh...@sunshineco.com 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
36 matches
Mail list logo
