* Re: What's cooking in git.git (Oct 2008, #04; Sat, 18)
From: Jeff King @ 2008-10-19 12:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqrpabep.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 18, 2008 at 01:36:14PM -0700, Junio C Hamano wrote:
> ----------------------------------------------------------------
> [Actively Cooking]
[...]
> * jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
> + diff: add filter for converting binary to text
> + diff: introduce diff.<driver>.binary
> + diff: unify external diff and funcname parsing code
> + t4012: use test_cmp instead of cmp
>
> A general cleanup on how diff drivers are implemented. Its still
> missing documentation updates and tests but doesn't break anything
> current as far as I can tell.
Hmm, I was planning on re-rolling this before it hit next to deal with
the issues brought up about the binary option, but I guess it is too
late now (yes, I was being slow about it...). I think I can salvage it
with some patches on top, though.
-Peff
^ permalink raw reply
* Re: [PATCH] feature request: git-mergetool --force
From: Jeff King @ 2008-10-19 11:47 UTC (permalink / raw)
To: Charles Bailey; +Cc: William Pursell, git
In-Reply-To: <48FA6E55.9030101@hashpling.org>
On Sun, Oct 19, 2008 at 12:16:37AM +0100, Charles Bailey wrote:
> I've recently been using git mergetool quite a bit and I'm currently
> cooking a couple of patches. The first, by coincidence, was a "-n"
> option which disabled the hit-return-to-actually-do-anything prompt. I,
> also, used the variable "NOPROMPT" to describe this behaviour.
>
> The other change that I am working was more of an issue for me. When I
> have a fair number of files to merge I sometimes want to skip a merge.
> Perhaps it's a tricky one and I want do the easy wins first.
> [...]
> Thoughts?
I think those are both reasonable behaviors. I also thought instantly of
the issue you mentioned, that people who really did want to abort would
get stuck in a loop of spawning the merge resolver. For that reason, I
think it makes sense to have both of them as options (either config,
command-line, or both). And if you do "git mergetool --no-prompt
--keep-going", then you are accepting the fact that you won't have a
chance to ask it to stop.
And I would suggest "-k, --keep-going" for the second option, as it
reminds me of the similar "make" option.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Anders Melchiorsen @ 2008-10-19 10:29 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20081019100454.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I see that you pushed out this change already, and you changed your
> mind and described them all. I think the result reads better.
While we are fixing up that paragraph, this part could also use some
elaboration:
Unknown (`X`), or have had their pairing Broken (`B`).
I would do it, but I have no idea what these two mean.
Regards,
Anders
^ permalink raw reply
* need help stripping a repo to one file
From: Caleb Cushing @ 2008-10-19 10:27 UTC (permalink / raw)
To: git
here's what I've done so far (note: this is a public repo if anyone
wants to take a look)
git clone git@github.com:xenoterracide/dot_usr.git sql_iabbr
cd sql_iabbr/
git checkout db3c5ffb180f10dde8e539a81a6644760e098dcd
git branch -D master
git checkout -b master
git filter-branch --subdirectory-filter vim/ftplugin/ -- --all
that leaves me with this
html sgml sh tex vim xhtml xml sql_iabbr.vim xml.vim
all I want left is sql_iabbr.vim and it's history
I've used stuff like
git filter-branch --tree-filter 'rm -rf xml.vim' HEAD
to remove the files... but I notice that leaves the logs.
I'm thinking I could do that and then remove those commits but I
haven't figured out how to remove the commits, and even then I'm not
sure the repo would be in the state I want.
can anyone help me get to where I want to be? also is there an easier
way to do what I've done so far?
--
Caleb Cushing
^ permalink raw reply
* Re: [PATCHv6 3/5] gitweb: use_pathinfo filenames start with /
From: Jakub Narebski @ 2008-10-19 8:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0810181657i67d6b9f8o66db9f57bcf01dd3@mail.gmail.com>
On Sun, 19 Oct 2008, Giuseppe Bilotta wrote:
> On Sun, Oct 19, 2008 at 1:26 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
>>
>>> When using path info, make filenames start with a / (right after the :
>>> that separates them from the hash base). This minimal change allows
>>> relative navigation to work properly when viewing HTML files in raw
>>> ('blob_plain') mode.
[...]
>> For example for http://repo.or.cz/w/git.git/html:/git.html links leads
>> to correct HTML pages, while for http://repo.or.cz/w/git.git/html:git.html
>> they lead to empty gitweb page (no errors, so link checker would be
>> fooled).
>
> An idea that could be taken into consideration, if the ability to
> navigate web documents is deemed of primary importance, would be a
> redirect from the no-slash URL (a hand-coded one, given that with this
> patch we only generate slashed URLs) to the slashed URL. Not sure it's
> worth the effort (and reparsing) though: it would obviously be MUCH
> nicer if we could change the URL without having to actually reload the
> document ...
I think that changing URL without reloading is impossible because of
security reasons. For example if you change document.location in
JavaScript changing the URL (you can add links to non-existing anchors
without reloading) then web browser reloads the page from new URL.
What you can do is early redirect using 301 Moved Permanently (or
similar) and Location: redirect, using $cgi->redirect() like in
git_object().
Also not sure if it is worth the effort...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: StGIT 0.14.3: extra space is added before e-mail on export after "stg edit"
From: Andrey Borzenkov @ 2008-10-19 8:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0810180148k4ba5bb2bgf3c5cdb2358b9419@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Saturday 18 October 2008, Catalin Marinas wrote:
> 2008/10/15 Andrey Borzenkov <arvidjaar@mail.ru>:
> > Funny problem. I have following export template:
> >
> > Subject: [PATCH] %(shortdescr)s
> > From: %(authname)s %(authemail)s
> >
> > %(longdescr)s
> > Signed-off-by: %(authname)s %(authemail)s
>
> The default templates contain "%(authname)s <%(authemail)s>", i.e.
> with the angle brackets arount authemail and I've never seen this
> problem. Does it work if you change them (or use the default
> templates)?
>
Well, my GIT_AUTHOR_EMAIL was with angle brackets. I do not remember, why
(apparently I had some issues in the past). I stripped brackets and changed
template, now it seems to work. I was never sure what exactly e-mail should
like like.
Thank you!
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH/RFR&A] gitweb: Better processing format string in custom links in navbar
From: Junio C Hamano @ 2008-10-19 7:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
I was not around when this was posted and discussed; Shawn's note says
this is waiting for "some sort of response from Pasky", hence this request
for review and ack. It still is parked in 'pu'.
-- >8 --
Make processing format string in custom links in action bar ('actions'
feature) more robust. Now there would be no problems if one of
expanded values (for example project name, of project filename)
contains '%'; additionally format string supports '%' escaping by
doubling, i.e. '%%' expands to '%'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
gitweb/gitweb.perl | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1116800..cc6edbe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -290,10 +290,10 @@ our %feature = (
# The 'default' value consists of a list of triplets in the form
# (label, link, position) where position is the label after which
- # to inster the link and link is a format string where %n expands
+ # to insert the link and link is a format string where %n expands
# to the project name, %f to the project path within the filesystem,
# %h to the current hash (h gitweb parameter) and %b to the current
- # hash base (hb gitweb parameter).
+ # hash base (hb gitweb parameter); %% expands to %.
# To enable system wide have in $GITWEB_CONFIG e.g.
# $feature{'actions'}{'default'} = [('graphiclog',
@@ -2866,14 +2866,19 @@ sub git_print_page_nav {
$arg{'tree'}{'hash_base'} = $treebase if defined $treebase;
my @actions = gitweb_check_feature('actions');
+ my %repl = (
+ '%' => '%',
+ 'n' => $project, # project name
+ 'f' => $git_dir, # project path within filesystem
+ 'h' => $treehead || '', # current hash ('h' parameter)
+ 'b' => $treebase || '', # hash base ('hb' parameter)
+ );
while (@actions) {
- my ($label, $link, $pos) = (shift(@actions), shift(@actions), shift(@actions));
+ my ($label, $link, $pos) = splice(@actions,0,3);
+ # insert
@navs = map { $_ eq $pos ? ($_, $label) : $_ } @navs;
# munch munch
- $link =~ s#%n#$project#g;
- $link =~ s#%f#$git_dir#g;
- $treehead ? $link =~ s#%h#$treehead#g : $link =~ s#%h##g;
- $treebase ? $link =~ s#%b#$treebase#g : $link =~ s#%b##g;
+ $link =~ s/%([%nfhb])/$repl{$1}/g;
$arg{$label}{'_href'} = $link;
}
--
1.6.0.2.767.g8f0e
^ permalink raw reply related
* [PATCH/RFR&A] Fix reading of cloud tags
From: Junio C Hamano @ 2008-10-19 7:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This is in 'next' but it would be nice to get acked before advancing it to
master.
-- >8 --
The projectroot path could have SP in it, in which case iterating over
<$git_dir/ctags/*> does not correctly enumerate the cloud tags files at
all.
This can be observed by creating an empty t/trash directory and running
t9500 test. The $projectroot ends with "trash directory.t9500-gitweb-/"
and <$glob> would give "trash", which can be opened and reading from it
immediately yields undef, which in turn gives an undef value warning to
the standard error stream upon attempt to chomp it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gitweb/gitweb.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1116800..41b6866 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1805,7 +1805,10 @@ sub git_get_project_ctags {
my $ctags = {};
$git_dir = "$projectroot/$path";
- foreach (<$git_dir/ctags/*>) {
+ unless (opendir D, "$git_dir/ctags") {
+ return $ctags;
+ }
+ foreach (grep { -f $_ } map { "$git_dir/ctags/$_" } readdir(D)) {
open CT, $_ or next;
my $val = <CT>;
chomp $val;
@@ -1813,6 +1816,7 @@ sub git_get_project_ctags {
my $ctag = $_; $ctag =~ s#.*/##;
$ctags->{$ctag} = $val;
}
+ closedir D;
$ctags;
}
--
1.6.0.2.767.g8f0e
^ permalink raw reply related
* [PATCH/RFR&A] Do not rename read-only files during a push
From: Junio C Hamano @ 2008-10-19 7:07 UTC (permalink / raw)
To: Petr Baudis, Johannes Sixt, Shawn O. Pearce; +Cc: git
This is on the "merged to 'master' soon" list, but has a small amend by me
(namely, chmod of final pack is done only when we are writing the final
pack, i.e. reading from stdin) to fix breakages observed in tests. It
would be nice to get a final Ack before moving it to 'master'.
-- >8 --
From: Petr Baudis <pasky@suse.cz>
Win32 does not allow renaming read-only files (at least on a Samba
share), making push into a local directory to fail. Thus, defer
the chmod() call in index-pack.c:final() only after
move_temp_to_file() was called.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
index-pack.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index d3a4d31..aec11cb 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -790,7 +790,6 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
err = close(output_fd);
if (err)
die("error while closing pack file: %s", strerror(errno));
- chmod(curr_pack_name, 0444);
}
if (keep_msg) {
@@ -824,8 +823,9 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
if (move_temp_to_file(curr_pack_name, final_pack_name))
die("cannot store pack file");
}
+ if (from_stdin)
+ chmod(final_pack_name, 0444);
- chmod(curr_index_name, 0444);
if (final_index_name != curr_index_name) {
if (!final_index_name) {
snprintf(name, sizeof(name), "%s/pack/pack-%s.idx",
@@ -835,6 +835,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
if (move_temp_to_file(curr_index_name, final_index_name))
die("cannot store index file");
}
+ chmod(final_index_name, 0444);
if (!from_stdin) {
printf("%s\n", sha1_to_hex(sha1));
--
1.6.0.2.767.g8f0e
^ permalink raw reply related
* Re: What is the pre-merge hook status?
From: Alexander Gladysh @ 2008-10-19 6:51 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git
In-Reply-To: <48FA5BBB.8060406@gnu.org>
On Sun, Oct 19, 2008 at 1:57 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
> > What is the status of your pre-merge hook patch?
> >
> > http://article.gmane.org/gmane.comp.version-control.git/93888
> >
> > I think it can help me greatly with my repository management process.
>
> I decided that it was a bad design for me at least, because the control
> had better be implemented on the server (using an update hook). But I
> can submit it if you need it for something.
Please do. I've found that things in newbie user repo may become way
too entangled before branch gets to server. My users need an
early-warning system.
Thanks,
Alexander.
^ permalink raw reply
* Re: git-svn crashing perl
From: Heinrich Nirschl @ 2008-10-19 6:39 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <b2cdc9f30810181500u357ce6e2tb8bef4fd559e89d3@mail.gmail.com>
On Sun, Oct 19, 2008 at 12:00 AM, Alex Bennee <kernel-hacker@bennee.com> wrote:
> Looks similar. libapr certainly seems to be breaking something:
>
>
> Core was generated by `/usr/bin/perl
> /home/alex/src/git.git/install/libexec/git-core/git-svn fetch --f'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007fd0d813c370 in ?? ()
> (gdb) bt
> #0 0x00007fd0d813c370 in ?? ()
> #1 0x00007fd0d9a52a5d in ?? () from /usr/lib/libapr-1.so.0
> #2 0x00007fd0d9a53d9a in ?? () from /usr/lib/libapr-1.so.0
> #3 0x00007fd0d9a54003 in ?? () from /usr/lib/libapr-1.so.0
> #4 0x00007fd0d9a53d88 in ?? () from /usr/lib/libapr-1.so.0
> #5 0x00007fd0d9a54003 in ?? () from /usr/lib/libapr-1.so.0
> #6 0x00007fd0d9a540f3 in apr_pool_terminate () from /usr/lib/libapr-1.so.0
> #7 0x00007fd0db1c6e83 in _wrap_apr_terminate () from
> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux/auto/SVN/_Core/_Core.so
> #8 0x000000000047dbab in Perl_pp_entersub ()
> #9 0x00000000004677fa in Perl_runops_debug ()
> #10 0x0000000000425ae8 in Perl_call_sv ()
> #11 0x0000000000425faa in Perl_call_list ()
> #12 0x000000000042a0e8 in perl_destruct ()
> #13 0x0000000000422238 in main ()
I found another bug report that seems to be related
http://bugs.gentoo.org/show_bug.cgi?id=223747
There is a workaround mentioned: disable runtime-module-search when
building subversion.
^ permalink raw reply
* Re: [PATCH] git-format-patch(1)- add note about creating patch for single commit
From: Junio C Hamano @ 2008-10-19 5:33 UTC (permalink / raw)
To: Dan McGee; +Cc: Junio C Hamano, git
In-Reply-To: <449c10960810182226t5e2ae1ay4b53656a7cac4606@mail.gmail.com>
"Dan McGee" <dpmcgee@gmail.com> writes:
> On Sun, Oct 19, 2008 at 12:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Heh, a more natural way to say that is:
>>
>> git format-patch -1 $that_one
>>
>> That uses the first option described in the documentation:
>>
>> -<n>::
>> Limits the number of patches to prepare.
>
> Wow, had no idea about that option. :)
>
> Given that I didn't even notice this option when I did go to the
> manpage, what if my above change was instead reworked a bit:
>>> +latter case. If you want to format only a single commit, say "git
>>> +format-patch -1 <commit>" .
I thought about it, but saw "formatting three commits" example in the
manpage, and stopped there ;-)
^ permalink raw reply
* Re: [PATCH] git-format-patch(1)- add note about creating patch for single commit
From: Dan McGee @ 2008-10-19 5:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vyd9n3d.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 19, 2008 at 12:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Dan McGee <dpmcgee@gmail.com> writes:
>
>> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
>> ---
>>
>> I thought this would be helpful because it took me the beter part of an hour
>> to find a solution instead of specifying C~1..C or other crazy things. The
>> current documentation just leaves you hanging when what you really want is
>> just one formatted patch.
>>
>> If there any suggestions on better wording, feel free to resubmit or whatever-
>> I just felt like this should be documented somewhere.
>>
>> Documentation/git-format-patch.txt | 4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
>> index adb4ea7..8518c33 100644
>> --- a/Documentation/git-format-patch.txt
>> +++ b/Documentation/git-format-patch.txt
>> @@ -46,7 +46,9 @@ applies to that command line and you do not get "everything
>> since the beginning of the time". If you want to format
>> everything since project inception to one commit, say "git
>> format-patch \--root <commit>" to make it clear that it is the
>> -latter case.
>> +latter case. If you want to format only a single commit, say "git
>> +format-patch <commit>^!" (which excludes all parent revisions of the
>> +specified commit).
>>
>> By default, each output file is numbered sequentially from 1, and uses the
>> first line of the commit message (massaged for pathname safety) as
>
> Heh, a more natural way to say that is:
>
> git format-patch -1 $that_one
>
> That uses the first option described in the documentation:
>
> -<n>::
> Limits the number of patches to prepare.
Wow, had no idea about that option. :)
Given that I didn't even notice this option when I did go to the
manpage, what if my above change was instead reworked a bit:
>> +latter case. If you want to format only a single commit, say "git
>> +format-patch -1 <commit>" .
^ permalink raw reply
* Re: [PATCH] git-format-patch(1)- add note about creating patch for single commit
From: Junio C Hamano @ 2008-10-19 5:21 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <1224392084-12956-1-git-send-email-dpmcgee@gmail.com>
Dan McGee <dpmcgee@gmail.com> writes:
> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
> ---
>
> I thought this would be helpful because it took me the beter part of an hour
> to find a solution instead of specifying C~1..C or other crazy things. The
> current documentation just leaves you hanging when what you really want is
> just one formatted patch.
>
> If there any suggestions on better wording, feel free to resubmit or whatever-
> I just felt like this should be documented somewhere.
>
> Documentation/git-format-patch.txt | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
> index adb4ea7..8518c33 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -46,7 +46,9 @@ applies to that command line and you do not get "everything
> since the beginning of the time". If you want to format
> everything since project inception to one commit, say "git
> format-patch \--root <commit>" to make it clear that it is the
> -latter case.
> +latter case. If you want to format only a single commit, say "git
> +format-patch <commit>^!" (which excludes all parent revisions of the
> +specified commit).
>
> By default, each output file is numbered sequentially from 1, and uses the
> first line of the commit message (massaged for pathname safety) as
Heh, a more natural way to say that is:
git format-patch -1 $that_one
That uses the first option described in the documentation:
-<n>::
Limits the number of patches to prepare.
^ permalink raw reply
* [PATCH] git-format-patch(1)- add note about creating patch for single commit
From: Dan McGee @ 2008-10-19 4:54 UTC (permalink / raw)
To: git; +Cc: Dan McGee
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
I thought this would be helpful because it took me the beter part of an hour
to find a solution instead of specifying C~1..C or other crazy things. The
current documentation just leaves you hanging when what you really want is
just one formatted patch.
If there any suggestions on better wording, feel free to resubmit or whatever-
I just felt like this should be documented somewhere.
Documentation/git-format-patch.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index adb4ea7..8518c33 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -46,7 +46,9 @@ applies to that command line and you do not get "everything
since the beginning of the time". If you want to format
everything since project inception to one commit, say "git
format-patch \--root <commit>" to make it clear that it is the
-latter case.
+latter case. If you want to format only a single commit, say "git
+format-patch <commit>^!" (which excludes all parent revisions of the
+specified commit).
By default, each output file is numbered sequentially from 1, and uses the
first line of the commit message (massaged for pathname safety) as
--
1.6.0.2
^ permalink raw reply related
* [PATCH] Documentation: Clarify '--signoff' for git-commit
From: Abhijit Bhopatkar @ 2008-10-19 4:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxmuec46.fsf@gitster.siamese.dyndns.org>
'--signoff' uses commiter name always to add the signoff line,
make it explicit in the documentation.
Signed-off-by: Abhijit Bhopatkar <bain@devslashzero.com>
---
Documentation/git-commit.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index eb05b0f..713ab0a 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -94,7 +94,8 @@ OPTIONS
-s::
--signoff::
- Add Signed-off-by line at the end of the commit message.
+ Add Signed-off-by line by the commiter at the end of the commit
+ log message.
-n::
--no-verify::
--
1.5.6.3
^ permalink raw reply related
* [PATCH] config.txt: alphabetize configuration variable groups
From: Matt McCutchen @ 2008-10-19 1:42 UTC (permalink / raw)
To: git
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
Documentation/config.txt | 96 +++++++++++++++++++++++-----------------------
1 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da18a54..704d1bb 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -570,9 +570,6 @@ color.status.<slot>::
to red). The values of these variables may be specified as in
color.branch.<slot>.
-commit.template::
- Specify a file to use as the template for new commit messages.
-
color.ui::
When set to `always`, always use colors in all git commands which
are capable of colored output. When false (or `never`), never. When
@@ -580,6 +577,9 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
+commit.template::
+ Specify a file to use as the template for new commit messages.
+
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
files, do not consider stat-only change as changed.
@@ -711,18 +711,6 @@ gc.rerereunresolved::
kept for this many days when 'git-rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
-rerere.autoupdate::
- When set to true, `git-rerere` updates the index with the
- resulting contents after it cleanly resolves conflicts using
- previously recorded resolution. Defaults to false.
-
-rerere.enabled::
- Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they
- be encountered again. linkgit:git-rerere[1] command is by
- default enabled if you create `rr-cache` directory under
- `$GIT_DIR`, but can be disabled by setting this option to false.
-
gitcvs.enabled::
Whether the CVS server interface is enabled for this repository.
See linkgit:git-cvsserver[1].
@@ -890,6 +878,10 @@ i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
running 'git-log' and friends.
+imap::
+ The configuration variables in the 'imap' section are described
+ in linkgit:git-imap-send[1].
+
instaweb.browser::
Specify the program that will be used to browse your working
repository in gitweb. See linkgit:git-instaweb[1].
@@ -925,8 +917,6 @@ man.viewer::
Specify the programs that may be used to display help in the
'man' format. See linkgit:git-help[1].
-include::merge-config.txt[]
-
man.<tool>.cmd::
Specify the command to invoke the specified man viewer. The
specified command is evaluated in shell with the man page
@@ -936,6 +926,8 @@ man.<tool>.path::
Override the path for the given tool that may be used to
display help in the 'man' format. See linkgit:git-help[1].
+include::merge-config.txt[]
+
merge.conflictstyle::
Specify the style in which conflicted hunks are written out to
working tree files upon merge. The default is "merge", which
@@ -1052,6 +1044,28 @@ pull.octopus::
pull.twohead::
The default merge strategy to use when pulling a single branch.
+receive.fsckObjects::
+ If it is set to true, git-receive-pack will check all received
+ objects. It will abort in the case of a malformed object or a
+ broken link. The result of an abort are only dangling objects.
+ Defaults to false.
+
+receive.unpackLimit::
+ If the number of objects received in a push is below this
+ limit then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` is used instead.
+
+receive.denyNonFastForwards::
+ If set to true, git-receive-pack will deny a ref update which is
+ not a fast forward. Use this to prevent such an update via a push,
+ even if that push is forced. This configuration variable is
+ set when initializing a shared repository.
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
@@ -1101,6 +1115,18 @@ repack.usedeltabaseoffset::
"false" and repack. Access from old git versions over the
native protocol are unaffected by this option.
+rerere.autoupdate::
+ When set to true, `git-rerere` updates the index with the
+ resulting contents after it cleanly resolves conflicts using
+ previously recorded resolution. Defaults to false.
+
+rerere.enabled::
+ Activate recording of resolved conflicts, so that identical
+ conflict hunks can be resolved automatically, should they
+ be encountered again. linkgit:git-rerere[1] command is by
+ default enabled if you create `rr-cache` directory under
+ `$GIT_DIR`, but can be disabled by setting this option to false.
+
showbranch.default::
The default set of branches for linkgit:git-show-branch[1].
See linkgit:git-show-branch[1].
@@ -1137,6 +1163,11 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) and
linkgit:git-archive[1].
+transfer.unpackLimit::
+ When `fetch.unpackLimit` or `receive.unpackLimit` are
+ not set, the value of this variable is used instead.
+ The default value is 100.
+
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
@@ -1165,37 +1196,6 @@ user.signingkey::
unchanged to gpg's --local-user parameter, so you may specify a key
using any method that gpg supports.
-imap::
- The configuration variables in the 'imap' section are described
- in linkgit:git-imap-send[1].
-
-receive.fsckObjects::
- If it is set to true, git-receive-pack will check all received
- objects. It will abort in the case of a malformed object or a
- broken link. The result of an abort are only dangling objects.
- Defaults to false.
-
-receive.unpackLimit::
- If the number of objects received in a push is below this
- limit then the objects will be unpacked into loose object
- files. However if the number of received objects equals or
- exceeds this limit then the received pack will be stored as
- a pack, after adding any missing delta bases. Storing the
- pack from a push can make the push operation complete faster,
- especially on slow filesystems. If not set, the value of
- `transfer.unpackLimit` is used instead.
-
-receive.denyNonFastForwards::
- If set to true, git-receive-pack will deny a ref update which is
- not a fast forward. Use this to prevent such an update via a push,
- even if that push is forced. This configuration variable is
- set when initializing a shared repository.
-
-transfer.unpackLimit::
- When `fetch.unpackLimit` or `receive.unpackLimit` are
- not set, the value of this variable is used instead.
- The default value is 100.
-
web.browser::
Specify a web browser that may be used by some commands.
Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
--
1.6.0.2.545.g6cb4a
^ permalink raw reply related
* Re: [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Nanako Shiraishi @ 2008-10-19 1:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anders Melchiorsen, git
In-Reply-To: <87vdvq5lu4.fsf_-_@cup.kalibalik.dk>
Quoting Junio C Hamano <gitster@pobox.com>:
>
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Quoting Anders Melchiorsen <mail@cup.kalibalik.dk>:
>>
>>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>>> index 7788d4f..7604a13 100644
>>> --- a/Documentation/diff-options.txt
>>> +++ b/Documentation/diff-options.txt
>>> @@ -137,7 +137,7 @@ endif::git-format-patch[]
>>> --diff-filter=[ACDMRTUXB*]::
>>> Select only files that are Added (`A`), Copied (`C`),
>>> Deleted (`D`), Modified (`M`), Renamed (`R`), have their
>>> - type (mode) changed (`T`), are Unmerged (`U`), are
>>> + type (symlink/regular file) changed (`T`), are Unmerged (`U`), are
>>> Unknown (`X`), or have had their pairing Broken (`B`).
>>> Any combination of the filter characters may be used.
>>> When `*` (All-or-none) is added to the combination, all
>>> --
>>> 1.6.0.2.514.g23abd3
>>
>> Are symlinks and regular files the only kind of object you can see in
>> diff? What happens when a file or directory changes to a submodule?
>
> Oops. I've already applied Anders's patch, but you are right. A change
> from a blob to submodule also shows up as a typechange event.
>
> Perhaps we should just remove the parenthesised comment from there
> instead. I'll rewind and rebuild, as I haven't pushed the results out
> yet (lucky me).
I see that you pushed out this change already, and you changed your mind and described them all. I think the result reads better.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* "git checkout: --track and --no-track require -b" check accidentally resurrected?
From: Matt McCutchen @ 2008-10-19 0:54 UTC (permalink / raw)
To: git
Merge commit 9ba929ed resurrected the following two-line check, which
was removed in the first parent and unchanged in the second:
if (!opts.new_branch && (opts.track != git_branch_track))
die("git checkout: --track and --no-track require -b");
Is this intentional? Does it make a difference?
(I noticed this while carefully examining 9ba929ed to find out why "git
merge" stopped honoring merge.conflictstyle. Ironically, I hit this bug
again during the examination.)
Matt
^ permalink raw reply
* [PATCH] git-merge-recursive: honor merge.conflictstyle once again
From: Matt McCutchen @ 2008-10-19 0:40 UTC (permalink / raw)
To: git
This was originally implemented in c236bcd06138bcbc929b86ad1a513635bf4847b2
but was lost to a mismerge in 9ba929ed652f5ed7707f1c684999af4ad02c4925.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
merge-recursive.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 245232a..7472d3e 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1332,7 +1332,7 @@ static int merge_recursive_config(const char *var, const char *value, void *cb)
o->merge_rename_limit = git_config_int(var, value);
return 0;
}
- return git_default_config(var, value, cb);
+ return git_xmerge_config(var, value, cb);
}
void init_merge_options(struct merge_options *o)
--
1.6.0.2.545.g6cb4a
^ permalink raw reply related
* [PATCH] -C/--chdir command line option
From: Maciej Pasternacki @ 2008-10-19 0:02 UTC (permalink / raw)
To: git
In my project cl-librarian, which is a layer built upon different
version control systems, I need to run git pull, but start it from
outside of work tree; however, pull needs to be in work tree (as in
getcwd()) in order to update said work tree. --git-dir and
--work-tree options don't work; I discussed it on #git yesterday,
and it turned out that this issue is nontrivial:
231701 <doener> hm, require_work_tree checks if you are _in_ the work tree,
and pull only switches to the work tree after the require_work_tree
call...
231710 <doener> looks like a chicken-egg-problem
231715 <shd> japhy`: spawning commands requires forking anyway, so do chdir in
forked process
231739 <doener> if you move the "cd_to_toplevel" call up in git-push, so that
it happens before require_work_tree, then it works
231747 <japhy`> shd: yup, that would be a workaround, but I tried to avoid
shell-quoting ;)
231749 <japhy`> doener: push?
231756 <doener> ehrm, pull
channel #git
231820 <doener> but I guess doing the cd_to_toplevel first might break somehow
if there is no working tree...
231843 <japhy`> Oh.
231922 <doener> I'd just ask on the list about that.
I don't like the idea of doing chdir() myself -- this would expose me to a
whole world of portability issues, and I don't feel like spending time to
figure out how to do a fork on windows ;) the best workaround that occured to
me was adding -C/--chdir option to main git binary, like one that Make accepts.
This fixed my problem, I paste the resulting patch below:
>From 4461cd1be99772c93a83bcdfe6e6a86e71abaa35 Mon Sep 17 00:00:00 2001
From: Maciej Pasternacki <maciej@pasternacki.net>
Date: Sun, 19 Oct 2008 01:33:49 +0200
Subject: [PATCH] Add command line option --chdir/-C to allow setting git process work directory.
Signed-off-by: Maciej Pasternacki <maciej@pasternacki.net>
---
Documentation/git.txt | 6 +++++-
git.c | 9 ++++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index df420ae..6676d68 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git' [--version] [--exec-path[=GIT_EXEC_PATH]]
[-p|--paginate|--no-pager]
[--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
- [--help] COMMAND [ARGS]
+ [-C DIRECTORY|--chdir=DIRECTORY] [--help] COMMAND [ARGS]
DESCRIPTION
-----------
@@ -185,6 +185,10 @@ help ...`.
environment is not set, it is set to the current working
directory.
+-C <directory>::
+--chdir=<directory>::
+ Change working directory before doing anything.
+
FURTHER DOCUMENTATION
---------------------
diff --git a/git.c b/git.c
index 89feb0b..8c97671 100644
--- a/git.c
+++ b/git.c
@@ -115,7 +115,14 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)
setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);
if (envchanged)
*envchanged = 1;
- } else {
+ } else if (!strcmp(cmd, "-C") || !strcmp(cmd, "--chdir")) {
+ chdir((*argv)[1]);
+ (*argv)++;
+ (*argc)--;
+ handled++;
+ } else if (!prefixcmp(cmd,"--chdir=")) {
+ chdir(cmd+8);
+ } else {
fprintf(stderr, "Unknown option: %s\n", cmd);
usage(git_usage_string);
}
--
1.6.0.1
^ permalink raw reply related
* Re: [PATCHv6 3/5] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-10-18 23:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200810190126.06697.jnareb@gmail.com>
On Sun, Oct 19, 2008 at 1:26 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
>
>> When using path info, make filenames start with a / (right after the :
>> that separates them from the hash base). This minimal change allows
>> relative navigation to work properly when viewing HTML files in raw
>> ('blob_plain') mode.
>
> This means generating project/action/hash_base:/filename rather than
> earlier project/action/hash_base:filename, isn't it?
Exactly. We _accept_ paths with or without the /, but we always
generate paths with it.
> For example for http://repo.or.cz/w/git.git/html:/git.html links leads
> to correct HTML pages, while for http://repo.or.cz/w/git.git/html:git.html
> they lead to empty gitweb page (no errors, so link checker would be
> fooled).
An idea that could be taken into consideration, if the ability to
navigate web documents is deemed of primary importance, would be a
redirect from the no-slash URL (a hand-coded one, given that with this
patch we only generate slashed URLs) to the slashed URL. Not sure it's
worth the effort (and reparsing) though: it would obviously be MUCH
nicer if we could change the URL without having to actually reload the
document ...
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv6 3/5] gitweb: use_pathinfo filenames start with /
From: Jakub Narebski @ 2008-10-18 23:26 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-4-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> When using path info, make filenames start with a / (right after the :
> that separates them from the hash base). This minimal change allows
> relative navigation to work properly when viewing HTML files in raw
> ('blob_plain') mode.
This means generating project/action/hash_base:/filename rather than
earlier project/action/hash_base:filename, isn't it?
For example for http://repo.or.cz/w/git.git/html:/git.html links leads
to correct HTML pages, while for http://repo.or.cz/w/git.git/html:git.html
they lead to empty gitweb page (no errors, so link checker would be
fooled).
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 5337d40..49730f3 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -727,7 +727,7 @@ sub href (%) {
> # try to put as many parameters as possible in PATH_INFO:
> # - project name
> # - action
> - # - hash or hash_base:filename
> + # - hash or hash_base:/filename
>
> # When the script is the root DirectoryIndex for the domain,
> # $href here would be something like http://gitweb.example.com/
> @@ -746,11 +746,11 @@ sub href (%) {
> delete $params{'action'};
> }
>
> - # Finally, we put either hash_base:file_name or hash
> + # Finally, we put either hash_base:/file_name or hash
> if (defined $params{'hash_base'}) {
> $href .= "/".esc_url($params{'hash_base'});
> if (defined $params{'file_name'}) {
> - $href .= ":".esc_url($params{'file_name'});
> + $href .= ":/".esc_url($params{'file_name'});
> delete $params{'file_name'};
> }
> delete $params{'hash'};
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv6 2/5] gitweb: generate project/action/hash URLs
From: Jakub Narebski @ 2008-10-18 23:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-3-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> When generating path info URLs, reduce the number of CGI parameters by
> embedding action and hash_parent:filename or hash in the path.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Nice, well commented, and clean.
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 33 ++++++++++++++++++++++++++++++---
> 1 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 6d0dc26..5337d40 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -724,14 +724,41 @@ sub href (%) {
>
> my ($use_pathinfo) = gitweb_check_feature('pathinfo');
> if ($use_pathinfo) {
> - # use PATH_INFO for project name
> + # try to put as many parameters as possible in PATH_INFO:
> + # - project name
> + # - action
> + # - hash or hash_base:filename
> +
> + # When the script is the root DirectoryIndex for the domain,
> + # $href here would be something like http://gitweb.example.com/
> + # Thus, we strip any trailing / from $href, to spare us double
> + # slashes in the final URL
> + $href =~ s,/$,,;
I like having this comment here.
> +
> + # Then add the project name, if present
> $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> delete $params{'project'};
>
> - # Summary just uses the project path URL
> - if (defined $params{'action'} && $params{'action'} eq 'summary') {
> + # Summary just uses the project path URL, any other action is
> + # added to the URL
Which meant that we prefer http://base_url/project over http://base_url/project/summary
> + if (defined $params{'action'}) {
> + $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
> delete $params{'action'};
> }
> +
> + # Finally, we put either hash_base:file_name or hash
> + if (defined $params{'hash_base'}) {
> + $href .= "/".esc_url($params{'hash_base'});
> + if (defined $params{'file_name'}) {
> + $href .= ":".esc_url($params{'file_name'});
> + delete $params{'file_name'};
> + }
> + delete $params{'hash'};
> + delete $params{'hash_base'};
> + } elsif (defined $params{'hash'}) {
> + $href .= "/".esc_url($params{'hash'});
> + delete $params{'hash'};
> + }
> }
>
> # now encode the parameters explicitly
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv6 1/5] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Jakub Narebski @ 2008-10-18 22:41 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-2-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> This patch enables gitweb to parse URLs with more information embedded
> in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
> path is now $project/$action/$hash_base:$file_name or
> $project/$action/$hash
>
> This is mostly backwards compatible with the old-style gitweb paths,
> $project/$branch[:$filename], except when it was used to access a branch
> whose name matches a gitweb action.
...in which case old code would access branch, and new code would treat
name as action. This shouldn't matter in practice, unless there are
branches named exactly as gitweb actions.
[But I think current commit description is enough. Just in case...]
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
I like it. For what it is worth:
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 37 +++++++++++++++++++++++++++++++------
> 1 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index c5254af..6d0dc26 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -534,23 +534,48 @@ sub evaluate_path_info {
> return if $input_params{'action'};
> $path_info =~ s,^\Q$project\E/*,,;
>
> + # next, check if we have an action
> + my $action = $path_info;
> + $action =~ s,/.*$,,;
> + if (exists $actions{$action}) {
> + $path_info =~ s,^$action/*,,;
> + $input_params{'action'} = $action;
> + }
> +
> + # list of actions that want hash_base instead of hash
...and can have no file_name ('f') parameter.
> + my @wants_base = (
> + 'tree',
> + 'history',
> + );
I like this solution. It makes path_info URL unambiguous: it is
<project>/log/<hash> (where <hash> is usually refname), and
<project>/tree/<hash_base> which is just shortcut for <project>/tree/<hash_base>:/
It means that the @wants_base list contains actions which require / use
$hash_base and $file_name, but $file_name might be not set, which denotes
top directory (root tree).
> +
> my ($refname, $pathname) = split(/:/, $path_info, 2);
> if (defined $pathname) {
> - # we got "project.git/branch:filename" or "project.git/branch:dir/"
> + # we got "branch:filename" or "branch:dir/"
> # we could use git_get_type(branch:pathname), but it needs $git_dir
Well, this comment was there... but actually I think we avoid
git_get_type("branch:pathname") because currently it is additional fork.
And with convention that filename part of path_info ends in '/' for
directories (quite sensible I think) it is not needed. Moreso after
next patch in series, when we state action explicitly, and the only
difference _might_ be for 'history' view (which is for directories
and for files both).
> $pathname =~ s,^/+,,;
> if (!$pathname || substr($pathname, -1) eq "/") {
> - $input_params{'action'} = "tree";
> + $input_params{'action'} ||= "tree";
> $pathname =~ s,/$,,;
> } else {
> - $input_params{'action'} = "blob_plain";
> + $input_params{'action'} ||= "blob_plain";
> }
> $input_params{'hash_base'} ||= $refname;
> $input_params{'file_name'} ||= $pathname;
> } elsif (defined $refname) {
> - # we got "project.git/branch"
> - $input_params{'action'} = "shortlog";
> - $input_params{'hash'} ||= $refname;
> + # we got "branch". in this case we have to choose if we have to
^ ^
|-|-- ??? (typo?)
> + # set hash or hash_base.
> + #
> + # Most of the actions without a pathname only want hash to be
> + # set, except for the ones specified in @wants_base that want
> + # hash_base instead. It should also be noted that hand-crafted
> + # links having 'history' as an action and no pathname or hash
> + # set will fail, but that happens regardless of PATH_INFO.
Ah, I see that the comment about what makes action to be put into
@wants_base is here.
> + $input_params{'action'} ||= "shortlog";
> + if (grep {$input_params{'action'} eq $_} @wants_base) {
Style: I would use here (but perhaps it is just me) for better
readibility
+ if (grep { $input_params{'action'} eq $_ } @wants_base) {
> + $input_params{'hash_base'} ||= $refname;
> + } else {
> + $input_params{'hash'} ||= $refname;
> + }
> }
> }
> evaluate_path_info();
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ 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