* Re: Git Notes idea.
From: Jeff King @ 2008-12-16 8:51 UTC (permalink / raw)
To: Govind Salinas; +Cc: Git Mailing List
In-Reply-To: <5d46db230812160015t55b4ff2fubbf1e2f826a97b98@mail.gmail.com>
On Tue, Dec 16, 2008 at 02:15:47AM -0600, Govind Salinas wrote:
> I was thinking about possible ideas for my little pet project and I
> had and idea for way to tack on notes to a commit, or any object
> really. I know that the idea has been flying around for a long time
> but there has never been any implementation or a concept that people
> liked enough to use (unless I have missed something).
I think you look at the previous suggestions, because yours is very
similar. Which is good, I think, because the current status is that the
design is good, but nobody has gotten around to working on it yet. So
maybe you can fix that. :)
> .git/refs/notes contains a tree-id (assuming that using a tree-id
> will not cause any problems, otherwise a commit object can be used.
> it does not *need* a history, but it *could* have one).
That is the same as the current proposal, except:
- the proposal is to use a commit, so your notes are version-controlled
- I have suggested supporting multiple note "bases" in the refs/notes
namespace. This would allow you to share some notes but not others
(e.g., if you had some automated notes related to a build/test
system, you might not want to mix those with your human-written
notes).
> That tree has a structure similar to the layout of .git/objects, where
> it is 2 letter subdirectories for the notes objects.
I don't think this has been suggested yet, but I'm not sure it is a good
idea. The usual reason for this split is that many filesystems handle
large directories badly; that isn't a problem here.
It does reduce the size of the resulting tree objects when a note is
modified (we make updates to two smaller trees instead of one big tree).
I don't know if this really matters all that much, since the trees
will end up deltified in a pack anyway.
And it does make the implementation slightly less simple, since we have
to deal with two levels of trees.
> Given a git object (commit, tree, blob, tag), use its sha as the
> path/filename in this tree.
> If I have a commit 1234567890123456789012345678901234567890 then
> the notes tree will have a file
> 12/34567890123456789012345678901234567890
>
> That file has a list of sha1s (one per line). These shas are object
> IDs for blobs that have the notes or whatever that you want attached
> to the item.
This is slightly different than the current proposal. You are proposing
that each item have a "list of notes". My thinking was to have "named
notes" using a tree for each entry full of blobs. So you could look up
the "foo" note for a given commit, but that note would be a single
scalar (which could, of course, be interpreted according to its name).
> I think you get the idea. When looking up an item, it should be
> fairly easy to have the notes tree and subtrees available for doing
> lookups. And as far as I know stuff under .git/refs can be
It is easy, but it's slow because we have to do a linear search in the
(potentially huge) notes tree. And that's what held up the initial
implementation. I did a proof-of-concept a month or so ago that
pre-seeded an in-memory hash using the tree contents and got pretty
reasonable performance.
> pushed/pulled even if its not under heads or remotes or tags using
> already existing machinery. I am not sure, but I think that would
> satisfy gc operations as well. Also, these trees and blobs never have
> to be put in the working directory.
Right, though I think one of the benefits of this approach is that you
_could_ do a checkout on the notes tree if you wanted to do very
flexible editing.
> Does this sound like something that is workable? I thought it might
> appeal since it uses only features that are already present.
Yes, it sounds workable, though if you diverge from what has already
been discussed, I think you should make an argument about why your
approach is better.
> This could be extended so that you have different sets of notes under
> .git/refs/notes/<my note set> or whatever. So that you can have some
> notes you keep private and some that you publish or whatever.
Oops, I should have read your whole mail. Yes, that is a good idea. :)
For reference, here are the previous discussions that I think are
relevant:
Johan Herland's original notes proposal (which I think is largely
dead, replaced by the one below):
http://thread.gmane.org/gmane.comp.version-control.git/46770
Johannes Schindelin's notes proposal (which is more or less the
current proposal, but I think the on-disk notes index was not
well liked):
http://thread.gmane.org/gmane.comp.version-control.git/52598
My test with using a hash to speed it up:
http://article.gmane.org/gmane.comp.version-control.git/99415
Some discussion of the interaction of notes and rebase:
http://thread.gmane.org/gmane.comp.version-control.git/100533
Some thoughts from me on naming issues:
http://article.gmane.org/gmane.comp.version-control.git/100402
Some thoughts from me on the tree speedup:
http://article.gmane.org/gmane.comp.version-control.git/101460
which I think should bring you up to speed. :)
-Peff
^ permalink raw reply
* Re: Can I use git protocol to push change to remote repo?
From: Jeff King @ 2008-12-16 8:52 UTC (permalink / raw)
To: Emily Ren; +Cc: git
In-Reply-To: <856bfe0e0812160048l7d901658tca96f5055c69743c@mail.gmail.com>
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: Git Notes idea.
From: Jeff King @ 2008-12-16 8:53 UTC (permalink / raw)
To: Govind Salinas; +Cc: Git Mailing List
In-Reply-To: <20081216085108.GA3031@coredump.intra.peff.net>
On Tue, Dec 16, 2008 at 03:51:08AM -0500, Jeff King wrote:
> I think you look at the previous suggestions, because yours is very
Sorry, there is a typo there. I meant "I think you _should_ look at the
previous suggestions." Not saying in broken English that you already
have looked at them.
-Peff
^ permalink raw reply
* 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
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