* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Leo Razoumov @ 2008-12-02 2:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081108142756.GC17100@coredump.intra.peff.net>
On 11/8/08, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
>
> > > The FAQ even says "don't do this until you know what you are doing." So
> > > the safety valve is configurable, so that those who know what they are
> > > doing can switch it off.
> >
> > "We are breaking your existing working setup but you can add a new
> > configuration to unbreak it" should not be done lightly. I think as the
> > end result it is a reasonable thing to aim for for this particular
> > feature, but we do need a transition plan patch in between that introduces
> > a step that warns but not forbids. We can ship 1.6.1 with it and then
> > switch the default to forbid in 1.6.3, for example.
>
>
> Yeah, I was kind of hoping we could assume that anybody relying on this
> behavior was somewhat insane, and wouldn't be too upset when it broke.
I do not think that having a work-flow different from yours deserves a
"somewhat insane" label. But let us consider the consequences of
banning push into a (current branch) non-bare repo. To propagate
changes to such a non-bare repo there are two remaining alternatives
neither of which is fully satisfactory:
(1) Switch target's current branch to something else (prevent a
conflict) before pushing and then restore it back after the push
(2) Use git-fetch from the target.
Method (1) is no better than what is available today with "git reset
--hard" to sync working directory.
Method (2) is even worse, because git-fetch provides no control of
what branches/tags to fetch, it sucks everything in from all branches.
"git-push", OTOH, can be instructed to be very selective.
Here is an example of such a work-flow
Foo.git -- main bare repo of the project
Foo.wip -- everyday "work in progress" repo. Cloned from Foo.git.
Pushes to Foo.git
Foo.wip.insane -- experimental "crazy" stuff cloned from Foo.wip.
Pushed to Foo.wip
Proposed patch makes this work flow impossible (cannot push from
Foo.wip.insane to Foo.wip)
--Leo--
^ permalink raw reply
* Re: two questions about the format of loose object
From: Liu Yubao @ 2008-12-02 2:26 UTC (permalink / raw)
To: Nick Andrew; +Cc: git list
In-Reply-To: <20081201121611.GC32415@mail.local.tull.net>
Nick Andrew wrote:
> On Mon, Dec 01, 2008 at 04:00:55PM +0800, Liu Yubao wrote:
>> I did a simple benchmark on my notebook and a server in my company,
>> writing a big file to disk is faster than compressing it first and
>> writing the result out. The former's performance for reading should
>> also be better because of file cache.
>
> In a corporate environment (and not related to git) I found the
> opposite. The disk was fairly slow (over NFS) and it was in fact
> quicker to read and write compressed files.
>
> Nick.
>
Ok, there must be exceptional cases, for these cases you can turn
off core.uncompressedLooseObject (if there will be this config).
Best regards,
Liu Yubao
^ permalink raw reply
* Git as a BuildRequires (packaging)
From: Josh Boyer @ 2008-12-02 2:30 UTC (permalink / raw)
To: git; +Cc: skvidal
Hi All,
Recently we've hit an issue where a new package being reviewed for
Fedora (cgit) needs to build against the git headers. The problem
is that these headers aren't typically installed with the git
package itself, and we have no git-devel subpackage either. This
is mostly due to the fact that from what I can tell the upstream
git Makefile doesn't install the headers anywhere.
There are a few options here. The first is to install the git
headers and create a git-devel subpackage. That seems like
overkill, given that the git headers are generically named and
would have to be installed to something like /usr/include/git/.
The second option is to create a patch file that includes all
the needed headers and use that in the cgit package. That is
sort of sub-optimal given that you'd have to keep checking
(and possibly regenerating) the patch for correctness every time
a new version of git comes out.
The third option is to include the entire git tarball as part of
the sources for the package. That is pretty easily done with the
Fedora infrastructure, but isn't exactly clean from a packaging
standpoint.
So, what do the git gurus recommend? I'm not sure if other
distros have tackled this problem before, but some kind of
commonality for the 'how do you package things that need to build
against git' question would be nice.
(Please CC me. I can't remember if I'm still subscribed to the
git list or not.)
thx,
josh
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Junio C Hamano @ 2008-12-02 2:29 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Jeff King, Junio C Hamano, git, Sam Vilain
In-Reply-To: <ee2a733e0812011822r4cef6a44ra68d6e84f9e30a90@mail.gmail.com>
"Leo Razoumov" <slonik.az@gmail.com> writes:
> On 11/8/08, Jeff King <peff@peff.net> wrote:
>> On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
>>
>> > > The FAQ even says "don't do this until you know what you are doing." So
>> > > the safety valve is configurable, so that those who know what they are
>> > > doing can switch it off.
>> >
>> > "We are breaking your existing working setup but you can add a new
>> > configuration to unbreak it" should not be done lightly. I think as the
>> > end result it is a reasonable thing to aim for for this particular
>> > feature, but we do need a transition plan patch in between that introduces
>> > a step that warns but not forbids. We can ship 1.6.1 with it and then
>> > switch the default to forbid in 1.6.3, for example.
>>
>>
>> Yeah, I was kind of hoping we could assume that anybody relying on this
>> behavior was somewhat insane, and wouldn't be too upset when it broke.
>
> I do not think that having a work-flow different from yours deserves a
> "somewhat insane" label. But let us consider the consequences of
> banning push into a (current branch) non-bare repo. To propagate
> changes to such a non-bare repo there are two remaining alternatives
> neither of which is fully satisfactory:
>
> (1) Switch target's current branch to something else (prevent a
> conflict) before pushing and then restore it back after the push
>
> (2) Use git-fetch from the target.
(3) set the config in the target repository to allow such a push
regardless of the git version.
Remember, I am in the third camp in this topic myself.
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Jeff King @ 2008-12-02 2:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vwrqpvf.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 01, 2008 at 06:20:52PM -0800, Junio C Hamano wrote:
> I think sending 0{40} would break older clients, but older clients cannot
> clone from an empty repository anyway, so that should not be so bad. I
> however do not think it is such a big thing to be able to clone void
> anyway.
>
> You just have to train yourself to announce that your repository is
> clonable _after_ making it actually clonable.
I disagree. 99% of the time we see people complain about this, it is not
"I tried to announce my repo to people but it didn't have any commits"
but rather "why must I hack, init remote, then push, instead of init
remote, hack, push"[1].
That is, some segment of people (myself included) want to say first "I'm
starting a new project, and so I'm going to create a spot for it on my
server". Of course we can train ourselves to do it in the other order,
but it is an unnecessary complication.
-Peff
[1] Actually, it is more than just arbitrary preference. It is less
typing to do:
ssh remote 'mkdir foo && cd foo && git init --bare'
git clone remote:foo
hack hack hack; commit
git push
than
git init
hack hack hack; commit
ssh remote 'mkdir foo && cd foo && git init --bare'
git push
git remote add -m refs/heads/master origin remote:foo
^ permalink raw reply
* Re: more merge strategies : feature request
From: Caleb Cushing @ 2008-12-02 2:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4933AC03.6050300@op5.se>
> If you could come up with use-cases where each would be useful, I
> think you'd have a much easier time to gain acceptance for your
> suggestions. Right now, you're saying "I want a red button" but
> you're not explaining what it's for.
conflict: when auto-merging isn't merging the way you want it too, but
you still want to see the diffs and handle them by hand. no commit
won't do this, it just doesn't commit. I've had 2 situations now where
git's fast-forward has overwritten changes in a branch I didn't want
it to, it would have been better if I could handle them by hand
without having to have 1 terminal open to the diff and the other open
to the editor to fix it. and yes git was right by it's perspective,
but the code it created was wrong by what I wanted and needed. I'm not
really sure what more of a use case is needed for this.
no-overwrite: it's basically my way of saying that even though git
thinks it's changes are newer and better than the ones in my branch I
know they aren't. I only want the new stuff from the other branch. In
the second situation mentioned above I have 2 branches that I like to
merge back and forth, each needing a specific set of changes to
certain files however most changes are shared. when I merge them I
often have to change those specific changes back, if it didn't
ovewrite them I wouldn't have a problem.
for example I'm tracking my dot files with git, in my main user
account I set umask 077 however in my web development account I need
umask 027 so apache can read the files I create. when I create a
change in webdev and need to merge it back into master it overwrites
the 077 umask which I then change back. when I create a change in
master that I want in webdev it then changes webdev's umask. very
annoying.
the other problem I had was where I'd overwritten a file in another
branch just for the point of merging it into the master branch so I
could see the differences, and handle them properly (as I see it)
unfortunately git felt that this file was newer and simply overwrote
the changes in master. this was incorrect they were simply different
versions of the same type of file, like comparing an httpd.conf from a
gentoo and another from a fedora system. I was merely trying to figure
the best of both files to get the results I wanted.
technically the conflict strategy I propose would be adequate for both
but the no-overwrite seems like a good idea as well.
--
Caleb Cushing
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Leo Razoumov @ 2008-12-02 2:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Sam Vilain
In-Reply-To: <7vtz9npawn.fsf@gitster.siamese.dyndns.org>
On 12/1/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Leo Razoumov" <slonik.az@gmail.com> writes:
>
> > On 11/8/08, Jeff King <peff@peff.net> wrote:
> >> On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
> >>
> >> > > The FAQ even says "don't do this until you know what you are doing." So
> >> > > the safety valve is configurable, so that those who know what they are
> >> > > doing can switch it off.
> >> >
> >> > "We are breaking your existing working setup but you can add a new
> >> > configuration to unbreak it" should not be done lightly. I think as the
> >> > end result it is a reasonable thing to aim for for this particular
> >> > feature, but we do need a transition plan patch in between that introduces
> >> > a step that warns but not forbids. We can ship 1.6.1 with it and then
> >> > switch the default to forbid in 1.6.3, for example.
> >>
> >>
> >> Yeah, I was kind of hoping we could assume that anybody relying on this
> >> behavior was somewhat insane, and wouldn't be too upset when it broke.
> >
> > I do not think that having a work-flow different from yours deserves a
> > "somewhat insane" label. But let us consider the consequences of
> > banning push into a (current branch) non-bare repo. To propagate
> > changes to such a non-bare repo there are two remaining alternatives
> > neither of which is fully satisfactory:
> >
> > (1) Switch target's current branch to something else (prevent a
> > conflict) before pushing and then restore it back after the push
> >
> > (2) Use git-fetch from the target.
>
>
> (3) set the config in the target repository to allow such a push
> regardless of the git version.
>
> Remember, I am in the third camp in this topic myself.
Junio,
thanks for supporting the "third way". I am not sure whether I
interpret it correctly but in the same thread several message earlier
you wrote "We can ship 1.6.1 with it and then switch the default to
forbid in 1.6.3, for example". With the default set to "deny" it would
be useful if the git-push error message will indicate what config
variable to set in order to reverse the denial.
--Leo--
^ permalink raw reply
* [PATCH] git-svn: Make branch use correct svn-remote
From: Deskin Miller @ 2008-12-02 2:43 UTC (permalink / raw)
To: git; +Cc: gitster, normalperson, Deskin Miller
The 'branch' subcommand incorrectly had the svn-remote to use hardcoded
as 'svn', the default remote name. This meant that branches derived
from other svn-remotes would try to use the branch and tag configuration
for the 'svn' remote, potentially copying would-be branches to the wrong
place in SVN, into the branch namespace for another project.
Fix this by using the remote name extracted from the svn info for the
specified git ref. Add a testcase for this behaviour.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
Applies on v1.6.1-rc1. Apologies for not catching this when first
writing testcases for the branch subcommand.
Deskin Miller
git-svn.perl | 2 +-
t/t9128-git-svn-cmd-branch.sh | 17 +++++++++++++++++
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 914c707..e64e97b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -558,7 +558,7 @@ sub cmd_branch {
my ($src, $rev, undef, $gs) = working_head_info($head);
- my $remote = Git::SVN::read_all_remotes()->{svn};
+ my $remote = Git::SVN::read_all_remotes()->{$gs->{repo_id}};
my $glob = $remote->{ $_tag ? 'tags' : 'branches' };
my ($lft, $rgt) = @{ $glob->{path} }{qw/left right/};
my $dst = join '/', $remote->{url}, $lft, $branch_name, ($rgt || ());
diff --git a/t/t9128-git-svn-cmd-branch.sh b/t/t9128-git-svn-cmd-branch.sh
index 47c4d4d..e2b6696 100755
--- a/t/t9128-git-svn-cmd-branch.sh
+++ b/t/t9128-git-svn-cmd-branch.sh
@@ -56,4 +56,21 @@ test_expect_success 'git svn branch tests' '
test_must_fail git svn tag tag1
'
+test_expect_success 'branch uses correct svn-remote' '
+ (svn co "$svnrepo" svn &&
+ cd svn &&
+ mkdir mirror &&
+ svn add mirror &&
+ svn copy trunk tags branches mirror/ &&
+ svn ci -m "made mirror" ) &&
+ rm -rf svn &&
+ git svn init -s -R mirror --prefix=mirror/ "$svnrepo"/mirror &&
+ git svn fetch -R mirror &&
+ git checkout mirror/trunk &&
+ base=$(git rev-parse HEAD:) &&
+ git svn branch -m "branch in mirror" d &&
+ test $base = $(git rev-parse remotes/mirror/d:) &&
+ test_must_fail git rev-parse remotes/d
+'
+
test_done
--
1.6.1.rc1
^ permalink raw reply related
* Re: two questions about the format of loose object
From: Liu Yubao @ 2008-12-02 2:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git list
In-Reply-To: <20081201152148.GG23984@spearce.org>
Shawn O. Pearce wrote:
> Liu Yubao <yubao.liu@gmail.com> wrote:
>> Thanks for your explanation, but I doubt if it's too costly to change the
>> format of loose object, after all this doesn't change the format of pack
>> file and affect git-pull/fetch of old git client.
>
> It is too costly; Jakub pointed out the dumb protocol clients
> would have issues with the new format. Anyone copying a repository
> between machines using scp or a USB memory stick may also run into
> a problem. Etc.
>
Yes, exceptional case, is it acceptable that core.uncompressedLooseObject
is set to false by default especially for NFS file system?
>> Some cons and pros.
>>
>> cons:
>>
>> * old git client can't read loose objects in new format
>> (People degrade git rarely and old git can read pack files
>> generated by new git, so it's not a big problem)
>
> That's a pretty big con. We can also add slower performance on NFS,
> as has been reported already by others.
>
I mean to add a format, not to replace the current format of loose object.
>> pros:
>>
>> * avoid compressing and uncompressing loose objects that are likely
>> frequently used when you are coding/merging
>
> True, loose objects are among the more frequently accessed items.
>
>> * share loose objects among multipe git processes
>
> Probably not a huge issue. How many concurrent git processes are
> you running on the same object store at once? During development?
> Its probably not more than 1. So sharing the objects doesn't make
> a very compelling argument.
>
In my company we have a central server to host source code repository
managed by git+ssh. Some collegues also work on the same machine (maybe
not a good practice) and set alternates to the central repository, so
there can be multiple git processes operating same git object database.
In fact we have a wrapper script of git to make git fit our development
process better because git's submodule support isn't good enough. One
command in the wrapper script can execute many git commands in a short
time.
>> * the new code path is simpler although we will have more code paths for
>> compatibility
>
> The new code path is more complex, because although one branch is
> very simple (mmap and use) the other code paths have to stay for
> backwards compatibility. Every time you add a branch point the
> code gets more complex. It works well enough now, and is at least
> one branch point simpler than what you are proposing. So I'm not
> really interested in seeing the change made.
>
Could you review my patches sent just a moment ago? The key changes are
rather small.
Best regards,
Liu Yubao
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-12-02 2:48 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <ee2a733e0812011822r4cef6a44ra68d6e84f9e30a90@mail.gmail.com>
On Mon, Dec 01, 2008 at 09:22:43PM -0500, Leo Razoumov wrote:
> I do not think that having a work-flow different from yours deserves a
> "somewhat insane" label. But let us consider the consequences of
a) you are responding to a nearly month-old message. Please read the
rest of the thread where we decide that it is not so insane, and
that the behavior should be configurable with a default of "warn"
at least for now.
b) My comment was not that it is insane simply because it is different
from mine. It is because it creates a dangerous situation (where
dangerous implies changes might be silently lost) which requires
manual intervention to fix, and which the user was given no warning
whatsoever about. It is a direct response to frequent complaints on
the list about users getting bit by this.
> (1) Switch target's current branch to something else (prevent a
> conflict) before pushing and then restore it back after the push
>
> (2) Use git-fetch from the target.
(3) Use git-reset --hard, but set a config variable that says "I know
what I'm doing." You don't even have to do it per-repo, you can do it
per-user.
(4) Push into a non-current branch and merge from the target.
> Method (2) is even worse, because git-fetch provides no control of
> what branches/tags to fetch, it sucks everything in from all branches.
> "git-push", OTOH, can be instructed to be very selective.
Er, what? git-fetch takes a refspec very similar to the ones used by
git-push. The real reason that (2) is not an acceptable solution is that
you can't necessarily connect to the source repo (e.g., it is on your
workstation with no ssh or git server running).
-Peff
^ permalink raw reply
* Re: more merge strategies : feature request
From: Leo Razoumov @ 2008-12-02 2:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Caleb Cushing, git
In-Reply-To: <4933AC03.6050300@op5.se>
On 12/1/08, Andreas Ericsson <ae@op5.se> wrote:
> Caleb Cushing wrote:
>
> > conflict: this strategy would always resolve in a merge conflict
> > allowing you to use git mergetool to piece the files back together.
> >
> > no-overwrite: if a change from the branch being merged in would
> > overwrite something in the current branch don't merge it. (I think it
> > needs a better name)
> >
I guess that "no-overwrite" can be achieved by
git merge -s ours --no-commit
--Leo--
^ permalink raw reply
* Re: two questions about the format of loose object
From: Liu Yubao @ 2008-12-02 3:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git list
In-Reply-To: <20081201153211.GH23984@spearce.org>
Shawn O. Pearce wrote:
> Liu Yubao <yubao.liu@gmail.com> wrote:
>> In current implementation the loose objects are compressed:
>>
>> loose object = deflate(typename + <space> + size + '\0' + data)
> ...
>> * Question 1:
>>
>> Why not use the format below for loose object?
>> loose object = typename + <space> + size + '\0' + deflate(data)
>
> Historical accident. We really should have used a format more
> like what you are asking here, because it makes inflation easier.
> The pack file format uses a header structure sort of like this,
> for exactly that reason. IOW we did learn our mistakes and fix them.
>
> If you look up the new style loose object code you'll see that it
> has a format like this (sort of), the header is actually the same
> format that is used in the pack files, making it smaller than what
> you propose but also easier to unpack as the code can be reused
> with the pack reading code.
>
> Unfortunately the new style loose object was phased out; it never
> really took off and it made the code much more complex. So it was
> pulled in commit 726f852b0ed7e03e88c419a9996c3815911c9db1:
>
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.
> Author: Nicolas Pitre <nico@cam.org>:
> > deprecate the new loose object header format
> >
> > Now that we encourage and actively preserve objects in a packed form
> > more agressively than we did at the time the new loose object format and
> > core.legacyheaders were introduced, that extra loose object format
> > doesn't appear to be worth it anymore.
> >
> > Because the packing of loose objects has to go through the delta match
> > loop anyway, and since most of them should end up being deltified in
> > most cases, there is really little advantage to have this parallel loose
> > object format as the CPU savings it might provide is rather lost in the
> > noise in the end.
> >
> > This patch gets rid of core.legacyheaders, preserve the legacy format as
> > the only writable loose object format and deprecate the other one to
> > keep things simpler.
>
Thank you for dig it out for me!
Best regards,
Liu Yubao
^ permalink raw reply
* Re: Git as a BuildRequires (packaging)
From: Jeff King @ 2008-12-02 3:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: git, skvidal
In-Reply-To: <20081202023004.GA30372@zod.rchland.ibm.com>
On Mon, Dec 01, 2008 at 09:30:04PM -0500, Josh Boyer wrote:
> Recently we've hit an issue where a new package being reviewed for
> Fedora (cgit) needs to build against the git headers. The problem
> is that these headers aren't typically installed with the git
> package itself, and we have no git-devel subpackage either. This
> is mostly due to the fact that from what I can tell the upstream
> git Makefile doesn't install the headers anywhere.
I don't think Linus, Junio, or anybody involved with git has _ever_
advocated using git source files as a library. The expected method for
interfacing with git is the plumbing API, which is stable and available
via the installed git programs.
That being said, I think linking with libgit.a has been discussed on the
list, and Lars took part in the discussion. So I think he is aware that
what cgit does is not officially supported, that there is no stable
library API, and that he is taking his chances.
> There are a few options here. The first is to install the git
> headers and create a git-devel subpackage. That seems like
> overkill, given that the git headers are generically named and
> would have to be installed to something like /usr/include/git/.
I think that is a mistake; the headers are subject to change in ways that
will break calling code, and creating a -devel package creates the
impression that it's OK to link against it.
> The second option is to create a patch file that includes all
> the needed headers and use that in the cgit package. That is
> [...]
> The third option is to include the entire git tarball as part of
> the sources for the package. That is pretty easily done with the
> Fedora infrastructure, but isn't exactly clean from a packaging
> standpoint.
I don't know how one is usually expected to build cgit. But yes, you are
always going to have a problem with upgrading git. I would think each
cgit release would be tested based on a particular git version. And you
should rely on cgit upstream to figure that out and just package (either
in whole or as patches, as appropriate) the upstream git headers with
it.
> So, what do the git gurus recommend? I'm not sure if other
> distros have tackled this problem before, but some kind of
> commonality for the 'how do you package things that need to build
> against git' question would be nice.
AFAIK, cgit is the only program that behaves in this way, and it doesn't
seem to be in Debian at all. So you might be the first to deal with it.
:)
-Peff
^ permalink raw reply
* Re: [PATCH 0/5] support reading and writing uncompressed loose object
From: Liu Yubao @ 2008-12-02 3:11 UTC (permalink / raw)
To: git list; +Cc: Junio C Hamano
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Hi all,
It seems my patch series are not in one mail thread, I'm very sorry
for that, I replied this thread and paste my patches into Thunderbird
with external editor plugin, don't know why they become separate topics.
Best regards,
Liu Yubao
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Leo Razoumov @ 2008-12-02 3:08 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081202024837.GB6804@coredump.intra.peff.net>
On 12/1/08, Jeff King <peff@peff.net> wrote:
> [..snip..]
> >
> Er, what? git-fetch takes a refspec very similar to the ones used by
> git-push. The real reason that (2) is not an acceptable solution is that
> you can't necessarily connect to the source repo (e.g., it is on your
> workstation with no ssh or git server running).
>
> -Peff
I am sorry, I had to be more accurate in my wording. "git fetch" with
no explicit refspecs fetches everything in. It is quite cumbersome to
form a refspec for git-fetch operation if you are not logged in into
the "source repo" machine. git-fetch does not have a --dry-run option
to help discover all the branch/tag names on the source side needed
for a meaningful refspec. "git-push -v --dry-run" allows one to
experiment and see what branches/tags exist at the destination and
form refspecs selectively. To the best of my knowledge, git-fetch does
not provide such discovery tools.
--Leo--
^ permalink raw reply
* Re: more merge strategies : feature request
From: Jeff King @ 2008-12-02 3:30 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Andreas Ericsson, git
In-Reply-To: <81bfc67a0812011838m68100020v727da1c06f0bcee4@mail.gmail.com>
On Mon, Dec 01, 2008 at 09:38:07PM -0500, Caleb Cushing wrote:
> conflict: when auto-merging isn't merging the way you want it too, but
> you still want to see the diffs and handle them by hand. no commit
> won't do this, it just doesn't commit. I've had 2 situations now where
> git's fast-forward has overwritten changes in a branch I didn't want
> it to, it would have been better if I could handle them by hand
> without having to have 1 terminal open to the diff and the other open
> to the editor to fix it. and yes git was right by it's perspective,
> but the code it created was wrong by what I wanted and needed. I'm not
> really sure what more of a use case is needed for this.
It's not clear to me exactly what you want. Let's say I have a file
'foo' with changes from my merged branches in two different spots.
For example:
merge base branch A branch B
1 2 1
2 3 2
3 4 3
4 5 4
5
Did you want conflict markers in the resulting file? If so, what should
the conflict markers look like, since there isn't actually a conflict?
Alternatively, you could have git leave the file in an unmerged state,
and then access the base, ours, and theirs version from the index (or
even use git mergetool). Then you would get your desired versions into
the merging tool of your choice.
Of course, you could also just use a custom merge driver to accomplish
the same thing:
git config merge.xxdiff.driver 'xxdiff %A %O %B'
echo '* merge=xxdiff' >.gitattributes
git merge your-branch
and of course you can specify whatever subset of files you want to
actually do this for instead of '*'.
-Peff
^ permalink raw reply
* [PATCH] Modifies the default git help message to be grouped by topic
From: Scott Chacon @ 2008-12-02 6:05 UTC (permalink / raw)
To: gitster; +Cc: git, peff
It's difficult to process 21 commands (which is what is output
by default for git when no command is given). They have been
re-grouped into 4 groups of 5-6 commands each, which is clearer
and easier for new users to process.
Also removes the common-cmd.h generation process, including
parts of the Makefile and the generate-cmdlist.sh file.
As discussed at the GitTogether.
Signed-off-by: Scott Chacon <schacon@gmail.com>
---
This is a followup patch based on Junio and Jeffs feedback.
It also should apply cleanly which the other one would no
longer to, since it was from the GitTogether and then resent.
Makefile | 13 ++++---------
builtin-help.c | 40 ++++++++++++++++++++++++++--------------
generate-cmdlist.sh | 24 ------------------------
3 files changed, 30 insertions(+), 47 deletions(-)
delete mode 100755 generate-cmdlist.sh
diff --git a/Makefile b/Makefile
index 649cfb8..9a564cb 100644
--- a/Makefile
+++ b/Makefile
@@ -1117,7 +1117,7 @@ shell_compatibility_test: please_set_SHELL_PATH_to_a_more_modern_shell
strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
-git.o: git.c common-cmds.h GIT-CFLAGS
+git.o: git.c GIT-CFLAGS
$(QUIET_CC)$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(ALL_CFLAGS) -c $(filter %.c,$^)
@@ -1125,7 +1125,7 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-builtin-help.o: builtin-help.c common-cmds.h GIT-CFLAGS
+builtin-help.o: builtin-help.c GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
'-DGIT_HTML_PATH="$(htmldir_SQ)"' \
'-DGIT_MAN_PATH="$(mandir_SQ)"' \
@@ -1137,11 +1137,6 @@ $(BUILT_INS): git$X
ln -s git$X $@ 2>/dev/null || \
cp git$X $@
-common-cmds.h: ./generate-cmdlist.sh command-list.txt
-
-common-cmds.h: $(wildcard Documentation/git-*.txt)
- $(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@
-
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
@@ -1363,7 +1358,7 @@ test-%$X: test-%.o $(GITLIBS)
check-sha1:: test-sha1$X
./test-sha1.sh
-check: common-cmds.h
+check:
if sparse; \
then \
for i in *.c; \
@@ -1498,7 +1493,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
- $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
+ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) config.log config.mak.autogen config.mak.append config.status config.cache
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
diff --git a/builtin-help.c b/builtin-help.c
index f076efa..537534a 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -6,7 +6,6 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
-#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
#include "help.h"
@@ -277,19 +276,32 @@ static struct cmdnames main_cmds, other_cmds;
void list_common_cmds_help(void)
{
- int i, longest = 0;
-
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- if (longest < strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
- }
-
- puts("The most commonly used git commands are:");
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(common_cmds[i].help);
- }
+ puts("The most commonly used git commands are:\n\
+\n\
+Basic Commands\n\
+ init Create an empty git repository or reinitialize an existing one\n\
+ add Add file contents to the staging area\n\
+ status Show the working tree and staging area status\n\
+ commit Record changes in the staging area to the repository\n\
+\n\
+History Commands\n\
+ log Show commit log history\n\
+ diff Show changes between commits, commit and working tree, etc\n\
+ reset Reset your staging area or working directory to a specified state\n\
+ show Show various types of objects\n\
+\n\
+Branch Commands\n\
+ checkout Checkout a branch or paths to the working tree\n\
+ branch List, create, or delete branches\n\
+ merge Join two or more development histories together\n\
+ rebase Apply changes introduced in one branch onto another\n\
+ tag Create, list, delete or verify a tag object signed with GPG\n\
+\n\
+Remote Commands\n\
+ clone Clone a repository into a new directory\n\
+ fetch Download objects and refs from another repository\n\
+ pull Fetch from and merge with another repository or a local branch\n\
+ push Update remote refs along with associated objects");
}
static int is_git_command(const char *s)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
deleted file mode 100755
index a2913c2..0000000
--- a/generate-cmdlist.sh
+++ /dev/null
@@ -1,24 +0,0 @@
-#!/bin/sh
-
-echo "/* Automatically generated by $0 */
-struct cmdname_help
-{
- char name[16];
- char help[80];
-};
-
-static struct cmdname_help common_cmds[] = {"
-
-sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
-sort |
-while read cmd
-do
- sed -n '
- /NAME/,/git-'"$cmd"'/H
- ${
- x
- s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
- p
- }' "Documentation/git-$cmd.txt"
-done
-echo "};"
--
1.6.0.8.gc9c8
^ permalink raw reply related
* Re: [PATCH] Modified the default git help message to be grouped by topic
From: Scott Chacon @ 2008-12-02 6:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v7i6jqriv.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, Dec 1, 2008 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Mon, Dec 01, 2008 at 09:30:37AM -0800, Scott Chacon wrote:
>>
>>> It's difficult to process 21 commands (which is what is output
>>> by default for git when no command is given). I've re-grouped
>>> them into 4 groups of 5 or 6 commands each, which I think is
>>> clearer and easier for new users to process.
>>
>> I like it (and I think the categorizations look reasonable, which is
>> something that I recall caused some discussion at the GitTogether).
>>
>> The only downside I see is that we're now >24 lines.
>
> If this list is meant to show "the most commonly used" basics, then you
> can trim the list somewhat. For example, "rm" and "mv" can be safely
> discarded, "status" can be replaced with "diff", and "diff" can be removed
> from "History Commands".
>
I sent a new patch that removes 'rm' and 'mv' and removes the
common-cmd.h build process. I did keep the 'status' command, since in
my personal experience people tend to like having that command.
Scott
^ permalink raw reply
* [PATCH] Add a built-in alias for 'stage' to the 'add' command
From: Scott Chacon @ 2008-12-02 6:14 UTC (permalink / raw)
To: gitster; +Cc: git, peff
This comes from conversation at the GitTogether where we thought it would
be helpful to be able to teach people to 'stage' files because it tends
to cause confusion when told that they have to keep 'add'ing them.
This continues the movement to start referring to the index as a
staging area (eg: the --staged alias to 'git diff'). Also adds a
doc file for 'git stage' that basically points to the docs for
'git add'.
Signed-off-by: Scott Chacon <schacon@gmail.com>
---
I changed the tense of a few things in the commit message and modified
the help file to be simpler.
Documentation/git-stage.txt | 19 +++++++++++++++++++
git.c | 1 +
2 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-stage.txt
diff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt
new file mode 100644
index 0000000..7f251a5
--- /dev/null
+++ b/Documentation/git-stage.txt
@@ -0,0 +1,19 @@
+git-stage(1)
+==============
+
+NAME
+----
+git-stage - Add file contents to the staging area
+
+
+SYNOPSIS
+--------
+[verse]
+'git stage' args...
+
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-add[1]. Please refer to the
+documentation of that command.
diff --git a/git.c b/git.c
index 89feb0b..9e5813c 100644
--- a/git.c
+++ b/git.c
@@ -266,6 +266,7 @@ static void handle_internal_command(int argc, const char **argv)
const char *cmd = argv[0];
static struct cmd_struct commands[] = {
{ "add", cmd_add, RUN_SETUP | NEED_WORK_TREE },
+ { "stage", cmd_add, RUN_SETUP | NEED_WORK_TREE },
{ "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply },
{ "archive", cmd_archive },
--
1.6.0.8.gc9c8
^ permalink raw reply related
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Johannes Sixt @ 2008-12-02 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Ralphson
In-Reply-To: <1228148005-9404-1-git-send-email-mike@abacus.co.uk>
Mike Ralphson schrieb:
> From: Junio C Hamano <gitster@pobox.com>
>
> This introduces make variable NO_PTHREADS for platforms that lack the
> support for pthreads library or people who do not want to use it for
> whatever reason. When defined, it makes the multi-threaded index
> preloading into a no-op, and also disables threaded delta searching by
> pack-objects.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
> ---
You can add
Tested-by: Johannes Sixt <j6t@kdbg.org> (AIX 4.3.x)
-- Hannes
^ permalink raw reply
* Re: [TOPGIT] Resolving conflicts
From: martin f krafft @ 2008-12-02 7:49 UTC (permalink / raw)
To: git; +Cc: Uwe Kleine-König, Sascha Hauer, Petr Baudis
In-Reply-To: <20081201143640.GA17818@cassiopeia.tralala>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.12.01.1536 +0100]:
> > Another thing is that the exported branch contains an empty commit
> > resulting from t/whatever (and a corresponding empty patch when exported
> > as a quilt series)
> I fixed one half of this in with a patch sent to the ML:
>
> http://article.gmane.org/gmane.comp.version-control.git/101728
>
> it didn't made it upstream yet, though.
This is now in HEAD. Sorry for the delay.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"i like wagner's music better than anybody's. it is so loud that one
can talk the whole time without other people hearing what one says."
-- oscar wilde
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] t4030-diff-textconv: Make octal escape sequence more portable
From: Johannes Sixt @ 2008-12-02 8:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
There are printfs around that do not grok '\1', but need '\01'.
Discovered on AIX 4.3.x.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I found no other instance of printf backslash-nonzero.
t/t4030-diff-textconv.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 03ba26a..4e961df 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -29,7 +29,7 @@ test_expect_success 'setup binary file with history' '
printf "\\0\\n" >file &&
git add file &&
git commit -m one &&
- printf "\\1\\n" >>file &&
+ printf "\\01\\n" >>file &&
git add file &&
git commit -m two
'
--
1.6.1.rc1.5.gf691f
^ permalink raw reply related
* Re: A better approach to diffing and merging
From: Karl Hasselström @ 2008-12-02 8:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ian Clarke, git
In-Reply-To: <m3y6z0i0mu.fsf@localhost.localdomain>
On 2008-12-01 03:41:38 -0800, Jakub Narebski wrote:
> Third, it would require embedding knowledge about various programming
> languages (including C, shell, Perl, TeX) and document formats
> (including XML, HTML, AsciiDoc) in version control system...
Really? I was under the impression that you could specify external
diff and merge programs in .gitattributes, which would be precisely
the right way to hook this stuff into git.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Git as a BuildRequires (packaging)
From: Miklos Vajna @ 2008-12-02 10:12 UTC (permalink / raw)
To: Jeff King; +Cc: Josh Boyer, git, skvidal
In-Reply-To: <20081202030922.GC6804@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
On Mon, Dec 01, 2008 at 10:09:23PM -0500, Jeff King <peff@peff.net> wrote:
> > So, what do the git gurus recommend? I'm not sure if other
> > distros have tackled this problem before, but some kind of
> > commonality for the 'how do you package things that need to build
> > against git' question would be nice.
>
> AFAIK, cgit is the only program that behaves in this way, and it doesn't
> seem to be in Debian at all. So you might be the first to deal with it.
> :)
We have it in Frugalware[1], and it's not a that big problem: the cgit
Makefile clearly states the supported git version, you just have to
download it "manually" (specify it in the spec file in case of Fedora)
in case you want an offline build (what every distro wants).
1: http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=blob;f=source/network-extra/cgit/FrugalBuild;hb=HEAD
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCHv3bis] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-12-02 10:43 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <200812020253.09430.jnareb@gmail.com>
The gitweb_check_feature routine was being used for two different
purposes: retrieving the actual feature value (such as the list of
snapshot formats or the list of additional actions), and checking if a
feature was enabled.
This led to subtle bugs in feature checking code: gitweb_check_feature
would return (0) for disabled features, so its use in scalar context
would return true instead of false.
To fix this issue and future-proof the code, we split feature value
retrieval into its own gitweb_get_feature()function, and ensure that
the boolean feature check function gitweb_check_feature() always returns
a scalar (precisely, the first/only item in the feature value list).
Usage of gitweb_check_feature() across gitweb is replaced with
gitweb_get_feature() where appropriate, and list evaluation of
gitweb_check_feature() is demoted to scalar evaluation to prevent
ambiguity. The few previously incorrect uses of gitweb_check_feature()
in scalar context are left untouched because they are now correct.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Fixed typo in commit message.
gitweb/gitweb.perl | 52 +++++++++++++++++++++++++++++++++++-----------------
1 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..4246819 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -190,7 +190,9 @@ our %feature = (
# if there is no 'sub' key (no feature-sub), then feature cannot be
# overriden
#
- # use gitweb_check_feature(<feature>) to check if <feature> is enabled
+ # use gitweb_get_feature(<feature>) to retrieve the <feature> value
+ # (an array) or gitweb_check_feature(<feature>) to check if <feature>
+ # is enabled
# Enable the 'blame' blob view, showing the last commit that modified
# each line in the file. This can be very CPU-intensive.
@@ -329,7 +331,8 @@ our %feature = (
'default' => [0]},
);
-sub gitweb_check_feature {
+# retrieve the value of a given feature, as an array
+sub gitweb_get_feature {
my ($name) = @_;
return unless exists $feature{$name};
my ($sub, $override, @defaults) = (
@@ -344,6 +347,21 @@ sub gitweb_check_feature {
return $sub->(@defaults);
}
+# check if a given feature is enabled or not, returning the first (and only)
+# value of the feature. This allows us to write
+# my $bool_feat = gitweb_check_feature('bool_feat');
+# or
+# gitweb_check_feature('bool_feat') or somecode;
+# instead of
+# my ($bool_feat) = gitweb_get_feature('bool_feat');
+# or
+# (gitweb_get_feature('bool_feat'))[0] or somecode;
+# respectively
+sub gitweb_check_feature {
+ return (gitweb_get_feature(@_))[0];
+}
+
+
sub feature_blame {
my ($val) = git_get_project_config('blame', '--bool');
@@ -767,7 +785,7 @@ our $git_dir;
$git_dir = "$projectroot/$project" if $project;
# list of supported snapshot formats
-our @snapshot_fmts = gitweb_check_feature('snapshot');
+our @snapshot_fmts = gitweb_get_feature('snapshot');
@snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
# dispatch
@@ -810,7 +828,7 @@ sub href (%) {
}
}
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
@@ -2101,7 +2119,7 @@ sub git_get_projects_list {
$filter ||= '';
$filter =~ s/\.git$//;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if (-d $projects_list) {
# search in directory
@@ -2947,7 +2965,7 @@ EOF
}
print "</div>\n";
- my ($have_search) = gitweb_check_feature('search');
+ my $have_search = gitweb_check_feature('search');
if (defined $project && $have_search) {
if (!defined $searchtext) {
$searchtext = "";
@@ -2961,7 +2979,7 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
$action .= "/".esc_url($project);
}
@@ -3084,7 +3102,7 @@ sub git_print_page_nav {
$arg{'tree'}{'hash'} = $treehead if defined $treehead;
$arg{'tree'}{'hash_base'} = $treebase if defined $treebase;
- my @actions = gitweb_check_feature('actions');
+ my @actions = gitweb_get_feature('actions');
my %repl = (
'%' => '%',
'n' => $project, # project name
@@ -3454,7 +3472,7 @@ sub is_patch_split {
sub git_difftree_body {
my ($difftree, $hash, @parents) = @_;
my ($parent) = $parents[0];
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
print "<div class=\"list_head\">\n";
if ($#{$difftree} > 10) {
print(($#{$difftree} + 1) . " files changed:\n");
@@ -3968,7 +3986,7 @@ sub git_project_list_body {
# actually uses global variable $project
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
my @projects = fill_project_list_info($projlist, $check_forks);
$order ||= $default_projects_order;
@@ -4428,7 +4446,7 @@ sub git_summary {
my @taglist = git_get_tags_list(16);
my @headlist = git_get_heads_list(16);
my @forklist;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if ($check_forks) {
@forklist = git_get_projects_list($project);
@@ -4457,7 +4475,7 @@ sub git_summary {
}
# Tag cloud
- my $show_ctags = (gitweb_check_feature('ctags'))[0];
+ my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
my $ctags = git_get_project_ctags($project);
my $cloud = git_populate_project_tagcloud($ctags);
@@ -4747,7 +4765,7 @@ sub git_blob {
$expires = "+1d";
}
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(500, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
@@ -4840,7 +4858,7 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $basedir = '';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
my @views_nav = ();
if (defined $file_name) {
@@ -5838,7 +5856,7 @@ insensitive).</p>
<dt><b>commit</b></dt>
<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
- my ($have_grep) = gitweb_check_feature('grep');
+ my $have_grep = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
@@ -5855,7 +5873,7 @@ EOT
<dt><b>committer</b></dt>
<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
- my ($have_pickaxe) = gitweb_check_feature('pickaxe');
+ my $have_pickaxe = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
print <<EOT;
<dt><b>pickaxe</b></dt>
@@ -5907,7 +5925,7 @@ sub git_shortlog {
sub git_feed {
my $format = shift || 'atom';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
# Atom: http://www.atomenabled.org/developers/syndication/
# RSS: http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
--
1.5.6.5
^ 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