* Re: Can I use git protocol to push change to remote repo?
From: Emily Ren @ 2008-12-16 8:59 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081216085205.GB3031@coredump.intra.peff.net>
Peff,
Yes, you are right ! I changed the permission of the repo, and it's OK now. :)
Thank you very much for your kindly help !
Emily
On Tue, Dec 16, 2008 at 4:52 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Dec 16, 2008 at 04:48:34PM +0800, Emily Ren wrote:
>
>> It failed with another error, is there anything I missed to config daemon ?
>> $ git push git://host.xz/testgit test_push2
>> updating 'refs/heads/test_push2'
>> from 0000000000000000000000000000000000000000
>> to eebb60caae38a38361d002cdace043124a2fc871
>> Generating pack...
>> Done counting 3 objects.
>> Deltifying 3 objects...
>> 100% (3/3) done
>> Writing 3 objects...
>> 100% (3/3) done
>> Total 3 (delta 0), reused 0 (delta 0)
>> unpack unpacker exited with error code
>> ng refs/heads/test_push2 n/a (unpacker error)
>> error: failed to push to 'git://host.xz/testgit'
>
> Does the user running git-daemon have permissions to write to the repo?
>
> -Peff
>
^ permalink raw reply
* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Junio C Hamano @ 2008-12-16 9:03 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, Jakub Narebski
In-Reply-To: <1229408179-7655-1-git-send-email-kraai@ftbfs.org>
I'll queue this in 'pu' for now; it has obvious and trivial conflicts with
other gitweb series that introduce new features ;-)
And regarding your follow-up patch you called "churn", I think it is
probably a good idea in the longer term, although I haven't really
looked at all the callers to make sure everybody would be happy.
But a change to the function signature of feature subroutines is not
something I'd like to apply while other series that want to add new
features are still cooking. How about doing these two patches as the
first thing that goes to 'next' after 1.6.1, and then force other series
rebase on top of your change? Alternatively, we could make you wait until
other series do settle in 'next' and then apply your change rebased on
them, but I think that is probably less optimal.
Thanks.
^ permalink raw reply
* [PATCHv5 1/3] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-16 10:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229422290-6213-1-git-send-email-giuseppe.bilotta@gmail.com>
The output of commitdiff_plain is not intended for git-am:
* when given a range of commits, commitdiff_plain publishes a single
patch with the message from the first commit, instead of a patchset
* the hand-built email format replicates the commit summary both as
email subject and as first line of the email itself, resulting in
a duplication if the output is used with git-am.
We thus create a new view that can be fed to git-am directly, allowing
patch exchange via gitweb. The new view exposes the output of git
format-patch directly, limiting it to a single patch in the case of a
single commit.
A configurable upper limit defaulting to 16 is imposed on the number of
commits which will be included in a patchset, to prevent DoS attacks on
the server. Setting the limit to 0 will disable the patch view, setting
it to a negative number will remove the limit.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..1006dfe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -330,6 +330,21 @@ our %feature = (
'ctags' => {
'override' => 0,
'default' => [0]},
+
+ # The maximum number of patches in a patchset generated in patch
+ # view. Set this to 0 or undef to disable patch view, or to a
+ # negative number to remove any limit.
+
+ # To disable system wide have in $GITWEB_CONFIG
+ # $feature{'patches'}{'default'} = [0];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'patches'}{'override'} = 1;
+ # and in project config gitweb.patches = 0|n;
+ # where n is the maximum number of patches allowed in a patchset.
+ 'patches' => {
+ 'sub' => \&feature_patches,
+ 'override' => 0,
+ 'default' => [16]},
);
sub gitweb_get_feature {
@@ -411,6 +426,16 @@ sub feature_pickaxe {
return ($_[0]);
}
+sub feature_patches {
+ my @val = (git_get_project_config('patches', '--int'));
+
+ if (@val) {
+ return @val;
+ }
+
+ return ($_[0]);
+}
+
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
@@ -504,6 +529,7 @@ our %actions = (
"heads" => \&git_heads,
"history" => \&git_history,
"log" => \&git_log,
+ "patch" => \&git_patch,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5387,6 +5413,13 @@ sub git_blobdiff_plain {
sub git_commitdiff {
my $format = shift || 'html';
+
+ my $patch_max;
+ if ($format eq 'patch') {
+ ($patch_max) = gitweb_get_feature('patches');
+ die_error(403, "Patch view not allowed") unless $patch_max;
+ }
+
$hash ||= $hash_base || "HEAD";
my %co = parse_commit($hash)
or die_error(404, "Unknown commit object");
@@ -5484,7 +5517,23 @@ sub git_commitdiff {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
'-p', $hash_parent_param, $hash, "--"
or die_error(500, "Open git-diff-tree failed");
-
+ } elsif ($format eq 'patch') {
+ # For commit ranges, we limit the output to the number of
+ # patches specified in the 'patches' feature.
+ # For single commits, we limit the output to a single patch,
+ # diverging from the git-format-patch default.
+ my @commit_spec = ();
+ if ($hash_parent) {
+ if ($patch_max > 0) {
+ push @commit_spec, "-$patch_max";
+ }
+ push @commit_spec, '-n', "$hash_parent..$hash";
+ } else {
+ push @commit_spec, '-1', '--root', $hash;
+ }
+ open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
+ '--stdout', @commit_spec
+ or die_error(500, "Open git-format-patch failed");
} else {
die_error(400, "Unknown commitdiff format");
}
@@ -5533,6 +5582,14 @@ sub git_commitdiff {
print to_utf8($line) . "\n";
}
print "---\n\n";
+ } elsif ($format eq 'patch') {
+ my $filename = basename($project) . "-$hash.patch";
+
+ print $cgi->header(
+ -type => 'text/plain',
+ -charset => 'utf-8',
+ -expires => $expires,
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
}
# write patch
@@ -5554,6 +5611,11 @@ sub git_commitdiff {
print <$fd>;
close $fd
or print "Reading git-diff-tree failed\n";
+ } elsif ($format eq 'patch') {
+ local $/ = undef;
+ print <$fd>;
+ close $fd
+ or print "Reading git-format-patch failed\n";
}
}
@@ -5561,6 +5623,11 @@ sub git_commitdiff_plain {
git_commitdiff('plain');
}
+# format-patch-style patches
+sub git_patch {
+ git_commitdiff('patch');
+}
+
sub git_history {
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 0/3] gitweb: patch view
From: Giuseppe Bilotta @ 2008-12-16 10:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Fifth iteration of the patch view in gitweb, that exposes the
git-format-patch output directly, allowing patchset exchange via gitweb.
No new functionality, just cleanups suggested by Jakub.
Giuseppe Bilotta (3):
gitweb: add patch view
gitweb: add patches view
gitweb: link to patch(es) view in commit(diff) and (short)log view
gitweb/gitweb.perl | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 108 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCHv5 2/3] gitweb: add patches view
From: Giuseppe Bilotta @ 2008-12-16 10:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229422290-6213-2-git-send-email-giuseppe.bilotta@gmail.com>
The only difference between patch and patches view is in the treatement
of single commits: the former only displays a single patch, whereas the
latter displays a patchset leading to the specified commit.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1006dfe..e7a6477 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -530,6 +530,7 @@ our %actions = (
"history" => \&git_history,
"log" => \&git_log,
"patch" => \&git_patch,
+ "patches" => \&git_patches,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5413,6 +5414,7 @@ sub git_blobdiff_plain {
sub git_commitdiff {
my $format = shift || 'html';
+ my %params = @_;
my $patch_max;
if ($format eq 'patch') {
@@ -5529,7 +5531,15 @@ sub git_commitdiff {
}
push @commit_spec, '-n', "$hash_parent..$hash";
} else {
- push @commit_spec, '-1', '--root', $hash;
+ if ($params{-single}) {
+ push @commit_spec, '-1';
+ } else {
+ if ($patch_max > 0) {
+ push @commit_spec, "-$patch_max";
+ }
+ push @commit_spec, "-n";
+ }
+ push @commit_spec, '--root', $hash;
}
open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
'--stdout', @commit_spec
@@ -5625,6 +5635,10 @@ sub git_commitdiff_plain {
# format-patch-style patches
sub git_patch {
+ git_commitdiff('patch', -single=> 1);
+}
+
+sub git_patches {
git_commitdiff('patch');
}
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 3/3] gitweb: link to patch(es) view in commit(diff) and (short)log view
From: Giuseppe Bilotta @ 2008-12-16 10:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229422290-6213-3-git-send-email-giuseppe.bilotta@gmail.com>
We link to patch view in commit and commitdiff view, and to patches view
in log and shortlog view.
In (short)log view, the link is only offered when the number of commits
shown is no more than the allowed maximum number of patches.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e7a6477..168deb7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5024,6 +5024,15 @@ sub git_log {
my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
+ my ($patch_max) = gitweb_get_feature('patches');
+ if ($patch_max) {
+ if ($patch_max < 0 || @commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patches", -replay=>1)},
+ "patches");
+ }
+ }
+
git_header_html();
git_print_page_nav('log','', $hash,undef,undef, $paging_nav);
@@ -5103,6 +5112,11 @@ sub git_commit {
} @$parents ) .
')';
}
+ if (gitweb_check_feature('patches')) {
+ $formats_nav .= " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
+ }
if (!defined $parent) {
$parent = "--root";
@@ -5416,9 +5430,8 @@ sub git_commitdiff {
my $format = shift || 'html';
my %params = @_;
- my $patch_max;
+ my ($patch_max) = gitweb_get_feature('patches');
if ($format eq 'patch') {
- ($patch_max) = gitweb_get_feature('patches');
die_error(403, "Patch view not allowed") unless $patch_max;
}
@@ -5436,6 +5449,11 @@ sub git_commitdiff {
$formats_nav =
$cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
"raw");
+ if ($patch_max) {
+ $formats_nav .= " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
+ }
if (defined $hash_parent &&
$hash_parent ne '-c' && $hash_parent ne '--cc') {
@@ -5992,6 +6010,14 @@ sub git_shortlog {
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
+ my $patch_max = gitweb_check_feature('patches');
+ if ($patch_max) {
+ if ($patch_max < 0 || @commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patches", -replay=>1)},
+ "patches");
+ }
+ }
git_header_html();
git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
--
1.5.6.5
^ permalink raw reply related
* Re: [RFCv4 3/3] gitweb: link to patch(es) view from commit and log views
From: Jakub Narebski @ 2008-12-16 10:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0812160202n1f4f7f4fi7f71455eb42bcd31@mail.gmail.com>
You lost CC, somehow...
On Tue, 16 Dec 2008, Giuseppe Bilotta wrote:
> On Tue, Dec 16, 2008 at 2:03 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Sat, 6 Dec 2008, Giuseppe Bilotta wrote:
>>> + if ($patch_max) {
>>> + if ($patch_max < 0 || @commitlist <= $patch_max) {
>>> + $paging_nav .= " ⋅ " .
>>> + $cgi->a({-href => href(action=>"patches", -replay=>1)},
>>> + @commitlist > 1 ? "patchset" : "patch");
[...]
>> I wonder if it would make sense to pass
>>
>> href(..., hash_parent => $commitlist[-1]{'id'}, ...)
>>
>> here. But I think having separate "patches" action, with intent being
>> displaying series of patches, is a better solution. This way you can
>> see in URL and in the page title (thus also in window title, or in
>> bookmark name) if it is single patch or patch series (perhaps consisting
>> of single patch).
>
> I'm not sure I'm following you here. Do you mean as in manually adding
> the parent endpoint to the URL when it's not specified in the log view
> itself? I think that would change the behaviour for > 100 patches.
First, I meant here that having separate "patches" action is a good
idea in itself, whether we pass explicitly and always $hash_parent
parameter here or not.
Second, I haven't thought about interaction with (short)log
pagination; in $patch_max < 0, i.e. unlimited patches, and most
common case of running 'shortlog' action without 'hp' (hash_parent)
limiter used, one would make 'patches' limited to page size,
other unlimited. On one hand side limiting to page size makes
"patches" be more of equivalent of current "shortlog" view; on the
other hand it makes 'unlimited' actually be limited to page size,
at least in this situation...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFCv4 2/3] gitweb: add patches view
From: Jakub Narebski @ 2008-12-16 10:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0812160149j1dcaefccv1caf4a2e589ffebb@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Tue, Dec 16, 2008 at 4:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sat, 6 Dec 2008 16:02, Giuseppe Bilotta wrote:
>>
>>> The only difference between patch and patches view is in the treatement
>>> of single commits: the former only displays a single patch, whereas the
>>> latter displays a patchset leading to the specified commit.
>>
>> I like that fact that we have "patches" action which intent is to
>> show series of patches, and "patch" action which intent is to show
>> single patch. I'm just not sure if "patch" view should not simply
>> ignore $hash_parent...
>
> I had doubts on this myself. In the end I decided to make patch
> consider hash_parent if present because IMO it's what a user would
> expect in case e.g. of hand-crafted URLs.
Ah. I can understand that.
[...]
>>> sub git_commitdiff {
>>> my $format = shift || 'html';
>>> + # for patch view: should we limit ourselves to a single patch
>>> + # if only a single commit is passed?
>>> + my $single_patch = shift && 1;
>>
>> What does this "shift && 1" does? Equivalent of "!!shift"?
>> Is it really needed?
>>
>> Perhaps it would be better to use %opts trick, like for some other
>> gitweb subroutines (-single=>1, or -single_patch=>1, or -nmax=>1)?
>> Or perhaps not...
>
> It would be MUCH better, I'll do it this way. I'll pass the -single
> param in both cases, having value true/false, even though the false
> case is not needed since undef is false in perl anyway. (I like
> symmetry.)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFCv4 3/3] gitweb: link to patch(es) view from commit and log views
From: Giuseppe Bilotta @ 2008-12-16 11:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200812161114.35336.jnareb@gmail.com>
On Tue, Dec 16, 2008 at 11:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> You lost CC, somehow...
Duh, clicked the wrong button.
>>> I wonder if it would make sense to pass
>>>
>>> href(..., hash_parent => $commitlist[-1]{'id'}, ...)
>>>
>>> here. But I think having separate "patches" action, with intent being
>>> displaying series of patches, is a better solution. This way you can
>>> see in URL and in the page title (thus also in window title, or in
>>> bookmark name) if it is single patch or patch series (perhaps consisting
>>> of single patch).
>>
>> I'm not sure I'm following you here. Do you mean as in manually adding
>> the parent endpoint to the URL when it's not specified in the log view
>> itself? I think that would change the behaviour for > 100 patches.
>
> First, I meant here that having separate "patches" action is a good
> idea in itself, whether we pass explicitly and always $hash_parent
> parameter here or not.
I'm not too sure about that. Do we pass the actual hash parent, or
just the last patch that would be included due to the patch limit?
This, btw, is an issue that should resolved with patch view: it should
warn when the patch limit is reached before all intended patches are
output. I'm just not sure about how to do it.
> Second, I haven't thought about interaction with (short)log
> pagination; in $patch_max < 0, i.e. unlimited patches, and most
> common case of running 'shortlog' action without 'hp' (hash_parent)
> limiter used, one would make 'patches' limited to page size,
> other unlimited. On one hand side limiting to page size makes
> "patches" be more of equivalent of current "shortlog" view; on the
> other hand it makes 'unlimited' actually be limited to page size,
> at least in this situation...
Consider that switching from log to shortlog view doesn't respect
pagination (e.g. if you're on page 3 of shortlog and click on log you
go to page 1 of log) I would be inclined to keep patches behaviour
independent of log view pagination.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git-scm.com transition
From: Petr Baudis @ 2008-12-16 11:41 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0812151007n1be9ce95h92c8c11592ea5f9d@mail.gmail.com>
Hi,
On Mon, Dec 15, 2008 at 10:07:05AM -0800, Scott Chacon wrote:
> I've been working on some docs, like an easy reference, that I could
> put up at git-scm.com. I was wondering if we were still planning on
> transitioning the site from git.or.cz -> git-scm.com?
sure - I just need to be prodded about it, as I said. ;-)
> Is there anything I need to do to help you with that? Are there any
> elements missing still?
hmm... I'm really busy before the end of the year, but this should
take just a really short while by now, so let's see if there are still
some nits:
"$ git clone git://github.com/git/hello-world.git" on the
frontpage overflows from the box for me, and so does "git commit -m
'Initial commit'" in the other box. I work on smallish notebook with
1024x768 resolution, but there are still wide white stripes on the
sides.
Mention FAQ in the "Got a question?" box?
Migrate the SVN crash course to git-scm.com too? Would make
sense, imho. Or maybe we can just throw it on the wiki.
Has anyone reviewed " Pragmatic Version Control Using Git by
Travis Swicegood " if we advertise it on the homepage? I remember
looking at some very early preview and feeling quite uncomfortable
about it. Mentioning a book on the homepage is some kind of an
endorsement.
Merge "Multimedia" into "Videos"?
I'm wondering if the "Related Tools" section shouldn't get a
kind of facelift (as e.g. by now imho people are perceiving gitk,
git-gui and gitweb all as integral git components, you might want to
mention TopGit instead of Cogito, etc.) and the 4x4 format is probably
not too appropriate (the hosting sites aren't a natural fit there, and I
chose it originally only to reduce the vertical length of the
single-page homepage). But that's certainly not a blocking issue for the
redirect.
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ permalink raw reply
* git filter-branch and superproject
From: Sergio Callegari @ 2008-12-16 11:56 UTC (permalink / raw)
To: git
Hi,
once a sub-project has been rewritten by filter branch, there is a problem with
references in superproject.
This is obviously a case where something "has been published" so filter-branch
is not a good idea. However, super-projects are a very special case of
publication since they might be "in full control" of whom did the rewriting of
their submodules.
Is there a way to filter branch the superproject so that whatever commit is
referenced that is in refs/original/something in the subproject gets updated to
the corresponding rewritten commit (or an error is given if such a
correspondance does not exist)?
Namely, can filter-branch on the subproject deliver a "commit conversion table"
that can then be fed to a filter-branch in a superproject?
^ permalink raw reply
* Undo a git stash clear
From: Alexander Gladysh @ 2008-12-16 12:07 UTC (permalink / raw)
To: git, git-users
Hi, list!
I've stashed some valuable changes and then I accidentally did git
stash clear. (Yes, today is not my day).
Is it possible to restore stashed changes?
Alexander.
^ permalink raw reply
* Re: Undo a git stash clear
From: Johannes Schindelin @ 2008-12-16 12:10 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git, git-users
In-Reply-To: <c6c947f60812160407l1b2593e1pde817f5cfb091d59@mail.gmail.com>
Hi,
On Tue, 16 Dec 2008, Alexander Gladysh wrote:
> I've stashed some valuable changes and then I accidentally did git stash
> clear. (Yes, today is not my day).
>
> Is it possible to restore stashed changes?
You might find them with "git fsck --lost-found".
Hth,
Dscho
^ permalink raw reply
* Re: Undo a git stash clear
From: Jeff King @ 2008-12-16 12:12 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git, git-users
In-Reply-To: <c6c947f60812160407l1b2593e1pde817f5cfb091d59@mail.gmail.com>
On Tue, Dec 16, 2008 at 03:07:28PM +0300, Alexander Gladysh wrote:
> I've stashed some valuable changes and then I accidentally did git
> stash clear. (Yes, today is not my day).
>
> Is it possible to restore stashed changes?
Try git-fsck; it should report some dangling commits (i.e., commits that
are in the object db but aren't reachable by any refs). Then you can
either pull the changes out directly (try git cherry-pick -m1 $sha1) or you
can even restore it as a stash (git update-ref -m oops refs/stash
$sha1).
-Peff
^ permalink raw reply
* Re: Undo a git stash clear
From: Jonathan del Strother @ 2008-12-16 12:12 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git, git-users
In-Reply-To: <c6c947f60812160407l1b2593e1pde817f5cfb091d59@mail.gmail.com>
On Tue, Dec 16, 2008 at 12:07 PM, Alexander Gladysh <agladysh@gmail.com> wrote:
> Hi, list!
>
> I've stashed some valuable changes and then I accidentally did git
> stash clear. (Yes, today is not my day).
>
> Is it possible to restore stashed changes?
I ran into this exact problem on Friday. Some helpful person on IRC
suggested using
git fsck | grep commit | cut -d' ' -f3 | while read hash; do git
rev-parse --verify --quiet $hash^2 && echo $hash; done | xargs git
show
Which will show a huge list of lost changes. Once you find the change
you're interested in, you can cherry-pick its sha1.
^ permalink raw reply
* Re: Undo a git stash clear
From: Matthieu Moy @ 2008-12-16 12:20 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alexander Gladysh, git, git-users
In-Reply-To: <57518fd10812160412j1edc2ea0mff732825f1f6c4a2@mail.gmail.com>
"Jonathan del Strother" <maillist@steelskies.com> writes:
> On Tue, Dec 16, 2008 at 12:07 PM, Alexander Gladysh <agladysh@gmail.com> wrote:
>> Hi, list!
>>
>> I've stashed some valuable changes and then I accidentally did git
>> stash clear. (Yes, today is not my day).
>>
>> Is it possible to restore stashed changes?
>
> I ran into this exact problem on Friday. Some helpful person on IRC
> suggested using
(and the obvious advice before anything else : don't "git gc", don't
"git prune", and if possible back-up the repository before anything
else)
--
Matthieu
^ permalink raw reply
* git-svn and empty directories
From: Thomas Jarosch @ 2008-12-16 12:53 UTC (permalink / raw)
To: Eric Wong, Deskin Miller; +Cc: git
Hello Eric and Deskin,
I'm currently looking into preserving empty directories from a SVN repository
by automatically creating empty .gitignore files for them.
The control flow of the git-svn code is still a jungle to me,
maybe you have a hint how to implement a proof-of-concept code?
I don't think I can just touch a .gitignore file in get_untracked()
and those files will magically turn up in git's index...
Thanks,
Thomas
^ permalink raw reply
* Re: git filter-branch and superproject
From: Boaz Harrosh @ 2008-12-16 13:01 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20081216T114923-354@post.gmane.org>
Sergio Callegari wrote:
> Hi,
>
> once a sub-project has been rewritten by filter branch, there is a problem with
> references in superproject.
>
> This is obviously a case where something "has been published" so filter-branch
> is not a good idea. However, super-projects are a very special case of
> publication since they might be "in full control" of whom did the rewriting of
> their submodules.
>
> Is there a way to filter branch the superproject so that whatever commit is
> referenced that is in refs/original/something in the subproject gets updated to
> the corresponding rewritten commit (or an error is given if such a
> correspondance does not exist)?
>
> Namely, can filter-branch on the subproject deliver a "commit conversion table"
> that can then be fed to a filter-branch in a superproject?
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
If I recall correctly, submodule was recently enabled to reference
a soft label, like a branch name, instead of an hard UID. Look it up
in the newest git.
But your post brings up another concern. The HEAD referenced by the
superproject does not have any hold in the subproject. So if the
subproject under-gone a git-gc the reference UID might disappear, as
in your case. I wish the git-submodule command would create a TAG or BRANCH
in the subproject of all referenced HEADs, so they will not disappear
in future maintenance of the subproject tree. (And it could be very
informative when viewing in gitweb). The subproject TAG name could, for
example, be the commit and date of the superproject's submodule commit.
Boaz
^ permalink raw reply
* Re: [PATCH v3] git-svn: Make following parents atomic
From: Thomas Jarosch @ 2008-12-16 13:22 UTC (permalink / raw)
To: Deskin Miller
Cc: Eric Wong, git, Junio C Hamano, Thomas Leonard,
Björn Steinbrink
In-Reply-To: <20081208233523.GB21675@hand.yhbt.net>
On Tuesday, 9. December 2008 00:35:23 you wrote:
> > To fix this, when we initialise the Git::SVN object $gs to search for
> > and perhaps fetch history, we check if there are any commits in SVN in
> > the range between the current revision $gs is at, and the top revision
> > for which we were asked to fill history. If there are commits we're
> > missing in that range, we continue the fetch from the current revision
> > to the top, properly getting all history before using it as the parent
> > for the branch we're trying to create.
> >
> > Signed-off-by: Deskin Miller <deskinm@umich.edu>
>
> Looks good Deskin, thanks
This patch has a very nice side effect, it seems to fix a long standing
problem with subversion imports. Here's the original report:
https://kerneltrap.org/mailarchive/git/2008/4/8/1377514/thread
Many of the 121 tags in my SVN tree were created by cvs2svn,
which often created tags by copying older revisions
of sub paths into the current tree.
I've written a small script that checks out the same tag via git and SVN.
It runs a diff against those two trees and saves the result to a file
so I can manually check it. With git-svn from 1.6.0.5, the results are
horrible: Over 30% of the tags didn't match the code in SVN.
With git-svn from 1.6.1rc3, my first two manual probes look very good.
Right now I'm reimporting the svn tree and will have the results
of the complete "checkout comparison" tomorrow.
Cheers,
Thomas
^ permalink raw reply
* Re: [TortoiseGit]: Anyone seen this challenge?
From: Tim Visher @ 2008-12-16 13:24 UTC (permalink / raw)
To: Frank Li; +Cc: Geoffrey Lee, Scott Chacon, git
In-Reply-To: <1976ea660812152006y7ae79a1bhfdcdb730c6a687a5@mail.gmail.com>
On Mon, Dec 15, 2008 at 11:06 PM, Frank Li <lznuaa@gmail.com> wrote:
> Scott, you help set up account on github for TortoiseGit project.
I guess you'll notify the rest of us when this project gets set up, Li?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Matt Kraai @ 2008-12-16 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vmyewqypk.fsf@gitster.siamese.dyndns.org>
On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:
> But a change to the function signature of feature subroutines is not
> something I'd like to apply while other series that want to add new
> features are still cooking. How about doing these two patches as the
> first thing that goes to 'next' after 1.6.1, and then force other series
> rebase on top of your change? Alternatively, we could make you wait until
> other series do settle in 'next' and then apply your change rebased on
> them, but I think that is probably less optimal.
OK, I'll resubmit the patches on top of 'next' once 1.6.1 is
released. Thanks for your help,
--
Matt http://ftbfs.org/
^ permalink raw reply
* [PATCH] git-daemon documentation: use {tilde}
From: Miklos Vajna @ 2008-12-16 15:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Use '{tilde}' instead of '~', becase the later does not appear in the
manpage version, just in the HTML one.
Noticed by gonzzor on IRC.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-daemon.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index f1a570a..36f00ae 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -110,9 +110,9 @@ OPTIONS
--user-path::
--user-path=path::
- Allow ~user notation to be used in requests. When
+ Allow {tilde}user notation to be used in requests. When
specified with no parameter, requests to
- git://host/~alice/foo is taken as a request to access
+ git://host/{tilde}alice/foo is taken as a request to access
'foo' repository in the home directory of user `alice`.
If `--user-path=path` is specified, the same request is
taken as a request to access `path/foo` repository in
--
1.6.1.rc1.35.gae26e.dirty
^ permalink raw reply related
* Re: git-diff should not fire up $PAGER if there is no diff
From: jidanni @ 2008-12-16 17:38 UTC (permalink / raw)
To: peff; +Cc: git
In-Reply-To: <20081216040722.GA4551@coredump.intra.peff.net>
Oh barf, having LESS=F in one's environment messes up less +G:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508919
^ permalink raw reply
* Re: [PATCH] git-daemon documentation: use {tilde}
From: Michael J Gruber @ 2008-12-16 17:38 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1229442492-11993-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna venit, vidit, dixit 16.12.2008 16:48:
> Use '{tilde}' instead of '~', becase the later does not appear in the
> manpage version, just in the HTML one.
Curiously, "git help daemon" (which execs "man git-daemon") displays the
tilde but "man git-daemon" does not (nor does "konqueror
man:git-daemon"). Humh?
Michael
^ permalink raw reply
* Re: [PATCH] git-daemon documentation: use {tilde}
From: Miklos Vajna @ 2008-12-16 17:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4947E7B1.2090608@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
On Tue, Dec 16, 2008 at 06:38:57PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Curiously, "git help daemon" (which execs "man git-daemon") displays the
> tilde but "man git-daemon" does not (nor does "konqueror
> man:git-daemon"). Humh?
'git help daemon' is wrong for me - without the patch - as well.
(Though I never use the git help foo form.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 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