* [PATCH 1/2] Move SCM interoperability tools into interop/
From: Ryan Anderson @ 2006-07-10 4:54 UTC (permalink / raw)
To: git; +Cc: Ryan Anderson
In-Reply-To: <1152507249880-git-send-email-ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Makefile | 12 +++--
interop/Makefile | 45 ++++++++++++++++++++
git-archimport.perl => interop/git-archimport.perl | 0
.../git-cvsexportcommit.perl | 0
git-cvsimport.perl => interop/git-cvsimport.perl | 0
git-cvsserver.perl => interop/git-cvsserver.perl | 0
git-p4import.py => interop/git-p4import.py | 0
git-quiltimport.sh => interop/git-quiltimport.sh | 0
git-send-email.perl => interop/git-send-email.perl | 0
git-svnimport.perl => interop/git-svnimport.perl | 0
10 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 13f7c89..d6e2b0f 100644
--- a/Makefile
+++ b/Makefile
@@ -127,14 +127,13 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
- git-lost-found.sh git-quiltimport.sh
+ git-lost-found.sh
SCRIPT_PERL = \
- git-archimport.perl git-cvsimport.perl git-relink.perl \
+ git-relink.perl \
git-shortlog.perl git-rerere.perl \
- git-annotate.perl git-cvsserver.perl \
- git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
- git-send-email.perl
+ git-annotate.perl \
+ git-mv.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
@@ -176,6 +175,9 @@ BUILT_INS = git-log$X git-whatchanged$X
git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \
git-fmt-merge-msg$X
+
+include interop/Makefile
+
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
diff --git a/interop/Makefile b/interop/Makefile
new file mode 100644
index 0000000..b1a11d1
--- /dev/null
+++ b/interop/Makefile
@@ -0,0 +1,45 @@
+
+INTEROP_PERL_BASE = \
+ git-archimport.perl \
+ git-cvsimport.perl \
+ git-cvsexportcommit.perl \
+ git-cvsserver.perl \
+ git-svnimport.perl \
+ git-send-email.perl
+
+INTEROP_PYTHON_BASE = \
+ git-p4import.py
+
+INTEROP_SH_BASE = \
+ git-quiltimport.sh
+
+SCRIPTS+=$(patsubst %.perl,%,$(INTEROP_PERL_BASE))
+SCRIPTS+=$(patsubst %.py,%,$(INTEROP_PYTHON_BASE))
+SCRIPTS+=$(patsubst %.sh,%,$(INTEROP_SH_BASE))
+
+$(patsubst %.sh,%,$(INTEROP_SH_BASE)) : % : interop/%.sh
+ rm -f $@ $@+
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
+ $^ >$@+
+ chmod +x $@+
+ mv $@+ $@
+
+$(patsubst %.perl,%,$(INTEROP_PERL_BASE)) : % : interop/%.perl
+ rm -f $@ $@+
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ $^ >$@+
+ chmod +x $@+
+ mv $@+ $@
+
+$(patsubst %.py,%,$(INTEROP_PYTHON_BASE)) : % : interop/%.py GIT-CFLAGS
+ rm -f $@ $@+
+ sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
+ -e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ $^ >$@+
+ chmod +x $@+
+ mv $@+ $@
diff --git a/git-archimport.perl b/interop/git-archimport.perl
similarity index 100%
rename from git-archimport.perl
rename to interop/git-archimport.perl
diff --git a/git-cvsexportcommit.perl b/interop/git-cvsexportcommit.perl
similarity index 100%
rename from git-cvsexportcommit.perl
rename to interop/git-cvsexportcommit.perl
diff --git a/git-cvsimport.perl b/interop/git-cvsimport.perl
similarity index 100%
rename from git-cvsimport.perl
rename to interop/git-cvsimport.perl
diff --git a/git-cvsserver.perl b/interop/git-cvsserver.perl
similarity index 100%
rename from git-cvsserver.perl
rename to interop/git-cvsserver.perl
diff --git a/git-p4import.py b/interop/git-p4import.py
similarity index 100%
rename from git-p4import.py
rename to interop/git-p4import.py
diff --git a/git-quiltimport.sh b/interop/git-quiltimport.sh
similarity index 100%
rename from git-quiltimport.sh
rename to interop/git-quiltimport.sh
diff --git a/git-send-email.perl b/interop/git-send-email.perl
similarity index 100%
rename from git-send-email.perl
rename to interop/git-send-email.perl
diff --git a/git-svnimport.perl b/interop/git-svnimport.perl
similarity index 100%
rename from git-svnimport.perl
rename to interop/git-svnimport.perl
--
1.4.1.gc473b-dirty
^ permalink raw reply related
* [RFC+PATCH 0/2] Clean up root directory
From: Ryan Anderson @ 2006-07-10 4:54 UTC (permalink / raw)
To: git
A second send of my patch to clean up the root directory a bit.
This series moves the "SCM interoperability" tools into interop/ and
builtin-*.c into builtin/.
All tests pass, and all finished scripts and binaries are dropped into the root
after a "make all".
GIT: Please enter your email below.
GIT: Lines beginning in "GIT: " will be removed.
GIT: Consider including an overall diffstat or table of contents
GIT: for the patch you are writing.
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Ryan Anderson @ 2006-07-10 3:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsllae1ik.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 985 bytes --]
Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
>
>> Comments on a way to make the Makefile less repetitive would be
>> appreciated, though.
>>
>
> One obvious way would be not to have scm/Makefile but have the
> dependencies in the main Makefile to say (the moral equivalent
> of):
>
> git-archimport.perl: scm/git-archimport.perl
>
I think that doing that means I still need to duplicate the actual
build rules, which is what I was hoping to avoid, as they encode all the
magic "path replacement" logic in multiple places.
On the other hand, I can fix *that*, if I break the ability to run in
the build directory, which is bad in its own way. (Fixing the tests
should be a matter of adapting the test library slightly, I think.)
For the time being, I'm going with ugly, but less disruptive, and I'm
willing/planning on revisiting it when things shake out a bit more.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* [PATCH] git-svn: fix --file/-F option in commit-diff
From: Eric Wong @ 2006-07-10 3:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
Also, allow messages from tags to be used as
commit messages.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 8bc4188..7cbfb6e 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -760,7 +760,7 @@ sub commit_diff {
exit 1;
}
if (defined $_file) {
- $_message = file_to_s($_message);
+ $_message = file_to_s($_file);
} else {
$_message ||= get_commit_message($tb,
"$GIT_DIR/.svn-commit.tmp.$$")->{msg};
@@ -1518,12 +1518,12 @@ sub get_commit_message {
open my $msg, '>', $commit_msg or croak $!;
chomp(my $type = `git-cat-file -t $commit`);
- if ($type eq 'commit') {
+ if ($type eq 'commit' || $type eq 'tag') {
my $pid = open my $msg_fh, '-|';
defined $pid or croak $!;
if ($pid == 0) {
- exec(qw(git-cat-file commit), $commit) or croak $!;
+ exec('git-cat-file', $type, $commit) or croak $!;
}
my $in_msg = 0;
while (<$msg_fh>) {
--
1.4.1.gda58
^ permalink raw reply related
* [PATCH] gitweb.cgi: Teach "a=blob" action to know the blob/file mime type
From: Luben Tuikov @ 2006-07-10 3:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
Now action "blob" knows the file type: if the file type is
not "text/*" then action "blob" defaults to "blob_plain",
i.e. the file is downloaded raw for the browser to interpret.
If the file type is "text/*", then "blob" defaults to the
current "cat -n"-like output, from which you can click
"plain", to get the "blob_plain" output.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.cgi | 127 ++++++++++++++++++++++++++++-------------------------
1 files changed, 67 insertions(+), 60 deletions(-)
[-- Attachment #2: 2862520298-blob.patch --]
[-- Type: application/octet-stream, Size: 6704 bytes --]
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 3e2790c..1e61ae6 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -1455,61 +1455,6 @@ sub git_get_hash_by_path {
}
}
-sub git_blob {
- if (!defined $hash && defined $file_name) {
- my $base = $hash_base || git_read_head($project);
- $hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
- }
- my $have_blame = git_get_project_config_bool ('blame');
- open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error(undef, "Open failed.");
- git_header_html();
- if (defined $hash_base && (my %co = git_read_commit($hash_base))) {
- print "<div class=\"page_nav\">\n" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=summary")}, "summary") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog")}, "shortlog") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=log")}, "log") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$hash_base")}, "commit") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commitdiff;h=$hash_base")}, "commitdiff") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$co{'tree'};hb=$hash_base")}, "tree") . "<br/>\n";
- if (defined $file_name) {
- if ($have_blame) {
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blame;h=$hash;hb=$hash_base;f=$file_name")}, "blame") . " | ";
- }
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;h=$hash;f=$file_name")}, "plain") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;hb=HEAD;f=$file_name")}, "head") . "<br/>\n";
- } else {
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;h=$hash")}, "plain") . "<br/>\n";
- }
- print "</div>\n".
- "<div>" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$hash_base"), -class => "title"}, esc_html($co{'title'})) .
- "</div>\n";
- } else {
- print "<div class=\"page_nav\">\n" .
- "<br/><br/></div>\n" .
- "<div class=\"title\">$hash</div>\n";
- }
- if (defined $file_name) {
- print "<div class=\"page_path\"><b>" . esc_html($file_name) . "</b></div>\n";
- }
- print "<div class=\"page_body\">\n";
- my $nr;
- while (my $line = <$fd>) {
- chomp $line;
- $nr++;
- while ((my $pos = index($line, "\t")) != -1) {
- if (my $count = (8 - ($pos % 8))) {
- my $spaces = ' ' x $count;
- $line =~ s/\t/$spaces/;
- }
- }
- printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n", $nr, $nr, $nr, esc_html($line);
- }
- close $fd or print "Reading blob failed.\n";
- print "</div>";
- git_footer_html();
-}
-
sub mimetype_guess_file {
my $filename = shift;
my $mimemap = shift;
@@ -1548,14 +1493,14 @@ sub git_blob_plain_mimetype {
my $fd = shift;
my $filename = shift;
- # just in case
- return $default_blob_plain_mimetype unless $fd;
-
if ($filename) {
my $mime = mimetype_guess($filename);
$mime and return $mime;
}
+ # just in case
+ return $default_blob_plain_mimetype unless $fd;
+
if (-T $fd) {
return 'text/plain' .
($default_text_plain_charset ? '; charset='.$default_text_plain_charset : '');
@@ -1573,8 +1518,10 @@ sub git_blob_plain_mimetype {
}
sub git_blob_plain {
- open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
- my $type = git_blob_plain_mimetype($fd, $file_name);
+ my $type = shift;
+ open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error("Couldn't cat $file_name, $hash");
+
+ $type ||= git_blob_plain_mimetype($fd, $file_name);
# save as filename, even when no $file_name is given
my $save_as = "$hash";
@@ -1593,7 +1540,66 @@ sub git_blob_plain {
close $fd;
}
+sub git_blob {
+ if (!defined $hash && defined $file_name) {
+ my $base = $hash_base || git_read_head($project);
+ $hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
+ }
+ my $have_blame = git_get_project_config_bool ('blame');
+ open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error(undef, "Open failed.");
+ my $mimetype = git_blob_plain_mimetype($fd, $file_name);
+ if ($mimetype !~ m/^text\//) {
+ close $fd;
+ return git_blob_plain($mimetype);
+ }
+ git_header_html();
+ if (defined $hash_base && (my %co = git_read_commit($hash_base))) {
+ print "<div class=\"page_nav\">\n" .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=summary")}, "summary") .
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog")}, "shortlog") .
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=log")}, "log") .
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$hash_base")}, "commit") .
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commitdiff;h=$hash_base")}, "commitdiff") .
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$co{'tree'};hb=$hash_base")}, "tree") . "<br/>\n";
+ if (defined $file_name) {
+ if ($have_blame) {
+ print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blame;h=$hash;hb=$hash_base;f=$file_name")}, "blame") . " | ";
+ }
+ print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;h=$hash;f=$file_name")}, "plain") .
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;hb=HEAD;f=$file_name")}, "head") . "<br/>\n";
+ } else {
+ print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;h=$hash")}, "plain") . "<br/>\n";
+ }
+ print "</div>\n".
+ "<div>" .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$hash_base"), -class => "title"}, esc_html($co{'title'})) .
+ "</div>\n";
+ } else {
+ print "<div class=\"page_nav\">\n" .
+ "<br/><br/></div>\n" .
+ "<div class=\"title\">$hash</div>\n";
+ }
+ if (defined $file_name) {
+ print "<div class=\"page_path\"><b>" . esc_html($file_name) . "</b></div>\n";
+ }
+ print "<div class=\"page_body\">\n";
+ my $nr;
+ while (my $line = <$fd>) {
+ chomp $line;
+ $nr++;
+ while ((my $pos = index($line, "\t")) != -1) {
+ if (my $count = (8 - ($pos % 8))) {
+ my $spaces = ' ' x $count;
+ $line =~ s/\t/$spaces/;
+ }
+ }
+ printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n", $nr, $nr, $nr, esc_html($line);
+ }
+ close $fd or print "Reading blob failed.\n";
+ print "</div>";
+ git_footer_html();
+}
+
sub git_tree {
if (!defined $hash) {
$hash = git_read_head($project);
--
1.4.1.g35dbd
^ permalink raw reply related
* [PATCH] gitweb.cgi: Create $git_temp if it doesn't exist
From: Luben Tuikov @ 2006-07-10 3:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 260 bytes --]
Unless we'd done diffs, $git_temp doesn't exist and then
mime lookups fail. Explicitly create it, if it doesn't
exist already.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.cgi | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
[-- Attachment #2: 2829251161-patch.patch --]
[-- Type: application/octet-stream, Size: 461 bytes --]
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 6798990..d37f4c6 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -41,6 +41,9 @@ if ($git_version =~ m/git version (.*)$/
# location for temporary files needed for diffs
our $git_temp = "/tmp/gitweb";
+if (! -d $git_temp) {
+ mkdir($git_temp, 0700) || die_error("Couldn't mkdir $git_temp");
+}
# target of the home link on top of all pages
our $home_link = $my_uri;
--
1.4.1.g35dbd
^ permalink raw reply related
* Re: [PATCH] Fix some doubled word typos
From: Junio C Hamano @ 2006-07-10 2:04 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <44B1B093.9000201@atoker.com>
Alp Toker <alp@atoker.com> writes:
> I hadn't realised that git-svn work was happening on a topic
> branch. In light of that, it makes perfect sense to split out the
> commit as you did. It's good to hear that git isn't just truncating
> patches.
No, what would happen (if I were not careful) if I try to apply
it to "master" would be that "git am" would refuse to touch any
file. IOW, it tries to apply the patches atomically. Not
truncating or omitting patches is one of the most important
things git needs to do correctly so it had better work right
;-).
^ permalink raw reply
* Re: [PATCH] Fix some doubled word typos
From: Alp Toker @ 2006-07-10 1:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodvye10h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Actually, I am a bit more careful than that ;-).
>
> I have split your patch into two, and applied the part that
> applicable to "master" first. The tip of ew/svn topic branch (I
> do not publish topic branch tips) have two patches that are
> still not in even "pu", and one of these two patches is your
> Documentation/git-svn.txt patch. These two will appear in
> "next" hopefully soon -- I just haven't gotten around to them.
I hadn't realised that git-svn work was happening on a topic branch. In
light of that, it makes perfect sense to split out the commit as you
did. It's good to hear that git isn't just truncating patches.
Cheers.
^ permalink raw reply
* Re: [PATCH] Fix some doubled word typos
From: Junio C Hamano @ 2006-07-10 0:50 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <44B1A01F.5090408@atoker.com>
Alp Toker <alp@atoker.com> writes:
> My patch was made against the 'next' branch, where the file had
> recently been moved to Documentation/git-svn.txt, but it was applied
> to the 'master' branch where the file still exists at
> contrib/git-svn/git-svn.txt as it has not yet been moved.
Actually, I am a bit more careful than that ;-).
I have split your patch into two, and applied the part that
applicable to "master" first. The tip of ew/svn topic branch (I
do not publish topic branch tips) have two patches that are
still not in even "pu", and one of these two patches is your
Documentation/git-svn.txt patch. These two will appear in
"next" hopefully soon -- I just haven't gotten around to them.
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Junio C Hamano @ 2006-07-10 0:39 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060709222308.GA4153@h4x0r5.com>
Ryan Anderson <ryan@michonline.com> writes:
> Comments on a way to make the Makefile less repetitive would be
> appreciated, though.
One obvious way would be not to have scm/Makefile but have the
dependencies in the main Makefile to say (the moral equivalent
of):
git-archimport.perl: scm/git-archimport.perl
^ permalink raw reply
* Re: [PATCH] Fix some doubled word typos
From: Alp Toker @ 2006-07-10 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11524377844177-git-send-email-alp@atoker.com>
Alp Toker wrote:
> Signed-off-by: Alp Toker <alp@atoker.com>
> ---
> Documentation/git-svn.txt | 2 +-
> Documentation/urls.txt | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
My patch was made against the 'next' branch, where the file had recently
been moved to Documentation/git-svn.txt, but it was applied to the
'master' branch where the file still exists at
contrib/git-svn/git-svn.txt as it has not yet been moved.
As a result, it seems that only the modification to
Documentation/urls.txt in this patch made it into the repository, with
the fix to Documentation/git-svn.txt having been silently omitted.
By the time the commit was merged from 'master' to 'next', it had
permanently lost the modification to git-svn.txt, and even though the
commit message claims to "Fix some doubled word typos" it only fixes one.
Could this situation have been avoided if the patch had mentioned that
it was against the 'next' branch? Should/does git warn the user if a
patch modifies files that don't exist? Would rename tracking have helped
this patch to apply properly?
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Ryan Anderson @ 2006-07-10 0:20 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: pasky, martin.langhoff, git
In-Reply-To: <20060710013405.54fbe6bb.tihirvon@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
Timo Hirvonen wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>
>
>> I've been meaning to do something like this for some time already; my
>> itch have been the builtins. The tree size _is_ getting out of hand and
>> a little more categorization of the sources would certainly help.
>> Although I'd take a different approach:
>>
>> libgit/
>> builtin/
>> standalone/
>> scripts/
>>
>
> Please don't. One directory is much easier to work with. At least
> don't split the Makefile. Also moving files makes "git log <file>"
> stop at the rename.
>
By "don't split the Makefile", do mean, "Don't use recursive make"?
I'm fine with that (and if you look at my patch, I "include
scm/Makefile" to do just that), but if you mean "keep only a top-level
Makefile", well, I think that continues the problem of "there is too
much stuff going on here", but I can be persuaded otherwise.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [BUGFIX][RESEND]git-cvsexportcommit can't handle merge commits correctly
From: Martin Langhoff (CatalystIT) @ 2006-07-09 23:12 UTC (permalink / raw)
To: Peter Baumann; +Cc: git, Junio C Hamano
In-Reply-To: <20060707105541.GA17004@xp.machine.xx>
Peter Baumann wrote:
> git-cvsexportcommit should check if the parent (supplied on the cmdline) to use
> for a merge commit is one of the real parents of the merge.
>
> But it errors out if the _first_ parent doesn't match and never checks
> the other parents.
>
Ack. Thanks for spotting this!
m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Timo Hirvonen @ 2006-07-09 22:34 UTC (permalink / raw)
To: pasky; +Cc: martin.langhoff, ryan, git
In-Reply-To: <20060709221326.GU29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.
> Although I'd take a different approach:
>
> libgit/
> builtin/
> standalone/
> scripts/
Please don't. One directory is much easier to work with. At least
don't split the Makefile. Also moving files makes "git log <file>"
stop at the rename.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: What *have* I done?
From: Nix @ 2006-07-09 22:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060709212113.GS29115@pasky.or.cz>
On Sun, 9 Jul 2006, Petr Baudis yowled:
> Hi,
>
> Dear diary, on Sun, Jul 09, 2006 at 12:48:22AM CEST, I got a letter
> where Nix <nix@esperi.org.uk> said that...
>> loki 593 /usr/packages/linux/linux% cg-diff | diffstat
>
> Note that cg-diff -s might be useful.
Indeed :)
>> loki 594 /usr/packages/linux/linux% cg-reset
>> loki 595 /usr/packages/linux/linux% cg-diff
>> loki 596 /usr/packages/linux/linux%
>
> ...but when you switch away and switch back, the uncommitted changes
> appear again?
Yes.
> Just in case, don't the tree happen to simply stay the same as in the
> branch you switched from? (Try cg-diff -r yourpreviousbranch.)
Yes. Also, that branch (which was forked recently from the misbehaving
one) claims that all changes are merged from that branch, but this is
demonstrably untrue.
> And most importantly, does this also happen with just stock 0.17.3
> cg-switch? With stock master cg-switch? (If both is no, you probably
> forgot to cherrypick some associated cg-switch bugfix or something.)
This is 0.17.3 cg-switch plus the seek speedup 40f8a28806a1c5a7cb1f7d137f1bb271b71f890f.
(I doubt that's to blame, but I've been wrong before.)
I think the oddity is related to git-cherry-pick somehow, but I'm
not sure how: I took the original upstream pack again, rebuilt the
branches from scratch and now I can't make the problem happen anymore.
If it happens again I'll keep the tree around and collect more data.
(I'll have to dig some more disk space up...)
--
`She *is*, however, one of the few sf authors with a last name ending in O,
which adds some extra appeal to those of us who obsess about things like
having a book review of an author for each letter in the alphabet.' -- rra
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Ryan Anderson @ 2006-07-09 22:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, Ryan Anderson, git
In-Reply-To: <20060709221326.GU29115@pasky.or.cz>
On Mon, Jul 10, 2006 at 12:13:26AM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> said that...
> > So I have to ask... what are the expected benefits of the move?
>
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.
That's what I was thinking, as well, basically. I started with the "scm
interop" tools because they should be the least controversial to move
around.
> Although I'd take a different approach:
>
> libgit/
> builtin/
> standalone/
> scripts/
>
> > In any case, use /interop instead. /scm in the tree of an SCM could be
> > anything ;-)
>
> I agree on this point.
Very good point.
So these seem obvious to me:
libgit/ (maybe just lib/?)
builtin/
interop/
I'm less sure of the rest, but I'll poke at doing the above for the
moment, and worry about the rest later.
Comments on a way to make the Makefile less repetitive would be
appreciated, though.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: git on HP-UX
From: Petr Baudis @ 2006-07-09 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vfyhe465i.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 07, 2006 at 02:20:41AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> > I hope the Autoconf based configure is on its way to git, but I don't
> > see in in the "pu" branch yet. I'm not very keen about reinventing
> > Autoconf and hacking a hand-made configure script.
>
> OK, you half-convinced me. The other half came from a recent
> series of patches to try using 'which' to detect executables,
> which is another common mistake handcrafted configure script
> makes, which autoconf people have solved for us long time ago.
Good! In fact, I have been a moderate autoconf fan and originally I have
meant the hand-crafted ./configure script partially just as a tease and
a nominal competitor for the autoconf one, so that we would for sure got
_some_ autoconfiguration mechanism (which is what I care about).
I have to admit that I have grown somewhat attached to my script over
time and I like it a lot more than the autoconf thing personally, but
then again I had no idea that we actually want to support such systems
like those with broken which...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Johannes Schindelin @ 2006-07-09 22:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, Ryan Anderson, git
In-Reply-To: <20060709221326.GU29115@pasky.or.cz>
Hi,
On Mon, 10 Jul 2006, Petr Baudis wrote:
> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> said that...
> > So I have to ask... what are the expected benefits of the move?
>
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.
Funny. I thought the builtin-* prefix, and the *.sh and *.perl extensions
were there for the sake of categorization.
And I disagree on the "out of hand" thing.
Ciao,
Dscho
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Alex Riesen @ 2006-07-09 22:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607090827430.5623@g5.osdl.org>
Linus Torvalds, Sun, Jul 09, 2006 17:30:26 +0200:
> > > > The basic idea is that "branch1" should be your current branch, and it
> > > > obviously is also expected to match (more or less) the current index. So
> > > > you can do a merge by
> > > >
> > > > - reading in "branch1" into the index:
> > > >
> > > > GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
> > >
> > > what is "-m" here for?
> >
> > It means that git-read-tree tries to merge the current index with branch1.
>
> Well, the current index always "merges" by just taking the timestamps from
> it. The actual _content_ doesn't matter for the single-tree case.
But the name suggests it's a temporary index, which would not have
anything in it and even the .git/tmp-index is not supposed to exist.
So I'd actually understand this as creating an index from the tree-ish
branch1, without merging anything. And continue wondering what that -m
is for...
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Petr Baudis @ 2006-07-09 22:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Ryan Anderson, git
In-Reply-To: <46a038f90607091426u5a6ea328h2090a876e51725ce@mail.gmail.com>
Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> So I have to ask... what are the expected benefits of the move?
I've been meaning to do something like this for some time already; my
itch have been the builtins. The tree size _is_ getting out of hand and
a little more categorization of the sources would certainly help.
Although I'd take a different approach:
libgit/
builtin/
standalone/
scripts/
> In any case, use /interop instead. /scm in the tree of an SCM could be
> anything ;-)
I agree on this point.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-09 22:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Marco Costalba, git
In-Reply-To: <20060709220116.GT29115@pasky.or.cz>
Hi,
On Mon, 10 Jul 2006, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Sun, Jul 09, 2006 at 04:33:53PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > On Sun, 9 Jul 2006, Marco Costalba wrote:
> >
> > > It is possible to add a message (and more) to a tag creating a tag
> > > object. FWIK this is not allowed for the other refs.
> > >
> > > Why there is this (artifical?) difference between tags and the other
> > > kind of refs?
> >
> > The tag message is nothing else than a commit message.
>
> huh?
>
> The tag message is a message in the "freeform" part of the tag object,
> but disregarding the format similiraties, it has really nothing to do
> with a commit message. (Also, commit messages don't tend to be commonly
> PGP signed. ;-)
Marco was talking about an "artificial difference", which means technical
issues. From a technical viewpoint, the tag message is _exactly_ the same
as a commit message.
Hth,
Dscho
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Petr Baudis @ 2006-07-09 22:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, git
In-Reply-To: <Pine.LNX.4.63.0607091632070.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sun, Jul 09, 2006 at 04:33:53PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sun, 9 Jul 2006, Marco Costalba wrote:
>
> > It is possible to add a message (and more) to a tag creating a tag
> > object. FWIK this is not allowed for the other refs.
> >
> > Why there is this (artifical?) difference between tags and the other
> > kind of refs?
>
> The tag message is nothing else than a commit message.
huh?
The tag message is a message in the "freeform" part of the tag object,
but disregarding the format similiraties, it has really nothing to do
with a commit message. (Also, commit messages don't tend to be commonly
PGP signed. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Martin Langhoff @ 2006-07-09 21:26 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11524258261798-git-send-email-ryan@michonline.com>
On 7/9/06, Ryan Anderson <ryan@michonline.com> wrote:
> This is the first in a series to categorize the source tree a little bit more
> than it is currently.
Given that you title it RFC, I guess it hasn't been discussed before.
I personally don't see much benefit from the move/rename. The tree is
not so large, the SCM import/export utilities are a single file each
and their names are quite clear. Having /contrib is more an issue of
marking utilities there as 'new, experimental, unsupported', and the
assumption is that when something matures it moves out of /contrib.
So I have to ask... what are the expected benefits of the move?
In any case, use /interop instead. /scm in the tree of an SCM could be
anything ;-)
martin
^ permalink raw reply
* Re: What *have* I done?
From: Petr Baudis @ 2006-07-09 21:21 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87u05ru30p.fsf@hades.wkstn.nix>
Hi,
Dear diary, on Sun, Jul 09, 2006 at 12:48:22AM CEST, I got a letter
where Nix <nix@esperi.org.uk> said that...
> loki 593 /usr/packages/linux/linux% cg-diff | diffstat
Note that cg-diff -s might be useful.
> loki 594 /usr/packages/linux/linux% cg-reset
> loki 595 /usr/packages/linux/linux% cg-diff
> loki 596 /usr/packages/linux/linux%
...but when you switch away and switch back, the uncommitted changes
appear again?
Just in case, don't the tree happen to simply stay the same as in the
branch you switched from? (Try cg-diff -r yourpreviousbranch.)
And most importantly, does this also happen with just stock 0.17.3
cg-switch? With stock master cg-switch? (If both is no, you probably
forgot to cherrypick some associated cg-switch bugfix or something.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Jan-Benedict Glaw @ 2006-07-09 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michal Rokos, git
In-Reply-To: <7v4pxqfri7.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
On Sun, 2006-07-09 13:33:04 -0700, Junio C Hamano <junkio@cox.net> wrote:
> Michal Rokos <michal.rokos@nextsoft.cz> writes:
> > On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
> >> Michal, is there a reason you do not want to have the version of
> >> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
> >
> > I have no problem with that. I can set $PATH.
> > But then I'd suggest to change magic #!
> > from #!/usr/bin/perl
> > to #!/usr/bin/env perl
> > for *.perl
> >
> > It that what you meant?
>
> No, that is not what I meant.
Though I think you actually should :-)
> Invocation of perl _in_ scripts can be controlled by user's
> PATH, but #! cannot be. As Merlyn says 'env' is a nice hack,
> but we configure the scripts we install to have #! pointing at
> the right interpreter as a more cleaner (than using 'env', that
> is) workaround anyway, so #! pointing at PERL_PATH and scripts
> relying on user's $PATH would be the right thing to do.
It's just a question of the target system, so: What is our target? If
we target a fairly recent Unix box, we'd put whatever a user asked for
into the shellbang, and hope that he properly sets $PATH.
If we try to aim at POSIX systems, then first of all, `env' isn't a
hack. It's specified i the POSIX documents, even argument passing is
given. (So if `#!/usr/bin/env perl -w' doesn't work on a HP-UX system,
that's simply broken wrt. POSIX.)
At the maximum, we'd allow the user to supply the location of `env' if
it's not /usr/bin/env, but I guess you'll find a hard time finding a
system where there's no /usr/bin/env... The final killer would be to
explicitely mention the interpreter and install all scripts a-x to
force that :-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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