* Re: [PATCH] merge: use editor by default in interactive sessions
From: Thomas Rast @ 2012-01-30 17:06 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vipk26p1b.fsf@alter.siamese.dyndns.org>
On Mon, 23 Jan 2012 14:18:40 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Traditionally, a cleanly resolved merge was committed by "git merge" using
> the auto-generated merge commit log message with invoking the editor.
>
> After 5 years of use in the field, it turns out that people perform too
> many unjustified merges of the upstream history into their topic branches.
> These merges are not just useless, but they are often not explained well,
> and making the end result unreadable when it gets time for merging their
> history back to their upstream.
Ok, so I'm late to the party and perhaps I missed the discussion about
this, but...
I think the proposed commit message should have a comment, just like for
an ordinary commit, that explains why we are showing the user an editor.
(I'm too lazy to check, but I suspect we *always* give a comment about
what is going on when we fire up an editor.)
I would suggest something like
# Please enter the commit message for your merge commit. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
or if you feel comfortable with educating the user in a
workflow-specific way, even
# Please enter the commit message for your merge commit. You should
# justify it especially if it merges an updated upstream into a topic
# branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-30 16:56 UTC (permalink / raw)
To: David A. Greene; +Cc: Jeff King, Ramkumar Ramachandra, git
In-Reply-To: <87aa56kvr4.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
> I originally put them under t97XX but now that is taken, as is
> everything up to and including t99XX.
Oops, I lied. I originally put them under t79XX and I've kept that for
now. Sound good?
-Dave
^ permalink raw reply
* git rebase and MacOS 10.7.2 file versions
From: Thomas Röfer @ 2012-01-30 16:46 UTC (permalink / raw)
To: git
Hi,
I get mysterious behavior during git rebase on MacOS 10.7.x. git reports unresolvable conflicts, stops the rebase, but afterwards the list of files that needs to be fixed is empty. git rebase --skip does not help, because then the commit is actually missing.
What helps is to abort the rebase, copy the conflicting files, delete the originals and move back the copies instead. The files themselves are identical before deleting and after restoring and their access rights are also unchanged. What is actually different is that all the conflicting files so far had older versions stored by Lion's "file versions" feature. The restored copies do not have such a version history. Since "file versions" cannot be deactivated, editing a file with an application that supports it (e.g. TextEdit) will basically result in strange git conflicts later.
I have tested this with a number of git versions, but the behavior is always the same.
All this may simply be a bug in MacOS 10.7.x, but maybe there is a workaround for git to make this work again.
Best regards,
Thomas Röfer
^ permalink raw reply
* Re: [PATCH v5.5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Bernhard R. Link @ 2012-01-30 16:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <201201301640.35843.jnareb@gmail.com>
* Jakub Narebski <jnareb@gmail.com> [120130 16:40]:
> Perhaps there are other cases...
>
> > @@ -2841,7 +2840,7 @@ sub git_get_projects_list {
> > my $pfxlen = length("$dir");
> > my $pfxdepth = ($dir =~ tr!/!!);
> > # when filtering, search only given subdirectory
> > - if ($filter) {
> > + if ($filter and not $paranoid) {
>
> Hmmmm... ($filter and !$paranoid) or ($filter && !$paranoid)?
> Which would be more Perl-ish and fit current code style better...
I cannot say what is more perlish, but gitweb.perl seems to contain
only the combinations "and not" (1 time) and "&& !" (8 times).
Bernhard R. Link
^ permalink raw reply
* Re: [PATCH v5 4/5] gitweb: show active project_filter in project_list page header
From: Jakub Narebski @ 2012-01-30 16:38 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Junio C Hamano, git
In-Reply-To: <20120130114852.GD9267@server.brlink.eu>
On Mon, 30 Jan 2012, Bernhard R. Link wrote:
> In a project_list view show breadcrumbs with the currently active
> project_filter (and those of parent directories) in the page header.
O.K. (though I'd prefer written it less concise and more clear).
> Signed-off-by: Bernhard R. Link <brlink@debian.org>
> ---
> gitweb/gitweb.perl | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e022e11..dfc79df 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3836,6 +3836,18 @@ sub print_header_links {
> }
> }
>
> +sub print_nav_breadcrumbs_path {
> + my $dirprefix = undef;
> + while (my $part = shift) {
Hmmm... using agument list directly, without copying it? Well, all right.
> + $dirprefix .= "/" if defined $dirprefix;
> + $dirprefix .= $part;
> + print $cgi->a({-href => href(project => undef,
> + project_filter => $dirprefix,
> + action=>"project_list")},
Minor nitpick: Let's use same whitespace rules for all key-value pairs
+ action => "project_list")},
> + esc_html($part)) . " / ";
> + }
> +}
> +
> sub print_nav_breadcrumbs {
> my %opts = @_;
>
> @@ -3854,6 +3866,8 @@ sub print_nav_breadcrumbs {
> print " / $opts{-action_extra}";
> }
> print "\n";
> + } elsif (defined $project_filter) {
> + print_nav_breadcrumbs_path(split '/', $project_filter);
> }
> }
Nice!
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/5] gitweb: limit links to alternate forms of project_list to active project_filter
From: Jakub Narebski @ 2012-01-30 16:09 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Junio C Hamano, git
In-Reply-To: <20120130114706.GC9267@server.brlink.eu>
On Mon, 30 Jan 2012, Bernhard R. Link wrote:
> If project_list action is given a project_filter argument, pass that to
> TXT and OPML formats.
Nice.
This way [OPML] and [TXT] links provide the same list of projects as
the projects_list page they are linked from.
> Signed-off-by: Bernhard R. Link <brlink@debian.org>
> ---
> gitweb/gitweb.perl | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 36efc10..e022e11 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3976,9 +3976,11 @@ sub git_footer_html {
> }
>
> } else {
> - print $cgi->a({-href => href(project=>undef, action=>"opml"),
> + print $cgi->a({-href => href(project=>undef, action=>"opml",
> + project_filter => $project_filter),
> -class => $feed_class}, "OPML") . " ";
> - print $cgi->a({-href => href(project=>undef, action=>"project_index"),
> + print $cgi->a({-href => href(project=>undef, action=>"project_index",
> + project_filter => $project_filter),
> -class => $feed_class}, "TXT") . "\n";
> }
Nicely short.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: gitweb showing slash r at the end of line
From: Ondra Medek @ 2012-01-30 16:09 UTC (permalink / raw)
To: git
In-Reply-To: <m3obtlczmu.fsf@localhost.localdomain>
Thanks for pointing out the [gitweb] section of the config. Should I try to
make the patch or someone else more skilled would pick this up?
Cheers
Ondra
--
View this message in context: http://git.661346.n2.nabble.com/gitweb-showing-slash-r-at-the-end-of-line-tp7229895p7237025.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v5 2/5] gitweb: add project_filter to limit project list to a subdirectory
From: Jakub Narebski @ 2012-01-30 15:57 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Junio C Hamano, git
In-Reply-To: <20120130114557.GB9267@server.brlink.eu>
On Mon, 30 Jan 2012, Bernhard R. Link wrote:
> This commit changes the project listing views (project_list,
> project_index and opml) to limit the output to only projects in a
> subdirectory if the new optional parameter ?pf=directory name is
> used.
It would be nice to have in this or in a separate commit an update
to get_page_title() for HTML output, and to git_opml() updating
<title> element in OPML output, so that it mentions that project
list is limitied to $project_filter subdirectory.
For plain text output of git_project_index() nothing really can be
done -- there is no title. Well, we could fiddle with 'filename'
part of Content-Disposition HTTP header...
> The implementation of the filter reuses the implementation used for
> the 'forks' action (i.e. listing all projects within that directory
> from the projects list file (GITWEB_LIST) or only projects in the
> given subdirectory of the project root directory without a projects
> list file).
O.K., more detailed description of $strict_export interaction is in
that other commit.
> Reusing $project instead of adding a new parameter would have been
> nicer from a UI point-of-view (including PATH_INFO support) but
> would complicate the $project validating code that is currently
> being used to ensure nothing is exported that should not be viewable.
Nb. I wonder if we should make it invalid to have both 'project' and
'project_filter' parameters...
> @@ -994,6 +995,13 @@ sub evaluate_and_validate_params {
> }
> }
>
> + our $project_filter = $input_params{'project_filter'};
> + if (defined $project_filter) {
> + if (!validate_pathname($project_filter)) {
> + die_error(404, "Invalid project_filter parameter");
> + }
> + }
> +
That accidentally makes "pf=foo/" (with trailing slash) invalid.
On the other hand being able to assume that $project_filter doesn't
end in '/' simplifies code a bit.
> @@ -5984,7 +5992,7 @@ sub git_project_list {
> - my @list = git_get_projects_list();
> + my @list = git_get_projects_list($project_filter, $strict_export);
> sub git_project_index {
> - my @projects = git_get_projects_list();
> + my @projects = git_get_projects_list($project_filter, $strict_export);
> sub git_opml {
> - my @list = git_get_projects_list();
> + my @list = git_get_projects_list($project_filter, $strict_export);
Nice!
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v5.5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Jakub Narebski @ 2012-01-30 15:40 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Junio C Hamano, git
In-Reply-To: <20120130145538.GA2162@server.brlink.eu>
On Mon, 30 Jul 2012, Bernhard R. Link wrote:
> Use of the filter option of git_get_projects_list is currently
> limited to forks. It hard codes removal of ".git" suffixes from
> the filter and assumes the project belonging to the filter directory
> was already validated to be visible in the project list.
>
> To make it more generic move the .git suffix removal to the callers
> and add an optional argument to denote visibility verification is
> still needed.
Even better for patch readability would be to split this patch further,
with the first part just moving removal of ".git" suffix from said
function to callers.
> If there is a projects list file (GITWEB_LIST) only projects from
> this list are returned anyway, so no more checks needed.
>
> If there is no projects list file and the caller requests strict
> checking (GITWEB_STRICT_EXPORT), do not jump directly to the
> given directory but instead do a normal search and filter the
> results instead.
>
> The only (hopefully non-existing) effect of GITWEB_STRICT_EXPORT
> without GITWEB_LIST is to make sure no project can be viewed without
> also be found starting from project root. git_get_projects_list without
> this patch does not enforce this but all callers only call it with
> a filter already checked this way. With this parameter a caller
> can request this check if the filter cannot be checked this way.
O.K. now I see where the "paranoid mode" might make difference: if
one of intermediate directories in $project_filter subdirectory has
search/access permission ('x' bit) but is not readable ('r' bit),
then gitweb would show nothing in $strict_export mode, but scan from
"$projects_list/$project_filter" in non-strict mode.
Perhaps there are other cases...
> @@ -2841,7 +2840,7 @@ sub git_get_projects_list {
> my $pfxlen = length("$dir");
> my $pfxdepth = ($dir =~ tr!/!!);
> # when filtering, search only given subdirectory
> - if ($filter) {
> + if ($filter and not $paranoid) {
Hmmmm... ($filter and !$paranoid) or ($filter && !$paranoid)?
Which would be more Perl-ish and fit current code style better...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: commit/from command in git-fast-import
From: Sverre Rabbelier @ 2012-01-30 15:35 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Barr, Mike Hommey, git, Dmitry Ivankov
In-Reply-To: <20120127210936.GC3124@burratino>
On Fri, Jan 27, 2012 at 15:09, Jonathan Nieder <jrnieder@gmail.com> wrote:
> The unfortunate term here is "existing branches", which seems to have
> been intended to refer to refs that have already been populated in
> this fast-import stream by a "commit" or "reset" command, rather than
> any old ref that already exists in the repository.
>
> In other words, instead of "existing branch", the manual should say
> something along the lines of "branch already in fast-import's internal
> branch table".
Looks sane.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: How often does git calculate SHAs?
From: Shawn Pearce @ 2012-01-30 14:59 UTC (permalink / raw)
To: Michael Cook; +Cc: git
In-Reply-To: <4F26A864.1080702@bbn.com>
On Mon, Jan 30, 2012 at 06:25, Michael Cook <mcook@bbn.com> wrote:
> How often does git actually calculate a file's SHA?
>
> `strace git status` shows that git stat'ed many files, but opened only a
> few. So I assume git has some heuristicsbased on the stat infofor when to
> recalculate the SHAs.
>
> Any pointers to how I could have figured this out myself from looking at the
> source code would be appreciated. Google wasn't helpful.
During `git status` Git performs an lstat() of every file in the
working tree. If the file matches stat structure data with the cache
held in .git/index, Git assumes the file is unmodified.
Things Git are looking for is usually size, mtime, inode number,
creation time, etc.
^ permalink raw reply
* How often does git calculate SHAs?
From: Michael Cook @ 2012-01-30 14:25 UTC (permalink / raw)
To: git
How often does git actually calculate a file's SHA?
`strace git status` shows that git stat'ed many files, but opened only a
few. So I assume git has some heuristicsbased on the stat infofor when
to recalculate the SHAs.
Any pointers to how I could have figured this out myself from looking at
the source code would be appreciated. Google wasn't helpful.
Michael
--
Michael Cook, Raytheon BBN Technologies, www.bbn.com
^ permalink raw reply
* [PATCH v5.5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Bernhard R. Link @ 2012-01-30 14:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <201201301442.06707.jnareb@gmail.com>
Use of the filter option of git_get_projects_list is currently
limited to forks. It hard codes removal of ".git" suffixes from
the filter and assumes the project belonging to the filter directory
was already validated to be visible in the project list.
To make it more generic move the .git suffix removal to the callers
and add an optional argument to denote visibility verification is
still needed.
If there is a projects list file (GITWEB_LIST) only projects from
this list are returned anyway, so no more checks needed.
If there is no projects list file and the caller requests strict
checking (GITWEB_STRICT_EXPORT), do not jump directly to the
given directory but instead do a normal search and filter the
results instead.
The only (hopefully non-existing) effect of GITWEB_STRICT_EXPORT
without GITWEB_LIST is to make sure no project can be viewed without
also be found starting from project root. git_get_projects_list without
this patch does not enforce this but all callers only call it with
a filter already checked this way. With this parameter a caller
can request this check if the filter cannot be checked this way.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Changes since v5:
- don't you use s/.../.../r
gitweb/gitweb.perl | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9cf7e71..19daabc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2829,10 +2829,9 @@ sub git_get_project_url_list {
sub git_get_projects_list {
my $filter = shift || '';
+ my $paranoid = shift;
my @list;
- $filter =~ s/\.git$//;
-
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
@@ -2841,7 +2840,7 @@ sub git_get_projects_list {
my $pfxlen = length("$dir");
my $pfxdepth = ($dir =~ tr!/!!);
# when filtering, search only given subdirectory
- if ($filter) {
+ if ($filter and not $paranoid) {
$dir .= "/$filter";
$dir =~ s!/+$!!;
}
@@ -2866,6 +2865,10 @@ sub git_get_projects_list {
}
my $path = substr($File::Find::name, $pfxlen + 1);
+ # paranoidly only filter here
+ if ($paranoid && $filter && $path !~ m!^\Q$filter\E/!) {
+ next;
+ }
# we check related file in $projectroot
if (check_export_ok("$projectroot/$path")) {
push @list, { path => $path };
@@ -6007,7 +6010,7 @@ sub git_forks {
die_error(400, "Unknown order parameter");
}
- my @list = git_get_projects_list($project);
+ my @list = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
if (!@list) {
die_error(404, "No forks found");
}
@@ -6066,7 +6069,7 @@ sub git_summary {
if ($check_forks) {
# find forks of a project
- @forklist = git_get_projects_list($project);
+ @forklist = git_get_projects_list((my $filter = $project) =~ s/\.git$//);
# filter out forks of forks
@forklist = filter_forks_from_projects_list(\@forklist)
if (@forklist);
--
1.7.8.3
^ permalink raw reply related
* gitk Wish hangs on Mac OS X 10.6.8
From: Matti Linnanvuori @ 2012-01-30 13:55 UTC (permalink / raw)
To: git
Hi!
gitk Wish occasionally hangs on Mac OS X 10.6.8. I have to force kill it to make it disappear. git version 1.7.5.4.
regards, Matti Linnanvuori
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Jonathan Nieder @ 2012-01-30 14:02 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Frans Klaver, Junio C Hamano, git
In-Reply-To: <CAMP44s3vXSJaXiQK4X0kNOECzfLFsTo1YeMCtVZ0NWY-CHJ++A@mail.gmail.com>
Felipe Contreras wrote:
> Either way. I'm not going to discuss in this thread any more. I'll
> resend the patches, feel free to comment there.
Good idea. Just for the record, I'm not happy with any patch until
I've seen the code. ;-)
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Felipe Contreras @ 2012-01-30 13:59 UTC (permalink / raw)
To: Frans Klaver; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAH6sp9PfVTTNL218syf-MS465M+sP4E8eVxuVCHZC0geE3ezfg@mail.gmail.com>
On Mon, Jan 30, 2012 at 2:21 PM, Frans Klaver <fransklaver@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 12:55 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>
>> We are not talking about backwards compatibility; we are talking about
>> compatibility of remotes completion of the bash completion script of
>> repositories more than 3 years old with remotes that haven't been
>> migrated.
>
> What's not backward about that?
Not all backwards compatibility issues are the same.
>> This barely resembles the git-foo -> 'git foo', which truly broke
>> backwards compatibility, and at the time I proposed many different
>> approaches to deal with these type of problems, which seem to be
>> followed now (although probably not because of my recommendations).
>>
>> But this has nothing to do with _attitude_; I am merely stating fact.
>> I have never expressed any opinion or attitude with respect to how
>> backwards compatibility should be handled in this thread, have I?
>
> As far as I know you haven't explicitly said anything about that.
> There may still be a possibility that the sentence Junio quoted in his
> reply could have implied a certain attitude.
I already asked, but I ask again; what would be that attitude? Not
caring about backwards compatibility? Then that implication would have
been wrong.
If you look a few lines below, you would see a change that doesn't
break backwards compatibility, which proves the previous implication
wrong... Not to mention previous discussions.
>>> Maybe numbers for this could be generated from the next git user
>>> survey. If numbers justify this change, maybe this or something like
>>> it could be scheduled for a major release of git.
>>
>> Maybe, but I doubt this issue hardly deserves much discussion.
>
> I wouldn't know about that. Apparently not everybody is happy with
> applying it without further discussion.
Jonathan Nieder is happy with the 'ls -1 "$d/remotes"' change, and I
haven't seen anybody object it.
Either way. I'm not going to discuss in this thread any more. I'll
resend the patches, feel free to comment there.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Felipe Contreras @ 2012-01-30 13:51 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <87pqe1nx9a.fsf@thomas.inf.ethz.ch>
On Mon, Jan 30, 2012 at 3:19 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Mon, Jan 30, 2012 at 10:22 AM, Junio C Hamano <jch2355@gmail.com> wrote:
>>> Thomas Rast <trast@inf.ethz.ch> wrote:
>>>>Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>
>>>>> No reason. I hope they read the mailing list, otherwise I'll resend
>>>>> and CC them. A get_maintainers script, or something like that would
>>>>> make things easier.
>>>>
>>>>I simply use
>>>>
>>>> git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
>>>>
>>>>(In many parts the revision limiter can be omitted without losing much,
>>>>but e.g. here this drops Shawn who hasn't worked on it since 2009.)
>>>
>>> Or "--since=1.year", which you can keep using forever without adjusting.
>>
>> Perhaps something like that can be stored in a script somewhere in
>> git's codebase so that people can set sendemail.cccmd to that.
>
> Umm, that seems rather AI-complete. You should always compile the list
> by hand.
Why? Take a look at the Linux kernel; having tons of contributors,
many still haven't learned the ropes, and looking at MAINTAIERS, plus
the output of 'git blame', for potentially dozens of patches is too
burdensome, which is why they have 'scripts/get_maintainer.pl' that
does a pretty good job of figuring out who to cc so you don't have to
think about it.
> Ok, this got rather long-winded. But I think the bottom line is, trying
> to put this in sendemail.cccmd is trying to script common sense.
It's still better than nothing.
I once wrote a much smarter script[1], but it never go into the tree.
The output I get is this:
"Shawn O. Pearce" <spearce@spearce.org>>
"Jonathan Nieder" <jrnieder@gmail.com>
"Mark Lodato" <lodatom@gmail.com>
"Junio C Hamano" <junkio@cox.net>
"Ted Pavlic" <ted@tedpavlic.com>
Note: seems like there's a bug with git blame -P:
% g blame -p -L 2730,+33 contrib/completion/git-completion.bash | grep
author-mail
And if this script is such a bad idea; why do you think sendmail.cccmd exists?
I think we should have a simple script that at least does something
sensible, at least in contrib, but I hope we could even have a
standard git-cccmd that all projects could use.
It looks like my ruby script never had much of a chance getting
anywhere, so would it be accepted in another format? perl? python?
bash?
Cheers.
[1] http://thread.gmane.org/gmane.comp.version-control.git/130391
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 1/5] gitweb: prepare git_get_projects_list for use outside 'forks'.
From: Jakub Narebski @ 2012-01-30 13:42 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Junio C Hamano, git
In-Reply-To: <20120130114447.GA9267@server.brlink.eu>
Bernhard R. Link wrote:
> @@ -6066,7 +6069,7 @@ sub git_summary {
>
> if ($check_forks) {
> # find forks of a project
> - @forklist = git_get_projects_list($project);
> + @forklist = git_get_projects_list($project =~ s/\.git$//r);
> # filter out forks of forks
> @forklist = filter_forks_from_projects_list(\@forklist)
> if (@forklist);
> --
The '/r' non-destructive modifier for regexp replacement is quite new
invention and requires Perl 5.14, while gitweb requires Perl 5.8.x
something. Please don't use it.
You can use this instead.
(my $filter = $project) =~ s/\.git$//
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] completion: --edit option for git-merge
From: Adrian Weimann @ 2012-01-30 13:37 UTC (permalink / raw)
To: git, gitster; +Cc: Adrian Weimann
Signed-off-by: Adrian Weimann <adrian.weimann@googlemail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1496c6d..be1fcea 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1622,7 +1622,7 @@ _git_log ()
__git_merge_options="
--no-commit --no-stat --log --no-log --squash --strategy
- --commit --stat --no-squash --ff --no-ff --ff-only
+ --commit --stat --no-squash --ff --no-ff --ff-only --edit
"
_git_merge ()
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 3/3] completion: remove unused code
From: Thomas Rast @ 2012-01-30 13:19 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAMP44s2ooo1uArhhtJkX3S9N=iE4MNJivMSvr3hsOkxFmJupFA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Mon, Jan 30, 2012 at 10:22 AM, Junio C Hamano <jch2355@gmail.com> wrote:
>> Thomas Rast <trast@inf.ethz.ch> wrote:
>>>Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> No reason. I hope they read the mailing list, otherwise I'll resend
>>>> and CC them. A get_maintainers script, or something like that would
>>>> make things easier.
>>>
>>>I simply use
>>>
>>> git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
>>>
>>>(In many parts the revision limiter can be omitted without losing much,
>>>but e.g. here this drops Shawn who hasn't worked on it since 2009.)
>>
>> Or "--since=1.year", which you can keep using forever without adjusting.
>
> Perhaps something like that can be stored in a script somewhere in
> git's codebase so that people can set sendemail.cccmd to that.
Umm, that seems rather AI-complete. You should always compile the list
by hand.
For example, the list in this case started
25 SZEDER Gábor
4 Michael J Gruber
3 Teemu Matilainen
3 Thomas Rast
Would you Cc Michael, Teemu and me? Probably not. What if it started
5 SZEDER Gábor
4 Michael J Gruber
3 Teemu Matilainen
3 Thomas Rast
Also, something I didn't mention so far was that you may be patching
squarely into the code of one contributor, even if he only had a single
patch in that area. To catch this, you should blame the code you are
fixing (you already checked the message of the commit to verify whether
the bug/feature was intentional, right?). On top of that, the patch may
have involved a large number of people not listed in the Author field.
As a random example,
$ git shortlog -sn --no-merges v1.7.0..origin/next -- grep.[ch] builtin/grep.[ch]
15 René Scharfe
9 Junio C Hamano
8 Nguyễn Thái Ngọc Duy
5 Michał Kiedrowicz
4 Johannes Schindelin
3 Jeff King
3 Thomas Rast
but if you were to submit a patch that disputes the case made by
53b8d931, you should probably cc René, Peff and me (see the Helped-by
lines).
Ok, this got rather long-winded. But I think the bottom line is, trying
to put this in sendemail.cccmd is trying to script common sense.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Frans Klaver @ 2012-01-30 12:21 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAMP44s3a05dZqOqpDFDnWQ_C03EODgeP1eRhko-Mc8OjGXj6FQ@mail.gmail.com>
On Mon, Jan 30, 2012 at 12:55 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> We are not talking about backwards compatibility; we are talking about
> compatibility of remotes completion of the bash completion script of
> repositories more than 3 years old with remotes that haven't been
> migrated.
What's not backward about that?
> This barely resembles the git-foo -> 'git foo', which truly broke
> backwards compatibility, and at the time I proposed many different
> approaches to deal with these type of problems, which seem to be
> followed now (although probably not because of my recommendations).
>
> But this has nothing to do with _attitude_; I am merely stating fact.
> I have never expressed any opinion or attitude with respect to how
> backwards compatibility should be handled in this thread, have I?
As far as I know you haven't explicitly said anything about that.
There may still be a possibility that the sentence Junio quoted in his
reply could have implied a certain attitude.
>> Maybe numbers for this could be generated from the next git user
>> survey. If numbers justify this change, maybe this or something like
>> it could be scheduled for a major release of git.
>
> Maybe, but I doubt this issue hardly deserves much discussion.
I wouldn't know about that. Apparently not everybody is happy with
applying it without further discussion.
Cheers,
Frans
^ permalink raw reply
* Re: Autocompletion - commands no longer work as stand alone
From: Nathan Bullock @ 2012-01-30 12:00 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, git
In-Reply-To: <20120124232658.GD2256@goldbirke>
2012/1/24 SZEDER Gábor <szeder@ira.uka.de>:
> Hi,
>
>
>> Nathan Bullock <nathanbullock@gmail.com> writes:
>>
>> > I have for a number of years had the following in my .bashrc
>> >
>> > alias br="git branch"
>> > complete -F _git_branch br
>> >
>> > As well as similar commands for co and log.
>> >
>> > Recently though this broke, now when I type something like "br
>> > mas<command completion>" it will occasionally complain with messages
>> > like:
>> > bash: [: 1: unary operator expected
>> >
>> > From digging through the source it looks like this was broken back in
>> > April. (The commit is show at the bottom of this email.)
>> >
>> > So my questions are:
>> > 1. Is it reasonable for things like _git_branch to work as a
>> > standalone autocompletion function instead of having to go through
>> > _git? I certainly like it to work as a standalone function. I also use
>> > it to add autocompletion to other bash scripts that I use frequently.
>> >
>> > 2. If I add code that verifies that the variable cword exists at the
>> > start of these functions and only if not call something like
>> > _get_comp_words_by_ref -n =: cur words cword prev. Would that be
>> > reasonable?
>
> That would be too fragile, it will break if $cword is set in the
> environment from which you invoke _git_<cmd>() completion functions
> directly (i.e. not though _git()).
>
>> > I think this should address the performance concerns that
>> > caused these to be removed in the first place, but it may make the
>> > code uglier.
>
> Actually it was not a performance problem, but a cleanup in a patch
> series to fix a zsh-related bug. Without this cleanup the bugfix
> would have been much more intrusive.
>
> http://thread.gmane.org/gmane.comp.version-control.git/172142/focus=172369
>
>
>> > I have already added wrapper functions in my bashrc so that this is no
>> > longer a problem for me, but there may be other people who start
>> > hitting this as well once they start using newer versions of git.
>
> This issue was reported earlier, so it seems there are people who
> would like to use it. But getting $cur, $cword, etc. variables right
> in _git_<cmd>() completion functions is just part of the problem,
> there are other issues, as mentioned in the previous thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232
>
> Unfortunately, I couldn't come up with a solution yet that doesn't
> introduce too much code churn and doesn't cause yet another
> inconsistency between bash and zsh. I also haven't looked whether
> there are other issues similar to that with _git_fetch() mentioned on
> the above link.
At the end of this thread that you refer to,
http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232,
there is a set of wrapper functions that look reasonably good for
solving this problem. There was a question if those could be included
in the main git code base. Do you know if that is likely to happen?
Nathan
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Felipe Contreras @ 2012-01-30 11:55 UTC (permalink / raw)
To: Frans Klaver; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <CAH6sp9Of2rT4ESMYj9kC2NPtapsN58X3A0FpHTTZO-kSqpb-2Q@mail.gmail.com>
On Mon, Jan 30, 2012 at 1:19 PM, Frans Klaver <fransklaver@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 11:51 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Mon, Jan 30, 2012 at 6:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> OK, maybe some people use it, but most likely they are using an old
>>>> version of git, and thus an old version of the completion script.
>>>
>>> Please adjust your attitude about backward compatibility to match the
>>> standard used for other parts of Git.
>>
>> What attitude?
>
> This attitude:
>
>> I am simply stating a fact. How much percentage of
>> people do you think still have .git/remotes around? How many people do
>> you think have clones more than 3 years old? And how many of these
>> people would complain if remotes were not properly completed for these
>> repos?
>>
>> I doubt anybody would have complained, but I guess we would never
>> know, because I already proposed a solution that would work for them
>> and only uses a *single* line of code, unlike the current 40 ones.
>>
>> I don't see what is the problem with the attitude of sending a patch
>> to remove code that most likely nobody cares about (neither you or I
>> have numbers on this), and then finding an alternative when people do
>> care about it.
>
> I don't think Junio actually meant an "attitude", but just your angle
> of approach (== attitude) on backwards compatibility.
We are not talking about backwards compatibility; we are talking about
compatibility of remotes completion of the bash completion script of
repositories more than 3 years old with remotes that haven't been
migrated.
This barely resembles the git-foo -> 'git foo', which truly broke
backwards compatibility, and at the time I proposed many different
approaches to deal with these type of problems, which seem to be
followed now (although probably not because of my recommendations).
But this has nothing to do with _attitude_; I am merely stating fact.
I have never expressed any opinion or attitude with respect to how
backwards compatibility should be handled in this thread, have I?
> Maybe numbers for this could be generated from the next git user
> survey. If numbers justify this change, maybe this or something like
> it could be scheduled for a major release of git.
Maybe, but I doubt this issue hardly deserves much discussion.
Nobody is proposing to break backwards compatibility--as you can see,
I already proposed a simple solution that should work.
And FTR, when I wrote 'We don't need to check for GIT_DIR/remotes,
right? This was removed long time ago." I clearly wasn't sure if
.git/remotes was still used or not, after Jonathan Nieder replied, I
checked the source code of remotes.c, and I found that it was still
supported, so I wrote the proposed alternative.
--
Felipe Contreras
^ permalink raw reply
* [PATCH v5 5/5] gitweb: place links to parent directories in page header
From: Bernhard R. Link @ 2012-01-30 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
Change html page headers to not only link the project root and the
currently selected project but also the directories in between using
project_filter. (Allowing to jump to a list of all projects within
that intermediate directory directly and making the project_filter
feature visible to users).
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index dfc79df..b54ddb9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3853,7 +3853,10 @@ sub print_nav_breadcrumbs {
print $cgi->a({-href => esc_url($home_link)}, $home_link_str) . " / ";
if (defined $project) {
- print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
+ my @dirname = split '/', $project;
+ my $projectbasename = pop @dirname;
+ print_nav_breadcrumbs_path(@dirname);
+ print $cgi->a({-href => href(action=>"summary")}, esc_html($projectbasename));
if (defined $action) {
my $action_print = $action ;
if (defined $opts{-action_extra}) {
--
1.7.8.3
^ permalink raw reply related
* [PATCH v5 4/5] gitweb: show active project_filter in project_list page header
From: Bernhard R. Link @ 2012-01-30 11:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <20120130095252.GA6183@server.brlink.eu>
In a project_list view show breadcrumbs with the currently active
project_filter (and those of parent directories) in the page header.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
gitweb/gitweb.perl | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e022e11..dfc79df 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3836,6 +3836,18 @@ sub print_header_links {
}
}
+sub print_nav_breadcrumbs_path {
+ my $dirprefix = undef;
+ while (my $part = shift) {
+ $dirprefix .= "/" if defined $dirprefix;
+ $dirprefix .= $part;
+ print $cgi->a({-href => href(project => undef,
+ project_filter => $dirprefix,
+ action=>"project_list")},
+ esc_html($part)) . " / ";
+ }
+}
+
sub print_nav_breadcrumbs {
my %opts = @_;
@@ -3854,6 +3866,8 @@ sub print_nav_breadcrumbs {
print " / $opts{-action_extra}";
}
print "\n";
+ } elsif (defined $project_filter) {
+ print_nav_breadcrumbs_path(split '/', $project_filter);
}
}
--
1.7.8.3
^ 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