* [PATCH 2/3] gitweb: Add generic git_object subroutine to display object of any type
From: Jakub Narebski @ 2006-12-10 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
Add generic "object" view implemented in git_object subroutine, which is
used to display object of any type; to be more exact it redirects to the
view of correct type: "blob", "tree", "commit" or "tag". To identify object
you have to provide either hash (identifier of an object), or (in the case of
tree and blob objects) hash of commit object (hash_base) and path (file_name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
First version had checking if $hash and $hash_base are explicit SHA-1
if are defined. This version doesn't have this check, which is
important for next patch.
gitweb/gitweb.perl | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0c2cfc7..a988f85 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -434,6 +434,7 @@ my %actions = (
"tags" => \&git_tags,
"tree" => \&git_tree,
"snapshot" => \&git_snapshot,
+ "object" => \&git_object,
# those below don't need $project
"opml" => \&git_opml,
"project_list" => \&git_project_list,
@@ -3620,6 +3621,53 @@ sub git_commit {
git_footer_html();
}
+sub git_object {
+ # object is defined by:
+ # - hash or hash_base alone
+ # - hash_base and file_name
+ my $type;
+
+ # - hash or hash_base alone
+ if ($hash || ($hash_base && !defined $file_name)) {
+ my $object_id = $hash || $hash_base;
+
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command cat-file -t $object_id 2>/dev/null"
+ or die_error('404 Not Found', "Object does not exist");
+ $type = <$fd>;
+ chomp $type;
+ close $fd
+ or die_error('404 Not Found', "Object does not exist");
+
+ # - hash_base and file_name
+ } elsif ($hash_base && defined $file_name) {
+ $file_name =~ s,/+$,,;
+
+ system(git_cmd(), "cat-file", '-e', $hash_base) == 0
+ or die_error('404 Not Found', "Base object does not exist");
+
+ # here errors should not hapen
+ open my $fd, "-|", git_cmd(), "ls-tree", $hash_base, "--", $file_name
+ or die_error(undef, "Open git-ls-tree failed");
+ my $line = <$fd>;
+ close $fd;
+
+ #'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
+ unless ($line && $line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t/) {
+ die_error('404 Not Found', "File or directory for given base does not exist");
+ }
+ $type = $2;
+ $hash = $3;
+ } else {
+ die_error('404 Not Found', "Not enough information to find object");
+ }
+
+ print $cgi->redirect(-uri => href(action=>$type, -full=>1,
+ hash=>$hash, hash_base=>$hash_base,
+ file_name=>$file_name),
+ -status => '302 Found');
+}
+
sub git_blobdiff {
my $format = shift || 'html';
--
1.4.4.1
^ permalink raw reply related
* [PATCH 3/3] gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
From: Jakub Narebski @ 2006-12-10 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
Make symbolic link target in "tree" view into hyperlink to generic
"object" view (as we don't know if the link target is file (blob) or
directory (tree), and if it exist at all).
Target of link is made into hyperlink when:
* hash_base is provided (otherwise we cannot find hash
of link target)
* link is relative
* in no place link goes out of root tree (top dir)
Full path of symlink target from the root dir is provided in the title
attribute of hyperlink.
Currently symbolic link name uses ordinary file style (hidden
hyperlink), while the hyperlink to symlink target uses default
hyperlink style, so it is underlined while link target which is not
made into hyperlink is not underlined.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio C Hamano wrote:
> In other words, I think trying to be lazy is extremely important
> while drawing a big list.
This implements "lazy" hyperlinking of symbolic link target in "tree"
view.
gitweb/gitweb.perl | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a988f85..6493311 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2008,6 +2008,48 @@ sub git_get_link_target {
return $link_target;
}
+# given link target, and the directory (basedir) the link is in,
+# return target of link relative to top directory (top tree);
+# return undef if it is not possible (including absolute links).
+sub normalize_link_target {
+ my ($link_target, $basedir, $hash_base) = @_;
+
+ # we can normalize symlink target only if $hash_base is provided
+ return unless $hash_base;
+
+ # absolute symlinks (beginning with '/') cannot be normalized
+ return if (substr($link_target, 0, 1) eq '/');
+
+ # normalize link target to path from top (root) tree (dir)
+ my $path;
+ if ($basedir) {
+ $path = $basedir . '/' . $link_target;
+ } else {
+ # we are in top (root) tree (dir)
+ $path = $link_target;
+ }
+
+ # remove //, /./, and /../
+ my @path_parts;
+ foreach my $part (split('/', $path)) {
+ # discard '.' and ''
+ next if (!$part || $part eq '.');
+ # handle '..'
+ if ($part eq '..') {
+ if (@path_parts) {
+ pop @path_parts;
+ } else {
+ # link leads outside repository (outside top dir)
+ return;
+ }
+ } else {
+ push @path_parts, $part;
+ }
+ }
+ $path = join('/', @path_parts);
+
+ return $path;
+}
# print tree entry (row of git_tree), but without encompassing <tr> element
sub git_print_tree_entry {
@@ -2029,7 +2071,15 @@ sub git_print_tree_entry {
if (S_ISLNK(oct $t->{'mode'})) {
my $link_target = git_get_link_target($t->{'hash'});
if ($link_target) {
- print " -> " . esc_path($link_target);
+ my $norm_target = normalize_link_target($link_target, $basedir, $hash_base);
+ if (defined $norm_target) {
+ print " -> " .
+ $cgi->a({-href => href(action=>"object", hash_base=>$hash_base,
+ file_name=>$norm_target),
+ -title => $norm_target}, esc_path($link_target));
+ } else {
+ print " -> " . esc_path($link_target);
+ }
}
}
print "</td>\n";
--
1.4.4.1
^ permalink raw reply related
* [PATCH/RFC 4/3] gitweb: SHA-1 in commit log message links to "object" view
From: Jakub Narebski @ 2006-12-10 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
Instead of checking if explicit SHA-1 in commit log message is sha1 of
commit and making link to "commit" view, make [fragment of] explicit
SHA-1 in commit log message link to "object" view. While at it allow
to hyperlink also shortened SHA-1, from 8 characters up to full SHA-1,
instead of requiring full 40 characters of SHA-1.
This makes the following changes:
* SHA-1 of objects which no longer exists, for example in commit
cherry-picked from no longer existing temporary branch, or revert
of commit in rebased branch, are no longer marked as such by not
being made into hyperlink (and not having default hyperlink view:
being underlined among others). On the other hand it makes gitweb
to not write error messages when object is not found to web serwer
log; it also moves cost of getting type and SHA-1 validation to
when link is clicked, and not only viewed.
* SHA-1 of other objects: blobs, trees, tags are also hyperlinked
and lead to appropriate view (although in the case of tags it is
more natural to just use tag name).
* You can put shortened SHA-1 of commit in the commit message, and it
would be hyperlinked; it would be checked on clicking if abbrev is
unique.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This follows the "lazy hyperlink" idea of symbolic link support in the
"tree" view.
It is an RFC (Requests For Comments) because I'm not sure if it
wouldn't be better to make dead SHA-1 marked in commit log message,
instead of finfing it out after clicking...
gitweb/gitweb.perl | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6493311..7d24c10 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -828,14 +828,12 @@ sub format_log_line_html {
my $line = shift;
$line = esc_html($line, -nbsp=>1);
- if ($line =~ m/([0-9a-fA-F]{40})/) {
+ if ($line =~ m/([0-9a-fA-F]{8,40})/) {
my $hash_text = $1;
- if (git_get_type($hash_text) eq "commit") {
- my $link =
- $cgi->a({-href => href(action=>"commit", hash=>$hash_text),
- -class => "text"}, $hash_text);
- $line =~ s/$hash_text/$link/;
- }
+ my $link =
+ $cgi->a({-href => href(action=>"object", hash=>$hash_text),
+ -class => "text"}, $hash_text);
+ $line =~ s/$hash_text/$link/;
}
return $line;
}
--
1.4.4.1
^ permalink raw reply related
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-10 12:41 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612101109.34267.jnareb@gmail.com>
Jakub Narebski wrote:
> P.S. Any hints to how to do this with CGI Perl module?
It's impossible, Apache doesn't supply e-tag info to CGI programs. (it
does supply HTTP_CACHE_CONTROL though apparently)
You could probably do it via mod_perl.
Jeff
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-10 13:02 UTC (permalink / raw)
To: Jeff Garzik
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457C0060.3050605@garzik.org>
Jeff Garzik wrote:
> Jakub Narebski wrote:
>>
>> P.S. Any hints to how to do this with CGI Perl module?
>
> It's impossible, Apache doesn't supply e-tag info to CGI programs. (it
> does supply HTTP_CACHE_CONTROL though apparently)
By ETag info you mean access to HTTP headers sent by browser
If-Modified-Since:, If-Match:, If-None-Match: do you?
It's a pity that CGI interface doesn't cover that...
> You could probably do it via mod_perl.
So the cache verification should be wrapped in if ($ENV{MOD_PERL}) ?
--
Jakub Narebski
^ permalink raw reply
* Using GIT to store /etc (Or: How to make GIT store all file permission bits)
From: Kyle Moffett @ 2006-12-10 13:40 UTC (permalink / raw)
To: git
I've recently become somewhat interested in the idea of using GIT to
store the contents of various folders in /etc. However after a bit
of playing with this, I discovered that GIT doesn't actually preserve
all permission bits since that would cause problems with the more
traditional software development model. I'm curious if anyone has
done this before; and if so, how they went about handling the
permissions and ownership issues.
I spent a little time looking over how GIT stores and compares
permission bits; trying to figure out if it's possible to patch in a
new configuration variable or two; say "preserve_all_perms" and
"preserve_owner", or maybe even "save_acls". It looks like standard
permission preservation is fairly basic; you would just need to patch
a few routines which alter the permissions read in from disk or
compare them with ones from the database. On the other hand, it
would appear that preserving ownership or full POSIX ACLs might be a
bit of a challenge.
Thanks for your insight and advice!
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-10 13:45 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612101402.51363.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]
Jakub Narebski wrote:
> Jeff Garzik wrote:
>> Jakub Narebski wrote:
>>> P.S. Any hints to how to do this with CGI Perl module?
>> It's impossible, Apache doesn't supply e-tag info to CGI programs. (it
>> does supply HTTP_CACHE_CONTROL though apparently)
>
> By ETag info you mean access to HTTP headers sent by browser
> If-Modified-Since:, If-Match:, If-None-Match: do you?
You can use this attached shell script as a CGI script, to see precisely
what information Apache gives you. You can even experiment with passing
back headers other than Content-type (such as E-tag), to see what sort
of results are produced. The script currently passes back both E-Tag
and Last-Modified of a sample file; modify or delete those lines to suit
your experiments.
> It's a pity that CGI interface doesn't cover that...
>
>> You could probably do it via mod_perl.
>
> So the cache verification should be wrapped in if ($ENV{MOD_PERL}) ?
Sorry, I was /assuming/ mod_perl would make this available. The HTTP
header info is available to all Apache modules, but I confess I have no
idea how mod_perl passes that info to scripts.
Also, an interesting thing while I was testing the attached shell
script: even though repeated hits to the script generate a proper 304
response to the browse, the CGI script and its output run to completion.
So, it didn't save work on the CGI side; the savings was solely in not
transmitting the document from server to client. The server still went
through the work of generating the document (by running the CGI), as one
would expect.
Jeff
[-- Attachment #2: fenv --]
[-- Type: text/plain, Size: 317 bytes --]
#!/bin/sh
FN=/tmp/foo
if [ ! -f "$FN" ]
then
echo "blah blah blah" > "$FN"
fi
HASH=`md5sum "$FN"`
echo "Content-type: text/plain"
echo "E-tag: $HASH"
echo Last-Modified: `date -r /tmp/foo '+%a, %d %b %Y %T %Z'`
echo ""
# don't pollute server environment output with our local additions
unset FN
unset HASH
set
^ permalink raw reply
* *** SPAM ***
From: Clemens Buchacher @ 2006-12-10 13:57 UTC (permalink / raw)
To: git
Make sure $EDITOR is executed as a command
---
commit 942341e051fdcbb77a6abfbc58cf08ef8cab388d
tree 96e8fd08cdc7c59b0d3d55d7cb5b4302db443aff
parent b6a6e87cb3e1368ad0f78c18fdb6c29dde4ae83e
author Clemens Buchacher <drizzd@aon.at> Sun, 10 Dec 2006 14:37:37 +0100
committer Clemens Buchacher <drizzd@aon.at> Sun, 10 Dec 2006 14:37:37 +0100
cg-Xlib | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index c1262bf..9d04eb4 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -568,7 +568,7 @@ _editor()
actionname="$1"; shift
actionkey="$1"; shift
- ${EDITOR:-vi} "$LOGMSG2"
+ command ${EDITOR:-vi} "$LOGMSG2"
[ -z "$force" ] || return 0
[ ! "$LOGMSG2" -nt "$LOGMSG" ] || return 0
^ permalink raw reply related
* Re: [PATCH] editor: make sure $EDITOR is executed as a command
From: Clemens Buchacher @ 2006-12-10 14:04 UTC (permalink / raw)
To: git
In-Reply-To: <20061210135753.GA12905@kzelldran.dyndns.org>
Hi,
Sorry about the missing subject.
Make sure $EDITOR is executed as a command. Otherwise, _editor may fail if
$EDITOR is set to something like 'editor', which is also a function within
cg-Xlib.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
commit 942341e051fdcbb77a6abfbc58cf08ef8cab388d
tree 96e8fd08cdc7c59b0d3d55d7cb5b4302db443aff
parent b6a6e87cb3e1368ad0f78c18fdb6c29dde4ae83e
author Clemens Buchacher <drizzd@aon.at> Sun, 10 Dec 2006 14:37:37 +0100
committer Clemens Buchacher <drizzd@aon.at> Sun, 10 Dec 2006 14:37:37 +0100
cg-Xlib | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index c1262bf..9d04eb4 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -568,7 +568,7 @@ _editor()
actionname="$1"; shift
actionkey="$1"; shift
- ${EDITOR:-vi} "$LOGMSG2"
+ command ${EDITOR:-vi} "$LOGMSG2"
[ -z "$force" ] || return 0
[ ! "$LOGMSG2" -nt "$LOGMSG" ] || return 0
^ permalink raw reply related
* Re: Easy shell question: how to make a script killing all his childs when killed?
From: Alex Riesen @ 2006-12-10 14:25 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550612091506g41e40e87n6356b8ddd5e16a5d@mail.gmail.com>
Marco Costalba, Sun, Dec 10, 2006 00:06:34 +0100:
> On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:
> >
> >Why do you need to save it in temporary file at all? Why don't you
> >read the output like gitk does? You can take a look at popen(3). It's
> >known to be portable among operating systems and libc's. Or, BTW, why
> >don't you just read qprocess.h, use processIdentifier()/pid(),
> >read*()-methods and the like? (though, looking at the QProcess in
> >qt3, I wouldn't really blame you)
> >
>
> Well, I _used_ QProcess interface until last week. It's socket based
> and it's quite fast (much more then gitk BTW), but due to some
> internal buffering not so fast as reading from a file (in my last post
> regarding git-rev-list access there are some performance numbers to
> document this). It seems that socket/pipe based IPC is not as fast as
> file write/read. Of course we are talking of OS cached files, no disk
> access must be involved to keep the speed.
Oh, I see now ("Fast access git-rev-list output...").
BTW, I just cannot reproduce that at all (on Linux):
time { git rev-list --all > /tmp/ggg; cat /tmp/ggg >/dev/null; }
tends to be somewhat slower than
time git rev-list --all | cat >/dev/null
QProcess must be doing something stupid.
> Regarding gitk we are at least one order of magnitude faster both with
> QProcess and, more, with temporary files, so it's not a useful
> reference in this case.
Dunno. It's hard to assess on "small" repos, like kernel. They feel
almost equally fast (maybe because qgit checks working directory too).
Haven't tried QGit on Windows yet (does it work there?).
> P.S: I didn't experiment with popen(). Thanks for the hint, I will
> give it a try ;-)
popen(3) usually uses pipe(2). It's also awkward with regard to
shell metacharacters and signals (as system(3) is). You can use your'
own buffers (setvbuf) so that could be a win against QProcess.
^ permalink raw reply
* Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)
From: Jeff Garzik @ 2006-12-10 14:49 UTC (permalink / raw)
To: Kyle Moffett; +Cc: git
In-Reply-To: <787BE48C-1808-4A33-A368-5E8A3F00C787@mac.com>
Kyle Moffett wrote:
> I've recently become somewhat interested in the idea of using GIT to
> store the contents of various folders in /etc. However after a bit of
> playing with this, I discovered that GIT doesn't actually preserve all
> permission bits since that would cause problems with the more
> traditional software development model. I'm curious if anyone has done
> this before; and if so, how they went about handling the permissions and
> ownership issues.
>
> I spent a little time looking over how GIT stores and compares
> permission bits; trying to figure out if it's possible to patch in a new
> configuration variable or two; say "preserve_all_perms" and
> "preserve_owner", or maybe even "save_acls". It looks like standard
> permission preservation is fairly basic; you would just need to patch a
> few routines which alter the permissions read in from disk or compare
> them with ones from the database. On the other hand, it would appear
> that preserving ownership or full POSIX ACLs might be a bit of a challenge.
It's a great idea, something I would like to do, and something I've
suggested before. You could dig through the mailing list archives, if
you're motivated.
I actively use git to version, store and distribute an exim mail
configuration across six servers. So far my solution has been a 'fix
perms' script, or using the file perm checking capabilities of cfengine.
But it would be a lot better if git natively cared about ownership and
permissions (presumably via an option).
Jeff
^ permalink raw reply
* Re: [RFC \ WISH] Add -o option to git-rev-list
From: Alex Riesen @ 2006-12-10 14:54 UTC (permalink / raw)
To: Marco Costalba
Cc: Git Mailing List, Junio C Hamano, Shawn Pearce, Linus Torvalds
In-Reply-To: <e5bfff550612100338ye2ca2a0u1c8f29bbc59c5431@mail.gmail.com>
Marco Costalba, Sun, Dec 10, 2006 12:38:42 +0100:
> So my request is if it is possible to make git-rev-list write
> _directly_ to a file, without shell redirection, I would ask if it is
> possible:
Well, it is usually possible to redirect stdout directly into a file
(see dup2). "Usually", unless you want windows which as always has
it's own stupid way of doing simple things. Nevertheless, it's
possible to do it without ever touching rev-list.
> I understand this could be not exactly a top priority feature for git
> people, but I would really like to get the best possible interface
> with the plumbing git and the -o options is also a very common one.
Sadly, you're right. Almost every command-line program got the option.
What education could have caused this, I wonder...
> P.S: On another thread I explained why I see problematic linking
> directly against libgit.a
It still is the fastest you can get.
^ permalink raw reply
* Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)
From: Santi Béjar @ 2006-12-10 15:06 UTC (permalink / raw)
To: Kyle Moffett; +Cc: git
In-Reply-To: <787BE48C-1808-4A33-A368-5E8A3F00C787@mac.com>
On 12/10/06, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> I've recently become somewhat interested in the idea of using GIT to
> store the contents of various folders in /etc. However after a bit
> of playing with this, I discovered that GIT doesn't actually preserve
> all permission bits since that would cause problems with the more
> traditional software development model. I'm curious if anyone has
> done this before; and if so, how they went about handling the
> permissions and ownership issues.
>
> I spent a little time looking over how GIT stores and compares
> permission bits; trying to figure out if it's possible to patch in a
> new configuration variable or two; say "preserve_all_perms" and
> "preserve_owner", or maybe even "save_acls". It looks like standard
> permission preservation is fairly basic; you would just need to patch
> a few routines which alter the permissions read in from disk or
> compare them with ones from the database. On the other hand, it
> would appear that preserving ownership or full POSIX ACLs might be a
> bit of a challenge.
>
> Thanks for your insight and advice!
I have not used it, but you could try:
http://www.isisetup.ch/
that uses git as a backend.
^ permalink raw reply
* Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)
From: Jakub Narebski @ 2006-12-10 15:30 UTC (permalink / raw)
To: git
In-Reply-To: <457C1E8E.4080407@garzik.org>
Jeff Garzik wrote:
> Kyle Moffett wrote:
>>
>> I've recently become somewhat interested in the idea of using GIT to
>> store the contents of various folders in /etc. However after a bit of
>> playing with this, I discovered that GIT doesn't actually preserve all
>> permission bits since that would cause problems with the more
>> traditional software development model. I'm curious if anyone has done
>> this before; and if so, how they went about handling the permissions and
>> ownership issues.
>>
>> I spent a little time looking over how GIT stores and compares
>> permission bits; trying to figure out if it's possible to patch in a new
>> configuration variable or two; say "preserve_all_perms" and
>> "preserve_owner", or maybe even "save_acls". It looks like standard
>> permission preservation is fairly basic; you would just need to patch a
>> few routines which alter the permissions read in from disk or compare
>> them with ones from the database. On the other hand, it would appear
>> that preserving ownership or full POSIX ACLs might be a bit of a challenge.
>
> It's a great idea, something I would like to do, and something I've
> suggested before. You could dig through the mailing list archives, if
> you're motivated.
>
> I actively use git to version, store and distribute an exim mail
> configuration across six servers. So far my solution has been a 'fix
> perms' script, or using the file perm checking capabilities of cfengine.
Fix perms' script used on a checkout hook is a best idea I think.
> But it would be a lot better if git natively cared about ownership and
> permissions (presumably via an option).
There is currently no place for ownership and extended attributes in
the tree object; and even full POSIX permissions might be challenge
because for example currently unused 'is socket' permission bit is
used for experimental commit-in-tree submodule support. And given Linus
stance that git is "content tracker"...
In the loooong thread "VCS comparison table" there was some talk
about using git (or any SCM) to manage /etc. Check out:
* Message-ID: <Pine.LNX.4.64.0610220926170.3962@g5.osdl.org>
http://permalink.gmane.org/gmane.comp.version-control.git/29765
* Message-ID: <20061023051932.GA8625@evofed.localdomain>
http://marc.theaimsgroup.com/?i=<20061023051932.GA8625@evofed.localdomain>
(and other messages in this subthread).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.
From: Robin Rosenberg @ 2006-12-10 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b7o8s5j.fsf@assigned-by-dhcp.cox.net>
söndag 10 december 2006 02:18 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> > This patch uses git-apply to do the patching which simplifies the code a
> > lot.
> >
> > Removed the test for checking for matching binary files when deleting
> > them since git-apply happily deletes the file. This is matter of taste
> > since we allow some fuzz for text patches also.
> >
> > Error handling was cleaned up, but not much tested.
>
> Interesting.
>
> I think you should be able to generate the patchfile once, and
> use git-apply to figure out additions, deletions and binaryness,
> and then use the same patchfile to apply the changes. Currently
> checking for binaryness is not easy with git-apply, so we would
> want to fix git-apply first, instead of forcing you to have a
> change like this:
>
> # the --binary format is harder to grok for names of binary
> # files so we execute a new diff
> # if it looks like binary files exists to find out
> if (grep /^GIT binary patch$/, @diff) {
> @binfiles = grep m/^Binary files/,
> safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
>
> which is way too ugly.
>
> ... goes to look and comes back, with a big grin ...
<grin> apparently
>
> Well, have you tried this?
>
> git diff-tree -p --binary fe142b3a | git apply --summary --numstat
of course not. I didn't understand it. Why can't it tell me about removed
binary files, so I could remove the git-diff-tree invocation to find out about
added/removed files?
> The numstat part would let you see the binaryness, so we do not
> have to "fix" git-apply.
>
> Another thing that _might_ be interesting is to use rename
> detection when preparing the patch, and make the matching rename
> on the CVS side, but I do not recall the details of how one
> would make CVS pretend to support renamed paths ;-). I think it
> involved copying the ,v file to a new name, and marking the
> older revisions in that new ,v file as nonexistent or something
> like that, but I did it only in my distant past and forgot the
> details.
In server mode, which is the normal way of using CVS you cannot
do this with the CVS most of us are used with. CvsNT does support
a rename command, I think, but I don't use it, partly due to rumors of it
being somewhat unstable. If there's any truth in that, I don't know.
Anyway, I don't practice the rename trick in CVS myself. I'm not sure how
that would work with the roundtripping via CVS that I do. cvsimport
detects "renames" with the current approach so I'm happy as is, not that I
rename files much. I also think there than a copy is needed to play nice,
like removing old tags from the copy, how about rename back and forth etc.
There's a reason people want to migrate from CVS, as well as there are
reasons not to hurry. CVS doesn't support rename, it's that simple.
> By the way, I am not sure if giving fuzz by default is such a
> good idea, though.
It was in the original. I don't know why. Maybe the original author can tell
us why it was important. It may be problematic to stay fully in sync with a
CVS repo because you have to git-cvsimport it first and that takes some time.
This fuzz gives some, but not much slack. Reverting the option could be a
good idea.
Update follows.
^ permalink raw reply
* [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.
From: Robin Rosenberg @ 2006-12-10 15:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200612101639.22397.robin.rosenberg@dewire.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 13412 bytes --]
From: Robin Rosenberg <robin.rosenberg@dewire.com>
This patch uses git-apply to do the patching which simplifies the code a lot.
Removed the test for checking for matching binary files when deleting them
since git-apply happily deletes the file. This is matter of taste since we
allow some fuzz for text patches also.
Error handling was cleaned up, but not much tested.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Updated patch using --numstat to figure which files are binary.
git-cvsexportcommit.perl | 158 +++++++++++-----------------------------
t/t9200-git-cvsexportcommit.sh | 108 ++++++++++++++++++++-------
2 files changed, 125 insertions(+), 141 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index c9d1d88..159af66 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -2,9 +2,8 @@
# Known limitations:
# - does not propagate permissions
-# - tells "ready for commit" even when things could not be completed
-# (not sure this is true anymore, more testing is needed)
-# - does not handle whitespace in pathnames at all.
+# - error handling has not been extensively tested
+#
use strict;
use Getopt::Std;
@@ -116,16 +115,13 @@ if ($opt_a) {
close MSG;
my (@afiles, @dfiles, @mfiles, @dirs);
-my %amodes;
-my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
-#print @files;
+my $files = safe_pipe_capture_blob('git-diff-tree', '-z', '-r', $parent, $commit);
$? && die "Error in git-diff-tree";
-foreach my $f (@files) {
- chomp $f;
- my @fields = split(m!\s+!, $f);
+while ($files =~ m/(.*?\000.*?\000)/g) {
+ my $f=$1;
+ my @fields = ( $f =~ m/^(\S+) (\S+) (\S+) (\S+) (\S+)\000(.*)\000/ );
if ($fields[4] eq 'A') {
my $path = $fields[5];
- $amodes{$path} = $fields[1];
push @afiles, $path;
# add any needed parent directories
$path = dirname $path;
@@ -141,20 +137,10 @@ foreach my $f (@files) {
push @dfiles, $fields[5];
}
}
-my (@binfiles, @abfiles, @dbfiles, @bfiles, @mbfiles);
-@binfiles = grep m/^Binary files/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
-map { chomp } @binfiles;
-@abfiles = grep s/^Binary files \/dev\/null and b\/(.*) differ$/$1/, @binfiles;
-@dbfiles = grep s/^Binary files a\/(.*) and \/dev\/null differ$/$1/, @binfiles;
-@mbfiles = grep s/^Binary files a\/(.*) and b\/(.*) differ$/$1/, @binfiles;
-push @bfiles, @abfiles;
-push @bfiles, @dbfiles;
-push @bfiles, @mbfiles;
-push @mfiles, @mbfiles;
+`git-diff-tree --binary -p $parent $commit >.cvsexportcommit.diff`;# || die "Cannot diff";
$opt_v && print "The commit affects:\n ";
$opt_v && print join ("\n ", @afiles,@mfiles,@dfiles) . "\n\n";
-undef @files; # don't need it anymore
# check that the files are clean and up to date according to cvs
my $dirty;
@@ -197,87 +183,36 @@ if ($dirty) {
}
}
-###
-### NOTE: if you are planning to die() past this point
-### you MUST call cleanupcvs(@files) before die()
-###
-
-
-print "Creating new directories\n";
-foreach my $d (@dirs) {
- unless (mkdir $d) {
- warn "Could not mkdir $d: $!";
- $dirty = 1;
- }
- `cvs add $d`;
- if ($?) {
- $dirty = 1;
- warn "Failed to cvs add directory $d -- you may need to do it manually";
- }
-}
-
-print "'Patching' binary files\n";
-
-foreach my $f (@bfiles) {
- # check that the file in cvs matches the "old" file
- # extract the file to $tmpdir and compare with cmp
- if (not(grep { $_ eq $f } @afiles)) {
- my $tree = safe_pipe_capture('git-rev-parse', "$parent^{tree}");
- chomp $tree;
- my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
- chomp $blob;
- `git-cat-file blob $blob > $tmpdir/blob`;
- if (system('cmp', '-s', $f, "$tmpdir/blob")) {
- warn "Binary file $f in CVS does not match parent.\n";
- if (not $opt_f) {
- $dirty = 1;
- next;
- }
- }
- }
- if (not(grep { $_ eq $f } @dfiles)) {
- my $tree = safe_pipe_capture('git-rev-parse', "$commit^{tree}");
- chomp $tree;
- my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
- chomp $blob;
- # replace with the new file
- `git-cat-file blob $blob > $f`;
- }
-
- # TODO: something smart with file modes
-
-}
-if ($dirty) {
- cleanupcvs(@files);
- die "Exiting: Binary files in CVS do not match parent";
-}
-
## apply non-binary changes
my $fuzz = $opt_p ? 0 : 2;
-print "Patching non-binary files\n";
+print "Patching\n";
-if (scalar(@afiles)+scalar(@dfiles)+scalar(@mfiles) != scalar(@bfiles)) {
- print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
-}
+my @stat;
+open APPLY, "GIT_DIR= git-apply -C$fuzz --binary --numstat --apply <.cvsexportcommit.diff|" || die "cannot patch";
+@stat=<APPLY>;
+close APPLY || die "Cannot patch";
+my @bfiles=grep { chomp && s/^\-\t\-\t(.*)$/$1/; } @stat;
+map { s/^"(.*)"$/$1/g } @bfiles;
+map { s/\\([\d]{3})/sprintf('%c',oct $1)/eg } @bfiles;
+print "Patch applied successfully. Adding new files and directories to CVS\n";
my $dirtypatch = 0;
-if (($? >> 8) == 2) {
- cleanupcvs(@files);
- die "Exiting: Patch reported serious trouble -- you will have to apply this patch manually";
-} elsif (($? >> 8) == 1) { # some hunks failed to apply
- $dirtypatch = 1;
+foreach my $d (@dirs) {
+ if (system('cvs','add',$d)) {
+ $dirtypatch = 1;
+ warn "Failed to cvs add directory $d -- you may need to do it manually";
+ }
}
foreach my $f (@afiles) {
- set_new_file_permissions($f, $amodes{$f});
if (grep { $_ eq $f } @bfiles) {
system('cvs', 'add','-kb',$f);
} else {
system('cvs', 'add', $f);
}
if ($?) {
- $dirty = 1;
+ $dirtypatch = 1;
warn "Failed to cvs add $f -- you may need to do it manually";
}
}
@@ -285,35 +220,40 @@ foreach my $f (@afiles) {
foreach my $f (@dfiles) {
system('cvs', 'rm', '-f', $f);
if ($?) {
- $dirty = 1;
+ $dirtypatch = 1;
warn "Failed to cvs rm -f $f -- you may need to do it manually";
}
}
print "Commit to CVS\n";
-print "Patch: $title\n";
-my $commitfiles = join(' ', @afiles, @mfiles, @dfiles);
-my $cmd = "cvs commit -F .msg $commitfiles";
+print "Patch title (first comment line): $title\n";
+my @commitfiles = map { unless (m/\s/) { '\''.$_.'\''; } else { $_; }; } (@afiles, @mfiles, @dfiles);
+my $cmd = "cvs commit -F .msg @commitfiles";
if ($dirtypatch) {
print "NOTE: One or more hunks failed to apply cleanly.\n";
- print "Resolve the conflicts and then commit using:\n";
+ print "You'll need to apply the patch in .cvsexportcommit.diff manually\n";
+ print "using a patch program. After applying the patch and resolving the\n";
+ print "problems you may commit using:";
print "\n $cmd\n\n";
exit(1);
}
-
if ($opt_c) {
print "Autocommit\n $cmd\n";
print safe_pipe_capture('cvs', 'commit', '-F', '.msg', @afiles, @mfiles, @dfiles);
if ($?) {
- cleanupcvs(@files);
die "Exiting: The commit did not succeed";
}
print "Committed successfully to CVS\n";
} else {
print "Ready for you to commit, just run:\n\n $cmd\n";
}
+
+# clean up
+unlink(".cvsexportcommit.diff");
+unlink(".msg");
+
sub usage {
print STDERR <<END;
Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [-f] [-m msgprefix] [ parent ] commit
@@ -321,17 +261,6 @@ END
exit(1);
}
-# ensure cvs is clean before we die
-sub cleanupcvs {
- my @files = @_;
- foreach my $f (@files) {
- system('cvs', '-q', 'update', '-C', $f);
- if ($?) {
- warn "Warning! Failed to cleanup state of $f\n";
- }
- }
-}
-
# An alternative to `command` that allows input to be passed as an array
# to work around shell problems with weird characters in arguments
# if the exec returns non-zero we die
@@ -346,12 +275,15 @@ sub safe_pipe_capture {
return wantarray ? @output : join('',@output);
}
-# For any file we want to add to cvs, we must first set its permissions
-# properly, *before* the "cvs add ..." command. Otherwise, it is impossible
-# to change the permission of the file in the CVS repository using only cvs
-# commands. This should be fixed in cvs-1.12.14.
-sub set_new_file_permissions {
- my ($file, $perm) = @_;
- chmod oct($perm), $file
- or die "failed to set permissions of \"$file\": $!\n";
+sub safe_pipe_capture_blob {
+ my $output;
+ if (my $pid = open my $child, '-|') {
+ local $/;
+ undef $/;
+ $output = (<$child>);
+ close $child or die join(' ',@_).": $! $?";
+ } else {
+ exec(@_) or die "$! $?"; # exec() can fail the executable can't be found
+ }
+ return $output;
}
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index c102479..63eafc8 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -89,18 +89,17 @@ test_expect_success \
! git cvsexportcommit -c $id
)'
-# Should fail, but only on the git-cvsexportcommit stage
-test_expect_success \
- 'Fail to remove binary file more than one generation old' \
- 'git reset --hard HEAD^ &&
- cat F/newfile6.png >>D/newfile4.png &&
- git commit -a -m "generation 2 (again)" &&
- rm -f D/newfile4.png &&
- git commit -a -m "generation 3" &&
- id=$(git rev-list --max-count=1 HEAD) &&
- (cd "$CVSWORK" &&
- ! git cvsexportcommit -c $id
- )'
+#test_expect_success \
+# 'Fail to remove binary file more than one generation old' \
+# 'git reset --hard HEAD^ &&
+# cat F/newfile6.png >>D/newfile4.png &&
+# git commit -a -m "generation 2 (again)" &&
+# rm -f D/newfile4.png &&
+# git commit -a -m "generation 3" &&
+# id=$(git rev-list --max-count=1 HEAD) &&
+# (cd "$CVSWORK" &&
+# ! git cvsexportcommit -c $id
+# )'
# We reuse the state from two tests back here
@@ -108,7 +107,7 @@ test_expect_success \
# fail with gnu patch, so cvsexportcommit must handle that.
test_expect_success \
'Remove only binary files' \
- 'git reset --hard HEAD^^^ &&
+ 'git reset --hard HEAD^^ &&
rm -f D/newfile4.png &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
@@ -142,20 +141,73 @@ test_expect_success \
diff F/newfile6.png ../F/newfile6.png
)'
-test_expect_success 'Retain execute bit' '
- mkdir G &&
- echo executeon >G/on &&
- chmod +x G/on &&
- echo executeoff >G/off &&
- git add G/on &&
- git add G/off &&
- git commit -a -m "Execute test" &&
- (
- cd "$CVSWORK" &&
- git-cvsexportcommit -c HEAD
- test -x G/on &&
- ! test -x G/off
- )
-'
+test_expect_success \
+ 'New file with spaces in file name' \
+ 'mkdir "G g" &&
+ echo ok then >"G g/with spaces.txt" &&
+ git add "G g/with spaces.txt" && \
+ cp ../test9200a.png "G g/with spaces.png" && \
+ git add "G g/with spaces.png" &&
+ git commit -a -m "With spaces" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c $id &&
+ test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.1/-kb with spaces.txt/1.1/"
+ )'
+
+test_expect_success \
+ 'Update file with spaces in file name' \
+ 'echo Ok then >>"G g/with spaces.txt" &&
+ cat ../test9200a.png >>"G g/with spaces.png" && \
+ git add "G g/with spaces.png" &&
+ git commit -a -m "Update with spaces" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c $id
+ test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.2/-kb with spaces.txt/1.2/"
+ )'
+
+# This test contains ISO-8859-1 characters
+test_expect_success \
+ 'File with non-ascii file name' \
+ 'mkdir Å &&
+ echo Foo >Å/gårdetsågårdet.txt &&
+ git add Å/gårdetsågårdet.txt &&
+ cp ../test9200a.png Å/gårdetsågårdet.png &&
+ git add Å/gårdetsågårdet.png &&
+ git commit -a -m "Går det så går det" && \
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -v -c $id &&
+ test "$(echo $(sort Å/CVS/Entries|cut -d/ -f2,3,5))" = "gårdetsågårdet.png/1.1/-kb gårdetsågårdet.txt/1.1/"
+ )'
+
+test_expect_success \
+ 'Mismatching patch should fail' \
+ 'date >>"E/newfile5.txt" &&
+ git add "E/newfile5.txt" &&
+ git commit -a -m "Update one" &&
+ date >>"E/newfile5.txt" &&
+ git add "E/newfile5.txt" &&
+ git commit -a -m "Update two" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ ! git-cvsexportcommit -c $id
+ )'
+
+test_expect_success \
+ 'Retain execute bit' \
+ 'mkdir G &&
+ echo executeon >G/on &&
+ chmod +x G/on &&
+ echo executeoff >G/off &&
+ git add G/on &&
+ git add G/off &&
+ git commit -a -m "Execute test" &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c HEAD
+ test -x G/on &&
+ ! test -x G/off
+ )'
^ permalink raw reply related
* Re: Collection of stgit issues and wishes
From: Catalin Marinas @ 2006-12-10 16:25 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20061208221744.GA3288@nan92-1-81-57-214-146.fbx.proxad.net>
On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
> Here is the remaining of my queue of stgit issues and ideas noted
> in the last months. A number of items in the "wishlist" section is
> really here to spawn discussion. Maybe some of them should end up
> in the TODO list.
Since this list gets changed pretty often, I would rather add TODO
Bugs wiki pages on http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT
(maybe I should create a page on one of the open-source hosting sites
and get some bug-tracking support). I keep the TODO file mainly for
what I plan to implement and, while I agree with many of the issues
you point below, I don't guarantee I have time to fix/implement.
From your list below, I removed those which I don't have any comments
for (I agree with you).
> - "stg import" leaves empty patch on the stack after failed patch application
That's a feature in the sense that it creates the empty patch with the
description and author information. It also leaves a
.stgit-failed.patch which you can manually apply.
> - "push --undo" should restore series order
Yes, but it requires some work to store the old series information
> - "stg fold" usage does not tell what <file> is used for
I think "stg help fold" is somewhat clear in this respect but, well,
it could be improved.
> - "patches -d" may be confused by files added then removed (below,
> file added to platform-v0, removed in rm-junk, problem encountered on
> 2006-08-14, probably on 0.10):
Is this still the case now? I fixed a similar issue a few months ago
(commit a57bd72016d3cf3ee8e8fd7ae2c12e047999b602; GIT considers a file
name to be revision name if the file isn't found on disk; easily
fixable by adding the "--" separator).
Only the push and pick comands take renames into account at the moment
(by using git-merge-recursive). It's not hard to modify the other
commands to deal better with renames, only that I didn't have time to
do it. There might be some performance impact on some commands. There
is also the case that I want to be able to send patches in a standard
GNU diff format for people not using GIT.
> - "refresh" should display .git/conflicts if any ?
stg status -c does this but I don't have anything against refresh
showing it as well (can be made more general by modifying the
check_conflicts function).
> - patches/*/*.log branches could be better named as patchlogs/*/*
> (easier to filter reliably)
It was easier to implement this way because the Patch objects have the
directory where they store the commits. I also didn't want to polute
the refs directory with yet another directory.
> - "stg show" should catch inexistant patch instead of saying "Unknown
> revision: that-patch^{commit}"
This command works for commit ids as well as patches. If the patch
isn't found, it considers the name to be a commit id.
> - "clean" should give enough info for the user to locate any problem
> (eg. conflict with files removed from revision control), eg. with a
> "popping to ..." message
Clean only removes empty patches and there shouldn't be any conflicts
caused by this operation (unless there is a bug).
> - "stg fold" should allow to pass -C<n> to git-apply: context mismatch
> currently makes folding unnecessarily hard
My solution was to leave a .stgit-failed.patch file which I apply
manually (I prefer to see what I apply rather than reducing the
context information). Indeed, an option to fold would be nice.
> - "stg goto <current>" causes IndexError exception
I thought it was fixed recently.
> - "sink" or "burry" as opposite to "float" (possibly with a target
> patch)
But how deep to burry it?
> - lacks "pick --patch=XXX" to pick by name
I don't understand this.
> - interactive merge tools could only be called automatically after
> failed merge, instead of requiring not-so-intuitive "resolved -i"
You can set the stgit.merger config option for this (diff3 followed by
xxdiff or emacs). I even have a .py file for doing this, I can add it
to the contrib dir. The other option would be to set this in the
config file and move the handling of this operation to a common file
(it can be used by all the operations involving a three-way merge)
> - needs a config example to call ediff via gnuserv (possibly sending
> several merges at a time, making use of the session registry)
Don't know how to do it.
> - shortcuts (st -> status, etc.), possibly making use of the git alias
> system ?
This could be easily implemented in the main.py file by finding a
single command match from the command list based on the first letters.
If more than one is found, just report the usual unknown command.
> - "stg fold" should allow to run a merge (insert conflict markers, or
> even just output a .rej patch somewhere)
It just calls git-apply. If this can do it, StGIT would use it.
> - support for atomicity of complex transactions (stg begin/snapshot,
> rollback, commit/finish - possibly with a transaction name so nesting would
> just work)
Would be nice but probably not that easy.
> - mark patches as deactivated (float above all unapplied ones), so
> even "push -a" would not push them
This would be good indeed.
> - "stg patches" should be able to report on unapplied patches
It invokes GIT to find out the commits modifying the give file. An
unapplied patch doesn't modify any local file.
--
^ permalink raw reply
* Re: RFC PATCH: support for default remote in StGIT
From: Catalin Marinas @ 2006-12-10 16:41 UTC (permalink / raw)
To: Pavel Roskin; +Cc: GIT list
In-Reply-To: <1165657360.2816.61.camel@portland.localdomain>
On 09/12/06, Pavel Roskin <proski@gnu.org> wrote:
> Sorry, I was unlucky to pick your address from setup.py, where it's
> incorrect (gmail.org, not gmail.com), so I'm sending you another copy.
Thanks for spotting this.
> One approach is to leave the default remote selection completely to git.
> The downside is that StGIT prints the remote it's pulling from. Now
> StGIT will have to print common words that it's pulling something. Or
> maybe it shouldn't print anything?
Yann started a thread on this but I didn't find the time to look at
this properly. He's idea was to store the remote branch information in
the StGIT metadata but I'd like to leave this for GIT to deal with.
The StGIT UI can probably be modified to display something useful but
I don't see a problem if it doesn't.
> The other approach is to calculate the default remote in StGIT. This
> would allow StGIT to tell the user where it's pulling from.
>
> However, I had to introduce a function that ignores errors except there
> is any output on stderr. This is because git-repo-config returns error
> code 1 if it cannot find the key. Maybe git-repo-config should have an
> option not to fail in this case? Perhaps a default value to return?
With the recent changes, StGIT shares the config files with GIT and it
has direct access to git settings without the need to use
git-repo-config. Just use "config.has_key" and "config.get_option".
Maybe a combination of your two options - StGIT could try to get the
default branch and, if there isn't any in the config files, just
invoke git-pull without any argument (and display something like
"pulling from default").
--
^ permalink raw reply
* Re: reexporting git repository via git-daemon
From: Arkadiusz Miskiewicz @ 2006-12-10 16:42 UTC (permalink / raw)
To: git
In-Reply-To: <200612082212.09682.arekm@maven.pl>
On Friday 08 December 2006 22:12, Arkadiusz Miskiewicz wrote:
> strace on git-daemon side:
> [...]
> 18241 lstat("refs/tags/v1.4.1-rc2", {st_mode=S_IFREG|0644, st_size=41,
> ...}) = 0
> 18241 open("refs/tags/v1.4.1-rc2", O_RDONLY) = 7
> 18241 read(7, "33c9db007159db11c1ad5fa7101ea95853740acf\n", 255) = 41
> 18241 close(7) = 0
> 18241 write(1, "004233c9db007159db11c1ad5fa7101ea95853740acf
> refs/tags/v1.4.1-rc2\n", 66) = 66
> 18241 write(1, "0045abc02670169cee9541793a86324a014272ca8ed5
> refs/tags/v1.4.1-rc2^{}\n", 69) = 69
> 18241 stat("refs/tags/v1.4.1.1", {st_mode=S_IFREG|0644, st_size=41, ...}) =
> 0 18241 lstat("refs/tags/v1.4.1.1", {st_mode=S_IFREG|0644, st_size=41,
> ...}) = 0 18241 open("refs/tags/v1.4.1.1", O_RDONLY) = 7
> 18241 read(7, "8419a453dc088b25b63ab1746d3d7e679caf686d\n", 255) = 41
> 18241 close(7)
> 18241 write(1, "00408419a453dc088b25b63ab1746d3d7e679caf686d
> refs/tags/v1.4.1.1\n", 64) = 64
> 18241 write(2, "fatal: ", 7) = 7
> 18241 write(2, "corrupted pack
> file ./objects/pack/pack-0bb22295a585ac173504a2f8dfb3e31e074a8715.pack",
> 85) = 85
> 18241 write(2, "\n", 1)
>
> 100% repeatable at this moment. Any ideas?
after:
$ git repack -a -d
Generating pack...
Done counting 33587 objects.
Deltifying 33587 objects.
100% (33587/33587) done
Writing 33587 objects.
100% (33587/33587) done
Total 33587, written 33587 (delta 23205), reused 33587 (delta 23205)
Pack pack-bc830a5d1c2efa3b727ef9af8faba13c3e719395 created.
the problem disapears and I can safely reexport git repository.
Does anyone care about this bug in git?
--
Arkadiusz Miśkiewicz PLD/Linux Team
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Jakub Narebski @ 2006-12-10 17:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0612100831t7b79d4b1p436de5dbb813e51a@mail.gmail.com>
Catalin Marinas wrote:
> On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> Here are some issues which are a bit annoying for me:
>>>> - make "stg help" (without command name) equivalent to "stg --help"
>
> There was a patch in this area. Doesn't it work correctly now?
I use stgit 0.11
1056:[gitweb/web!git]$ stg help
usage: stg help <command>
while "stg --help" lists all commands.
>>>> - stg new lacks --sign option (I have to remember to do this during
>>>> "stg refresh").
>
> For that I use the .git/patchdescr.tmpl file to use as the initial
> commit message. This has a Signed-off-by line.
Ah. I'm sorry, I haven't noticed this. It is
in /usr/share/stgit/examples/
>> And as far as I can see it doe not use git credentials (user.name and
>> user.email).
>
> StGIT now uses the GIT credentials (and config files).
Hmmm... in stgit 0.11 "stg refresh --sign" once gave me Signed-off-by:
Nobody line instead of using git user.name and user.email.
>> And yet another one: better support for reflog, namely giving the "reason"
>> i.e. the reflog message (like "stg push: <subject>", "stg refresh:
>> <subject>", "stg pop: <subject>", "stg commit" etc.), like git-rebase,
>> git-commit --amend and git-am (for example) does.
>
> I had a patch doing this but I haven't included it. I considered it
> was taking extra time for the push operation. I eventually added some
> patch history support via the "stg log" command.
The git commands StGit uses to perform operations automatically record
changes in branches in reflog. What StGit does not provide is the "reason".
You do use git-update-ref?
--
Jakub Narebski
^ permalink raw reply
* Re: reexporting git repository via git-daemon
From: Robin Rosenberg @ 2006-12-10 17:22 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: git
In-Reply-To: <200612082212.09682.arekm@maven.pl>
fredag 08 december 2006 22:12 skrev Arkadiusz Miskiewicz:
> Hi,
>
> I have weird problem wit git (1.4.4.2).
>
> git --bare clone git://git.kernel.org/pub/scm/git/git.git
> fetches everything correctly;
You proably ment git clone --bare git://git.kernel.org/pub/scm/git/git.git
Maybe git shouldn't accept useless (in this case) options.
^ permalink raw reply
* Problems with git-svn authors file
From: Nicolas Vilz @ 2006-12-10 17:26 UTC (permalink / raw)
To: git
hello,
i tried to use git-svn with author-files and got stuck with following
error message:
Use of uninitialized value in hash element at /usr/bin/git-svn line
2952.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-svn line 2953.
Author: not defined in .git/info/svn-authors file
512 at /usr/bin/git-svn line 457
main::fetch_lib() called at /usr/bin/git-svn line 328
main::fetch() called at /usr/bin/git-svn line 187
my svn-authors file looks like this:
---->8-----------------
username = Real Name <email@address>
---->8-----------------
It is placed in .git/info/svn-authors and is configured via
svn.authorsfile. I tried to dig in the code and it says at line 2952 if
there is an $_author variable defined and no $users{$author}, then die
with that message...
above function load_authors i have found
# '<svn username> = real-name <email address>' mapping based on git-svnimport:
now i am a bit confused, because the manual says, the svn-authors file
looks like my file above and here it sounds like
<svn username> = real-name <email address>
is the real syntax for that file...
If i ommit the -A or --authors-file= parameter (or unset the
svn.authorsfile config-parameter) while git-svn fetch, afterwards in
gitk --all, there is only the svn-username and the revision-uuid.
Am i doing something wrong?
Sincerly
^ permalink raw reply
* curl with ares support
From: Han Boetes @ 2006-12-10 17:26 UTC (permalink / raw)
To: git
Hi,
This is what my libcurl libs looks like:
~% pkg-config --libs libcurl
-lcurl -lcares -lidn -lssl -lcrypto -ldl -lz
But the git Makefile assumes '-lcurl' will do.
Bug identical to: https://trac.xiph.org/ticket/1092
# Han
--
_/| VK |\_
// o\ Decision maker, n.: The person in your office who /o \\
|| ._) was unable to form a task force before the music (_. ||
//__\ stopped. /__\\
^ permalink raw reply
* Re: reexporting git repository via git-daemon
From: Arkadiusz Miskiewicz @ 2006-12-10 17:28 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200612101822.09385.robin.rosenberg.lists@dewire.com>
On Sunday 10 December 2006 18:22, Robin Rosenberg wrote:
> fredag 08 december 2006 22:12 skrev Arkadiusz Miskiewicz:
> > Hi,
> >
> > I have weird problem wit git (1.4.4.2).
> >
> > git --bare clone git://git.kernel.org/pub/scm/git/git.git
> > fetches everything correctly;
>
> You proably ment git clone --bare git://git.kernel.org/pub/scm/git/git.git
Tested - result is the same, git-damon strace:
[pid 6686] write(1, "00408419a453dc088b25b63ab1746d3d7e679caf686d
refs/tags/v1.4.1.1\n", 64) = 64
[pid 6686] write(2, "fatal: ", 7) = 7
[pid 6686] write(2, "corrupted pack
file ./objects/pack/pack-bc830a5d1c2efa3b727ef9af8faba13c3e719395.pack", 85)
= 85
[pid 6686] write(2, "\n", 1) = 1
> Maybe git shouldn't accept useless (in this case) options.
Options handling in git* is a nightmare. It accepts non-existant options. You
never know if the option is fine, missplaced or ignored :/
> -- robin
--
Arkadiusz Miśkiewicz PLD/Linux Team
^ permalink raw reply
* Re: reexporting git repository via git-daemon
From: Jakub Narebski @ 2006-12-10 17:35 UTC (permalink / raw)
To: git
In-Reply-To: <200612082212.09682.arekm@maven.pl>
Arkadiusz Miskiewicz wrote:
> I have weird problem wit git (1.4.4.2).
I have tried to reproduce this error, but no luck.
> $ git --bare clone git://git.kernel.org/pub/scm/git/git.git
> fetches everything correctly;
It should be "git clone --bare git://git.kernel.org/pub/scm/git/git.git"
or "git clone --bare git://git.kernel.org/pub/scm/git/git.git git.git"
Git doesn't need GIT_DIR for clone.
> $ cd /tmp
> $ git clone /gitroot/home/gitrepo/git
>
> also correctly fetched. The problem begins with exporting that cloned repo
> once again via git-daemon:
I didn't do this second cloning, but it should not matter I think.
> $ git clone git://git.my-server/git
> fatal: unexpected EOF
> fetch-pack from 'git://git.my-server/git' failed.
True, the error messages of git-clone are bit cryptic and doesn't
give us much information. Does there exist such repository? Perhaps
it is not exported? Were there any error?
> strace on git-daemon side:
> [...]
> 18241 lstat("refs/tags/v1.4.1-rc2", {st_mode=S_IFREG|0644, st_size=41, ...}) =
> 0
> 18241 open("refs/tags/v1.4.1-rc2", O_RDONLY) = 7
> 18241 read(7, "33c9db007159db11c1ad5fa7101ea95853740acf\n", 255) = 41
> 18241 close(7) = 0
> 18241 write(1, "004233c9db007159db11c1ad5fa7101ea95853740acf
> refs/tags/v1.4.1-rc2\n", 66) = 66
> 18241 write(1, "0045abc02670169cee9541793a86324a014272ca8ed5
> refs/tags/v1.4.1-rc2^{}\n", 69) = 69
> 18241 stat("refs/tags/v1.4.1.1", {st_mode=S_IFREG|0644, st_size=41, ...}) = 0
> 18241 lstat("refs/tags/v1.4.1.1", {st_mode=S_IFREG|0644, st_size=41, ...}) = 0
> 18241 open("refs/tags/v1.4.1.1", O_RDONLY) = 7
> 18241 read(7, "8419a453dc088b25b63ab1746d3d7e679caf686d\n", 255) = 41
> 18241 close(7)
> 18241 write(1, "00408419a453dc088b25b63ab1746d3d7e679caf686d
> refs/tags/v1.4.1.1\n", 64) = 64
> 18241 write(2, "fatal: ", 7) = 7
> 18241 write(2, "corrupted pack
> file ./objects/pack/pack-0bb22295a585ac173504a2f8dfb3e31e074a8715.pack", 85)
> = 85
> 18241 write(2, "\n", 1)
>
> 100% repeatable at this moment. Any ideas?
WORKSFORME
$ git --version
git version 1.4.4.1
$ git clone --bare git://git.kernel.org/pub/scm/git/git.git
remote: Generating pack...
remote: Done counting 33587 objects.
remote: Deltifying 33587 objects.
remote: 100% (33587/33587) done
Indexing 33587 objects.
remote: Total 33587, written 33587 (delta 23205), reused 33325 (delta 23034)
100% (33587/33587) done
Resolving 23205 deltas.
100% (23205/23205) done
By the way, I wonder why git-clone names bare repository 'git',
and not 'git.git' as, I think, it should?
$ git-daemon --verbose --export-all --base-path=<pwd>
[31823] Connection from 127.0.0.1:46736
[31823] Extended attributes (16 bytes) exist <host=localhost>
[31823] Request upload-pack for '/git.git'
[31823] Disconnected
The above is generated when I was cloning locally, i.e. when I run the
following command:
$ git clone git://localhost/git.git
remote: Generating pack...
remote: Done counting 33587 objects.
remote: Deltifying 33587 objects.
remote: 100% (33587/33587) done
Indexing 33587 objects.
remote: Total 33587, written 33587 (delta 23205), reused 33587 (delta 23205)
100% (33587/33587) done
Resolving 23205 deltas.
100% (23205/23205) done
Checking files out...
100% (743/743) done
which went without any problem.
P.S. Please reply also to git mailing list
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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