* Re: [PATCH] Stop making git-merge-recur
From: A Large Angry SCM @ 2006-10-02 4:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu02nz5w6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>> Git-merge-recur is no longer installed and make clean no longer
>> removes it, so creating making it.
>
> Thanks for noticing.
>
> The bug is actually not installing nor cleaning it. People who
> wanted to stay on the bleeding edge could add "-s recur" on the
> command line, or have "merge.twohead = recur" in the config;
> this is what we actually encouraged people for wider testing.
> We do not suddenly break them. I planned the removal for the
> release after 1.4.3.
>
> This should fix it -- could you eyeball it please?
+1
^ permalink raw reply
* Re: [PATCH] Stop making git-merge-recur
From: Junio C Hamano @ 2006-10-02 4:41 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <45207D32.8040300@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Git-merge-recur is no longer installed and make clean no longer
> removes it, so creating making it.
Thanks for noticing.
The bug is actually not installing nor cleaning it. People who
wanted to stay on the bleeding edge could add "-s recur" on the
command line, or have "merge.twohead = recur" in the config;
this is what we actually encouraged people for wider testing.
We do not suddenly break them. I planned the removal for the
release after 1.4.3.
This should fix it -- could you eyeball it please?
-- >8 --
Makefile: install and clean merge-recur, still.
We advertised git-merge-recur for some time, and we planned to
support it for one release after we made it the 'recursive'.
However we forgot to install it nor have "make clean" clean it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Makefile b/Makefile
index dd33158..401b893 100644
--- a/Makefile
+++ b/Makefile
@@ -215,7 +215,8 @@ BUILT_INS = \
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
# what 'all' will build and 'install' will install, in gitexecdir
-ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
+ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) \
+ git-merge-recur$X
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@@ -586,8 +587,7 @@ export prefix TAR INSTALL DESTDIR SHELL_
### Build rules
-all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi \
- git-merge-recur$X
+all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
all: perl/Makefile
$(MAKE) -C perl
^ permalink raw reply related
* [PATCH] Do not create tag leading directories since git update-ref does it.
From: Christian Couder @ 2006-10-02 4:36 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-tag.sh | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-tag.sh b/git-tag.sh
index a3f1819..ac269e3 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -112,6 +112,5 @@ if [ "$annotate" ]; then
object=$(git-mktag < "$GIT_DIR"/TAG_TMP)
fi
-leading=`expr "refs/tags/$name" : '\(.*\)/'` &&
-mkdir -p "$GIT_DIR/$leading" &&
-GIT_DIR="$GIT_DIR" git update-ref "refs/tags/$name" "$object" "$prev"
+git update-ref "refs/tags/$name" "$object" "$prev"
+
--
1.4.2.2.gbcb49-dirty
^ permalink raw reply related
* Re: [PATCH] Stop making git-merge-recur
From: A Large Angry SCM @ 2006-10-02 2:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <45207D32.8040300@gmail.com>
A Large Angry SCM wrote:
> Git-merge-recur is no longer installed and make clean no longer
> removes it, so creating making it.
^^^^^^^^^^^^^^^^^^
Should be "so stop creating" it.
^ permalink raw reply
* [PATCH] Stop making git-merge-recur
From: A Large Angry SCM @ 2006-10-02 2:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Git-merge-recur is no longer installed and make clean no longer
removes it, so creating making it.
Signed-off-by: A Large Angry SCM <gitzilla@gmail.com>
---
Makefile | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index dd33158..37bd59d 100644
--- a/Makefile
+++ b/Makefile
@@ -586,8 +586,7 @@ export prefix TAR INSTALL DESTDIR SHELL_
### Build rules
-all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi \
- git-merge-recur$X
+all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
all: perl/Makefile
$(MAKE) -C perl
@@ -603,9 +602,6 @@ git$X: git.c common-cmds.h $(BUILTIN_OBJ
help.o: common-cmds.h
-git-merge-recur$X: git-merge-recursive$X
- rm -f $@ && ln git-merge-recursive$X $@
-
$(BUILT_INS): git$X
rm -f $@ && ln git$X $@
@@ -918,7 +914,7 @@ check-docs::
do \
case "$$v" in \
git-merge-octopus | git-merge-ours | git-merge-recursive | \
- git-merge-resolve | git-merge-stupid | git-merge-recur | \
+ git-merge-resolve | git-merge-stupid | \
git-merge-recursive-old | \
git-ssh-pull | git-ssh-push ) continue ;; \
esac ; \
^ permalink raw reply related
* Re: [BUG] 'git mv a/fileA b/fileB' causes 'c/fileC' to be deleted
From: Michael Cassar @ 2006-10-02 1:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsdc0wkz.fsf@assigned-by-dhcp.cox.net>
On 10/2/06, Junio C Hamano <junkio@cox.net> wrote:
> There could be a bigger problem, but it does not seem to easily
> reproduce as you noted in the message. It could be that some
> unrelated thing in the working tree is playing a role in this
> breakage, but I do not think of offhand what that is.
> [...] Care to show a bit more details
> on your working tree?
Okay, I should stop being lazy and actually produce a minimal test-case.
Here we go:
--CUT--
#!/bin/bash
git init-db
mkdir papers
mkdir papers/unsorted
mkdir papers/all-papers
mkdir partA
echo 'moo' > papers/unsorted/Thesis.pdf
echo 'cow' > partA/outline.txt
echo 'this file has brackets in its filename' > 'papers/unsorted/(brackets).pdf'
git add papers partA
git commit -m 'intial commit'
git mv papers/unsorted/Thesis.pdf papers/all-papers/moo-blah.pdf
git commit -m 'move a file'
cg log -f
--CUT--
The problem seems to have come from the fact that a file in the source
directory of the move contained brackets in its filename.Removing the
file causes the problem to go away.
Hope this helps a little,
Mike
^ permalink raw reply
* Re: gitweb: using quotemeta
From: Jakub Narebski @ 2006-10-02 0:28 UTC (permalink / raw)
To: git
In-Reply-To: <20060928232752.99373.qmail@web31804.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
>>
>> Ouch, that was a sloppy planning and coding, and sloppier
>> reviewing. Sorry.
>>
>> What is the right quoting there? Just quoting double-quotes?
>
> I'm not sure. What undesired character could we have in $filename
> of a snapshot? The commit ab41dfbfd4f message gives this
> justification: "Just in case filename contains end of line character."
>
> It looks like $filename is constructed by well defined strings:
> basename($project), $hash and $suffix all of which should be ok.
>
> I'd say we don't need quotemeta for $filename of snapshot.
But we do need quoting for blob_plain and perhaps blobdiff_plain
views, although not quotemeta, but perhaps the reverse of unescape,
i.e. quote '"', EOLN (end of line) and perhaps also TAB.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Jakub Narebski @ 2006-10-01 22:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060929233037.42926.qmail@web31808.mail.mud.yahoo.com>
Luben Tuikov wrote:
> What this patch does is simply set "h" and/or "hb" to
> the string "HEAD" instead of the string "<SHA1 of HEAD>" when
> h/hb is not defined.
I guess there it is a good idea, but we should always think
over if we want "constant" link, always showing the same thing,
or a "variable" (or "news") link, showing current version.
Explicit sha1 hash as 'h'/'hb' gives persistent, cacheable link,
while e.g. "HEAD" gives "variable" link.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: start to generate PATH_INFO URLs.
From: Martin Waitz @ 2006-10-01 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfye9dtv7.fsf@assigned-by-dhcp.cox.net>
Instead of providing the project as a ?p= parameter it is simply appended to
the base URI. All other parameters are appended to that, except for ?a=summary
which is the default and can be omitted.
The old URL generation can be selected by disabling the "pathinfo" feature
in gitweb_config.perl.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
gitweb/gitweb.perl | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 597d29f..edbd3ea 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -102,6 +102,10 @@ our %feature = (
'sub' => \&feature_pickaxe,
'override' => 0,
'default' => [1]},
+
+ 'pathinfo' => {
+ 'override' => 0,
+ 'default' => [1]},
);
sub gitweb_check_feature {
@@ -355,6 +359,7 @@ ## action links
sub href(%) {
my %params = @_;
+ my $href = $my_uri;
my @mapping = (
project => "p",
@@ -373,6 +378,19 @@ sub href(%) {
$params{'project'} = $project unless exists $params{'project'};
+ my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ if ($use_pathinfo) {
+ # use PATH_INFO for project name
+ $href .= "/$params{'project'}" if defined $params{'project'};
+ delete $params{'project'};
+
+ # Summary just uses the project path URL
+ if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ delete $params{'action'};
+ }
+ }
+
+ # now encode the parameters explicitly
my @result = ();
for (my $i = 0; $i < @mapping; $i += 2) {
my ($name, $symbol) = ($mapping[$i], $mapping[$i+1]);
@@ -380,7 +398,9 @@ sub href(%) {
push @result, $symbol . "=" . esc_param($params{$name});
}
}
- return "$my_uri?" . join(';', @result);
+ $href .= "?" . join(';', @result) if scalar @result;
+
+ return $href;
}
--
1.4.2.gb8b6b
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH] gitweb: Decode long title for link tooltips
From: Jakub Narebski @ 2006-10-01 21:49 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87r6xrvi0g.wl@mail2.atmark-techno.com>
Yasushi SHOJI wrote:
> At Sun, 01 Oct 2006 18:45:46 +0200,
> Jakub Narebski wrote:
> >
> > Yasushi SHOJI wrote:
> >
> > > This is a simple one liner to decode long title string in perl's
> > > internal form to utf-8 for link tooltips.
> > >
> > > This is not crucial if the commit message is all in ASCII, however, if
> > > you decide to use other encoding, such as UTF-8, tooltips ain't
> > > readable any more.
> >
> > Perhaps it would be better to abstract it away into esc_attr (as escape
> > attribute) subroutine, if such situation i.e. output of generated string
> > into some attribute of some element happens in some other place.
>
> I liked the idea. there were 7 places already.
>
> I just couldn't get why you picked esc_attr for the name. is there a
> patch for the func I missed?
To keep it in the style of names like esc_param (escaping the GET parameter
to be passed), esc_url (escaping URL to be put as argument of href attribute
of <link> or <a> element) and esc_html (escaping output).
esc_attr is to escape ATTRibutes of elements, for example title attribute.
I'm not sure if CGI module does escaping for example of '"' in attributes...
> anyway, a patch for the abstruction is attached. rename the func name
> if you don't like it.
Anyone can send patch renaming subroutines. to_utf8 is a good name... till
we allow non-utf8 encodings. And the name can be used for other places where
we do string decoding from Perl internal form to utf-8.
> # i don't know how to reply to an email and also attaching a patch
> # from git format-patch. should I just submit the patch in a separate
> # email?
There are two formats used (check out Documentation/SubmittingPatches).
First used for short replies, or some comments which you don't want to have
in commit description (commit message) is to put additional text just right
after "---" separating commit message from the patch.
Second, used for example if reply is longer than commit message, or patch
is just an attachement/footnote to reply, is to put the reply above the
body of message generated by format patch, and separate it from the
patch for example by "-- >8 --". The idea is that committer can remove the
top part of email and apply the rest as is.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Decode long title for link tooltips
From: Yasushi SHOJI @ 2006-10-01 21:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eforb7$fgd$1@sea.gmane.org>
At Sun, 01 Oct 2006 18:45:46 +0200,
Jakub Narebski wrote:
>
> Yasushi SHOJI wrote:
>
> > This is a simple one liner to decode long title string in perl's
> > internal form to utf-8 for link tooltips.
> >
> > This is not crucial if the commit message is all in ASCII, however, if
> > you decide to use other encoding, such as UTF-8, tooltips ain't
> > readable any more.
>
> Perhaps it would be better to abstract it away into esc_attr (as escape
> attribute) subroutine, if such situation i.e. output of generated string
> into some attribute of some element happens in some other place.
I liked the idea. there were 7 places already.
I just couldn't get why you picked esc_attr for the name. is there a
patch for the func I missed?
anyway, a patch for the abstruction is attached. rename the func name
if you don't like it.
# i don't know how to reply to an email and also attaching a patch
# from git format-patch. should I just submit the patch in a separate
# email?
regards,
--
yashi
>From cb5f740afb265e67fabf09cd76141fdda24d6745 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI <yashi@atmark-techno.com>
Date: Mon, 2 Oct 2006 06:21:33 +0900
Subject: [PATCH] gitweb: refactor decode() for utf8 conversion
we already had a few place using decode() to convert perl internal
encode to utf8. added a new thin wrapper to do just that.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
gitweb/gitweb.perl | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 44991b1..87a644e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -440,6 +440,12 @@ sub validate_refname {
return $input;
}
+# very thin wrapper for decode("utf8", $str, Encode::FB_DEFAULT);
+sub to_utf8 {
+ my $str = shift;
+ return decode("utf8", $str, Encode::FB_DEFAULT);
+}
+
# quote unsafe chars, but keep the slash, even when it's not
# correct, but quoted slashes look too horrible in bookmarks
sub esc_param {
@@ -462,7 +468,7 @@ sub esc_url {
# replace invalid utf8 character with SUBSTITUTION sequence
sub esc_html {
my $str = shift;
- $str = decode("utf8", $str, Encode::FB_DEFAULT);
+ $str = to_utf8($str);
$str = escapeHTML($str);
$str =~ s/\014/^L/g; # escape FORM FEED (FF) character (e.g. in COPYING file)
return $str;
@@ -664,7 +670,7 @@ sub format_subject_html {
if (length($short) < length($long)) {
return $cgi->a({-href => $href, -class => "list subject",
- -title => decode("utf8", $long, Encode::FB_DEFAULT)},
+ -title => to_utf8($long)},
esc_html($short) . $extra);
} else {
return $cgi->a({-href => $href, -class => "list subject"},
@@ -841,7 +847,7 @@ sub git_get_projects_list {
-e "$projectroot/$path/$export_ok")) {
my $pr = {
path => $path,
- owner => decode("utf8", $owner, Encode::FB_DEFAULT),
+ owner => to_utf8($owner),
};
push @list, $pr
}
@@ -870,7 +876,7 @@ sub git_get_project_owner {
$pr = unescape($pr);
$ow = unescape($ow);
if ($pr eq $project) {
- $owner = decode("utf8", $ow, Encode::FB_DEFAULT);
+ $owner = to_utf8($ow);
last;
}
}
@@ -1232,7 +1238,7 @@ sub get_file_owner {
}
my $owner = $gcos;
$owner =~ s/[,;].*$//;
- return decode("utf8", $owner, Encode::FB_DEFAULT);
+ return to_utf8($owner);
}
## ......................................................................
@@ -3585,7 +3591,7 @@ XML
"<![CDATA[\n";
my $comment = $co{'comment'};
foreach my $line (@$comment) {
- $line = decode("utf8", $line, Encode::FB_DEFAULT);
+ $line = to_utf8($line);
print "$line<br/>\n";
}
print "<br/>\n";
@@ -3594,7 +3600,7 @@ XML
next;
}
my $file = esc_html(unquote($7));
- $file = decode("utf8", $file, Encode::FB_DEFAULT);
+ $file = to_utf8($file);
print "$file<br/>\n";
}
print "]]>\n" .
--
1.4.3.rc1
^ permalink raw reply related
* Re: Multiple checkouts of the same repository
From: Matt McCutchen @ 2006-10-01 21:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610012116310.14200@wbgn013.biozentrum.uni-wuerzburg.de>
On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> The fact is, your setup is fragile, and I think that is hard to fix if you
> do not make A and B git repositories in their own right.
I think my setup is much simpler than having two separate repositories
that update each other using hooks. What can go wrong, besides the
scenario I mentioned where one working tree doesn't get updated when I
commit through the other one?
Matt
^ permalink raw reply
* Re: [BUG] "git cat-file tree <sha1>" prints garbage
From: Johannes Schindelin @ 2006-10-01 20:48 UTC (permalink / raw)
To: Sebastian Harl; +Cc: git
In-Reply-To: <20061001202602.GD32373@albany.tokkee.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 727 bytes --]
Hi,
On Sun, 1 Oct 2006, Sebastian Harl wrote:
> When using "git cat-file tree <sha1>" to print a tree's content, it produces
> garbage output like the following:
>
> $ git cat-file -t c0cd1e4e1888be6a70d44476996ece8be1ab52a2
> tree
> $ git cat-file tree c0cd1e4e1888be6a70d44476996ece8be1ab52a2
> 100644 .gitignore%ëF7¦ùq¤¢«‚:“y—ǽ100644
> COPYINGoø|Fd˜C—bW‘Èê;»_"y£40000 DocumentationŠ>Ý¢ÞÀŸçœ $ë#ºâü100755
> GIT-VERSION-GEN
> [...]
>
> Using "git cat-file -p <sha1>" works fine.
> (The above example uses one of the latest commits of the git.git repository)
That is not a bug. "git cat-file tree <sha1>" produces the _exact_
contents of the object, while "-p" _pretty_-prints the contents.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Check that a tag exists using show-ref instead of looking for the ref file.
From: Christian Couder @ 2006-10-01 20:33 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-tag.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-tag.sh b/git-tag.sh
index 6463b31..a3f1819 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -66,7 +66,7 @@ done
name="$1"
[ "$name" ] || usage
prev=0000000000000000000000000000000000000000
-if test -e "$GIT_DIR/refs/tags/$name"
+if git-show-ref --verify --quiet -- "refs/tags/$name"
then
test -n "$force" || die "tag '$name' already exists"
prev=`git rev-parse "refs/tags/$name"`
--
1.4.2.1.gd567
^ permalink raw reply related
* [BUG] "git cat-file tree <sha1>" prints garbage
From: Sebastian Harl @ 2006-10-01 20:26 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
Hi,
When using "git cat-file tree <sha1>" to print a tree's content, it produces
garbage output like the following:
$ git cat-file -t c0cd1e4e1888be6a70d44476996ece8be1ab52a2
tree
$ git cat-file tree c0cd1e4e1888be6a70d44476996ece8be1ab52a2
100644 .gitignore%ëF7¦ùq¤¢«‚:“y—ǽ100644
COPYINGoø|Fd˜C—bW‘Èê;»_"y£40000 DocumentationŠ>Ý¢ÞÀŸçœ $ë#ºâü100755
GIT-VERSION-GEN
[...]
Using "git cat-file -p <sha1>" works fine.
(The above example uses one of the latest commits of the git.git repository)
Cheers,
Sebastian
--
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Linus Torvalds @ 2006-10-01 20:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0610012208410.14200@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 1 Oct 2006, Johannes Schindelin wrote:
>
> The problem is that the Makefile does not realize that Git.xs no longer is
> there. Neither does the code which recreates the Makefile.
No. The problem is that top-level dependency rules for perl/Makefile are
simply _wrong_. It claims it depends on some things (which is true), but
then it totally ignores _other_ things that it also depends on.
Further, even if it was right, the rules to actually _generate_ the
Makefile then seems wrong, in that it cares about files it shouldn't care
about in the first place.
So why do that at all? Why accept such crap?
Linus
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Johannes Schindelin @ 2006-10-01 20:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610011256580.3952@g5.osdl.org>
Hi,
On Sun, 1 Oct 2006, Linus Torvalds wrote:
> On Sun, 1 Oct 2006, Johannes Schindelin wrote:
> >
> > Just rm perl/{Git.{bs,c},Makefile} and remake.
>
> Now this works.
>
> So somebody tell me why we even invoke that Makefile that shouldn't be
> there?
The problem is that the Makefile does not realize that Git.xs no longer is
there. Neither does the code which recreates the Makefile.
You will notice that there is a new generated perl/Makefile, which no
longer tries to compile Git.xs, Git.bs or Git.c
When there is a Git.c, "perl Makefile.PL" will do the wrong thing, namely
it expects that you created Git.c by hand, and wants to compile it. If
there is a Git.bs, it thinks you want Git.c created.
Sort of automake for Perl.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Use git-update-ref to delete a tag instead of rm()ing the ref file.
From: Christian Couder @ 2006-10-01 20:16 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-tag.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-tag.sh b/git-tag.sh
index 2bde3c0..6463b31 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -47,8 +47,10 @@ do
-d)
shift
tag_name="$1"
- rm "$GIT_DIR/refs/tags/$tag_name" && \
- echo "Deleted tag $tag_name."
+ tag=$(git-show-ref --verify --hash -- "refs/tags/$tag_name") ||
+ die "Seriously, what tag are you talking about?"
+ git-update-ref -m 'tag: delete' -d "refs/tags/$tag_name" "$tag" &&
+ echo "Deleted tag $tag_name."
exit $?
;;
-*)
--
1.4.2.1.g8a7b-dirty
^ permalink raw reply related
* Re: What will happen to git.git in the near future
From: Linus Torvalds @ 2006-10-01 19:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0610012052520.14200@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 1 Oct 2006, Johannes Schindelin wrote:
>
> Just rm perl/{Git.{bs,c},Makefile} and remake.
Now this works.
So somebody tell me why we even invoke that Makefile that shouldn't be
there?
Linus
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Linus Torvalds @ 2006-10-01 19:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlknz27qm.fsf@assigned-by-dhcp.cox.net>
On Sun, 1 Oct 2006, Junio C Hamano wrote:
>
> Everybody hated the perl crud, so we removed Git.xs and is not
> even part of the source anymore.
>
> This is a symptom that Git.c leftover from an earlier build was
> in the working tree. Could you try running "rm -f perl/Git.c"
> before building and see if it helps?
Nope.
Then I just get
make[1]: Entering directory `/home/torvalds/git/perl'
Running Mkbootstrap for Git ()
chmod 644 Git.bs
rm -f blib/arch/auto/Git/Git.so
gcc -shared -L/usr/local/lib Git.o -o blib/arch/auto/Git/Git.so \
\
gcc: Git.o: No such file or directory
gcc: no input files
instead.
If that file isn't even supposed to _exist_, then why do we have build
rules etc crap to do all this? It sounds like the makefiles are broken.
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Jakub Narebski @ 2006-10-01 19:27 UTC (permalink / raw)
To: Junio C Hamano, Luben Tuikov; +Cc: git
In-Reply-To: <7vd59b27c4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > ... That means that we cannot distinguish really well (at
> > least color) between tree and blob entries.
>
> Do we even say links are blue and underlined by forcing that in
> our css?
That is default style of link element, as specified by default CSS
for HTML/XHTML.
> Doesn't leading drwxr-xr-x mean anything?
Neither d in drwxr-xr-x, nor trailing / in the name are significant
enough indicators of directory vs file (tree vs blob) indicator,
especially that by default git-ls-tree output mixes trees with blobs.
> Why is making the distinction important in the first place?
If you browse tree, you usually click on tree links, but not on blob
links.
> > In the case of shortlog/log/history/heads/tags view, to clearly mark
> > subject/title of a commit or tag as link, we would have to use default
> > link decoration....
> > But underlined text is harder to read, and blue underlined text even
> > more so...
>
> This is something in which I can see some more sense than tree
> vs blob issue, but only as a principle issue. In practice, the
> list of commit subjects is the first thing users encounter, and
> as long as there is some visual indication (e.g. mousing over it
> makes it obvious it is something that is clickable), I think
> users will quickly pick up that it will lead to the commit's
> detail.
Well, that is certainly the question of style (redundancy vs. uncluttered
output plus some coding issues).
By the way, I've planned to move printing those kind of links to separate
subroutine (output based on type of object the links are related to, and
somewhat als on the action/view we are in)...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Remove excessively redundant entries from git_difftree_body
From: Jakub Narebski @ 2006-10-01 19:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vmz8k7nhc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> 1) All entries on the left are blobs and clicking on them
>> leads to blobs. No more diff or blob depending on what
>> happened (modified or mode changed) to the file -- this goes
>> to the right, in the "link" column.
>>
>> 2) Remove redundant "blob" from the link column on the right.
>> This can now be had by clicking on the entry itself.
>>
>> This reduces and simplifies the code.
>>
>> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
>
> We lost blobdiff from commitdiff page with this patch, which I
> think it probably is a good change. We can say "when we display
> a pathname you can click it to get the blob or tree".
In my opinion it is a bad change. We now have "patch" inner-link
to anchor in commitdiff view, but it's equivalent in commit view
i.e. diff aka blobdiff vanished.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Multiple checkouts of the same repository
From: Johannes Schindelin @ 2006-10-01 19:17 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <3bbc18d20610011214y6132d98eq9cd58b23721bb87d@mail.gmail.com>
Hi,
On Sun, 1 Oct 2006, Matt McCutchen wrote:
> On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > A better method is to use a local clone:
> >
> > git-clone --local --shared A B
> >
> > Such a clone will be very fast, and cheap, because it sets up links (not
> > just symbolic links, but links that git understands).
>
> But that gives me two separate repositories, so I have to push and
> pull to keep them in sync, which is a pain.
So you want the commits to show in A, too? I propose using a hook for
that.
The fact is, your setup is fragile, and I think that is hard to fix if you
do not make A and B git repositories in their own right.
Hth,
Dscho
^ permalink raw reply
* Re: Multiple checkouts of the same repository
From: Matt McCutchen @ 2006-10-01 19:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610012105590.14200@wbgn013.biozentrum.uni-wuerzburg.de>
On 10/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> A better method is to use a local clone:
>
> git-clone --local --shared A B
>
> Such a clone will be very fast, and cheap, because it sets up links (not
> just symbolic links, but links that git understands).
But that gives me two separate repositories, so I have to push and
pull to keep them in sync, which is a pain.
I symlinked only the top-level things in .git, not the individual
files inside them. That is to say, B/.git/objects is a symlink to
A/.git/objects, B/.git/refs is a symlink to A/.git/refs, etc. In
fact, this is necessary for A to see objects and refs written through
B.
Matt
^ permalink raw reply
* Re: Multiple checkouts of the same repository
From: Johannes Schindelin @ 2006-10-01 19:08 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <3bbc18d20610011203p40d631b7o3bd2c6971a2bfcca@mail.gmail.com>
Hi,
On Sun, 1 Oct 2006, Matt McCutchen wrote:
> Maybe this is common knowledge, but I thought I should mention it in
> case it isn't. I had a git repository in a directory A and I wanted
> to check out a branch of the repository to a different directory B.
> So I created B/.git and filled it with symlinks pointing to the files
> in A/.git, except for index and HEAD because those need to be
> different for each checkout;
A better method is to use a local clone:
git-clone --local --shared A B
Such a clone will be very fast, and cheap, because it sets up links (not
just symbolic links, but links that git understands).
Hth,
Dscho
^ 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