* [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
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Jan Hudec @ 2007-11-30 17:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0711291200000.27959@racer.site>
On Thu, Nov 29, 2007 at 12:01:47 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 29 Nov 2007, Jan Hudec wrote:
>
> > On Wed, Nov 28, 2007 at 23:48:12 +0000, Johannes Schindelin wrote:
> >
> > > Furthermore, my complaint was not about a platform where neither C#
> > > nor Python work. That is irrelevant. If you have one platform where
> > > only one works, and another platform where only the other works, you
> > > cannot have a single program for both platforms. Right?
> >
> > Right.
> >
> > I probably shouldn't be surprised that mono does not work on older unices,
> > but I am a bit surprised python does not.
>
> *Sigh* I managed again to make myself misunderstood.
>
> Even if newer Python does not easily compile on that IRIX, I have an old
> Python there (2.2). But I don't have any Python on MSys. (Yes, there is
> a _MinGW_ port, but no _MSys_ one.) So for me, Python is out.
While it would be a problem, but is it really fatal? AFAIK MSys uses unixy
paths inside the program, but accepts arguments and calls other processes
using the windows convention, so mingw python should have no problem calling
msys programs and vice versa. It might be more problematic to compile
a shared module for it, but .dlls are quite well isolated, so even compiling
a plugin linked with msys for mingw python might not be impossible.
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.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: can't commit files that have been git add'ed because "fatal: you need to resolve your current index first"
From: Bill Priest @ 2007-11-30 16:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, 28 Nov 2007 12:08:40 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> You can still do that by hand, by doing something
like:
>
> $ git merge --squash A
> $ resolve only partly
> $ git commit -m 'Prepare to merge A'
> $ git reset --hard
> $ git merge A
> $ resolve the rest
> $ git commit -m 'Fully merged A'
>
> For such a multi-step merge to make sense, the
change between B---M
> should make sense by itself for people who have to
read such a history
> later. Such a half-a-squash-merge may probably not
make sense by itself
> in most cases, so I suspect the above workflow would
not be useful in
> general.
>
Junio,
I resolved all the merges and then committed
different files as groups to make it easy to
cherry-pick after this merge. Does this "mess up" the
merge info? What does the "git reset --hard" do after
the commit (I'm assuming it throws away the
non-resolved changes not committed)? But from my
experience git wouldn't let me do the commit above it
w/o first fixing the conflicts.
Am I mis-interpreting your example or are you saying
that you think git would let me do the commit w/o
resolving all conflicts?
Bill
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 16:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Santi B?jar, Steffen Prohaska, Junio C Hamano,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.9999.0711300745330.8458@woody.linux-foundation.org>
On Fri, Nov 30, 2007 at 07:50:47AM -0800, Linus Torvalds wrote:
> Well, different people will want different viewers *anyway* (ie some will
> prefer qgit etc), so how about making "git view" be something that
> literally acts as a built-in alias that just defaults to running gitk (if
> for no other reason than the fact that gitk is the one that ships with
> git, and simply has most users).
I think that is a good idea, and here's a patch.
-- >8 --
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) {
--
1.5.3.6.2064.g2e22f-dirty
^ permalink raw reply related
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