* Re: [PATCH] Adding rebase merge strategy
From: Johannes Schindelin @ 2007-10-02 10:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tom Clarke, Carl Worth, Junio C Hamano, git
In-Reply-To: <20071001223050.GE2137@spearce.org>
Hi,
On Mon, 1 Oct 2007, Shawn O. Pearce wrote:
> But I have to agree with (was it Junio who said this?) doing a rebase
> in a merge strategy doesn't make sense when conflicts come into play.
In contrast, I think that it makes sense, absolutely. If you asked for
"rebase", you _have_ to know what is coming.
It's all about convenience: in many repos, I just to "git pull", because
there is really only one upstream.
But in one repo, the upstream is svn, and I mistakenly checked in a merge.
Not wanting to know svn deeply, I have no nice way (as I would have with
git) to cover up my mistake. So in this repo, I would have liked to set
branch.master.mergeOptions to '-s rebase'.
Ciao,
Dscho
^ permalink raw reply
* Re: git-http-push / webDAV
From: Thomas Pasch @ 2007-10-02 9:57 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20071002085416.GW975@void.codelabs.ru>
Dear Eygene,
well, *somewhat* better with the trailing slash:
> echo "modified" >>grep.c
> git commit -a
Created commit e147e54: mod
1 files changed, 1 insertions(+), 0 deletions(-)
> git push -v
Pushing to http://test@192.1.1.184/git/git.git/
Fetching remote heads...
refs/
refs/heads/
refs/tags/
updating 'refs/heads/master'
from 34c6dbdef439f7cd93d3fe22493a3c1496ce96f7
to e147e54b14828fa2e88e88907e0ca4dc3d694448
sending 3 objects
done
Updating remote server info
There's no more error message. However, push has still
not worked. If I try to check out the new HEAD:
> git clone http://test@192.1.1.184/git/git.git/
Initialized empty Git repository in /home/tpasch/tmp/git/.git/
Getting alternates list for http://test@192.1.1.184/git/git.git
Getting pack list for http://test@192.1.1.184/git/git.git
Getting index for pack 563e2090185692c7d765775569a0ce986840fd17
Getting pack 563e2090185692c7d765775569a0ce986840fd17
which contains 3af9d3e08da868c3a7687ab38d72f4296a99005d
[...]
walk 24778e335a6450e34257a311d0bf4a12bdb3006c
walk 19b2860cba5742ab31fd682b80fefefac19be141
walk bf0c6e839c692142784caf07b523cd69442e57a5
walk e497ea2a9b6c378f01d092c210af20cbee762475
walk 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
walk e83c5163316f89bfbde7d9ab23ca2e25604af290
Getting alternates list for http://test@192.1.1.184/git/git.git
Getting pack list for http://test@192.1.1.184/git/git.git
error: Unable to find e147e54b14828fa2e88e88907e0ca4dc3d694448 under
http://test@192.1.1.184/git/git.git
Cannot obtain needed object e147e54b14828fa2e88e88907e0ca4dc3d694448
Cheers,
Thomas
Eygene Ryabinkin wrote:
> Thomas, good day.
>
> Tue, Oct 02, 2007 at 10:49:07AM +0200, Thomas Pasch wrote:
>> I've investigated my problem a little further. The nasty
>> 'UNLOCK HTTP error 400' has come from a proxy that
>> doesn't accept webDAV stuff. Thus I unset the 'http_proxy'
>> env variable (looks like cadaver hasn't cared...).
>
> Yep, proxies can be tricky with the DAV stuff.
>
>> However, the main problem still remains. Using a non empty
>> remote http repo, modifying and committing, then:
>>
>>> git push -v
>> Pushing to http://test@x.x.x.x/git/git.git
>>
>> still waits for a long time and finally:
>>
>> Error: no DAV locking support on remote repo http://test@x.x.x.x/git/git.git
>> error: failed to push to 'http://test@x.x.x.x/git/git.git'
>
> Try using URL with the slash at the end, like
> 'http://test@x.x.x.x/git/git.git/'. This should help.
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Johannes Schindelin @ 2007-10-02 9:46 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Barry Fishman, git
In-Reply-To: <87bqbisae6.wl%cworth@cworth.org>
Hi,
On Mon, 1 Oct 2007, Carl Worth wrote:
> On Mon, 01 Oct 2007 15:32:58 -0700, Junio C Hamano wrote:
> > "master:master") does not exist there, and we do not create it
> > unless you give a full refname that begins with refs/ (so that
> > push can tell if you want to create a tag or a branch).
>
> And why is that?
Well, if the OP had used "git push <bla> master" instead of
"... master:master", it would have worked. I am unaware of any tutorial
that suggests the latter, only of tutorials that suggest the former.
Ciao,
Dscho
^ permalink raw reply
* Re: what's a useful definition of full text index on a repository?
From: David Tweed @ 2007-10-02 9:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910710011025y790800b5s4e8cf65409bc2cce@mail.gmail.com>
On 10/1/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> This is what full text is used for with code:
> http://lxr.mozilla.org/
>
> It makes grep instant.
I'd thought that keeping a full-text index of all my program files was
my dirty little secret that shows I'm not a "pro" programmer ;-)
> For source code you can take the full text concept further and store
> parse trees.
[details snipped]
This sounds interesting in principle but is beyond what I'm thinking
in practice (particularly since I'm not in the "C is the only language
worth ever using" camp).
> Full text indexing can also achieve high levels of compression as
> stated in the earlier threads. It is full scale dictionary
> compression. When it is being used for compression you want to apply
> it to all revisions.
Well, as I say I'm not convinced it makes sense to integrate this with
existing pack stuff precisely because I don't think it's universally
useful. So you seem to end up with all the usual tricks, eg, Golomb
coding inverted indexes, etc, _if_ you treat each blob as completely
independent. I was wondering if there was anything else you can do
given the special structure that might be both more useful and more
compact?
> You would full text index the expanded source text for each revision,
> not the delta. There are forms of full text indexes that record the
> words position in the document. They let you search for "vision NEAR
> feedback"
Well, the kind of question I was thinking was "clearly you can use the
existing sort of full text indexing (eg, the stuff covered in Cleary,
Witten & Bell's covered Managing Gigabytes), but is that the most
useful way of doing things in the context of an evolving database?" If
you treat every blob as essentially a different document there are
indexing tools out there already you can use. What I was wondering was
if it's really that useful to a human user to report every revision of
a document containing those keywords even if the differences are in
other parts of the text far removed from the text containing the
keywords. I don't know the answer.
> > (One question is "why do you want to build a table rather than
> > actively search the full git repo for each query (ie, combination of
> > words) as you make it?" My primary motivation is that I might in the
> > future like to do queries on some sort of low processor power
> > UMPC-type thing, having built the file containing a "full text index"
> > data structure for the index on a quite beefy desktop. The other point
> > is that searching natural language text based on a fallible memory
> > you're more likely to try different combinations of search terms
> > iteratively to try and hit the right one, so there might be some point
> > in trying to build an index.)
>
> I do admit that these indexes are used to make functions that can be
> done with brute force faster. As computers get faster the need for
> these decrease. Right now the size of the kernel repo is not growing
> faster than the progress of hardware. If you went back are tried to do
> these things on a 386 you'd be shouting for indexes tomorrow.
The other point is that direct searching is easier because you know
exactly what the query is at the point you have access to the full
text, whereas building an index you want to extract no more and no
less information to be able to answer all allowed queries. But I still
like the idea of getting a UMPC type thing if they become affordable.
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: git-http-push / webDAV
From: Eygene Ryabinkin @ 2007-10-02 8:54 UTC (permalink / raw)
To: Thomas Pasch; +Cc: git
In-Reply-To: <47020603.3080000@jentro.com>
Thomas, good day.
Tue, Oct 02, 2007 at 10:49:07AM +0200, Thomas Pasch wrote:
> I've investigated my problem a little further. The nasty
> 'UNLOCK HTTP error 400' has come from a proxy that
> doesn't accept webDAV stuff. Thus I unset the 'http_proxy'
> env variable (looks like cadaver hasn't cared...).
Yep, proxies can be tricky with the DAV stuff.
> However, the main problem still remains. Using a non empty
> remote http repo, modifying and committing, then:
>
> > git push -v
> Pushing to http://test@x.x.x.x/git/git.git
>
> still waits for a long time and finally:
>
> Error: no DAV locking support on remote repo http://test@x.x.x.x/git/git.git
> error: failed to push to 'http://test@x.x.x.x/git/git.git'
Try using URL with the slash at the end, like
'http://test@x.x.x.x/git/git.git/'. This should help.
--
Eygene
^ permalink raw reply
* Re: git-http-push / webDAV
From: Thomas Pasch @ 2007-10-02 8:49 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20071001155454.GU975@void.codelabs.ru>
Dear Eygene,
I've investigated my problem a little further. The nasty
'UNLOCK HTTP error 400' has come from a proxy that
doesn't accept webDAV stuff. Thus I unset the 'http_proxy'
env variable (looks like cadaver hasn't cared...).
However, the main problem still remains. Using a non empty
remote http repo, modifying and committing, then:
> git push -v
Pushing to http://test@x.x.x.x/git/git.git
still waits for a long time and finally:
Error: no DAV locking support on remote repo http://test@x.x.x.x/git/git.git
error: failed to push to 'http://test@x.x.x.x/git/git.git'
Interestingly apache2 access_log is:
[...]
x.x.x.x - test [02/Oct/2007:10:38:03 +0200] "GET /git/git.git/objects/pack/p
ack-563e2090185692c7d765775569a0ce986840fd17.pack HTTP/1.1" 200 15038211
"-" "gi
t/1.5.3.3"
x.x.x.x - test [02/Oct/2007:10:38:35 +0200] "GET /git/git.git/HEAD HTTP/1.1"
200 23 "-" "curl/7.15.5 (i686-suse-linux-gnu) libcurl/7.15.5
OpenSSL/0.9.8d zli
b/1.2.3 libidn/0.6.8"
x.x.x.x - test [02/Oct/2007:10:39:27 +0200] "PROPFIND /git/git.git HTTP/1.1"
301 319 "-" "git/1.5.3.3"
Hence a 'Moved Permanently' Error?!?
I'm using a SuSE 10.2 system here. Apache2 git configuration
is in /etc/apache2/conf.d/git-dav.conf:
--->8--->8--->8--->8--->8--->8--->8--->8--->8
<IfModule mod_alias.c>
Alias /git /data/git
</IfModule>
DAVLockDB /var/lock/apache2/DAVLock
<Directory /data/git>
# http://httpd.apache.org/docs/2.0/mod/mod_dav.html
DAV On
Options +Indexes
AuthType Basic
AuthName "git"
AuthBasicProvider file
AuthUserFile /etc/apache2/auth/userfile
Require valid-user
Order allow,deny
Allow from all
</Directory>
--->8--->8--->8--->8--->8--->8--->8--->8--->8
Cheers,
Thomas
Eygene Ryabinkin wrote:
> Thomas, good day.
>
> Mon, Oct 01, 2007 at 03:31:40PM +0200, Thomas Pasch wrote:
>> trying to set up a webDAV enabled http push
>> git server (1.5.3.3) like it is described in
>>
>>
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
>>
>> Tested the apache2 (2.2.6) DAV setup with
>> cadaver (and tried the browser as well).
>> With cadaver I could lock files, download
>> and upload content.
>>
>> However,
>>
>>> git push -v upload master
>> Pushing to http://test@x.x.x.x/git/DepTrack.git/
>> Fetching remote heads...
>> refs/
>> refs/heads/
>> refs/tags/
>> updating 'refs/heads/master'
>> from 0000000000000000000000000000000000000000
>> to d75dce3fe0e9ec5915feda5574f214bd432ccb14
>> sending 89 objects
>> done
>> Updating remote server info
>> UNLOCK HTTP error 400
>
> And how is your Apache configuration looks like? I used to
> make 2.2.4 work flawlessly with git. Perhaps I will get it
> a shot with the 2.2.6.
^ permalink raw reply
* Re: [PATCH 1/2] Change "refs/" references to symbolic constants
From: Andy Parkins @ 2007-10-02 8:41 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20071002011659.GA7938@coredump.intra.peff.net>
On Tuesday 2007 October 02, Jeff King wrote:
> - patlen != namelen - 5 &&
> - prefixcmp(name, "refs/heads/") &&
> - prefixcmp(name, "refs/tags/")) {
> + patlen != namelen - STRLEN_PATH_REFS_HEADS &&
> + prefixcmp(name, PATH_REFS_HEADS) &&
> + prefixcmp(name, PATH_REFS_HEADS)) {
>
> This is totally bogus. You meant STRLEN_PATH_REFS, and the second path
> should be PATH_REFS_TAGS. With those changes, t5516 passes.
Excellent! Well done. I spent a couple of hours last night going through
every changed line and have spotted the TAGS mistake but didn't spot the
STRLEN being wrong. Amazing how easy it is to become blind to these things.
There were a couple of errors in "/" placement too, but I don't think they
were causing any trouble, just doubled up "/" characters.
> I haven't combed through your patch in detail, so there might be similar
> problems lurking. I did notice one or two spots where you call
> strlen(PATH_REFS_*), which should of course also be changed to
> STRLEN_PATH_REFS_*.
I think I caught a few of them in my review. I think I had originally left
them like that on purpose. My reasoning was that a patch like that should
leave the resultant code identical. So I did replacements like:
- strlen("refs/heads/");
+ strlen(PATH_REFS_HEADS);
However, I think it was just pedantry, so I've been correcting them too.
I noticed a couple of places where memcmp() has been used where prefixcmp()
would work fine. I'm tempted to change them too - what do you think?
Perhaps a separate patch?
> And as a final comment, your patch doesn't apply to next at all because
> of the reorganization of the fetching API (e.g., fetch-pack.c doesn't
> exist at all anymore). You should probably prepare a parallel patch for
> next.
I'm happy to do prepare a patch against any revision, I was really waiting for
feedback from Junio as to how he'd like to manage it. Last time I submitted
this patch he (quite correctly) asked that I delay until after the next point
release; of course I promptly found other things to do and never
resubmitted :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Matthieu Moy @ 2007-10-02 8:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steffen Prohaska
In-Reply-To: <7vlkamm16s.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> I'm also concerned about the possibility of stash/unstash to fail:
>> that means the user has to deal with two kinds of conflicts (rebase
>> can conflict, unstash can also), which can be confusing.
>
> Unstash should be invoked automatically _only_ after rebase
> completes, so I do not forsee such confusion.
Well, if rebase itself conflicts, it will stop and tell you about
conflicts, then you'll have to "rebase --continue". If unstash fails,
you'll have to resolve the conflicts, and probably do "commit", or
continue working afterwards. You don't have to deal with both at the
same time, but both do exist, and they have to be taken care of
differently.
For an advanced user with good understanding of the flow, that's OK,
but I'm still afraid of the confusion for not-so-advanced users.
But that's not a strong argument against auto-stash, just one
downside.
> But the trouble I have with the auto unstashing is more at the
> conceptual and workflow level. You start rebasing a branch, and
> your work tree is dirty. What branch should the local
> modification belong to?
You're in a better position than me to juge on that point.
> # The tree must be really really clean.
> -git update-index --refresh || exit
> +o=$(git update-index -q --refresh) || {
> + printf "cannot rebase: the work tree is not clean.\n%s\n" "$o"
> + exit 1
> +}
> diff=$(git diff-index --cached --name-status -r HEAD)
> case "$diff" in
> ?*) echo "cannot rebase: your index is not up-to-date"
That alone would already be a real improvement.
I'd add this to be consistant with "git status". I find the "needs
update" really short, and especially confusing for centralized systems
users, for whom "needs update" would probably mean "new version
available, please run '$VCS update'".
diff --git a/read-cache.c b/read-cache.c
index 2e40a34..3745a48 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -869,7 +869,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
}
if (quiet)
continue;
- printf("%s: needs update\n", ce->name);
+ printf("%s: Changed but not updated\n", ce->name);
has_errors = 1;
continue;
}
--
Matthieu
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: David Kågedal @ 2007-10-02 8:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkamm16s.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * not to do the autostash, but fail as we have always done,
> when "git rebase base other" form was used, first instructing
> rebase to switch to another branch;
I don't like the idea of automatic stashing on a rebase. It makes it
harder to understand what is happening, and figuring out were things
went if everything wasn't successful.
--
David Kågedal
^ permalink raw reply
* mirror pushing
From: Junio C Hamano @ 2007-10-02 7:55 UTC (permalink / raw)
To: git
Existing "git push --all" is almost perfect for backing up to
another repository, except that "--all" only means "all
branches" in modern git, and it does not delete old branches and
tags that exist at the back-up repository that you have removed
from your local repository.
This teaches "git-send-pack" a new "--mirror" option. The
difference from the "--all" option are that (1) it sends all
refs, not just branches, and (2) it deletes old refs you no
longer have on the local side from the remote side.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This even applies to "maint", but it probably should be done
on top of Daniel's remote.c changes. Teaching this to "git
push" wrapper is left as an exercise to the reader.
remote.c | 15 ++++++++++-----
send-pack.c | 35 ++++++++++++++++++++++++-----------
2 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/remote.c b/remote.c
index bb774d0..a3aa5ad 100644
--- a/remote.c
+++ b/remote.c
@@ -574,10 +574,12 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
* without thinking.
*/
int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
- int nr_refspec, char **refspec, int all)
+ int nr_refspec, char **refspec, int flags)
{
struct refspec *rs =
parse_ref_spec(nr_refspec, (const char **) refspec);
+ int send_all = flags & 01;
+ int send_mirror = flags & 02;
if (match_explicit_refs(src, dst, dst_tail, rs, nr_refspec))
return -1;
@@ -594,7 +596,7 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
if (!pat)
continue;
}
- else if (prefixcmp(src->name, "refs/heads/"))
+ else if (!send_mirror && prefixcmp(src->name, "refs/heads/"))
/*
* "matching refs"; traditionally we pushed everything
* including refs outside refs/heads/ hierarchy, but
@@ -615,10 +617,13 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
if (dst_peer && dst_peer->peer_ref)
/* We're already sending something to this ref. */
goto free_name;
- if (!dst_peer && !nr_refspec && !all)
- /* Remote doesn't have it, and we have no
+
+ if (!dst_peer && !nr_refspec && !(send_all || send_mirror))
+ /*
+ * Remote doesn't have it, and we have no
* explicit pattern, and we don't have
- * --all. */
+ * --all nor --mirror.
+ */
goto free_name;
if (!dst_peer) {
/* Create a new one and link it */
diff --git a/send-pack.c b/send-pack.c
index 9fc8a81..39b4b17 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -7,11 +7,12 @@
#include "remote.h"
static const char send_pack_usage[] =
-"git-send-pack [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
+"git-send-pack [--all | --mirror] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
" --all and explicit <ref> specification are mutually exclusive.";
static const char *receivepack = "git-receive-pack";
static int verbose;
static int send_all;
+static int send_mirror;
static int force_update;
static int use_thin_pack;
@@ -200,7 +201,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
if (!remote_tail)
remote_tail = &remote_refs;
if (match_refs(local_refs, remote_refs, &remote_tail,
- nr_refspec, refspec, send_all))
+ nr_refspec, refspec, (send_all | (send_mirror << 1))))
return -1;
if (!remote_refs) {
@@ -215,19 +216,24 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
for (ref = remote_refs; ref; ref = ref->next) {
char old_hex[60], *new_hex;
int will_delete_ref;
+ const unsigned char *new_sha1;
- if (!ref->peer_ref)
- continue;
-
+ if (!ref->peer_ref) {
+ if (!send_mirror)
+ continue;
+ new_sha1 = null_sha1;
+ }
+ else
+ new_sha1 = ref->peer_ref->new_sha1;
- will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
+ will_delete_ref = is_null_sha1(new_sha1);
if (will_delete_ref && !allow_deleting_refs) {
error("remote does not support deleting refs");
ret = -2;
continue;
}
if (!will_delete_ref &&
- !hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
+ !hashcmp(ref->old_sha1, new_sha1)) {
if (verbose)
fprintf(stderr, "'%s': up-to-date\n", ref->name);
continue;
@@ -257,8 +263,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
!is_null_sha1(ref->old_sha1) &&
!ref->force) {
if (!has_sha1_file(ref->old_sha1) ||
- !ref_newer(ref->peer_ref->new_sha1,
- ref->old_sha1)) {
+ !ref_newer(new_sha1, ref->old_sha1)) {
/* We do not have the remote ref, or
* we know that the remote ref is not
* an ancestor of what we are trying to
@@ -276,7 +281,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
continue;
}
}
- hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
+ hashcpy(ref->new_sha1, new_sha1);
if (!will_delete_ref)
new_refs++;
strcpy(old_hex, sha1_to_hex(ref->old_sha1));
@@ -396,6 +401,10 @@ int main(int argc, char **argv)
send_all = 1;
continue;
}
+ if (!strcmp(arg, "--mirror")) {
+ send_mirror = 1;
+ continue;
+ }
if (!strcmp(arg, "--force")) {
force_update = 1;
continue;
@@ -420,7 +429,11 @@ int main(int argc, char **argv)
}
if (!dest)
usage(send_pack_usage);
- if (heads && send_all)
+ /*
+ * --all and --mirror are incompatible; neither makes sense
+ * with any refspecs.
+ */
+ if ((heads && (send_all || send_mirror)) || (send_all && send_mirror))
usage(send_pack_usage);
verify_remote_names(nr_heads, heads);
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-10-02 7:21 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Matthieu Moy
In-Reply-To: <vpq641qroae.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> I'm also concerned about the possibility of stash/unstash to fail:
> that means the user has to deal with two kinds of conflicts (rebase
> can conflict, unstash can also), which can be confusing.
Unstash should be invoked automatically _only_ after rebase
completes, so I do not forsee such confusion.
But the trouble I have with the auto unstashing is more at the
conceptual and workflow level. You start rebasing a branch, and
your work tree is dirty. What branch should the local
modification belong to?
Logically, it is with the branch you were on when you typed "git
rebase" command.
But when "rebase" successfully concludes (either with or without
manual fix-ups), you can be either on your original branch (if
you said "git rebase base") or something totally unrelated (if
you said "git rebase base other"). Currently we auto-unstash in
both cases. I _think_ the former case should auto-unstash, but
the latter shouldn't.
However, this auto-stash uses the new "git stash create" command
that does not update the reflog for "refs/stash", specifically
so that the auto-stashing does _not_ interfere with the normal
stash the end user uses. Which means that it is a bit
cumbersome to give the autostashed state back to the user if we
do _not_ unstash upon completion of rebase.
Perhaps a good compromise would be to
* not to do the autostash, but fail as we have always done,
when "git rebase base other" form was used, first instructing
rebase to switch to another branch;
* autostash when "git rebase base" form was used, and auto
unstash upon completion.
> But the current behavior can be greatly improved by just making the
> error message better. Currently, I have this:
>
> $ git rebase branch
> foo.txt: needs update
> $ _
>
> I'd prefer something like
>
> $ git rebase branch
> cannot rebase: the working tree is not clean.
> foo.txt: Changed but not updated
> Commit your changes, or put them appart with "git stash" and retry.
> $ _
You forgot 'needs merge' case, so that would not fly very well,
but something like this might be a good starting point.
---
git-rebase.sh | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 058fcac..4f8aeb9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -252,7 +252,10 @@ else
fi
# The tree must be really really clean.
-git update-index --refresh || exit
+o=$(git update-index -q --refresh) || {
+ printf "cannot rebase: the work tree is not clean.\n%s\n" "$o"
+ exit 1
+}
diff=$(git diff-index --cached --name-status -r HEAD)
case "$diff" in
?*) echo "cannot rebase: your index is not up-to-date"
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Matthieu Moy @ 2007-10-02 7:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <49137EAF-BB73-40DC-973C-E60C14B3FA7F@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Oct 2, 2007, at 7:53 AM, Junio C Hamano wrote:
>
>>
>> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
>> + rebase: allow starting from a dirty tree.
>> + stash: implement "stash create"
>>
>> Instead of refusing to rebase, telling you that your work tree
>> is dirty, this stashes your local changes, runs rebase and then
>> unstashes automatically. That _sounds_ nicer and easier to use,
>> but I am not sure if it is a wise/sane thing to do. We may want
>> to revert the "autostash" from rebase. Opinions?
>
> What would happen if 'git stash' fails to work? Could this bring
> the repo in a state that is hard to recover from? Especially if
> 'stash' commands were run automatically for you. Maybe if you had
> a choice you would not choose to use stash but would commit your
> changes, or would bring your work tree in a clean state by other means.
I'm also concerned about the possibility of stash/unstash to fail:
that means the user has to deal with two kinds of conflicts (rebase
can conflict, unstash can also), which can be confusing.
But the current behavior can be greatly improved by just making the
error message better. Currently, I have this:
$ git rebase branch
foo.txt: needs update
$ _
I'd prefer something like
$ git rebase branch
cannot rebase: the working tree is not clean.
foo.txt: Changed but not updated
Commit your changes, or put them appart with "git stash" and retry.
$ _
--
Matthieu
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Steffen Prohaska @ 2007-10-02 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3awunjup.fsf@gitster.siamese.dyndns.org>
On Oct 2, 2007, at 7:53 AM, Junio C Hamano wrote:
>
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
> + rebase: allow starting from a dirty tree.
> + stash: implement "stash create"
>
> Instead of refusing to rebase, telling you that your work tree
> is dirty, this stashes your local changes, runs rebase and then
> unstashes automatically. That _sounds_ nicer and easier to use,
> but I am not sure if it is a wise/sane thing to do. We may want
> to revert the "autostash" from rebase. Opinions?
What would happen if 'git stash' fails to work? Could this bring
the repo in a state that is hard to recover from? Especially if
'stash' commands were run automatically for you. Maybe if you had
a choice you would not choose to use stash but would commit your
changes, or would bring your work tree in a clean state by other means.
I'm a bit concerned because 'git stash' still doesn't work for me
when the work tree is dirty because of a changed subproject (in
msysgit with git 1.5.3). After I run 'git stash' the work tree stays
dirty. How would "autostash" behave?
BTW, I run 'git submodule update' to bring the tree into a clean
state and later manually check out the previous head in the submodule.
Quite annoying, but not directly related to the discussion above.
Steffen
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Steven Grimm @ 2007-10-02 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3awunjup.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
> + rebase: allow starting from a dirty tree.
> + stash: implement "stash create"
>
> Instead of refusing to rebase, telling you that your work tree
> is dirty, this stashes your local changes, runs rebase and then
> unstashes automatically. That _sounds_ nicer and easier to use,
> but I am not sure if it is a wise/sane thing to do. We may want
> to revert the "autostash" from rebase. Opinions?
>
I can say that for people coming from svn (who are often using "git svn
rebase" rather than directly running "git rebase") this is a nice
workflow improvement. It eliminates one more "Why is this more of a pain
to do in git than in svn?" complaint.
I don't see any circumstance in my use of git -- either in a git-svn
context or not -- where this wouldn't be an improvement over the
existing behavior. However, I don't claim to be using git in any
particularly interesting way, so I suppose it's possible that this will
break someone's workflow horribly.
-Steve
^ permalink raw reply
* Re: [PATCH] fixed link in documentation of diff-options
From: Junio C Hamano @ 2007-10-02 6:27 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11913056772885-git-send-email-prohaska@zib.de>
Sharp eyes; thanks.
^ permalink raw reply
* Re: git clone questions relating to cpio
From: Junio C Hamano @ 2007-10-02 6:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Reece Dunn, Git
In-Reply-To: <4701E10C.7050405@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> FWIW, I'm thinking about changing the cpio -p (passthrough) part to use
> 'cp -l --parents --target-directory=...' instead of tar; this gives us
> hard links, even on NTFS. But it needs GNU's cp, of course.
Yeah, that's the reason it is not appropriate than cpio, even if
we forget about Windows.
^ permalink raw reply
* [PATCH] fixed link in documentation of diff-options
From: Steffen Prohaska @ 2007-10-02 6:14 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/diff-options.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 228ccaf..b1f528a 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -179,8 +179,8 @@
--ext-diff::
Allow an external diff helper to be executed. If you set an
- external diff driver with gitlink:gitattributes(5), you need
- to use this option with gitlink:git-log(1) and friends.
+ external diff driver with gitlink:gitattributes[5], you need
+ to use this option with gitlink:git-log[1] and friends.
--no-ext-diff::
Disallow external diff drivers.
--
1.5.3.3.127.g40d17
^ permalink raw reply related
* Re: git clone questions relating to cpio
From: Johannes Sixt @ 2007-10-02 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Reece Dunn, Git
In-Reply-To: <7vwsu6pg0v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Mon, 1 Oct 2007, Reece Dunn wrote:
>>
>>> I am running a Linux From Scratch 6.2 system that does not have cpio
>>> installed on it. This means that I can't clone a local repository
>>> unless I install cpio.
>> You might be interested in the workaround Hannes did in mingw.git; he made
>> a wrapper script called 'cpio' using 'tar'.
>
> I think that may be good enough as workaround, but I do not
> think you would get the space saving from hardlinks that way.
FWIW, I'm thinking about changing the cpio -p (passthrough) part to use
'cp -l --parents --target-directory=...' instead of tar; this gives us hard
links, even on NTFS. But it needs GNU's cp, of course.
-- Hannes
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-10-02 6:10 UTC (permalink / raw)
To: git
In-Reply-To: <20071002051332.GA4462@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Oct 02, 2007 at 01:08:20AM -0400, Jeff King wrote:
>
>> One approach which I haven't tried but might be promising is to actually
>> keep each list sorted, and then do a "merge" of the two lists, comparing
>> as you go. We don't really need to do arbitrary lookups in the hash; we
>> just need to compare two hash tables at a time. My approach was to be
>> simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
>> order of 2^17), and that's clearly just too big. But with a list merge,
>> it should be O(n), where n is the actual number of lines in the files
>> (or binary chunks for the binary case).
>
> BTW, I don't want to steal credit for this idea...it comes from thinking
> about what David Kastrup said earlier in the thread, though I think he
> was proposing sorting just inside buckets.
Yes: my proposal was about a microoptimization: work with the
basically existing data structures and put the already contained
information to best use.
I have not actually looked at the actual task that the structures are
going to be used in, and whether "reusing" the information is likely
to be worth the trouble.
When we are talking about buzzword compliance, "keep sorted" with the
meaning of "maintain sorted across modifications" has an O(n^2) or at
least O(nm) ring to it. However, if it is possible to sort it just
once, and then then only merge with other lists...
I am actually quite a fan of merge sort and have even posted a small
and quite efficient version to this list once. However, merge sorts
were really greatest at the time when cache memory was unusual to
have. Nowadays, quicksort or similar could be faster due to better
locality of memory accesses. I think the glibc qsort more or less
uses an array-based merge into a separate memory area (unless it runs
out of memory in which case it resorts to regular quicksort).
--
David Kastrup
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-10-02 5:53 UTC (permalink / raw)
To: git
In-Reply-To: <7vfy11yyxk.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
----------------------------------------------------------------
* ph/strbuf (Thu Sep 27 13:33:19 2007 +0200) 44 commits
+ Make read_patch_file work on a strbuf.
+ strbuf_read_file enhancement, and use it.
+ strbuf change: be sure ->buf is never ever NULL.
+ double free in builtin-update-index.c
+ Clean up stripspace a bit, use strbuf even more.
+ Add strbuf_read_file().
...
Will be in 'master' soon. We've seen nice linecount reduction
and the end result is rather pleasant to read.
* jc/am-quiet (Mon Oct 1 00:27:51 2007 -0700) 2 commits
+ git-am: fix typo in the previous one.
+ git-am: make the output quieter.
Response against recent "rebase being too chatty" complaints.
This should be a 'master' material.
* ap/dateformat (Fri Sep 28 15:17:45 2007 +0100) 3 commits
+ Make for-each-ref's grab_date() support per-atom formatting
+ Make for-each-ref allow atom names like "<name>:<something>"
+ parse_date_format(): convert a format name to an enum date_mode
With some test suite additions, this could go to 'master' soon.
Yes, that's a HINT, people ;-).
* je/hooks (Wed Sep 26 15:31:01 2007 -0600) 1 commit
+ post-checkout hook, tests, and docs
Will be in 'master' soon.
* db/fetch-pack (Mon Oct 1 00:59:39 2007 +0100) 49 commits
+ fetch/push: readd rsync support
+ Introduce remove_dir_recursively()
+ bundle transport: fix an alloc_ref() call
+ Allow abbreviations in the first refspec to be merged
+ Prevent send-pack from segfaulting when a branch doesn't match
+ Cleanup unnecessary break in remote.c
...
Has been cooking for quite long time.
There was a regression that made me quite unhappy about the
rewrite, but Daniel fixed it, so I should be happy. There is
another usability regression: http transport is now totally
silent. Even when you fetch daily, if the other end frequently
repacks everything into one big ball of wax like repo.or.cz
does, you will end up transferring quite a large pack every
time, and the total lack of progress report is unacceptably
unnerving. At least we should reinstate "Fetching blah from URL
using http", and preferrably "walk $object_name" lines. The
latter could be replaced with just series of CR + "walked N
commits..." if we do not like many output from the current "walk
$object_name" lines scrolling the other information away.
I am not sure the quality of "rsync" transport near the tip,
either, but at least the change should not affect other
transports. Nobody should using about rsync transport these
days anyway. Perhaps we should put a deprecation notice in the
release notes to 1.5.4, and remove it three months later.
* jc/autogc (Mon Sep 17 00:55:13 2007 -0700) 10 commits
+ git-gc --auto: run "repack -A -d -l" as necessary.
+ git-gc --auto: restructure the way "repack" command line is built.
+ git-gc --auto: protect ourselves from accumulated cruft
+ git-gc --auto: add documentation.
+ git-gc --auto: move threshold check to need_to_gc() function.
+ repack -A -d: use --keep-unreachable when repacking
+ pack-objects --keep-unreachable
+ Export matches_pack_name() and fix its return value
+ Invoke "git gc --auto" from commit, merge, am and rebase.
+ Implement git gc --auto
I think this one is reasonably sane, but I was the one who wrote
it so people should take that with a grain of salt. What it is
and isn't:
- "gc --auto" is a way to prevent you from keeping your
repository _grossly_ inefficient. Ideally, if you ever
rapacked your repository once, and do the regular repository
maintenance ("'git gc' before you leave for lunch every other
day"), it should never trigger.
- "gc --auto" is not something you can background. We do not
want to lock the repository and worry about associated stale
lock, expiry etc. The complexity is not worth it, compared
to the stated purpose above (I suspect it might already be
safe to run multiple instances at the same time, but the
effort to analyze if it is is not even worth, compared to the
stated purpose above. Just let it run synchronously if it
triggers, but it should not trigger for you).
* js/rebase-i (Tue Sep 25 16:43:15 2007 +0100) 1 commits
+ rebase -i: work on a detached HEAD
Will be in 'master', together with "gc --auto", soon.
* mv/unknown (Tue Sep 25 16:38:46 2007 +0200) 1 commit
+ Don't use "<unknown>" for placeholders and suppress printing of
empty user formats.
Will be in 'master' soon.
* lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
+ git-merge: add --ff and --no-ff options
+ git-merge: add support for --commit and --no-squash
+ git-merge: add support for branch.<name>.mergeoptions
+ git-merge: refactor option parsing
+ git-merge: fix faulty SQUASH_MSG
+ Add test-script for git-merge porcelain
Will be in 'master' soon.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
Instead of refusing to rebase, telling you that your work tree
is dirty, this stashes your local changes, runs rebase and then
unstashes automatically. That _sounds_ nicer and easier to use,
but I am not sure if it is a wise/sane thing to do. We may want
to revert the "autostash" from rebase. Opinions?
* kh/commit (Mon Sep 17 20:06:47 2007 -0400)
+ Export rerere() and launch_editor().
+ Introduce entry point add_interactive and add_files_to_cache
+ Clean up stripspace a bit, use strbuf even more.
+ Add strbuf_read_file().
+ rerere: Fix use of an empty strbuf.buf
+ Small cache_tree_write refactor.
...
Stalled.
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
Stalled. This is about my pet-peeve that log (diff-tree) family
has much limited pathspec semantics. It should learn to glob
like ls-files and grep do.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-10-02 5:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vhclhyyxw.fsf@gitster.siamese.dyndns.org>
There are a few usability fixes to 'maint' after 1.5.3.3 but
nothing worth doing 1.5.3.4 for yet.
On the 'master' front, handful topics that have been cooking in
'next' have been merged, to be part of 1.5.4. Notable are:
* "git-remote rm"
* "git-send-email --smtp-server-port"
* "git-svn" futureproofing.
There are many changes cooking in 'next' that will graduate to
'master' real soon now. It would probably be a good idea to
slow down and cut 1.5.4 early without aiming to have anything
with huge user visible changes once that happens, because there
are two rather big topics mostly about the implementation and
not about user experience (other than performance gain of fetch
in a repository with insane number of refs).
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.3.3
Andy Parkins (1):
post-receive-hook: Remove the From field from the generated email
header so that the pusher's name is used
Jari Aalto (1):
git-remote: exit with non-zero status after detecting errors.
Jean-Luc Herren (2):
git-add--interactive: Allow Ctrl-D to exit
git-add--interactive: Improve behavior on bogus input
Johannes Schindelin (1):
rebase -i: squash should retain the authorship of the _first_
commit
Junio C Hamano (1):
Whip post 1.5.3.3 maintenance series into shape.
Miklos Vajna (1):
git stash: document apply's --index switch
* The 'master' branch has these since the last announcement
in addition to the above.
Alexandre Julliard (4):
git.el: Preserve file marks when doing a full refresh.
git.el: Do not print a status message on every git command.
git.el: Update a file status in the git buffer upon save.
git.el: Reset the permission flags when changing a file state.
Daniel Barkalow (1):
Fix adding a submodule with a remote url
James Bowes (2):
remote: add 'rm' subcommand
remote: document the 'rm' subcommand
Jari Aalto (1):
git-remote: exit with non-zero status after detecting error in
"rm".
Jeff King (1):
diffcore-rename: cache file deltas
Johannes Schindelin (1):
rebase -i: support single-letter abbreviations for the actions
Junio C Hamano (3):
git-remote rm: add tests and minor fix-ups
send-email --smtp-server-port: allow overriding the default port
Update stale documentation link in the k.org site
Mark Levedahl (1):
git-submodule - allow a relative path as the subproject url
Sam Vilain (3):
git-svn: fix test for trunk svn (commit message not needed)
git-svn: fix test for trunk svn (transaction out of date)
git-svn: handle changed svn command-line syntax
Stefan Sperling (1):
Fix pool handling in git-svnimport to avoid memory leaks.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-02 5:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20071002050820.GA4261@coredump.intra.peff.net>
On Tue, Oct 02, 2007 at 01:08:20AM -0400, Jeff King wrote:
> One approach which I haven't tried but might be promising is to actually
> keep each list sorted, and then do a "merge" of the two lists, comparing
> as you go. We don't really need to do arbitrary lookups in the hash; we
> just need to compare two hash tables at a time. My approach was to be
> simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
> order of 2^17), and that's clearly just too big. But with a list merge,
> it should be O(n), where n is the actual number of lines in the files
> (or binary chunks for the binary case).
BTW, I don't want to steal credit for this idea...it comes from thinking
about what David Kastrup said earlier in the thread, though I think he
was proposing sorting just inside buckets.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-02 5:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl4up0tf.fsf@gitster.siamese.dyndns.org>
On Mon, Oct 01, 2007 at 10:01:16PM -0700, Junio C Hamano wrote:
> > Just to update, I tried using a non-colliding hash for this (at the
> > expense of much memory), and I wasn't able to get things much faster
> > (and certainly not worth the explosion in memory), short of reducing the
> > size of the hash (which is going to reduce the quality of the output).
> > So I am giving up for the time being, but if others are interested in
> > trying to speed things up, I would be happy to discuss ideas.
>
> Bummer. You are giving up at the same place I gave up the last
> time. I was somehow hoping that other people are more clever
> and determined than I was ;-).
>
> Thanks for trying.
What was so discouraging is that I literally simplified the process to
for(i = 0; i < HASH_SIZE; i++)
if(src[i] < dst[i])
...
and it spent all of the time on that one conditional.
One approach which I haven't tried but might be promising is to actually
keep each list sorted, and then do a "merge" of the two lists, comparing
as you go. We don't really need to do arbitrary lookups in the hash; we
just need to compare two hash tables at a time. My approach was to be
simple, but have O(HASH_SIZE) comparisons (where HASH_SIZE is on the
order of 2^17), and that's clearly just too big. But with a list merge,
it should be O(n), where n is the actual number of lines in the files
(or binary chunks for the binary case).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-10-02 5:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071002041652.GA32133@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Just to update, I tried using a non-colliding hash for this (at the
> expense of much memory), and I wasn't able to get things much faster
> (and certainly not worth the explosion in memory), short of reducing the
> size of the hash (which is going to reduce the quality of the output).
> So I am giving up for the time being, but if others are interested in
> trying to speed things up, I would be happy to discuss ideas.
Bummer. You are giving up at the same place I gave up the last
time. I was somehow hoping that other people are more clever
and determined than I was ;-).
Thanks for trying.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-02 4:16 UTC (permalink / raw)
To: git
In-Reply-To: <20070927023633.GA28902@coredump.intra.peff.net>
On Wed, Sep 26, 2007 at 10:36:33PM -0400, Jeff King wrote:
> > * jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
> > + diffcore-rename: cache file deltas
> >
> > Parked in 'next' for now but is 'master' material.
>
> My tests after this patch show that spanhash_find is responsible for
> a large portion of the processing time in large renames, so I am going
> to look into speeding that up.
Just to update, I tried using a non-colliding hash for this (at the
expense of much memory), and I wasn't able to get things much faster
(and certainly not worth the explosion in memory), short of reducing the
size of the hash (which is going to reduce the quality of the output).
So I am giving up for the time being, but if others are interested in
trying to speed things up, I would be happy to discuss ideas.
-Peff
^ 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