* Re: (class=ham score=-4.96032) memmem.c improvement
From: Christian Thaeter @ 2007-12-01 2:30 UTC (permalink / raw)
To: Tor Myklebust; +Cc: libc-alpha, git
In-Reply-To: <Pine.LNX.4.64.0711301954370.9426@caffeine.csclub.uwaterloo.ca>
Tor Myklebust wrote:
> On Sat, 1 Dec 2007, Christian Thaeter wrote:
>
>> Short story, 'memmem()' is a gnuish, nonstandard function. I wanted to
>> provide a generic fallback in some code. So, lets borrow it somewhere
>> else:
>>
>> First looking at git's compat/memmem.c which I found was suboptimal
>> with roughly O(M*N) performance (albeit ok for that case since it was
>> just a generic fallback).
>>
>> Well, second taking a look at glibc's source surprised me, there is
>> the same code as in git. I somewhat expected a faster implementation
>> from a generic C library.
>
> I don't think anybody involved with glibc really feels like having
> strstr() (or memmem(), for that matter) go fast. (The grounds I heard
> were that "applications requiring large searches are more likely to have
> own fast string search implementations.')
>
>> That thought and done, the code is attached to this mail. The
>> algorithm is similar to the Rabin/Karp method for string searches but
>> uses a weaker and simpler additive rolling hash.
>
> There are rolling hashes based on arithmetic in fields of order 2^k.
> These can typically be computed using a bunch of bit-shifts and
> additions; have you tried using one? There are lots of irreducible
> polynomials over Z_2 of degree k, so you can even fall back to a
> different one every few false positives.
>
>> The result is still somewhat like O(M+N) for most cases
>
> I don't think you get linear performance in the average case. (But I do
> think you shave a factor of 256 off of the quadratic term. The same
> algorithm, where your hash function is the population count, gives a
> collision between two random strings of length m with probability
> sum_(i=0)^m (m choose i)^2 / 4^m, which grows like sqrt(m). Your
> algorithm helps this by a factor of 256.)
...
>
>> (There may be corner cases where it not that good, but its really hard
>> to imagine those).
>
> The needle "1100110011001100...1100" and the haystack
> "10101010101010...10" will produce quite a few false matches with your
> hash function (simply because every substring of the haystack of the
> appropriate length has the same hash as your needle). (Making the
> needle "1010101010...101100" makes it even worse.)
I am fully aware that this is not the best possible search algorithm. It
is considerably better than the actual one for 'common' data. Having a
string with few symbols or other corner cases needs an algorithm better
suited for that task. But well, this was just reaching a low hanging
fruit. I just wanted to share it because it is better than the algorithm
which is in git and glibc, feel free to submit a even better one or keep
the old one, whatever. For me it suffices and I won't put more efforts
into improving or lobbying it, its just not worth it.
Christian
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-12-01 2:05 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5o6jbq9.fsf@gitster.siamese.dyndns.org>
* The 'maint' branch has these fixes since the last announcement.
J. Bruce Fields (4):
user-manual: define "branch" and "working tree" at start
user-manual: failed push to public repository
user-manual: clarify language about "modifying" old commits
user-manual: recovering from corruption
Jan Hudec (1):
Improve description of git-branch -d and -D in man page.
Jeff King (4):
Add basic cvsimport tests
cvsimport: use rev-parse to support packed refs
cvsimport: miscellaneous packed-ref fixes
cvsimport: fix usage of cvsimport.module
Johannes Schindelin (1):
Replace the word 'update-cache' by 'update-index' everywhere
Johannes Sixt (1):
t7003-filter-branch: Fix test of a failing --msg-filter.
Junio C Hamano (1):
scripts: do not get confused with HEAD in work tree
* The 'master' branch has these since the last announcement
in addition to the above.
André Goddard Rosa (2):
Print the real filename that we failed to open.
Error out when user doesn't have access permission to the repository
Jakub Narebski (1):
Add config_int() method to the Git perl module
Jeff King (1):
Revert "t5516: test update of local refs on push"
Johannes Schindelin (4):
filter-branch: fix dirty way to provide the helpers to commit filters
git checkout's reflog: even when detaching the HEAD, say from where
bash completion: add diff options
receive-pack: allow deletion of corrupt refs
Junio C Hamano (3):
revert/cherry-pick: do not mention the original ref
dir.c: minor clean-up
per-directory-exclude: lazily read .gitignore files
Linus Torvalds (2):
Fix a pathological case in git detecting proper renames
Fix a pathological case in git detecting proper renames
Pascal Obry (1):
git-stash: do not get fooled with "color.diff = true"
Steffen Prohaska (2):
Use is_absolute_path() in diff-lib.c, lockfile.c, setup.c, trace.c
sha1_file.c: Fix size_t related printf format warnings
Wincent Colaiuta (1):
Fix typo in draft 1.5.4 release notes
^ permalink raw reply
* Re: (class=ham score=-4.96032) memmem.c improvement
From: Tor Myklebust @ 2007-12-01 1:58 UTC (permalink / raw)
To: Christian Thaeter; +Cc: libc-alpha, git
In-Reply-To: <4750AF4F.6090207@pipapo.org>
On Sat, 1 Dec 2007, Christian Thaeter wrote:
> Short story, 'memmem()' is a gnuish, nonstandard function. I wanted to
> provide a generic fallback in some code. So, lets borrow it somewhere
> else:
>
> First looking at git's compat/memmem.c which I found was suboptimal with
> roughly O(M*N) performance (albeit ok for that case since it was just a
> generic fallback).
>
> Well, second taking a look at glibc's source surprised me, there is the
> same code as in git. I somewhat expected a faster implementation from a
> generic C library.
I don't think anybody involved with glibc really feels like having
strstr() (or memmem(), for that matter) go fast. (The grounds I heard
were that "applications requiring large searches are more likely to have
own fast string search implementations.')
> That thought and done, the code is attached to this mail. The algorithm
> is similar to the Rabin/Karp method for string searches but uses a
> weaker and simpler additive rolling hash.
There are rolling hashes based on arithmetic in fields of order 2^k.
These can typically be computed using a bunch of bit-shifts and additions;
have you tried using one? There are lots of irreducible polynomials over
Z_2 of degree k, so you can even fall back to a different one every few
false positives.
> The result is still somewhat like O(M+N) for most cases
I don't think you get linear performance in the average case. (But I do
think you shave a factor of 256 off of the quadratic term. The same
algorithm, where your hash function is the population count, gives a
collision between two random strings of length m with probability
sum_(i=0)^m (m choose i)^2 / 4^m, which grows like sqrt(m). Your
algorithm helps this by a factor of 256.)
> (There may be corner cases where it not that good, but its really hard
> to imagine those).
The needle "1100110011001100...1100" and the haystack
"10101010101010...10" will produce quite a few false matches with your
hash function (simply because every substring of the haystack of the
appropriate length has the same hash as your needle). (Making the needle
"1010101010...101100" makes it even worse.)
> Anyways, it is always faster than the current implementation,
Try the example above. (Your code also needs a "return NULL;" at the end,
by the way.)
> in my tests with common data (parsing multipart/form-data cgi responses)
> it yields approx 20%-100% improvements and with little artificial
> cheating (having strings in haystack which only differ at the last char
> of needle) the improvements are much better (500%, since is another
> complexity class). The fact is that the old implementation does a brute
> force search which has corner cases which are quite easy to hit
> (repeating symbol sequences, small set of possible symbols) while for my
> implementation the corner cases are much more rare and even then, it
> will still perform better than the old implementation.
The old implementation is about 50% faster than yours in the example
above.
> The code is not much more complex as the old one, not the original
> 'Rabin/Karp' algorithm because that would require a efficient modulo
> operation with a prime number which might be slower on some platforms
> (just a guess, I didn't even tried, the performance satisfies me
> perfectly).
Karp-Rabin with hashing done mod a prime is an impractical string matching
algorithm.
> Other search algorithms like 'Knuth/Morris/Pratt'
A KMP-like algorithm can be implemented in a way that uses constant
additional space. For unordered alphabets, it's called "Galil-Seiferas"
and for ordered alphabets the analogous algorithm is to decompose (in
linear time and constant space) the string into its lexicographically
largest suffix and some prefix. Then you look for the suffix. Everywhere
where the suffix appears and appears at least prefix-length later than the
last occurrence of the suffix, you check for the prefix.
> or 'Boyer/More' are more complex to implement and require O(Needle)
> extra memory
There are variants of both that require constant additional space. (They
also perform way better than anything else I've seen.)
> for common implementations, which reserve them for special purposes imo.
> I just wanted to keep it simple but still considerably better than the
> current one.
As it happens, the extra space consumed by the KMP and suffix shift tables
(and the associated bad cache effects) make the usual KMP and Boyer-Moore
way, way slower than naive string matching on random inputs.
^ permalink raw reply
* [PATCH] gitweb: Try harder in parse_tag; perhaps it was given ambiguous name
From: Jakub Narebski @ 2007-12-01 1:47 UTC (permalink / raw)
To: git; +Cc: Guillaume Seguin
In-Reply-To: <200712010245.29204.jnareb@gmail.com>
If parse_tag was given ambiguous name, i.e. name which is both head
(branch) name and tag name, parse_tag failed because git prefer heads
to tags if there is ambiguity. Now it tries harder: if git-cat-file
doesn't produce output, try to resolve argument as tag name using
git-show-ref.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This supplements previous patch; while previous modified links to always
use unambiguous name, this one makes 'tag' view work even if passed
ambiguous name which is both name of head and of tag.
gitweb/gitweb.perl | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6ff4221..0427290 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1876,6 +1876,18 @@ sub parse_tag {
my @comment;
open my $fd, "-|", git_cmd(), "cat-file", "tag", $tag_id or return;
+ # try harder in case there is head (branch) with the same name as tag
+ if (eof($fd)) {
+ close $fd or return;
+ my $git_command = git_cmd_str();
+ $tag_id = qx($git_command show-ref --hash --tags $tag_id);
+ return unless $tag_id;
+ open $fd, "-|", git_cmd(), "cat-file", "tag", $tag_id or return;
+ if (eof($fd)) {
+ close $fd;
+ return;
+ };
+ }
$tag{'id'} = $tag_id;
while (my $line = <$fd>) {
chomp $line;
--
1.5.3.6
^ permalink raw reply related
* [PATCH] gitweb: disambiguate heads and tags withs the same name
From: Jakub Narebski @ 2007-12-01 1:45 UTC (permalink / raw)
To: git; +Cc: Guillaume Seguin
Avoid wrong disambiguation that would link logs/trees of tags and heads which
share the same name to the same page, leading to a disambiguation that would
prefer the tag, thus making it impossible to access the corresponding
head log and tree without hacking the url by hand.
It does it by using full refname (with 'refs/heads/' or 'refs/tags/' prefix)
instead of shortened one in the URLs in 'heads' and 'tags' tables.
Signed-off-by: Guillaume Seguin <guillaume@segu.in>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This does exactly the same as patch send by Guillaume Seguin earlier
Message-ID: <1194126032.15420.4.camel@ed3n-m>
http://permalink.gmane.org/gmane.comp.version-control.git/63317
Original patch added 'refs/heads/' and 'refs/tags/' in git_heads_body
and git_tags_body respectively; this one uses 'fullname' field, which
contain refname before stripping 'refs/heads/' or 'refs/tags/'. The
change is in git_get_heads_list and git_get_tags_list, respectively.
Original patch was either badly whitespace damaged, or GMane has
broken 'raw' display.
Note that this patch does not help handcrafted URLs, and saved URLs from
older version of gitweb.
gitweb/gitweb.perl | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 491a3f4..6ff4221 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2234,6 +2234,7 @@ sub git_get_heads_list {
my ($hash, $name, $title) = split(' ', $refinfo, 3);
my ($committer, $epoch, $tz) =
($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
+ $ref_item{'fullname'} = $name;
$name =~ s!^refs/heads/!!;
$ref_item{'name'} = $name;
@@ -2271,6 +2272,7 @@ sub git_get_tags_list {
my ($id, $type, $name, $refid, $reftype, $title) = split(' ', $refinfo, 6);
my ($creator, $epoch, $tz) =
($creatorinfo =~ /^(.*) ([0-9]+) (.*)$/);
+ $ref_item{'fullname'} = $name;
$name =~ s!^refs/tags/!!;
$ref_item{'type'} = $type;
@@ -3691,8 +3693,8 @@ sub git_tags_body {
"<td class=\"link\">" . " | " .
$cgi->a({-href => href(action=>$tag{'reftype'}, hash=>$tag{'refid'})}, $tag{'reftype'});
if ($tag{'reftype'} eq "commit") {
- print " | " . $cgi->a({-href => href(action=>"shortlog", hash=>$tag{'name'})}, "shortlog") .
- " | " . $cgi->a({-href => href(action=>"log", hash=>$tag{'name'})}, "log");
+ print " | " . $cgi->a({-href => href(action=>"shortlog", hash=>$tag{'fullname'})}, "shortlog") .
+ " | " . $cgi->a({-href => href(action=>"log", hash=>$tag{'fullname'})}, "log");
} elsif ($tag{'reftype'} eq "blob") {
print " | " . $cgi->a({-href => href(action=>"blob_plain", hash=>$tag{'refid'})}, "raw");
}
@@ -3727,13 +3729,13 @@ sub git_heads_body {
$alternate ^= 1;
print "<td><i>$ref{'age'}</i></td>\n" .
($curr ? "<td class=\"current_head\">" : "<td>") .
- $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'name'}),
+ $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'fullname'}),
-class => "list name"},esc_html($ref{'name'})) .
"</td>\n" .
"<td class=\"link\">" .
- $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'name'})}, "shortlog") . " | " .
- $cgi->a({-href => href(action=>"log", hash=>$ref{'name'})}, "log") . " | " .
- $cgi->a({-href => href(action=>"tree", hash=>$ref{'name'}, hash_base=>$ref{'name'})}, "tree") .
+ $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'fullname'})}, "shortlog") . " | " .
+ $cgi->a({-href => href(action=>"log", hash=>$ref{'fullname'})}, "log") . " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$ref{'fullname'}, hash_base=>$ref{'name'})}, "tree") .
"</td>\n" .
"</tr>";
}
--
1.5.3.6
^ permalink raw reply related
* memmem.c improvement
From: Christian Thaeter @ 2007-12-01 0:48 UTC (permalink / raw)
To: libc-alpha, git
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
Short story, 'memmem()' is a gnuish, nonstandard function. I wanted to
provide a generic fallback in some code. So, lets borrow it somewhere else:
First looking at git's compat/memmem.c which I found was suboptimal with
roughly O(M*N) performance (albeit ok for that case since it was just a
generic fallback).
Well, second taking a look at glibc's source surprised me, there is the
same code as in git. I somewhat expected a faster implementation from a
generic C library.
That thought and done, the code is attached to this mail. The algorithm
is similar to the Rabin/Karp method for string searches but uses a
weaker and simpler additive rolling hash. The result is still somewhat
like O(M+N) for most cases (There may be corner cases where it not that
good, but its really hard to imagine those). Anyways, it is always
faster than the current implementation, in my tests with common data
(parsing multipart/form-data cgi responses) it yields approx 20%-100%
improvements and with little artificial cheating (having strings in
haystack which only differ at the last char of needle) the improvements
are much better (500%, since is another complexity class). The fact is
that the old implementation does a brute force search which has corner
cases which are quite easy to hit (repeating symbol sequences, small set
of possible symbols) while for my implementation the corner cases are
much more rare and even then, it will still perform better than the old
implementation.
The code is not much more complex as the old one, not the original
'Rabin/Karp' algorithm because that would require a efficient modulo
operation with a prime number which might be slower on some platforms
(just a guess, I didn't even tried, the performance satisfies me
perfectly). Other search algorithms like 'Knuth/Morris/Pratt' or
'Boyer/More' are more complex to implement and require O(Needle) extra
memory for common implementations, which reserve them for special
purposes imo. I just wanted to keep it simple but still considerably
better than the current one.
Feel free to use the code in glibc and/or git.
Christian
[-- Attachment #2: memmem.c --]
[-- Type: text/x-csrc, Size: 2251 bytes --]
/* Copyright (C) 1991,92,93,94,96,97,98,2000,2004 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA. */
#include <stddef.h>
#include <string.h>
#ifndef _LIBC
# define __builtin_expect(expr, val) (expr)
#endif
#undef memmem
/* Return the first occurrence of NEEDLE in HAYSTACK. */
void *
memmem (haystack, haystack_len, needle, needle_len)
const void *haystack;
size_t haystack_len;
const void *needle;
size_t needle_len;
{
/* not really Rabin-Karp, just using additive hashing */
char* haystack_ = (char*)haystack;
char* needle_ = (char*)needle;
int hash = 0; /* this is the static hash value of the needle */
int hay_hash = 0; /* rolling hash over the haystack */
char* last;
size_t i;
if (haystack_len < needle_len)
return NULL;
if (!needle_len)
return haystack_;
/* initialize hashes */
for (i = needle_len; i; --i)
{
hash += *needle_++;
hay_hash += *haystack_++;
}
/* iterate over the haystack */
haystack_ = (char*)haystack;
needle_ = (char*)needle;
last = haystack_+(haystack_len - needle_len + 1);
for (; haystack_ < last; ++haystack_)
{
if (__builtin_expect(hash == hay_hash, 0) &&
*haystack_ == *needle_ && /* prevent calling memcmp, was a optimization from existing glibc */
!memcmp (haystack_, needle_, needle_len))
return haystack_;
/* roll the hash */
hay_hash -= *haystack_;
hay_hash += *(haystack_+needle_len);
}
return NULL;
}
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Michael Witten @ 2007-12-01 0:19 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Junio C Hamano, Johannes Schindelin
In-Reply-To: <47500F0B.10300@viscovery.net>
On 30 Nov 2007, at 8:24:27 AM, Johannes Sixt wrote:
>> The difference is that it puts objects in place
>> by hand, requiring the code to mirror hook calls
>> anyway.
>> I'm simply proposing that the code be reworked,
>> so that cvs commits actually become git pushes,
>> so that all future changes to the pushing mechanism
>> are automatically handled.
>
> But in order push something, you must first have the commit in a
> repository. How would git-cvsserver do that? For example, by
> putting objects in place by hand. You gain nothing, except that it
> would push instead of call the hooks directly.
"The difference is that it puts objects in place
by hand, requiring the code to mirror hook calls
anyway."
As far as I can tell, hook calls are the only thing.
However, I still had to write a patch to include post-receive;
by doing everything by hand, git-cvsserver is inherently unsafe
and incomplete over time.
The question is not the RESULT, but HOW YOU GET that result;
the current design is---essentially---a hack; it is written
in perl, after all ;-P
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-30 23:38 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Santi B?jar, Steffen Prohaska, Junio C Hamano,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130232127.GA3169@sigill.intra.peff.net>
Hi,
On Fri, 30 Nov 2007, Jeff King wrote:
> On Fri, Nov 30, 2007 at 11:05:50PM +0000, Johannes Schindelin wrote:
>
> > > > > alias_command = (*argv)[0];
> > > > > git_config(git_alias_config);
> > > > > + if (!alias_string)
> > > > > + alias_string = builtin_alias(alias_command);
> > > > > if (alias_string) {
> > > > > if (alias_string[0] == '!') {
> > > > > if (*argcp > 1) {
> > > >
> > > > Didn't you mean to put this _before_ the git_config() call? As you wrote
> > > > it, the "soft" alias overrides the user-specified one.
> > >
> > > No. The "if (!alias_string)" means we only do the lookup if no user
> > > alias was found. Try it.
> >
> > Ah. To me, that was rather easy to miss, though...
>
> I don't particularly care if it is re-written as:
>
> alias_string = builtin_alias(alias_command);
> git_config(git_alias_config);
>
> which should be equivalent. I wrote it the original way to avoid doing
> the O(n) search through builtin aliases when it was unnecessary, but
> obviously this isn't a performance critical code path.
Actually, I felt/feel quite dumb missing it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 23:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Santi B?jar, Steffen Prohaska, Junio C Hamano,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0711302305300.27959@racer.site>
On Fri, Nov 30, 2007 at 11:05:50PM +0000, Johannes Schindelin wrote:
> > > > alias_command = (*argv)[0];
> > > > git_config(git_alias_config);
> > > > + if (!alias_string)
> > > > + alias_string = builtin_alias(alias_command);
> > > > if (alias_string) {
> > > > if (alias_string[0] == '!') {
> > > > if (*argcp > 1) {
> > >
> > > Didn't you mean to put this _before_ the git_config() call? As you wrote
> > > it, the "soft" alias overrides the user-specified one.
> >
> > No. The "if (!alias_string)" means we only do the lookup if no user
> > alias was found. Try it.
>
> Ah. To me, that was rather easy to miss, though...
I don't particularly care if it is re-written as:
alias_string = builtin_alias(alias_command);
git_config(git_alias_config);
which should be equivalent. I wrote it the original way to avoid doing
the O(n) search through builtin aliases when it was unnecessary, but
obviously this isn't a performance critical code path.
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-30 23:10 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Andreas Ericsson, Nicolas Pitre, Linus Torvalds,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130212500.GB25946@coredump.intra.peff.net>
Hi,
On Fri, 30 Nov 2007, Jeff King wrote:
> On Fri, Nov 30, 2007 at 12:01:13PM -0800, Junio C Hamano wrote:
>
> > I already can see exchanges in the user community after such a change
> > you propose would happen:
> > [...]
> > Jeff: If you really like that, here is a hidden trick. Add
> > /usr/libexec/git-core/ to your PATH.
>
> What if I promise not to tell anyone? :)
By the same reasoning you can invade an unsuspecting country, saying that
everybody will be better off afterwards. But the risk is high, not
because of the probability, but because of the cost to pay if it does not
work out.
Really, I'd rather have this be done right. So I am quite happy with
Junio being "girly" (which I would have called cautious and nice-to-users,
as well as considerate, though).
In the end I would be so much happier not to have hard links at all,
and it seems that all the "easy" SCMs out there are quite well off without
hard links, too.
To me, it is mighty annoying anybody brings up that "144 commands"
argument Linus was referring to, and if there is _any_ way to shut up
those bikeshedders, I am all for it.
But if that is not possible, so be it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-30 23:05 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Santi B?jar, Steffen Prohaska, Junio C Hamano,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130183755.GA29382@sigill.intra.peff.net>
Hi,
On Fri, 30 Nov 2007, Jeff King wrote:
> On Fri, Nov 30, 2007 at 06:28:50PM +0000, Johannes Schindelin wrote:
>
> > > @@ -162,6 +169,8 @@ static int handle_alias(int *argcp, const char ***argv)
> > >
> > > alias_command = (*argv)[0];
> > > git_config(git_alias_config);
> > > + if (!alias_string)
> > > + alias_string = builtin_alias(alias_command);
> > > if (alias_string) {
> > > if (alias_string[0] == '!') {
> > > if (*argcp > 1) {
> >
> > Didn't you mean to put this _before_ the git_config() call? As you wrote
> > it, the "soft" alias overrides the user-specified one.
>
> No. The "if (!alias_string)" means we only do the lookup if no user
> alias was found. Try it.
Ah. To me, that was rather easy to miss, though...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] cvsimport: fix usage of cvsimport.module
From: Jeff King @ 2007-11-30 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Emanuele Giaquinta, git
There were two problems:
1. We only look at the config variable if there is no module
given on the command line. We checked this by comparing
@ARGV == 0. However, at the time of the comparison, we
have not yet parsed the dashed options, meaning that
"git cvsimport" would read the variable but "git
cvsimport -a" would not. This is fixed by simply moving
the check after the call to getopt.
2. If the config variable did not exist, we were adding an
empty string to @ARGV. The rest of the script, rather
than barfing for insufficient input, would then try to
import the module '', leading to rather confusing error
messages. Based on patch from Emanuele Giaquinta.
Signed-off-by: Jeff King <peff@peff.net>
---
On Fri, Nov 30, 2007 at 08:33:04PM +0100, Emanuele Giaquinta wrote:
> I found another minor bug in git-cvsimport, which the
> attached patch fixes [...]
Emanuele, thanks for submitting the patch. However, please be sure
to copy the list (git@vger.kernel.org), and please follow
the format described in Documentation/SubmittingPatches.
As it turns out, while checking your patch, I found another
serious error, so I just rolled them together.
git-cvsimport.perl | 8 ++++----
t/t9600-cvsimport.sh | 21 +++++++++++++++++++++
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 321a27e..92648f4 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -108,10 +108,6 @@ sub read_repo_config {
}
}
}
- if (@ARGV == 0) {
- chomp(my $module = `git-repo-config --get cvsimport.module`);
- push(@ARGV, $module);
- }
}
my $opts = "haivmkuo:d:p:r:C:z:s:M:P:A:S:L:";
@@ -119,6 +115,10 @@ read_repo_config($opts);
getopts($opts) or usage();
usage if $opt_h;
+if (@ARGV == 0) {
+ chomp(my $module = `git-repo-config --get cvsimport.module`);
+ push(@ARGV, $module) if $? == 0;
+}
@ARGV <= 1 or usage("You can't specify more than one CVS module");
if ($opt_d) {
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 3338d44..29fee2d 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -98,4 +98,25 @@ test_expect_success 'update git module' '
'
+test_expect_success 'update cvs module' '
+
+ cd module-cvs &&
+ echo 1 >tick &&
+ cvs add tick &&
+ cvs commit -m 1
+ cd ..
+
+'
+
+test_expect_success 'cvsimport.module config works' '
+
+ cd module-git &&
+ git config cvsimport.module module &&
+ git cvsimport -a -z0 &&
+ git merge origin &&
+ cd .. &&
+ git diff module-cvs/tick module-git/tick
+
+'
+
test_done
--
1.5.3.6.2064.g2e22f-dirty
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 21:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Andreas Ericsson, Nicolas Pitre, Linus Torvalds,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <7vve7jqz92.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 30, 2007 at 12:01:13PM -0800, Junio C Hamano wrote:
> I already can see exchanges in the user community after such a change
> you propose would happen:
> [...]
> Jeff: If you really like that, here is a hidden trick. Add
> /usr/libexec/git-core/ to your PATH.
What if I promise not to tell anyone? :)
Anyway, I don't think it will be a problem. You think it might. But I
suspect neither of us has anything more than a gut feeling to argue
with. And now I have registered my complaint, so you can do what you
think is best.
I can, of course, always make my own hardlinks (which is really the same
thing, except the "trick" is slightly harder to perform and perhaps less
socially acceptable; OTOH, if such a trick is common, perhaps it means
taking away the dash forms wasn't such a good idea after all).
> Newbie: Stupid inconsistency. Who suggested that?
Jeff [runs git-blame]: It must have been Junio! :)
-Peff
^ permalink raw reply
* Re:* [Resend PATCH] Fix segmentation fault when user doesn't have access permission to the repository.
From: Junio C Hamano @ 2007-11-30 21:22 UTC (permalink / raw)
To: André Goddard Rosa
Cc: Git Mailing List, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <b8bf37780711251339y796286fbj2cd8d9225008e13@mail.gmail.com>
"André Goddard Rosa" <andre.goddard@gmail.com> writes:
> On Nov 22, 2007 2:09 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> ...
> I tested it here before posting but luckly (or not, as I didn't catch
> this when compiling) it worked,
> as a pointer have the sizeof(int) in my x86 platform. >:|
Most of the changes look trivially correct. Thanks.
> diff --git a/builtin-fetch.c b/builtin-fetch.c
> index be9e3ea..84c8ed4 100644
> --- a/builtin-fetch.c
> +++ b/builtin-fetch.c
> @@ -263,8 +263,13 @@ static void store_updated_refs(const char *url,
> struct ref *ref_map)
> char note[1024];
> const char *what, *kind;
> struct ref *rm;
> + char *filename = git_path("FETCH_HEAD");
>
> - fp = fopen(git_path("FETCH_HEAD"), "a");
> + fp = fopen(filename, "a");
> + if (!fp) {
> + error("cannot open %s: %s\n", filename, strerror(errno));
> + return 1;
> + }
> for (rm = ref_map; rm; rm = rm->next) {
> struct ref *ref = NULL;
I started to wonder if there was a particular reason you chose to return
1, not -1 (or just say 'return error("cannot open...", ...)')?
> @@ -404,7 +410,7 @@ static int fetch_refs(struct transport *transport,
> struct ref *ref_map)
> if (ret)
> ret = transport_fetch_refs(transport, ref_map);
> if (!ret)
> - store_updated_refs(transport->url, ref_map);
> + ret |= store_updated_refs(transport->url, ref_map);
> transport_unlock_pack(transport);
> return ret;
> }
I think the callers of fetch_refs() are interested in seeing only 0 or
non-zero, so it seems more consistent to signal error with negative
return. I modified the hunk that starts at line 263 to return the
return value from error() and applied.
That made me follow the transport code, fetch_refs_via_pack(). This is
not your code, so Shawn and Daniel are CC'ed.
The code calls fetch_pack() to get the list of refs it fetched, and
discards refs and always returns 0 to signal success.
But builtin-fetch-pack.c::fetch_pack() has error cases. The function
returns NULL if error is detected (shallow-support side seems to choose
to die but I suspect that is easily fixable to error out as well).
Shouldn't fetch_refs_via_pack() propagate that error to the caller?
---
transport.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index 50db980..048df1f 100644
--- a/transport.c
+++ b/transport.c
@@ -655,7 +655,7 @@ static int fetch_refs_via_pack(struct transport *transport,
free(heads);
free_refs(refs);
free(dest);
- return 0;
+ return (refs ? 0 : -1);
}
static int git_transport_push(struct transport *transport, int refspec_nr, const char **refspec, int flags)
^ permalink raw reply related
* Re: [PATCH] git-stash: Display help message if git-stash is run without sub-commands
From: David Kastrup @ 2007-11-30 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin Leung, Mike Hommey, Git ML, Nanako Shiraishi
In-Reply-To: <7vr6i7qz6b.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Kevin Leung" <kevinlsk@gmail.com> writes:
>
>> On Nov 30, 2007 4:41 PM, Mike Hommey <mh@glandium.org> wrote:
>>> Still, 'git stash' alone should *do* the stash.
>>>
>>
>> How about `git stash' still does the stash, and `git stash llist'
>> exits with usage message? And if you want to save the stash with name,
>> you can only do it with `git stash save name_of_stash'.
>
> Sounds like a sensible thing to do.
Instead of "save", one could use "stash" since that is what it is
supposed to do. Then
git stash stash stash
would create a stash called "stash".
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] git-stash: Display help message if git-stash is run without sub-commands
From: Junio C Hamano @ 2007-11-30 20:02 UTC (permalink / raw)
To: Kevin Leung; +Cc: Mike Hommey, Git ML, Junio C Hamano, Nanako Shiraishi
In-Reply-To: <e66701d40711300109nc43f3efyb33e591af15a060b@mail.gmail.com>
"Kevin Leung" <kevinlsk@gmail.com> writes:
> On Nov 30, 2007 4:41 PM, Mike Hommey <mh@glandium.org> wrote:
>> Still, 'git stash' alone should *do* the stash.
>>
>
> How about `git stash' still does the stash, and `git stash llist'
> exits with usage message? And if you want to save the stash with name,
> you can only do it with `git stash save name_of_stash'.
Sounds like a sensible thing to do.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Junio C Hamano @ 2007-11-30 20:01 UTC (permalink / raw)
To: Jeff King
Cc: Andreas Ericsson, Nicolas Pitre, Linus Torvalds,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130150948.GA22095@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 30, 2007 at 08:18:16AM +0100, Andreas Ericsson wrote:
> ...
>> It would provide a ui inconsistency between platforms. Several people
>> pointed that out. It's decidedly a Bad Thing.
>
> Which, as I said, I have already addressed (and which Linus has also
> expanded upon in this thread). Since those hardlinks would be hidden
> from users who did not go to some trouble to find them, there will not
> be inconsistency problems.
I already can see exchanges in the user community after such a change
you propose would happen:
Newbie: Ay! why doesn't git-commit work anymore?
Jeff: Stupid Junio and Linus decided that you should not use dash form
but say "git commit" instead.
Newbie: But my fingers are trained and I like the "git-<tab>"
completion.
Jeff: If you really like that, here is a hidden trick. Add
/usr/libexec/git-core/ to your PATH.
Newbie: Ah, that worked, thanks.
A few days later...
Newbie: Jeff, your trick does not work for my coworker. He also has
the latest git. His installation does not even have that
directory! What gives?
Jeff: Ah, sorry, that trick works for some platforms but not others.
Newbie: Stupid inconsistency. Who suggested that?
^ permalink raw reply
* [PATCH] Adding menu for Emacs git.el
From: =?utf-8?q?R=C3=A9mi=20Vanicat?=, Remi Vanicat @ 2007-11-30 19:29 UTC (permalink / raw)
To: git; +Cc: Alexandre Julliard
Adding three menu to the git-status-mode of git.el : One for marking
and unmarking, one for every thing you need when you have a conflict,
and a last one for all the rest.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
---
This use easymenu.
contrib/emacs/git.el | 46 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index e147da0..f41b2ef 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1297,7 +1297,51 @@ Return the list of files that haven't been handled."
(define-key toggle-map "i" 'git-toggle-show-ignored)
(define-key toggle-map "k" 'git-toggle-show-unknown)
(define-key toggle-map "m" 'git-toggle-all-marks)
- (setq git-status-mode-map map)))
+ (setq git-status-mode-map map))
+ (easy-menu-define git-menu-mark git-status-mode-map
+ "Git Merge Menu"
+ `("Merge"
+ ["Next Unmerged File" git-next-unmerged-file t]
+ ["Prev Unmerged File" git-prev-unmerged-file t]
+ ["Mark as Resolved" git-resolve-file t]
+ ["Interctive Merge File" git-find-file-imerge t]
+ ["Diff Against Common Base File" git-diff-file-base t]
+ ["Diff Combined" git-diff-file-combined t]
+ ["Diff Against Merge Head" git-diff-file-merge-head t]
+ ["Diff Against Mine" git-diff-file-mine t]
+ ["Diff Against Other" git-diff-file-other t]))
+ (easy-menu-define git-menu-mark git-status-mode-map
+ "Git Mark Menu"
+ `("Mark"
+ ["Mark File" git-mark-file t]
+ ["Mark All" git-mark-all t]
+ ["Unmark File" git-unmark-file t]
+ ["Unmark All" git-unmark-all t]
+ ["Toggle All Mark" git-toggle-all-marks t]))
+ (easy-menu-define git-menu git-status-mode-map
+ "Git Menu."
+ `("Git"
+ ["Refresh" git-refresh-status t]
+ ["Commit" git-commit-file t]
+ "--------"
+ ["Add File" git-add-file t]
+ ["Revert File" git-revert-file t]
+ ["Ignore File" git-ignore-file t]
+ ["Remove File" git-remove-file t]
+ "--------"
+ ["Find File" git-find-file t]
+ ["View File" git-view-file t]
+ ["Diff File" git-diff-file t]
+ ["Interctive Diff File" git-diff-file-idiff t]
+ ["Log" git-log-file t]
+ "--------"
+ ["Quit" git-status-quit t]
+ "--------"
+ ["Show Uptodate" git-toggle-show-uptodate :style toggle :selected git-show-uptodate]
+ ["Toggle Show Ignored" git-toggle-show-ignored :style toggle :selected git-show-ignored]
+ ["Toggle Show Unknown" git-toggle-show-unknown :style toggle :selected git-show-unknown]))
+
+)
;; git mode should only run in the *git status* buffer
(put 'git-status-mode 'mode-class 'special)
--
1.5.3.6
^ permalink raw reply related
* Re: git-cvsimport bug
From: Emanuele Giaquinta @ 2007-11-30 18:41 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071128185504.GA11236@coredump.intra.peff.net>
On Wed, Nov 28, 2007 at 01:55:04PM -0500, Jeff King wrote:
> 2/3: cvsimport: use show-ref to support packed refs
>
> This fix is hopefully obvious, and the included test fails
> without it (and this should probably fix Emanuele's problem).
It does, thanks!
Emanuele
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 18:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Santi B?jar, Steffen Prohaska, Junio C Hamano,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0711301828050.27959@racer.site>
On Fri, Nov 30, 2007 at 06:28:50PM +0000, Johannes Schindelin wrote:
> > @@ -162,6 +169,8 @@ static int handle_alias(int *argcp, const char ***argv)
> >
> > alias_command = (*argv)[0];
> > git_config(git_alias_config);
> > + if (!alias_string)
> > + alias_string = builtin_alias(alias_command);
> > if (alias_string) {
> > if (alias_string[0] == '!') {
> > if (*argcp > 1) {
>
> Didn't you mean to put this _before_ the git_config() call? As you wrote
> it, the "soft" alias overrides the user-specified one.
No. The "if (!alias_string)" means we only do the lookup if no user
alias was found. Try it.
-Peff
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Jan Hudec @ 2007-11-30 18:34 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jakub Narebski, git, Robin Rosenberg
In-Reply-To: <20071129200710.GA3314@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]
On Thu, Nov 29, 2007 at 21:07:10 +0100, Alex Riesen wrote:
> Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100:
> > + <s id="git">
> > + Medium. There's Git User's Manual, manpages, some
> > + technical documentation and some howtos. All
> > + documentation is also available online in HTML format;
> > + there is additional information (including beginnings
> > + of FAQ) on git wiki.
> > + Nevertheles one of complaints in surveys is insufficient
>
> "Nevertheless" (two "s").
I think it's not amount of documentation that's insufficient, but rather the
organization. The problem is not that the information is not there, but that
it's sometimes not easy to find.
> BTW, I wouldn't call the level of documentation "Medium" when compared
> to any commercial SCM. How can they earn more than "a little", when
> compared to any opensource program?
I don't know that many commercial SCM, but clearcase does have more than "a
little" documentation.
> [...]
>
> > @@ -1106,6 +1165,10 @@ TODO:
> > There exists some HTTP-functionality, but it is quite
> > limited.
> > </s>
> > + <s id="git">
> > + Good. Uses HTTPS (with WebDAV) or ssh for push,
> > + HTTP, FTP, ssh or custom protocol for fetch.
> > + </s>
>
> You forgot bundles (aka SneakerNet).
> Again, compared to everyone else it is "vastly superior" :)
In fact at least darcs and bzr can also do SneakerNet.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-30 18:28 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Santi B?jar, Steffen Prohaska, Junio C Hamano,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130162257.GA22882@coredump.intra.peff.net>
Hi,
On Fri, 30 Nov 2007, Jeff King wrote:
> Support builtin aliases
>
> Builtin aliases are "default" alias values that can be
> overridden by user-configured aliases.
>
> For example, the first such alias is "view", an alias for
> gitk. A user with no further configuration can run
> "git view" to use gitk. However, they can also set the
> config option "alias.view" to "!tig" to run tig.
> ---
> git.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/git.c b/git.c
> index f220284..95296aa 100644
> --- a/git.c
> +++ b/git.c
> @@ -151,6 +151,13 @@ static int split_cmdline(char *cmdline, const char ***argv)
> return count;
> }
>
> +static char *builtin_alias(const char *cmd)
> +{
> + if (!strcmp(cmd, "view"))
> + return xstrdup("!gitk");
> + return NULL;
> +}
> +
> static int handle_alias(int *argcp, const char ***argv)
> {
> int nongit = 0, envchanged = 0, ret = 0, saved_errno = errno;
> @@ -162,6 +169,8 @@ static int handle_alias(int *argcp, const char ***argv)
>
> alias_command = (*argv)[0];
> git_config(git_alias_config);
> + if (!alias_string)
> + alias_string = builtin_alias(alias_command);
> if (alias_string) {
> if (alias_string[0] == '!') {
> if (*argcp > 1) {
Didn't you mean to put this _before_ the git_config() call? As you wrote
it, the "soft" alias overrides the user-specified one.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Marco Costalba @ 2007-11-30 18:25 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <20071130175018.GB30048@efreet.light.src>
On Nov 30, 2007 6:50 PM, Jan Hudec <bulb@ucw.cz> wrote:
>
> Nevertheless, I actually think git-gui is quite well in Tcl/Tk and rewriting
> it in python nor any other language would probably help it in any way.
>
A little provocation: I've never seen in open source a discussion on
what language to use for an application and then the development of
the application from scratch.
What I see daily instead is the effort of one (or a very little number
of people) to develop something in the language he choose and then ,
_after_ some code has been produced, the effort embraced by other
people that join the project.
Some near examples? gitk, gitweb, stgit, git itself especially for
shell parts (why shell should be a better prototyping language then
other prototyping languages? portability? easy to learn? performance?
library support? syntax? probably no one of the above in general
terms).
I would say this thread, although very interesting from a learning
point of view, it's a a little bit academic.
Marco
^ permalink raw reply
* Re: git bug/feature request
From: Jan Hudec @ 2007-11-30 18:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <figv47$926$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
On Tue, Nov 27, 2007 at 12:30:16 +0100, Jakub Narebski wrote:
> gapon wrote:
>
> > hi all,
> > first of all i don't know if there's a bugzilla or something similar
> > for git - i have found just this email (on http://git.or.cz/ webpage).
>
> There isn't any bug tracker for git. Use git mailing list for bug
> reports and feature requests.
>
> > i have discovered "weird" behaviour of git in this scenario*:
> > - user A is working in repo A
> > - user B clones repo A
> > - user B makes some changes, commits, pushes
>
> Do not push into checked out branch!
Push is the only non-local operation, that could break the checked out state,
right? Than it should be possible to add a check that a push is trying to
change the checked-out ref and detach the HEAD if so.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Converting a directory to submodule
From: Paul Sadauskas @ 2007-11-30 17:53 UTC (permalink / raw)
To: git
Dear list,
I'm having some trouble when I change an existing directory in a
project into a submodule. After pushing this change to the origin, I
can no longer pull into any other projects. I can, however, clone the
origin without problems.
These are the steps I take to change the dir into a submod:
rm -rf /submod
git commit -a
git submodule add git://abc/submod submod
git commit
git push
But then attempting to pull this anywhere else results in a
half-completed pull, and dies with the error:
fatal: cannot read object bb138891993fdeb3dbfcb41fe8c2a4693676f8fe
'submod~564e58282ce575db34b6f249a42b1ea59f56efd3'
Merge with strategy recursive failed.
Like I said, though, a fresh clone works fine. Am I doing something
wrong in my push, or is this a bug?
Thanks,
Paul Sadauskas
^ 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