* [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Sébastien Cevey @ 2008-12-04 0:46 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Petr Baudis,
Gustavo Sverzut Barbieri
In-Reply-To: <87iqq022gz.wl%seb@cine7.net>
This adds the $projects_list_group_categories option which, if enabled,
will result in grouping projects by category on the project list page.
The category is specified for each project by the $GIT_DIR/category file
or the 'category' variable in its configuration file. By default, projects
are put in the $project_list_default_category category.
Note:
- Categories are always sorted alphabetically, with projects in
each category sorted according to the globally selected $order.
- When displaying a subset of all the projects (page limiting), the
category headers are only displayed for projects present on the page.
The feature is inspired from Sham Chukoury's patch for the XMMS2
gitweb, but has been rewritten for the current gitweb development
HEAD. The CSS for categories is inspired from Gustavo Sverzut Barbieri's
patch to group projects by path.
Thanks to Florian Ragwitz for Perl tips.
Signed-off-by: Sebastien Cevey <seb@cine7.net>
---
Cleaner patch this time indeed. Still no fancy sorting of categories,
only alphabetical.
gitweb/README | 16 ++++++++++++
gitweb/gitweb.css | 7 +++++
gitweb/gitweb.perl | 67 +++++++++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 825162a..f8f8872 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -188,6 +188,15 @@ not include variables usually directly set during build):
full description is available as 'title' attribute (usually shown on
mouseover). By default set to 25, which might be too small if you
use long project descriptions.
+ * $projects_list_group_categories
+ Enables the grouping of projects by category on the project list page.
+ The category of a project is determined by the $GIT_DIR/category
+ file or the 'gitweb.category' variable in its repository configuration.
+ Disabled by default.
+ * $project_list_default_category
+ Default category for projects for which none is specified. If set
+ to the empty string, such projects will remain uncategorized and
+ listed at the top, above categorized projects.
* @git_base_url_list
List of git base URLs used for URL to where fetch project from, shown
in project summary page. Full URL is "$git_base_url/$project".
@@ -269,6 +278,13 @@ You can use the following files in repository:
from the template during repository creation. You can use the
gitweb.description repo configuration variable, but the file takes
precedence.
+ * category (or gitweb.category)
+ Singe line category of a project, used to group projects if
+ $projects_list_group_categories is enabled. By default (file and
+ configuration variable absent), uncategorized projects are put in
+ the $project_list_default_category category. You can use the
+ gitweb.category repo configuration variable, but the file takes
+ precedence.
* cloneurl (or multiple-valued gitweb.url)
File with repository URL (used for clone and fetch), one per line.
Displayed in the project summary page. You can use multiple-valued
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index a01eac8..64f2a41 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -264,6 +264,13 @@ td.current_head {
text-decoration: underline;
}
+td.category {
+ background-color: #d9d8d1;
+ border-top: 1px solid #000000;
+ border-left: 1px solid #000000;
+ font-weight: bold;
+}
+
table.diff_tree span.file_status.new {
color: #008000;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a6bb702..97a9b73 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -87,6 +87,14 @@ our $projects_list = "++GITWEB_LIST++";
# the width (in characters) of the projects list "Description" column
our $projects_list_description_width = 25;
+# group projects by category on the projects list
+# (enabled if this variable evaluates to true)
+our $projects_list_group_categories = 0;
+
+# default category if none specified
+# (leave the empty string for no category)
+our $project_list_default_category = "";
+
# default order of projects list
# valid values are none, project, descr, owner, and age
our $default_projects_order = "project";
@@ -2023,6 +2031,11 @@ sub git_get_project_description {
return git_get_file_or_project_config('description', $path);
}
+sub git_get_project_category {
+ my $path = shift;
+ return git_get_file_or_project_config('category', $path);
+}
+
sub git_get_project_ctags {
my $path = shift;
my $ctags = {};
@@ -3915,8 +3928,9 @@ sub git_patchset_body {
# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-# fills project list info (age, description, owner, forks) for each
-# project in the list, removing invalid projects from returned list
+# fills project list info (age, description, owner, category, forks)
+# for each project in the list, removing invalid projects from
+# returned list
# NOTE: modifies $projlist, but does not remove entries from it
sub fill_project_list_info {
my ($projlist, $check_forks) = @_;
@@ -3939,6 +3953,11 @@ sub fill_project_list_info {
if (!defined $pr->{'owner'}) {
$pr->{'owner'} = git_get_project_owner("$pr->{'path'}") || "";
}
+ if ($projects_list_group_categories && !defined $pr->{'category'}) {
+ my $cat = git_get_project_category($pr->{'path'}) ||
+ $project_list_default_category;
+ $pr->{'category'} = to_utf8($cat);
+ }
if ($check_forks) {
my $pname = $pr->{'path'};
if (($pname =~ s/\.git$//) &&
@@ -3956,6 +3975,19 @@ sub fill_project_list_info {
return @projects;
}
+# returns a hash of categories, containing the list of project
+# belonging to each category
+sub build_projlist_by_category {
+ my $projlist = shift;
+ my %categories;
+
+ for my $pr (@$projlist) {
+ push @{$categories{ $pr->{'category'} }}, $pr;
+ }
+
+ return %categories;
+}
+
# print 'sort by' <th> element, generating 'sort by $name' replay link
# if that order is not selected
sub print_sort_th {
@@ -4077,7 +4109,36 @@ sub git_project_list_body {
"</tr>\n";
}
- print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
+ if ($projects_list_group_categories) {
+ # only display categories with projects in the $from-$to window
+ my %categories = build_projlist_by_category(\@projects);
+ foreach my $cat (sort keys %categories) {
+ my $num_cats = @{$categories{$cat}};
+
+ # out of the window to display, done
+ last if defined $to and $to < 0;
+
+ # in the window to display
+ if (!defined $from or $from < $num_cats) {
+ unless ($cat eq "") {
+ print "<tr>\n";
+ if ($check_forks) {
+ print "<td></td>\n";
+ }
+ print "<td class=\"category\" colspan=\"5\">$cat</td>\n";
+ print "</tr>\n";
+ }
+
+ print_project_rows($categories{$cat}, $from, $to, $check_forks, $show_ctags);
+ }
+
+ # adjust $from/$to offset, keep $from positive
+ $from = ($from > $num_cats) ? $from - $num_cats : 0 if defined $from;
+ $to -= $num_cats if defined $to;
+ }
+ } else {
+ print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
+ }
if (defined $extra) {
print "<tr>\n";
--
1.5.6.5
^ permalink raw reply related
* Re: two questions about the format of loose object
From: Nicolas Pitre @ 2008-12-04 0:54 UTC (permalink / raw)
To: Liu Yubao; +Cc: Shawn O. Pearce, git list
In-Reply-To: <4934A5EC.2090708@gmail.com>
On Tue, 2 Dec 2008, Liu Yubao wrote:
> In fact the format I proposed in my patches is uncompressed loose
> object, not uncompressed loose object header, that's to say I
> proposed format 2 in my question 2, I am just curious why the
> loose object header is compressed in question 1.
>
> I did a test to add all files of git-1.6.1-rc1 with git-add, the
> time spent decreased by half. Other commands like git diff,
> git diff --cached, git diff HEAD~ HEAD should be faster now
> although the change may be not noticable for small and medium project.
Please try this with an unmodified git version:
git config --global core.loosecompression 0
and redo your tests please.
One thing that a purely uncompressed loose object format is missing is
quick data integrity protection. With the above, you'll have all your
loose objects uncompressed but they'll still have a CRC32 done over
them.
Nicolas
^ permalink raw reply
* Re: [RFCv3 1/2] gitweb: add patch view
From: Jakub Narebski @ 2008-12-04 1:48 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <cb7bb73a0812031620s2459f773q3db33971e3507b2f@mail.gmail.com>
On Thu, Dec 4, 2008 at 01:20, Giuseppe Bilotta wrote:
> On Thu, Dec 4, 2008 at 12:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>> +
>>> + # 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.
>>> + 'patches' => {
>>> + 'override' => 1,
>>> + 'default' => [16]},
Errr... you need something like 'sub' => \&feature_patches for override
to actually work, I think.
>>> );
>>
>> Looking at the existing entries in the %feature hash, it seems that it is
>> our tradition that a new feature starts as disabled and not overridable
>> (see 'ctags' in the context above).
>
> I always assumed that the disabled default was related to how invasive
> the changes would be (to the UI or computationally-wise). As for the
> overridability, that's actually the only reason why it would make
> sense to put in the %feature hash ... otherwise a conf-settable
> $patch_max (as in v2) would have been enough.
Add to that the fact that this patch just adds the new view, like for
example in the case of 'snapshot' link, which was turned on... but fact,
it was by default not overridable. I would agree that it can be turned
on with low limit but not overridable in introductory patch.
>>> sub git_commitdiff {
>>> my $format = shift || 'html';
>>> +
>>> + my $patch_max = gitweb_check_feature('patches');
>>> + if ($format eq 'patch') {
>>> + die_error(403, "Patch view not allowed") unless $patch_max;
>>> + }
>>> +
>>
>> Should you have to pay overhead for the check-feature call even when
>> the $format is not "patch"?
>
> Actually I wasn't sure if I could use my within the if block, and have
> the value visible outside (it's used further down when picking the
> options to pass to format-patch). And since it was used in the second
> patch anyway to choose whether to add the 'patch' link in html view or
> not, I just put it outside the block.
You have to use _declaration_ ourside block, but assignment can happen
inside:
+ my $patch_max;
+ if ($format eq 'patch') {
+ $patch_max = gitweb_check_feature('patches');
+ die_error(403, "Patch view not allowed") unless $patch_max;
+ }
(Side note: doesn't it uses spaces instead of tabs for align?)
[...]
>> Other than that the patch seems quite straightforward and was a pleasant
>> read. Thanks.
BTW. I'll try to review patch (and probably Ack) soon.
--
Jakub Narebski
Poland
^ permalink raw reply
* [RFC/PATCH] Document "git-reset --merge"
From: Junio C Hamano @ 2008-12-04 2:00 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linus Torvalds
In-Reply-To: <alpine.LFD.2.00.0812031634520.3256@nehalem.linux-foundation.org>
The commit log message for the feature made it sound as if this is a saner
version of --mixed, but the use case presented makes it clear that it is a
better variant of --hard when your changes and somebody else's changes are
mixed together.
Perhaps we would want to rewrite the example that shows the use of --hard
not to talk about recovering from a failed merge?
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-reset.txt | 29 ++++++++++++++++++++++++++++-
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git c/Documentation/git-reset.txt i/Documentation/git-reset.txt
index 52aab5e..c542b0c 100644
--- c/Documentation/git-reset.txt
+++ i/Documentation/git-reset.txt
@@ -8,7 +8,7 @@ git-reset - Reset current HEAD to the specified state
SYNOPSIS
--------
[verse]
-'git reset' [--mixed | --soft | --hard] [-q] [<commit>]
+'git reset' [--mixed | --soft | --hard | --merge] [-q] [<commit>]
'git reset' [-q] [<commit>] [--] <paths>...
DESCRIPTION
@@ -45,6 +45,11 @@ OPTIONS
switched to. Any changes to tracked files in the working tree
since <commit> are lost.
+--merge::
+ Resets the index to match the tree recorded by the named commit,
+ and updates the files that are different between the named commit
+ and the current commit in the working tree.
+
-q::
Be quiet, only report errors.
@@ -152,6 +157,28 @@ tip of the current branch in ORIG_HEAD, so resetting hard to it
brings your index file and the working tree back to that state,
and resets the tip of the branch to that commit.
+Undo a merge or pull inside a dirty work tree::
++
+------------
+$ git pull <1>
+Auto-merging nitfol
+Merge made by recursive.
+ nitfol | 20 +++++----
+ ...
+$ git reset --merge ORIG_HEAD <2>
+------------
++
+<1> Even if you may have local modifications in your
+working tree, you can safely say "git pull" when you know
+that the change in the other branch does not overlap with
+them.
+<2> After inspecting the result of the merge, you may find
+that the change in the other branch is unsatisfactory. Running
+"git reset --hard ORIG_HEAD" will let you go back to where you
+were, but it will discard your local changes, which you do not
+want. "git reset --merge" keeps your local changes.
+
+
Interrupted workflow::
+
Suppose you are interrupted by an urgent fix request while you
^ permalink raw reply related
* Re: Add 'sane' mode to 'git reset'
From: Junio C Hamano @ 2008-12-04 2:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812031634520.3256@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 3 Dec 2008, Junio C Hamano wrote:
>>
>> The recovery procedure I would use in such a case (and I rarely pull while
>> managing git.git even though I do so in my day job) would be:
>>
>> $ git checkout -b this-needs-more-work
>> $ git checkout master
>
> No, that won't work. The second 'git checkout' does nothing, since
> 'master' still has all the broken code in it.
Yeah, brain-o. I should have said
git checkout -b needs-more-work
git branch -f master master~$n
git checkout master
or something like that.
^ permalink raw reply
* Re: more merge strategies : feature request
From: Junio C Hamano @ 2008-12-04 2:15 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Leo Razoumov, Caleb Cushing, git
In-Reply-To: <20081204062717.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Isn't what Caleb wants "-X ours/theirs" per-hunk option for merge strategy backends?
>
> It was discussed several months ago on the list and was rejected. For details you can start here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021
>
> I still think the patch in the above link was reasonable, but the thread
> was distracted into discussing minor syntactical details of how the
> option gets passed to the backend, and the rest of the discussion to
> decide if it makes sense to add such a feature was unfortunately lost in
> the noise and never concluded.
I thought http://article.gmane.org/gmane.comp.version-control.git/89033 in
the thread (and your response to it which is 89175) pretty much concluded
the discussion. Is Caleb adding anything new to the discussion (iow, is
there a convincing new argument why having such a merge is a good idea and
what the workflow looks like that benefits from it)?
^ permalink raw reply
* How to update the tag to Git server?
From: Gary Yang @ 2008-12-04 2:16 UTC (permalink / raw)
To: git
I pushed code from my local repository to Git Server.
git push git.company.com:/pub/git/training.git
I, then tagged my local repository.
git tag -u gyang@company.com RELEASE_2
I want to update the Git server so that I can have the tag at my Git server, I did:
git push git.company.com:/pub/git/training.git
Everything up-to-date
I got "Everything up-to-date". Same story for the command with -f.
git push -f svdcgit01.amcc.com:/pub/git/training.git
git tag -l
RELEASE_2
>From my git server, git.company.com, I cannot see the tag at summary. I need to have the tag, RELEASE_2 at git.company.com. Can someone tell me how to do it?
Thanks.
^ permalink raw reply
* Re: How to update the tag to Git server?
From: Peter Harris @ 2008-12-04 2:35 UTC (permalink / raw)
To: garyyang6; +Cc: git
In-Reply-To: <84437.20577.qm@web37903.mail.mud.yahoo.com>
On Wed, Dec 3, 2008 at 9:16 PM, Gary Yang wrote:
>
> I pushed code from my local repository to Git Server.
> git push git.company.com:/pub/git/training.git
>
> I, then tagged my local repository.
> git tag -u gyang@company.com RELEASE_2
>
> I want to update the Git server so that I can have the tag at my Git server, I did:
> git push git.company.com:/pub/git/training.git
> Everything up-to-date
Did you try "git push git.company.com:/pub/git/training.git tag
RELEASE_2" or "git push git.company.com:/pub/git/training.git --tags",
as it suggests in "git help push"?
Peter Harris
^ permalink raw reply
* Re: How to update the tag to Git server?
From: Junio C Hamano @ 2008-12-04 2:48 UTC (permalink / raw)
To: garyyang6; +Cc: git
In-Reply-To: <84437.20577.qm@web37903.mail.mud.yahoo.com>
Gary Yang <garyyang6@yahoo.com> writes:
> I pushed code from my local repository to Git Server.
> git push git.company.com:/pub/git/training.git
>
> I, then tagged my local repository.
> git tag -u gyang@company.com RELEASE_2
git-push(1) manual page says that the syntax of the command is:
'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-v | --verbose]
[<repository> <refspec>...]
and its OPTIONS section explains what <refspec> means.
<refspec>...::
The canonical format of a <refspec> parameter is
`+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
...
The <src> side represents the source branch (or arbitrary
"SHA1 expression", such as `master~4` (four parents before the
tip of `master` branch); see linkgit:git-rev-parse[1]) that you
want to push. The <dst> side represents the destination location.
You want to update refs/tags/RELEASE_2 on the destination side (i.e. the
public server) with the same refs/tags/RELEASE_2 on the source side
(i.e. your side), so you would want to say
refs/tags/RELEASE_2:refs/tags/RELEASE_2
for <refspec>. The documentation further mentions that there is a
short-hand for that:
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
Hence the command line becomes:
$ git push svdcgit01.amcc.com:/pub/git/training.git tag RELEASE_2
Note that saying "tag" is redundant these days as long as you do not have
a branch named "RELEASE_2" at the same time. But saying "tag" never
hurts, as it is still (and will be) supported.
Note to people who teach git to new people. The moral of the story is not
that people should learn to read the manual pages. It is that people
should not learn "push" without remote nor refspec first. In other words,
the first push command you teach them should be the "git push $over_there
$this_refspec" form, fully spelled.
^ permalink raw reply
* Re: "git help stage" doesn't display git-stage man page
From: Jeff King @ 2008-12-04 3:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Teemu Likonen, git, Scott Chacon
In-Reply-To: <7vmyfdfyi9.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 03, 2008 at 12:34:22AM -0800, Junio C Hamano wrote:
> diff --git a/Makefile b/Makefile
> index 9577d6f..5158197 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
> BUILT_INS += git-peek-remote$X
> BUILT_INS += git-repo-config$X
> BUILT_INS += git-show$X
> +BUILT_INS += git-stage$X
> BUILT_INS += git-status$X
> BUILT_INS += git-whatchanged$X
We need this, too, then.
-- >8 --
add stage to gitignore
This is a generated builtin since 24b1f65f (Install git-stage in
exec-path).
Signed-off-by: Jeff King <peff@peff.net>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 0c35577..327e660 100644
--- a/.gitignore
+++ b/.gitignore
@@ -118,6 +118,7 @@ git-show
git-show-branch
git-show-index
git-show-ref
+git-stage
git-stash
git-status
git-stripspace
--
1.6.1.rc1.309.g51074
^ permalink raw reply related
* Re: summaries in git add --patch[PATCH 1/2]
From: William Pursell @ 2008-12-04 6:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4g8alp7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Do you really want the surrounding @@ in the result, by the way?
Oddly, I liked it before. But now that you mention it, it does
seem ugly.
> How well does substr() work with utf-8 and other multi-byte encodings
> these days, I have to wonder...
Hopefully, it works well.
Here's another go, with your suggestions applied.
From 92ab9b7c694ba98b43984bbbdfcd5eeb9cbb7d56 Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Thu, 4 Dec 2008 06:09:50 +0000
Subject: [PATCH 1/2] Add subroutine to display one-line summary of hunks.
This commit implements a rather simple-minded mechanism
to display a one-line summary of the hunks in an array ref.
The display consists of the line numbers and the first
changed line, truncated to 80 characters. 20 lines are
displayed at a time, and the index of the first undisplayed
line is returned, allowing the caller to display more if
desired. (The 20 and 80 should be made configurable.)
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 42 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..b25a841 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -836,6 +836,48 @@ sub patch_update_cmd {
}
}
+# Generate a one line summary of a hunk.
+sub summarize_hunk {
+ my $rhunk = shift;
+ my $summary = $rhunk->{TEXT}[0];
+
+ # Keep the line numbers, discard extra context.
+ $summary =~ s/@@(.*?)@@.*/$1 /s;
+ $summary .= " " x (20 - length $summary);
+
+ # Add some user context, the first changed line that contains
+ # some non-white character other than a bracket.
+ for my $line (@{$rhunk->{TEXT}}) {
+ if ($line =~ m/^([+-][][{}()\s]*[^][{}()\s])/) {
+ $summary .= $line;
+ last;
+ }
+ }
+
+ chomp $summary;
+ return substr($summary, 0, 80) . "\n";
+}
+
+
+# Print a one-line summary of each hunk in the array ref in
+# the first argument, starting wih the index in the 2nd.
+sub display_hunks {
+ my ($hunks, $i) = @_;
+ my $ctr = 0;
+ $i = 0 if not $i;
+ for (; $i < @$hunks && $ctr < 20; $i++, $ctr++) {
+ my $status = " ";
+ if (defined $hunks->[$i]{USE}) {
+ $status = $hunks->[$i]{USE} ? "+" : "-";
+ }
+ printf "%s%2d: %s",
+ $status,
+ $i + 1,
+ summarize_hunk($hunks->[$i]);
+ }
+ return $i;
+}
+
sub patch_update_file {
my ($ix, $num);
my $path = shift;
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: summaries in git add --patch[PATCH 2/2]
From: William Pursell @ 2008-12-04 6:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4p1kalno.fsf@gitster.siamese.dyndns.org>
From b039fb8aa03efab3faf46c0a0a8d84cea974f26f Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Thu, 4 Dec 2008 06:48:57 +0000
Subject: [PATCH 2/2] Add 'g' command to go to a hunk.
When a minor change is made while the working directory
is in a bit of a mess (and the user should have done a
stash before making the minor edit, but didn't) it is
somewhat difficult to wade through all of the hunks using
git add --patch. This allows one to jump to the hunk
that needs to be staged without having to respond 'n' to
each preceding hunk.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b25a841..555c981 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -800,6 +800,7 @@ y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
+g - select a hunk to goto
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@@ -946,6 +947,9 @@ sub patch_update_file {
if ($ix < $num - 1) {
$other .= '/J';
}
+ if ($num > 1) {
+ $other .= '/g';
+ }
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$undecided = 1;
@@ -979,6 +983,28 @@ sub patch_update_file {
}
next;
}
+ elsif ($other =~ 'g' && $line =~ /^g(.*)/) {
+ my $response = $1;
+ my $i = $ix > 10 ? $ix - 10 : 0;
+ while ($response eq '') {
+ my $extra = "";
+ $i = display_hunks(\@hunk, $i);
+ if ($i < $num) {
+ $extra = " (<ret> to see more)";
+ }
+ print "goto which hunk$extra? ";
+ $response = <STDIN>;
+ chomp $response;
+ }
+ if ($response !~ /^\s*\d+\s*$/) {
+ print STDERR "Invalid number: '$response'\n";
+ } elsif (0 < $response && $response <= $num) {
+ $ix = $response - 1;
+ } else {
+ print STDERR "Sorry, only $num hunks available.\n";
+ }
+ next;
+ }
elsif ($line =~ /^d/i) {
while ($ix < $num) {
if (!defined $hunk[$ix]{USE}) {
--
1.6.1.rc1.37.g83daf.dirty
^ permalink raw reply related
* Re: [RFCv3 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-04 7:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <200812040249.01374.jnareb@gmail.com>
On Thu, Dec 4, 2008 at 2:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, Dec 4, 2008 at 01:20, Giuseppe Bilotta wrote:
>> On Thu, Dec 4, 2008 at 12:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>>> +
>>>> + # 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.
>>>> + 'patches' => {
>>>> + 'override' => 1,
>>>> + 'default' => [16]},
>
> Errr... you need something like 'sub' => \&feature_patches for override
> to actually work, I think.
Oops, right.
>> I always assumed that the disabled default was related to how invasive
>> the changes would be (to the UI or computationally-wise). As for the
>> overridability, that's actually the only reason why it would make
>> sense to put in the %feature hash ... otherwise a conf-settable
>> $patch_max (as in v2) would have been enough.
>
> Add to that the fact that this patch just adds the new view, like for
> example in the case of 'snapshot' link, which was turned on... but fact,
> it was by default not overridable. I would agree that it can be turned
> on with low limit but not overridable in introductory patch.
Ok, I'll make it non-overridable, and keep this 16 limit for starters.
Or would you suggest even lower?
>>>> sub git_commitdiff {
>>>> my $format = shift || 'html';
>>>> +
>>>> + my $patch_max = gitweb_check_feature('patches');
>>>> + if ($format eq 'patch') {
>>>> + die_error(403, "Patch view not allowed") unless $patch_max;
>>>> + }
>>>> +
>>>
>>> Should you have to pay overhead for the check-feature call even when
>>> the $format is not "patch"?
>>
>> Actually I wasn't sure if I could use my within the if block, and have
>> the value visible outside (it's used further down when picking the
>> options to pass to format-patch). And since it was used in the second
>> patch anyway to choose whether to add the 'patch' link in html view or
>> not, I just put it outside the block.
>
> You have to use _declaration_ ourside block, but assignment can happen
> inside:
>
> + my $patch_max;
> + if ($format eq 'patch') {
> + $patch_max = gitweb_check_feature('patches');
> + die_error(403, "Patch view not allowed") unless $patch_max;
> + }
Right, stupid me.
> (Side note: doesn't it uses spaces instead of tabs for align?)
I'll check.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 1/2]
From: Junio C Hamano @ 2008-12-04 8:47 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <49377ED8.4050905@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
>> How well does substr() work with utf-8 and other multi-byte encodings
>> these days, I have to wonder...
>
> Hopefully, it works well.
"Hopefully" is the last word I'd like to hear from submitters. It would
be either "I do not know" or "I studied the topic and I know the code works".
> Here's another go, with your suggestions applied.
Sorry, this came too late for tonight's round. I have a fixed-up one
based on your previous round parked in 'pu', which I'll be replacing with
this one (or your future re-submission if there is any) later in the week.
By the way, I noticed that you are sending your patches with:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Please don't. format=flawed tends to destroy whitespaces (I fixed them up
by hand for the ones I parked in 'pu').
> + # Add some user context, the first changed line that contains
> + # some non-white character other than a bracket.
> + for my $line (@{$rhunk->{TEXT}}) {
> + if ($line =~ m/^([+-][][{}()\s]*[^][{}()\s])/) {
I would say "$line =~ /^[-+].*\w/" (i.e. match any +/- line that contains
a word letter) would be sufficient, and it would be much easier to read.
As you append the entire $line to $summary, there is no need to capture
with ().
> +# Print a one-line summary of each hunk in the array ref in
> +# the first argument, starting wih the index in the 2nd.
> +sub display_hunks {
> + my ($hunks, $i) = @_;
> + my $ctr = 0;
> + $i = 0 if not $i;
I think "$i ||= 0" is more customary.
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 2/2]
From: Junio C Hamano @ 2008-12-04 9:00 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <49377F25.9020005@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> From b039fb8aa03efab3faf46c0a0a8d84cea974f26f Mon Sep 17 00:00:00 2001
> From: William Pursell <bill.pursell@gmail.com>
> Date: Thu, 4 Dec 2008 06:48:57 +0000
> Subject: [PATCH 2/2] Add 'g' command to go to a hunk.
>
> When a minor change is made while the working directory
> is in a bit of a mess (and the user should have done a
> stash before making the minor edit, but didn't) it is
> somewhat difficult to wade through all of the hunks using
> git add --patch. This allows one to jump to the hunk
> that needs to be staged without having to respond 'n' to
> each preceding hunk.
The issue is not limited to "forgot to stash" situation.
> Signed-off-by: William Pursell <bill.pursell@gmail.com>
> ---
It is customary to explain what you changed since v1 here, after the
three-dash separator, to help reviewers.
> git-add--interactive.perl | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index b25a841..555c981 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -800,6 +800,7 @@ y - stage this hunk
> n - do not stage this hunk
> a - stage this and all the remaining hunks in the file
> d - do not stage this hunk nor any of the remaining hunks in the file
> +g - select a hunk to goto
"go to"? There are a few more.
> j - leave this hunk undecided, see next undecided hunk
> J - leave this hunk undecided, see next hunk
> k - leave this hunk undecided, see previous undecided hunk
> @@ -946,6 +947,9 @@ sub patch_update_file {
> if ($ix < $num - 1) {
> $other .= '/J';
> }
> + if ($num > 1) {
> + $other .= '/g';
> + }
> for ($i = 0; $i < $num; $i++) {
> if (!defined $hunk[$i]{USE}) {
> $undecided = 1;
> @@ -979,6 +983,28 @@ sub patch_update_file {
> }
> next;
> }
> + elsif ($other =~ 'g' && $line =~ /^g(.*)/) {
I think I fixed this with ($other =~ /g/ && ...) when I queued your
previous round to 'pu' tonight.
> + my $response = $1;
> + my $i = $ix > 10 ? $ix - 10 : 0;
This is different from v1. I understand the motivation (i.e. if you are
at 73rd hunk of a 100-hunk series, showing hunks 63-83 instead of starting
from hunk 1-10 would be nicer), but that is something to explain as one of
the "changes since v1".
I think you are inside a loop that is controlled by another $i (see the
context in the hunk before this one) and it would be better to use
different variable, such as $hunk_no (or just $no).
> + while ($response eq '') {
> + my $extra = "";
> + $i = display_hunks(\@hunk, $i);
> + if ($i < $num) {
> + $extra = " (<ret> to see more)";
> + }
> + print "goto which hunk$extra? ";
"go to"?
Again, this came too late for tonight's round. I've parked your previous
one with fix-up in 'pu', but you are free to tell me to replace it
(together with [1/2] from your previous round) with an updated pair.
^ permalink raw reply
* Re: [StGit PATCH] Print conflict details with the new infrastructure (bug #11181)
From: Karl Hasselström @ 2008-12-04 9:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081203213813.9924.62751.stgit@localhost.localdomain>
On 2008-12-03 21:38:13 +0000, Catalin Marinas wrote:
> The patch modifies the IndexAndWorkTree.merge() function to display
> pass the conflict information (files) when raising an exception. The
> logic is similar to the one in the old infrastructure.
Looks good. Thanks.
> Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: read-only mode
From: Michael J Gruber @ 2008-12-04 9:47 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <8763m0swtz.fsf@jidanni.org>
jidanni@jidanni.org venit, vidit, dixit 03.12.2008 23:44:
> Here's a documentation stub. Please fix and finish it and place in some manual.
[Warning: irony ahead] Yes master, at your service!
[I'm aware he tone in the quote above may be due to translation issues.]
> ==Using git in read-only mode==
> Let's say you just want to examine things. There is a fine line
> between commands and options that just examine things vs. those that
> change things. One might worry that they can't remember that fine line.
>
> Therefore the safest way to ensure you are using git in 'read-only mode' is to
> * su nobody, or
> * chmod -R u-w . (and remember to chmod -R u+w when you are finished), or
This does change things (time stamps).
I'd say the two above are no git-specific suggestions at all, and "cp -a
.git .git-orig" is the best safety-net for the cautious (assuming a
clean working tree) when doing heavy work but overkill for inspection.
> * ???
* clone and inspect the clone instead
* use obvious read-only commands (status, log, diff, show, ls-files,
tag&branch without argument) and avoid obvious write commands (commit,
checkout, apply, ...)
Without specifying "things" any further (repo, objects, index, working
tree) I don't really understand what the problem is.
Michael
^ permalink raw reply
* Re: more merge strategies : feature request
From: Nanako Shiraishi @ 2008-12-04 10:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Leo Razoumov, Caleb Cushing, git
In-Reply-To: <7vabbc7kk5.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> I thought http://article.gmane.org/gmane.comp.version-control.git/89033 in
> the thread (and your response to it which is 89175) pretty much concluded
> the discussion. Is Caleb adding anything new to the discussion (iow, is
> there a convincing new argument why having such a merge is a good idea and
> what the workflow looks like that benefits from it)?
I first thought so, but after reading this feature request thread again I do not think so anymore.
Sorry for the noise.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* git-gui: Warn when username and e-mail address is unconfigured?
From: Peter Krefting @ 2008-12-04 10:43 UTC (permalink / raw)
To: Git Mailing List
Hi!
When using Git on Windows, it doesn't pick up a user name from the
environment, which leads to commits made by git gui (and probably by
git itself) to show up as being made by "unknown <username@.(none)>"
(where "username" is the Windows account name).
Is it possible to add a warning to git-gui the first time a commit is
attempted if the e-mail address is not configured, and have the user
open the configuration dialogue to set up the name properly?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 1/2]
From: William Pursell @ 2008-12-04 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdu0e38a.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> William Pursell <bill.pursell@gmail.com> writes:
>
>>> How well does substr() work with utf-8 and other multi-byte encodings
>>> these days, I have to wonder...
>> Hopefully, it works well.
>
> "Hopefully" is the last word I'd like to hear from submitters. It would
> be either "I do not know" or "I studied the topic and I know the code works".
Right. From what I can tell (30 minutes of research, and I
am by no means an expert), perl 5.8 will handle this just
fine with no changes to the code as long as one of the
environment variables LANGUAGE, LC_ALL, LC_TYPE, or LANG
contains either 'UTF-8' or 'UTF8'. With that setting,
all file handles will be opened in UTF8 mode, so the
git diff-files pipe should be parsed appropriately.
I think this is not an issue except with older Perl.
> By the way, I noticed that you are sending your patches with:
>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Please don't. format=flawed tends to destroy whitespaces (I fixed them up
> by hand for the ones I parked in 'pu').
Thanks for pointing that out. Settings changed. I do appreciate
you taking the time to essentially hold my hand through this
process, and hope that I'm not causing you too much extra work.
> I would say "$line =~ /^[-+].*\w/" (i.e. match any +/- line that contains
> a word letter) would be sufficient, and it would be much easier to read.
>
> As you append the entire $line to $summary, there is no need to capture
> with ().
Done.
>
> I think "$i ||= 0" is more customary.
>
Also changed.
>From 2d191d7170948246007cbde5afb28eeb666b3427 Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Thu, 4 Dec 2008 10:00:24 +0000
Subject: [PATCH 1/2] Add subroutine to display one-line summary of hunks.
This commit implements a rather simple-minded mechanism
to display a one-line summary of the hunks in an array ref.
The display consists of the line numbers and the first
changed line, truncated to 80 characters. 20 lines are
displayed at a time, and the index of the first undisplayed
line is returned, allowing the caller to display more if
desired. (The 20 and 80 should be made configurable.)
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
changes from v1:
do not print '@@' characters in summary
pad line numbers in summary to 20 chars to help alignment
only accept diff lines with a non-space, non-bracket character
ensure a newline appears on a trimmed line
changes from v2:
accept any line with a word char (instead of insisting on non-bracket)
use "$i || = 0" instead of "$i = 0 if not $i"
git-add--interactive.perl | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..eb11132 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -836,6 +836,47 @@ sub patch_update_cmd {
}
}
+# Generate a one line summary of a hunk.
+sub summarize_hunk {
+ my $rhunk = shift;
+ my $summary = $rhunk->{TEXT}[0];
+
+ # Keep the line numbers, discard extra context.
+ $summary =~ s/@@(.*?)@@.*/$1 /s;
+ $summary .= " " x (20 - length $summary);
+
+ # Add some user context.
+ for my $line (@{$rhunk->{TEXT}}) {
+ if ($line =~ m/^[+-].*\w/) {
+ $summary .= $line;
+ last;
+ }
+ }
+
+ chomp $summary;
+ return substr($summary, 0, 80) . "\n";
+}
+
+
+# Print a one-line summary of each hunk in the array ref in
+# the first argument, starting wih the index in the 2nd.
+sub display_hunks {
+ my ($hunks, $i) = @_;
+ my $ctr = 0;
+ $i ||= 0;
+ for (; $i < @$hunks && $ctr < 20; $i++, $ctr++) {
+ my $status = " ";
+ if (defined $hunks->[$i]{USE}) {
+ $status = $hunks->[$i]{USE} ? "+" : "-";
+ }
+ printf "%s%2d: %s",
+ $status,
+ $i + 1,
+ summarize_hunk($hunks->[$i]);
+ }
+ return $i;
+}
+
sub patch_update_file {
my ($ix, $num);
my $path = shift;
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: summaries in git add --patch[PATCH 2/2]
From: William Pursell @ 2008-12-04 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljuwe2na.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> William Pursell <bill.pursell@gmail.com> writes:
>> Signed-off-by: William Pursell <bill.pursell@gmail.com>
>> ---
>
> It is customary to explain what you changed since v1 here, after the
> three-dash separator, to help reviewers.
Thanks for pointing that out.
>> + elsif ($other =~ 'g' && $line =~ /^g(.*)/) {
>
> I think I fixed this with ($other =~ /g/ && ...) when I queued your
> previous round to 'pu' tonight.
I didn't notice that the first time around. Fixed here.
>
>> + my $response = $1;
>> + my $i = $ix > 10 ? $ix - 10 : 0;
>
> This is different from v1. I understand the motivation (i.e. if you are
> at 73rd hunk of a 100-hunk series, showing hunks 63-83 instead of starting
> from hunk 1-10 would be nicer), but that is something to explain as one of
> the "changes since v1".
>
> I think you are inside a loop that is controlled by another $i (see the
> context in the hunk before this one) and it would be better to use
> different variable, such as $hunk_no (or just $no).
Agreed. Masking enclosing variables is a no-no.
>From 03ae1932337c15cdd20e0d8370782a6343efc5aa Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Thu, 4 Dec 2008 10:22:40 +0000
Subject: [PATCH 2/2] Add 'g' command to go to a hunk.
When a minor change is made while the working directory is in a bit
of a mess, it is somewhat difficult to wade through all of the
hunks using git add --patch. This allows one to jump to the hunk
that needs to be staged without having to respond 'n' to each
preceding hunk.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
changes since v1:
start the summary list from current hunk - 10 rather than 0
replace a statement modifier with a conditional block, for readability
clean up the prompt, so "(<ret> to see more)" appears before '?'
allow trailing whitespace in the user response
changes since v2:
s/goto/go to/
s|=~ 'g'|=~ /g/|
change loop index name from $i to $no, as $i masks a name in the enclosing
scope
git-add--interactive.perl | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index eb11132..ca60356 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -800,6 +800,7 @@ y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
+g - select a hunk to go to
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@@ -945,6 +946,9 @@ sub patch_update_file {
if ($ix < $num - 1) {
$other .= '/J';
}
+ if ($num > 1) {
+ $other .= '/g';
+ }
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$undecided = 1;
@@ -978,6 +982,28 @@ sub patch_update_file {
}
next;
}
+ elsif ($other =~ /g/ && $line =~ /^g(.*)/) {
+ my $response = $1;
+ my $no = $ix > 10 ? $ix - 10 : 0;
+ while ($response eq '') {
+ my $extra = "";
+ $no = display_hunks(\@hunk, $no);
+ if ($no < $num) {
+ $extra = " (<ret> to see more)";
+ }
+ print "go to which hunk$extra? ";
+ $response = <STDIN>;
+ chomp $response;
+ }
+ if ($response !~ /^\s*\d+\s*$/) {
+ print STDERR "Invalid number: '$response'\n";
+ } elsif (0 < $response && $response <= $num) {
+ $ix = $response - 1;
+ } else {
+ print STDERR "Sorry, only $num hunks available.\n";
+ }
+ next;
+ }
elsif ($line =~ /^d/i) {
while ($ix < $num) {
if (!defined $hunk[$ix]{USE}) {
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: git alias always chdir to top
From: Jeff King @ 2008-12-04 12:34 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20081203160852.GA3773@osc.edu>
On Wed, Dec 03, 2008 at 11:08:52AM -0500, Pete Wyckoff wrote:
> It looks like handle_alias() uses setup_git_directory_gently() to
> find the .git, which chdir()s up until it gets there. Is there a
> way to do this without changing the process current working
> directory instead? I could even handle an environment variable
> saving the original cwd, but that's ickier.
There has been some discussion of refactoring the setup to _not_ do that
chdir until later, which should fix your problem. And other problems,
too, since aliases can get confused about whether or not we're in a
worktree (try "git config alias.st status && cd .git && git st") as a
result of the startup sequence. Ideally the _only_ thing to happen
before running an alias would be to look at the config to see how to run
the alias, and everything else would be "as if" you had just run the
alias manually.
So no, there's no way to do it correctly right now. The git commands
internally do know the original prefix, but I don't think it is exposed
via the environment.
I hope this will get fixed eventually, but refactoring this code is
unpleasant enough and I have been busy enough that it hasn't happened
yet. You are of course welcome to volunteer. ;)
-Peff
^ permalink raw reply
* [PATCH] gitk: fix 'can't read "notflag"'
From: Johannes Schindelin @ 2008-12-04 14:34 UTC (permalink / raw)
To: Paul Mackerras, Alejandro Riveira; +Cc: git
In-Reply-To: <gh5q1t$qjn$1@ger.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 973 bytes --]
Sometimes, when calling git bisect visualize, parameters including
a "--not" are passed to gitk, triggering an uninitialized-variable bug
introduced in ee66e089(gitk: Make updates go faster).
Noticed by Alejandro Riveira Fernández.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 3 Dec 2008, Alejandro Riveira wrote:
> $ git bisect visualize (03-12 12:16)
> Error in startup script: can't read "notflag": no such variable
Alejandro was good enough to test this fix.
gitk-git/gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..b18bdf0 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -139,6 +139,7 @@ proc parseviewargs {n arglist} {
set origargs $arglist
set allknown 1
set filtered 0
+ set notflag 0
set i -1
foreach arg $arglist {
incr i
--
1.6.0.4.1189.g8876f
^ permalink raw reply related
* [PATCH] git-p4: Fix bug in p4Where method.
From: Tor Arvid Lund @ 2008-12-04 13:37 UTC (permalink / raw)
To: Junio C. Hamano, Simon Hausmann; +Cc: git, Tor Arvid Lund
When running:
p4 where //depot/SomePath/...
The result can in some situations look like:
//depot/SomePath/... //client/SomePath/... /home/user/p4root/SomePath/...
-//depot/SomePath/UndesiredSubdir/... //client/SomePath/UndesiredSubdir/... /home/user/p4root/SomePath/UndesiredSubdir/...
This depends on the users Client view. The current p4Where method will now
return /home/user/p4root/SomePath/UndesiredSubdir/... which is not what we
want. This patch loops through the results from "p4 where", and picks the one
where the depotFile exactly matches the given depotPath (//depot/SomePath/...
in this example).
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com>
---
contrib/fast-import/git-p4 | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 46136d4..7ade777 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -245,7 +245,15 @@ def p4Cmd(cmd):
def p4Where(depotPath):
if not depotPath.endswith("/"):
depotPath += "/"
- output = p4Cmd("where %s..." % depotPath)
+ depotPath = depotPath + "..."
+ outputList = p4CmdList("where %s" % depotPath)
+ output = None
+ for entry in outputList:
+ if entry["depotFile"] == depotPath:
+ output = entry
+ break
+ if output == None:
+ return ""
if output["code"] == "error":
return ""
clientPath = ""
--
1.6.0.2.1172.ga5ed0
^ permalink raw reply related
* Re: [PATCH] gitk: fix 'can't read "notflag"'
From: Johannes Schindelin @ 2008-12-04 15:09 UTC (permalink / raw)
To: Paul Mackerras, Alejandro Riveira; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812041532160.7045@racer>
Hi,
On Thu, 4 Dec 2008, Johannes Schindelin wrote:
> diff --git a/gitk-git/gitk b/gitk-git/gitk
D'oh. Please apply with -p2.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox