* Re: [PATCH] Do not ignore hidden refs
From: Junio C Hamano @ 2006-11-18 18:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0611180933360.3692@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 18 Nov 2006, Petr Baudis wrote:
>>
>> Some of the ref manipulation tools (git-for-each-ref and git-show-ref in
>> particular) would not handle hidden (~ /^\./) refs. This may be an
>> acceptable or possibly even desirable behaviour for the ref walkers and
>> repackers, but git-show-ref hiddenrefname must work.
>
> No.
>
> Refnames MUST NOT start with a ".".
>
> It's not even about the traditional unix "hidden file" thing. It's simply
> a syntactic issue. A ref cannot start with a ".", because we use things
> like ".." and "..." to separate them.
We do not forbid a refname that ends with a ".", but I think it
was a mistake. We _can_ disambiguate the ones that begin with a
"." by saying "whatever..heads/.I-begin-with-dot", but not the
ones that end with "heads/I-end-with-dot...end-of-range".
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Junio C Hamano @ 2006-11-18 18:38 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550611180115j135746a1h916e8ae029d1374d@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> Time needed to execute git-peek-remote in my box with cold cache currently is:
>
> - git tree 2.347 ms
> - linux tree 2.144 ms
>
> And refs are *already* packed in both repos.
>
> Looking at packed-refs file, it contains something like:
>
> d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
> 4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
>
> while I would need something like git-peek-remote output,
>
> d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
> e0b0830726286287744cc9e1a629a534bbe75452 refs/tags/v1.4.3^{}
> 4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
> 1965efb1599f59b8e3380335d1fa395e2008a30b refs/tags/v1.4.3-rc1^{}
>
> Because the sha value a tag points to is needed to match against
> git-rev-list output so to identify tagged revisions.
>
> Would be possible to store in packed-refs also the dereferenced tag
> info, so that cold opening of a repository would be much faster?
>
> Just to give an idea, with warmed up cache, refs reading times are:
>
> - git tree 43 ms
> - linux tree 28 ms
>
> Thanks
> Marco
>
> P.S: In case it's not clear I don't suggest to read directly the
> packed-refs file with the added info, but always to use
> git-peek-remote that _would_ became much faster.
I think the question is why you would want to run peek-remote.
Do you use the ^{} peeled-onion information and if so how and
why?
^ permalink raw reply
* Re: Possible but in gitweb
From: Petr Baudis @ 2006-11-18 18:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <200611181901.31708.jnareb@gmail.com>
On Sat, Nov 18, 2006 at 07:01:30PM CET, Jakub Narebski wrote:
> Paolo Ciarrocchi wrote:
> > On 11/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >> Paolo Ciarrocchi wrote:
> >>>
> >>> Browsing the repo I reach the following URL
> >>> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=HEAD
> >>> that is not accessible.
> >>
> >> Because HEAD is master, not html, and there us no such file in master branch?
> >
> > Fair enough but then there should be no link in the web interface.
> > That sounds like a bug in the interface.
>
> Where did you find this link? On what page?
>
> "Browsing the repo" is not enough information to discover where
> there is a bug.
It's not really hard to find. :-)
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;h=b5e39498997930cd14ecddfe120f62c577ce2e28;hb=html
I think the link shouldn't be 'HEAD' but 'latest' and point to the
latest version in the currently browser branch.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Petr Baudis @ 2006-11-18 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, Git Mailing List
In-Reply-To: <7vmz6oeh2k.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 18, 2006 at 07:38:11PM CET, Junio C Hamano wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > Time needed to execute git-peek-remote in my box with cold cache currently is:
> >
> > - git tree 2.347 ms
> > - linux tree 2.144 ms
> >
> > And refs are *already* packed in both repos.
> >
> > Looking at packed-refs file, it contains something like:
> >
> > d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
> > 4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
> >
> > while I would need something like git-peek-remote output,
> >
> > d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
> > e0b0830726286287744cc9e1a629a534bbe75452 refs/tags/v1.4.3^{}
> > 4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
> > 1965efb1599f59b8e3380335d1fa395e2008a30b refs/tags/v1.4.3-rc1^{}
> >
> > Because the sha value a tag points to is needed to match against
> > git-rev-list output so to identify tagged revisions.
> >
> > Would be possible to store in packed-refs also the dereferenced tag
> > info, so that cold opening of a repository would be much faster?
> >
> > Just to give an idea, with warmed up cache, refs reading times are:
> >
> > - git tree 43 ms
> > - linux tree 28 ms
> >
> > Thanks
> > Marco
> >
> > P.S: In case it's not clear I don't suggest to read directly the
> > packed-refs file with the added info, but always to use
> > git-peek-remote that _would_ became much faster.
>
> I think the question is why you would want to run peek-remote.
> Do you use the ^{} peeled-onion information and if so how and
> why?
My wild guess would be to attach tags to the right commits in qgit?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Marco Costalba @ 2006-11-18 18:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20061118184345.GO7201@pasky.or.cz>
On 11/18/06, Petr Baudis <pasky@suse.cz> wrote:
> On Sat, Nov 18, 2006 at 07:38:11PM CET, Junio C Hamano wrote:
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >
> > > Time needed to execute git-peek-remote in my box with cold cache currently is:
> > >
> > > - git tree 2.347 ms
> > > - linux tree 2.144 ms
> > >
> > > And refs are *already* packed in both repos.
> > >
> > > Looking at packed-refs file, it contains something like:
> > >
> > > d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
> > > 4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
> > >
> > > while I would need something like git-peek-remote output,
> > >
> > > d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
> > > e0b0830726286287744cc9e1a629a534bbe75452 refs/tags/v1.4.3^{}
> > > 4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
> > > 1965efb1599f59b8e3380335d1fa395e2008a30b refs/tags/v1.4.3-rc1^{}
> > >
> > > Because the sha value a tag points to is needed to match against
> > > git-rev-list output so to identify tagged revisions.
> > >
> > > Would be possible to store in packed-refs also the dereferenced tag
> > > info, so that cold opening of a repository would be much faster?
> > >
> > > Just to give an idea, with warmed up cache, refs reading times are:
> > >
> > > - git tree 43 ms
> > > - linux tree 28 ms
> > >
> > > Thanks
> > > Marco
> > >
> > > P.S: In case it's not clear I don't suggest to read directly the
> > > packed-refs file with the added info, but always to use
> > > git-peek-remote that _would_ became much faster.
> >
> > I think the question is why you would want to run peek-remote.
> > Do you use the ^{} peeled-onion information and if so how and
> > why?
>
> My wild guess would be to attach tags to the right commits in qgit?
>
Yes. It is. From a list like
> > > d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
> > > e0b0830726286287744cc9e1a629a534bbe75452 refs/tags/v1.4.3^{}
> > > 4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
> > > 1965efb1599f59b8e3380335d1fa395e2008a30b refs/tags/v1.4.3-rc1^{}
>
qgit (but also gitk FWIK) extracts
e0b0830726286287744cc9e1a629a534bbe75452
1965efb1599f59b8e3380335d1fa395e2008a30b
Stores in a quick look-up container and then checks against loaded
commits to, as Pasky says, attach the nice green markers to tags.
^ permalink raw reply
* Re: [PATCH] Document git-runstatus
From: Junio C Hamano @ 2006-11-18 18:49 UTC (permalink / raw)
To: Sean
Cc: Rene Scharfe, Petr Baudis, Git Mailing List, Johannes Schindelin,
Jeff King
In-Reply-To: <BAYC1-PASMTP06C814AB518D7544770C01AEEF0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On Sat, 18 Nov 2006 16:04:43 +0100
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>
>> git-status is a wrapper around git-runstatus that takes the same
>> options as git-commit. It could have been named 'git-commit --dry-run'.
>
> What could be said in the docs as to when the use of one is preferred
> over the other?
You should treat git-runstatus the same way as you would treat
"git-merge-recursive". It strictly is a helper and you never
use it by itself.
It takes the parts that are too cumbersome to be enhanced in
shell script from the old git-status script, and rewrites it in
C.
"git-status $args" is to give a preview of the commit that would
be made with "git-commit $args" (where $args can be things like
-a, $paths...). The part that still remain as script in
git-commit and git-status performs the gory details of index
preparation for the next commit, and tells git-runstatus to show
the status of that index and the working tree relative to the
current HEAD.
Most notably, running "git-update-index --refresh" part is still
done in the script part that calls runstatus, so in a
cache-dirty but otherwise clean tree, running git-runstatus and
then git-status (without any parameters) in this order would
show cache dirty paths in the former but not in the latter (nor
after the latter runs once, since it calls --refresh).
^ permalink raw reply
* Re: [PATCH] Document git-runstatus
From: Sean @ 2006-11-18 18:49 UTC (permalink / raw)
To: gitzilla
Cc: Rene Scharfe, Petr Baudis, Junio C Hamano, Git Mailing List,
Johannes Schindelin, Jeff King
In-Reply-To: <455F4F06.3090902@gmail.com>
On Sat, 18 Nov 2006 10:20:54 -0800
A Large Angry SCM <gitzilla@gmail.com> wrote:
> Are you suggesting that all non section 1 man pages should not exist?
>
No... I was wrong to suggest there shouldn't be a man page.. I
guess my real concern was why this particular command was needed
at all.
Really, it's not the man pages that are the problem but rather
the large number of commands that are installed into the standard
path that should only ever be accessed as plumbing.
The plumbing-only commands should really be installed somewhere
else, and man pages for them need only be installed in a
-devel package, not in the standard install.
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Junio C Hamano @ 2006-11-18 19:04 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550611181047w6712774fkccc697d312b87c7e@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 11/18/06, Petr Baudis <pasky@suse.cz> wrote:
>> On Sat, Nov 18, 2006 at 07:38:11PM CET, Junio C Hamano wrote:
>> >
>> > I think the question is why you would want to run peek-remote.
>> > Do you use the ^{} peeled-onion information and if so how and
>> > why?
>>..
> Yes. It is. From a list like
>
>> > > d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
>> > > e0b0830726286287744cc9e1a629a534bbe75452 refs/tags/v1.4.3^{}
>> > > 4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
>> > > 1965efb1599f59b8e3380335d1fa395e2008a30b refs/tags/v1.4.3-rc1^{}
>>
> qgit (but also gitk FWIK) extracts
>
> e0b0830726286287744cc9e1a629a534bbe75452
> 1965efb1599f59b8e3380335d1fa395e2008a30b
>
> Stores in a quick look-up container and then checks against loaded
> commits to, as Pasky says, attach the nice green markers to tags.
Two answers.
A quick one that is to the point to solve "your" problem.
show-ref -d
Not a quick one but that may lead to solution of a similar issue
for wider audiences is...
I wonder how fast update-server-info is under the same condition
with your earlier timing.
I am not suggesting you to use update-server-info. The reason I
am wondering about it are:
(1) traditionally, "peek-remote ." has been the only way to get
to that information, so you have every right to keep doing
so;
(2) however, even with presense of packed-refs, upload-pack
that is invoked by peek-remote needs to consult unpacked
refs first and then fall back to packed-refs, and only
using the ^{} information "cached" in packed-refs file and
computing ^{} itself when dealing with unpacked refs means
more code, which we need to assess the pros-and-cons.
(3) another inefficiency of using "peek-remote ." is that it
spawns another process in the "remote" repo and talks with
it.
So storing this information making upload-pack to reuse it when
it can might make things go faster for other applications but
first I wanted to know how much overhead is incurred in the
extra upload-pack process, and time update-server-info needs to
prepare the info in .git/info/refs would be a way to get a rough
estimate for that (you subtract that from "peek-remote ." time).
^ permalink raw reply
* Re: Possible but in gitweb
From: Luben Tuikov @ 2006-11-18 19:06 UTC (permalink / raw)
To: Jakub Narebski, Paolo Ciarrocchi; +Cc: git
In-Reply-To: <200611181921.25873.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Paolo Ciarrocchi wrote:
> > On 11/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >> Paolo Ciarrocchi wrote:
> >>> On 11/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >>>> Paolo Ciarrocchi wrote:
> >>>>>
> >>>>> Browsing the repo I reach the following URL
> >>>>>
>
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=HEAD
> >>>>> that is not accessible.
> >>>>
> >>>> Because HEAD is master, not html, and there us no such file in master branch?
> >>>
> >>> Fair enough but then there should be no link in the web interface.
> >>> That sounds like a bug in the interface.
> >>
> >> Where did you find this link? On what page?
> >
> > Here:
> >
>
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;h=b5e39498997930cd14ecddfe120f62c577ce2e28;hb=html
> >
> > try now to press "HEAD"
>
> Ah, well. This could be considered a bug... but it can be not.
> The link is clearly marked "HEAD", so you are requesting HEAD
> version of the file... which does not exist.
>
> We could check if the file has HEAD version, but that is another
> call to git commands.
>
> What you want is the link to the tip of branch ("head", "top" or "tip")...
> you are welcome to add that (or replace "HEAD" link with that).
I think so too, at lest this is the intention: "head of line", "latest"
whatever you want to call it, in the branch context one is at.
Luben
> Tip: href(...,hash_base => $hash_base,...)
>
> --
> Jakub Narebski
> Poland
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Petr Baudis @ 2006-11-18 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmapdxki.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 18, 2006 at 08:27:09AM CET, Junio C Hamano wrote:
> I think, however, if we (collectively as all the Porcelain
> writers although I am not really one of them) are to support it,
> they should not make distinction to the core, and it should be
> handled with the agreed-upon convention.
I guess I agree.
> Personally I established a convention to treat heads/??/* as
> "private namespace" while using heads/* as public refs for my
> own work (I do that for git.git as people know, and I do that
> for my day job project as well). I do not think it is a great
> enough convention to be promoted as the official BCP, but it has
> been good enough for me, especially commands like "show-branch"
> and "tag -l" understands the shell-style filegrobs (e.g
> "show-branch master heads/??/*" would show what's yet to be
> polished and merged).
That's way too arbitrary for my taste, I think I needn't explain why.
:-)
What about leading underscore?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [PATCH] Move --pretty options into Documentation/pretty-formats.txt
From: Junio C Hamano @ 2006-11-18 19:39 UTC (permalink / raw)
To: Chris Riddoch; +Cc: git
In-Reply-To: <11638310552964-git-send-email-chris@syntacticsugar.org>
Chris Riddoch <chris@syntacticsugar.org> writes:
> This describes all the pretty-formats currently listed in the cmit_fmt
> enum in commit.h, and also briefly describes the presence and format
> of the 'Merge: ' line in some pretty formats.
Thanks. Getting much warmer.
> @@ -0,0 +1,56 @@
> +--pretty[='<format>']::
> +
> + Pretty-prints the details of a commit. The default format is
> + 'medium'. If the commit is a merge, and the pretty-format is
> + not 'oneline', 'email' or 'raw', an additional line is
> + inserted before the 'Author:' line. This line begins with
> + "Merge: " and the sha1s of each parent commit are printed,
> + separated by spaces. These sha1's are abbreviated to 8
> + characters; use the --abbrev or --no-abbrev options to alter
> + this behavior.
The default abbreviation depends on the command. Porcelain-ish
commands default to abbreviate but plumbing commands tend to
show unabbreviated.
A few other things to note.
- When --parents option is in effect, you will see the list of
parent commits on "commit" line after the commit itself.
- The list of parents shown on "Merge:" may be different from
the true parents when the command's revision traversal is
limited with paths parameters; they show simplified parents.
This rule also applies to the parents on the "commit" line
under --parents option.
- The history simplification does not affect "parent" line of
"--pretty=raw" format. You can use this to find the
simplified parents from "commit" line and the true parents
from "parent" lines with --pretty=raw.
Here are some examples from git.git repository to illustrate
differences between various combinations.
C=2a54323
git diff-tree -s -m --pretty=$format $C
git diff-tree -s -m --pretty=$format --abbrev $C
git diff-tree -s -m --pretty=$format --abbrev --abbrev-commit $C
git log --pretty=$format --parents -n 1 --abbrev-commit $C
git log --pretty=$format --parents -n 1 $C
git log --pretty=$format --parents -n 1 $C -- t/
^ permalink raw reply
* [PATCH] Documentation: Define symref and update HEAD description
From: Petr Baudis @ 2006-11-18 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
HEAD was still described as a symlink instead of a symref.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/glossary.txt | 7 +++++++
Documentation/repository-layout.txt | 14 +++++++++-----
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 7e560b0..894883d 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -282,6 +282,13 @@ SCM::
SHA1::
Synonym for object name.
+symref::
+ Symbolic reference: instead of containing the SHA1 id itself, it
+ is of the format 'ref: refs/some/thing' and when referenced, it
+ recursively dereferences to this reference. 'HEAD' is a prime
+ example of a symref. Symbolic references are manipulated with
+ the gitlink:git-symbolic-ref[1] command.
+
topic branch::
A regular git branch that is used by a developer to
identify a conceptual line of development. Since branches
diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt
index 275d18b..fd9f406 100644
--- a/Documentation/repository-layout.txt
+++ b/Documentation/repository-layout.txt
@@ -70,12 +70,16 @@ refs/tags/`name`::
object, or a tag object that points at a commit object).
HEAD::
- A symlink of the form `refs/heads/'name'` to point at
- the current branch, if exists. It does not mean much if
- the repository is not associated with any working tree
+ A symref (see glossary) to the `refs/heads/` namespace
+ describing the currently active branch. It does not mean
+ much if the repository is not associated with any working tree
(i.e. a 'bare' repository), but a valid git repository
- *must* have such a symlink here. It is legal if the
- named branch 'name' does not (yet) exist.
+ *must* have the HEAD file; some porcelains may use it to
+ guess the designated "default" branch of the repository
+ (usually 'master'). It is legal if the named branch
+ 'name' does not (yet) exist. In some legacy setups, it is
+ a symbolic link instead of a symref, but this has been
+ deprecated long ago.
branches::
^ permalink raw reply related
* Re: [PATCH] Do not ignore hidden refs
From: Junio C Hamano @ 2006-11-18 19:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061118192830.GP7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Sat, Nov 18, 2006 at 08:27:09AM CET, Junio C Hamano wrote:
>> I think, however, if we (collectively as all the Porcelain
>> writers although I am not really one of them) are to support it,
>> they should not make distinction to the core, and it should be
>> handled with the agreed-upon convention.
>
> I guess I agree.
>
>> ... I do not think it is a great
>> enough convention to be promoted as the official BCP, but it has
>> been good enough for me, ...
>
> That's way too arbitrary for my taste, I think I needn't explain why.
Because _I_ explained why already ;-).
> What about leading underscore?
I would rather prefer to do refs/{heads,private}/ and allow
checkout to treat either of them as branches. We are talking
about allowing checkout to go to a non-branch by storing a raw
commit object name in HEAD instead of leaving it as a symref, so
we know we are going to touch that area already.
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Petr Baudis @ 2006-11-18 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejs0cz5s.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 18, 2006 at 08:50:23PM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > On Sat, Nov 18, 2006 at 08:27:09AM CET, Junio C Hamano wrote:
> >> ... I do not think it is a great
> >> enough convention to be promoted as the official BCP, but it has
> >> been good enough for me, ...
> >
> > That's way too arbitrary for my taste, I think I needn't explain why.
>
> Because _I_ explained why already ;-).
Oops. ;-) Me too sloppy today, sorry.
> > What about leading underscore?
>
> I would rather prefer to do refs/{heads,private}/ and allow
> checkout to treat either of them as branches. We are talking
> about allowing checkout to go to a non-branch by storing a raw
> commit object name in HEAD instead of leaving it as a symref, so
> we know we are going to touch that area already.
Cogito _heavily_ assumes on a lot of places that heads live in
refs/heads/ and tags live in refs/tags/. Besides, I think private tags
are much more useful to support than private heads (not that you would
necessarily make more private tags than private heads, but you are more
likely to want tags autopushed than heads; or perhaps that just in my
head?). So what about refs/{heads,tags}/private/? :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [PATCH] Documentation: Define symref and update HEAD description
From: Junio C Hamano @ 2006-11-18 19:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061118194408.27106.65771.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> HEAD was still described as a symlink instead of a symref.
>...
> HEAD::
> + A symref (see glossary) to the `refs/heads/` namespace
> + describing the currently active branch. It does not mean
> + much if the repository is not associated with any working tree
> (i.e. a 'bare' repository), but a valid git repository
> + *must* have the HEAD file; some porcelains may use it to
> + guess the designated "default" branch of the repository
> + (usually 'master'). It is legal if the named branch
> + 'name' does not (yet) exist. In some legacy setups, it is
> + a symbolic link instead of a symref, but this has been
> + deprecated long ago.
We fully support dealing with repositories with symlinked HEAD,
and will continue to do so; I do not think we ever talked about
deprecating it. Public "distribution point" repositories that
have been established long ago that do not have reason to switch
HEAD to point at different branch still have symlinked HEAD and
they should continue to work.
What we _don't_ do these days is to set up new repositories with
symlinked HEAD, but that does not have anything to do with
deprecating symlinked HEAD.
^ permalink raw reply
* Re: [PATCH] Document git-runstatus
From: Sean @ 2006-11-18 20:04 UTC (permalink / raw)
To: Git Mailing List
Cc: A Large Angry SCM, Rene Scharfe, Petr Baudis, Junio C Hamano,
Johannes Schindelin, Jeff King
In-Reply-To: <455F60EA.2080009@gmail.com>
On Sat, 18 Nov 2006 11:37:14 -0800
A Large Angry SCM <gitzilla@gmail.com> wrote:
> I disagree. If a command is install on a system, it's man
> pages/documentation should also be installed.
Well this isn't a huge issue. One point you made though that struck
a chord is that many of the commands should probably not be in
section 1.
> I'm also not convinced that there are a "large number of commands [...]
> that should only ever be accessed as plumbing". I am convinced, however,
> that there are a number of relatively low level commands with poor user
> interfaces that are useful on their own.
Is there really a reason for a git user to access these from the
command line rather than a script:
commit-tree, diff-files, diff-index, diff-tree, for-each-ref,
hash-object, http-fetch, http-push, index-pack, local-fetch,
merge-base, merge-index, merge-octopus, merge-one-file, merge-ours,
merge-recur, merge-recursive, merge-recursive-old, merge-resolve,
merge-stupid, merge-tree, receive-pack, runstatus, ssh-fetch, ssh-pull,
ssh-push, ssh-upload, symbolic-ref, unpack-file, unpack-objects,
update-ref, upload-archive, upload-pack, upload-tar, write-tree
Not a complete list, and maybe i overlooked something in there
that is needed from the command line, but for the most part
these could be installed somewhere other than the users path.
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Junio C Hamano @ 2006-11-18 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejs0cz5s.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> What about leading underscore?
>
> I would rather prefer to do refs/{heads,private}/ and allow
> checkout to treat either of them as branches. We are talking
> about allowing checkout to go to a non-branch by storing a raw
> commit object name in HEAD instead of leaving it as a symref, so
> we know we are going to touch that area already.
Oops. Consider this rescinded. I myself already talked about
"not necessarily just public vs private". Silly me.
I think this is related to the common gripe of "why can't Junio
mark pu to be rewinded in his public repository". We should be
able to leave the branch grouping to users.
Not just public vs private, but I can see an organization that
uses something like this:
heads/1.5/{maint,master,next,pu} are to maintain and advance 1.5 series
heads/1.5/topics/{foo,bar} are topics applicable to 1.5
heads/2.0/{maint,master,next,pu} are to maintain and advance 2.0 series
heads/2.0/topics/{foo,bar} are topics applicable only to 2.0
heads/topics/{frotz,nitfol} are topics applicable to both
and wanting to view all the topics, only things related to 1.5,
etc. So Porcelains _can_ enforce their own policies to arrange
things differently but we should also be able to let the users
(and project branch naming policy) to do what we've been talking
about by saying:
use heads/private/ for your own stuff. And have
configuration that says "heads/private/" are private
branches that are not subject to default
pushing/pulling.
The real instruction from the project would say what the syntax
for telling that to git but I think you got the idea...
^ permalink raw reply
* Re: [PATCH] Documentation: Define symref and update HEAD description
From: Petr Baudis @ 2006-11-18 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64dccyx2.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 18, 2006 at 08:55:37PM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > HEAD was still described as a symlink instead of a symref.
> >...
> > HEAD::
> > + A symref (see glossary) to the `refs/heads/` namespace
> > + describing the currently active branch. It does not mean
> > + much if the repository is not associated with any working tree
> > (i.e. a 'bare' repository), but a valid git repository
> > + *must* have the HEAD file; some porcelains may use it to
> > + guess the designated "default" branch of the repository
> > + (usually 'master'). It is legal if the named branch
> > + 'name' does not (yet) exist. In some legacy setups, it is
> > + a symbolic link instead of a symref, but this has been
> > + deprecated long ago.
>
> We fully support dealing with repositories with symlinked HEAD,
> and will continue to do so; I do not think we ever talked about
> deprecating it. Public "distribution point" repositories that
> have been established long ago that do not have reason to switch
> HEAD to point at different branch still have symlinked HEAD and
> they should continue to work.
>
> What we _don't_ do these days is to set up new repositories with
> symlinked HEAD, but that does not have anything to do with
> deprecating symlinked HEAD.
That's true, perhaps "obsoleted" is a better word.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-11-18 22:24 UTC (permalink / raw)
To: git
Executive Summary
- 'maint' and 'master' are the same, since we are still in
"v1.4.4 fix" mood right now. A maintenance release v1.4.4.1
should follow soonish.
- 'next' has a few 'these are obviously the right things to me
but I want a bit of cheering-up before pushing them out, and
they can wait until the dust settles after early fixes to
v1.4.4 anyway' changes.
- 'pu' has the shallow clone WIP and a half-finished rewrite of
git branch in C, both by Johannes. Both needs a bit more
polishing and confidence building before going into 'next',
and given the recent discussion of enhancing branch
management for pulls/pushes, it might be easier to drop the
latter for now.
I should also bring Shawn's piecemeal-mmap into 'pu'; I've
looked at his code and it mostly looked sane.
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.4.4 release. The
'master' is the same as 'maint' right now.
Alexandre Julliard:
gitweb: Put back shortlog instead of graphiclog in the project list.
Jim Meyering:
Run "git repack -a -d" once more at end, if there's 1MB or more of
not-packed data.
Johannes Schindelin:
Seek back to current filepos when mmap()ing with NO_MMAP
Junio C Hamano:
git-checkout: do not allow -f and -m at the same time.
git-checkout: allow pathspec to recover lost working tree directory
convert-objects: set _XOPEN_SOURCE to 600
Linus Torvalds:
git-pull: allow pulling into an empty repository
"git fmt-merge-msg" SIGSEGV
Petr Baudis:
Fix git-for-each-refs broken for tags
git-apply: Documentation typo fix
Documentation: Define symref and update HEAD description
Rene Scharfe:
sparse fix: non-ANSI function declaration
sparse fix: Using plain integer as NULL pointer
git-apply: slightly clean up bitfield usage
Document git-runstatus
* The 'next' branch, in addition, has these.
Junio C Hamano
upload-pack: stop the other side when they have more roots than we do.
apply --numstat: mark binary diffstat with - -, not 0 0
pack-objects: tweak "do not even attempt delta" heuristics
* The 'pu' branch, in addition, has these.
Alexandre Julliard (1):
Shallow clone: do not ignore shallowness when following tags
Jakub Narebski (1):
gitweb: New improved formatting of chunk header in diff
Johannes Schindelin (6):
upload-pack: no longer call rev-list
support fetching into a shallow repository
allow cloning a repository "shallowly"
allow deepening of a shallow repository
add tests for shallow stuff
Build in shortlog
Junio C Hamano (11):
git-branch -a: show both local and remote tracking branches.
git-commit: show --summary after successful commit.
para-walk: walk n trees, index and working tree in parallel
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
rev-list --left-right
blame: --show-stats for easier optimization work.
gitweb: steal loadavg throttle from kernel.org
We should make sure that the protocol is still extensible.
Why does it mean we do not have to register shallow if we have one?
Why didn't we mark want_obj as ~UNINTERESTING in the old code?
shallow clone: unparse and reparse an unshallowed commit
^ permalink raw reply
* [PATCH 2/5] gitweb: Buffer diff header to deal with split patches + git_patchset_body refactoring
From: Jakub Narebski @ 2006-11-18 22:35 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1163889342877-git-send-email-jnareb@gmail.com>
There are some cases when one line from "raw" git-diff output (raw format)
corresponds to more than one patch in the patchset git-diff output. To deal
with this buffer git diff header and extended diff header (everything up to
actual patch) to check from information from "index <hash>..<hash>" extended
header line if the patch corresponds to the same or next difftree raw line.
This could also be used to gather information needed for hyperlinking, and
used for printing gitweb quoted filenames, from extended diff header instead
of raw git-diff output.
While at it, refactor git_patchset_body subroutine from the event-driven,
AWK-like state-machine parsing to sequential parsing: for each patch
parse (and output) git diff header, parse extended diff header, parse two-line
from-file/to-file diff header, parse patch itself; patch ends with the end
of input [file] or the line matching m/^diff /.
For better understanding the code, there were added assertions in the
comments a la Carp::Assert module. Just in case there is commented out code
dealing with unexpected end of input (should not happen, hence commented
out).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
While starting to write buffering part of this patch I have realized
that git_patchset_body needs refactoring. I think it is now much more
readable, at least for people who know the patch format.
gitweb/gitweb.perl | 235 ++++++++++++++++++++++++++++++----------------------
1 files changed, 136 insertions(+), 99 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b2482fe..bf58c3b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2202,31 +2202,56 @@ sub git_patchset_body {
my ($fd, $difftree, $hash, $hash_parent) = @_;
my $patch_idx = 0;
- my $in_header = 0;
- my $patch_found = 0;
+ my $patch_line;
my $diffinfo;
my (%from, %to);
+ my ($from_id, $to_id);
print "<div class=\"patchset\">\n";
- LINE:
- while (my $patch_line = <$fd>) {
+ # skip to first patch
+ while ($patch_line = <$fd>) {
chomp $patch_line;
- if ($patch_line =~ m/^diff /) { # "git diff" header
- # beginning of patch (in patchset)
- if ($patch_found) {
- # close extended header for previous empty patch
- if ($in_header) {
- print "</div>\n" # class="diff extended_header"
- }
- # close previous patch
- print "</div>\n"; # class="patch"
- } else {
- # first patch in patchset
- $patch_found = 1;
+ last if ($patch_line =~ m/^diff /);
+ }
+
+ PATCH:
+ while ($patch_line) {
+ my @diff_header;
+
+ # git diff header
+ #assert($patch_line =~ m/^diff /) if DEBUG;
+ #assert($patch_line !~ m!$/$!) if DEBUG; # is chomp-ed
+ push @diff_header, $patch_line;
+
+ # extended diff header
+ EXTENDED_HEADER:
+ while ($patch_line = <$fd>) {
+ chomp $patch_line;
+
+ last EXTENDED_HEADER if ($patch_line =~ m/^--- /);
+
+ if ($patch_line =~ m/^index ([0-9a-fA-F]{40})..([0-9a-fA-F]{40})/) {
+ $from_id = $1;
+ $to_id = $2;
}
- print "<div class=\"patch\" id=\"patch". ($patch_idx+1) ."\">\n";
+
+ push @diff_header, $patch_line;
+ }
+ #last PATCH unless $patch_line;
+ my $last_patch_line = $patch_line;
+
+ # check if current patch belong to current raw line
+ # and parse raw git-diff line if needed
+ if (defined $diffinfo &&
+ $diffinfo->{'from_id'} eq $from_id &&
+ $diffinfo->{'to_id'} eq $to_id) {
+ # this is split patch
+ print "<div class=\"patch cont\">\n";
+ } else {
+ # advance raw git-diff output if needed
+ $patch_idx++ if defined $diffinfo;
# read and prepare patch information
if (ref($difftree->[$patch_idx]) eq "HASH") {
@@ -2247,100 +2272,112 @@ sub git_patchset_body {
hash=>$diffinfo->{'to_id'},
file_name=>$to{'file'});
}
- $patch_idx++;
-
- # print "git diff" header
- $patch_line =~ s!^(diff (.*?) )"?a/.*$!$1!;
- if ($from{'href'}) {
- $patch_line .= $cgi->a({-href => $from{'href'}, -class => "path"},
- 'a/' . esc_path($from{'file'}));
- } else { # file was added
- $patch_line .= 'a/' . esc_path($from{'file'});
- }
- $patch_line .= ' ';
- if ($to{'href'}) {
- $patch_line .= $cgi->a({-href => $to{'href'}, -class => "path"},
- 'b/' . esc_path($to{'file'}));
- } else { # file was deleted
- $patch_line .= 'b/' . esc_path($to{'file'});
- }
-
- print "<div class=\"diff header\">$patch_line</div>\n";
- print "<div class=\"diff extended_header\">\n";
- $in_header = 1;
- next LINE;
+ # this is first patch for raw difftree line with $patch_idx index
+ # we index @$difftree array from 0, but number patches from 1
+ print "<div class=\"patch\" id=\"patch". ($patch_idx+1) ."\">\n";
}
- if ($in_header) {
- if ($patch_line !~ m/^---/) {
- # match <path>
- if ($patch_line =~ s!^((copy|rename) from ).*$!$1! && $from{'href'}) {
- $patch_line .= $cgi->a({-href=>$from{'href'}, -class=>"path"},
- esc_path($from{'file'}));
- }
- if ($patch_line =~ s!^((copy|rename) to ).*$!$1! && $to{'href'}) {
- $patch_line = $cgi->a({-href=>$to{'href'}, -class=>"path"},
- esc_path($to{'file'}));
- }
- # match <mode>
- if ($patch_line =~ m/\s(\d{6})$/) {
- $patch_line .= '<span class="info"> (' .
- file_type_long($1) .
- ')</span>';
+ # print "git diff" header
+ $patch_line = shift @diff_header;
+ $patch_line =~ s!^(diff (.*?) )"?a/.*$!$1!;
+ if ($from{'href'}) {
+ $patch_line .= $cgi->a({-href => $from{'href'}, -class => "path"},
+ 'a/' . esc_path($from{'file'}));
+ } else { # file was added
+ $patch_line .= 'a/' . esc_path($from{'file'});
+ }
+ $patch_line .= ' ';
+ if ($to{'href'}) {
+ $patch_line .= $cgi->a({-href => $to{'href'}, -class => "path"},
+ 'b/' . esc_path($to{'file'}));
+ } else { # file was deleted
+ $patch_line .= 'b/' . esc_path($to{'file'});
+ }
+ print "<div class=\"diff header\">$patch_line</div>\n";
+
+ # print extended diff header
+ print "<div class=\"diff extended_header\">\n" if (@diff_header > 0);
+ EXTENDED_HEADER:
+ foreach $patch_line (@diff_header) {
+ # match <path>
+ if ($patch_line =~ s!^((copy|rename) from ).*$!$1! && $from{'href'}) {
+ $patch_line .= $cgi->a({-href=>$from{'href'}, -class=>"path"},
+ esc_path($from{'file'}));
+ }
+ if ($patch_line =~ s!^((copy|rename) to ).*$!$1! && $to{'href'}) {
+ $patch_line = $cgi->a({-href=>$to{'href'}, -class=>"path"},
+ esc_path($to{'file'}));
+ }
+ # match <mode>
+ if ($patch_line =~ m/\s(\d{6})$/) {
+ $patch_line .= '<span class="info"> (' .
+ file_type_long($1) .
+ ')</span>';
+ }
+ # match <hash>
+ if ($patch_line =~ m/^index/) {
+ my ($from_link, $to_link);
+ if ($from{'href'}) {
+ $from_link = $cgi->a({-href=>$from{'href'}, -class=>"hash"},
+ substr($diffinfo->{'from_id'},0,7));
+ } else {
+ $from_link = '0' x 7;
}
- # match <hash>
- if ($patch_line =~ m/^index/) {
- my ($from_link, $to_link);
- if ($from{'href'}) {
- $from_link = $cgi->a({-href=>$from{'href'}, -class=>"hash"},
- substr($diffinfo->{'from_id'},0,7));
- } else {
- $from_link = '0' x 7;
- }
- if ($to{'href'}) {
- $to_link = $cgi->a({-href=>$to{'href'}, -class=>"hash"},
- substr($diffinfo->{'to_id'},0,7));
- } else {
- $to_link = '0' x 7;
- }
- my ($from_id, $to_id) = ($diffinfo->{'from_id'}, $diffinfo->{'to_id'});
- $patch_line =~ s!$from_id\.\.$to_id!$from_link..$to_link!;
+ if ($to{'href'}) {
+ $to_link = $cgi->a({-href=>$to{'href'}, -class=>"hash"},
+ substr($diffinfo->{'to_id'},0,7));
+ } else {
+ $to_link = '0' x 7;
}
- print $patch_line . "<br/>\n";
-
- } else {
- #$in_header && $patch_line =~ m/^---/;
- print "</div>\n"; # class="diff extended_header"
- $in_header = 0;
+ #affirm {
+ # my ($from_hash, $to_hash) =
+ # ($patch_line =~ m/^index ([0-9a-fA-F]{40})..([0-9a-fA-F]{40})/);
+ # my ($from_id, $to_id) =
+ # ($diffinfo->{'from_id'}, $diffinfo->{'to_id'});
+ # ($from_hash eq $from_id) && ($to_hash eq $to_id);
+ #} if DEBUG;
+ my ($from_id, $to_id) = ($diffinfo->{'from_id'}, $diffinfo->{'to_id'});
+ $patch_line =~ s!$from_id\.\.$to_id!$from_link..$to_link!;
+ }
+ print $patch_line . "<br/>\n";
+ }
+ print "</div>\n" if (@diff_header > 0); # class="diff extended_header"
+
+ # from-file/to-file diff header
+ $patch_line = $last_patch_line;
+ #assert($patch_line =~ m/^---/) if DEBUG;
+ if ($from{'href'}) {
+ $patch_line = '--- a/' .
+ $cgi->a({-href=>$from{'href'}, -class=>"path"},
+ esc_path($from{'file'}));
+ }
+ print "<div class=\"diff from_file\">$patch_line</div>\n";
- if ($from{'href'}) {
- $patch_line = '--- a/' .
- $cgi->a({-href=>$from{'href'}, -class=>"path"},
- esc_path($from{'file'}));
- }
- print "<div class=\"diff from_file\">$patch_line</div>\n";
+ $patch_line = <$fd>;
+ #last PATCH unless $patch_line;
+ chomp $patch_line;
- $patch_line = <$fd>;
- chomp $patch_line;
+ #assert($patch_line =~ m/^+++/) if DEBUG;
+ if ($to{'href'}) {
+ $patch_line = '+++ b/' .
+ $cgi->a({-href=>$to{'href'}, -class=>"path"},
+ esc_path($to{'file'}));
+ }
+ print "<div class=\"diff to_file\">$patch_line</div>\n";
- #$patch_line =~ m/^+++/;
- if ($to{'href'}) {
- $patch_line = '+++ b/' .
- $cgi->a({-href=>$to{'href'}, -class=>"path"},
- esc_path($to{'file'}));
- }
- print "<div class=\"diff to_file\">$patch_line</div>\n";
+ # the patch itself
+ LINE:
+ while ($patch_line = <$fd>) {
+ chomp $patch_line;
- }
+ next PATCH if ($patch_line =~ m/^diff /);
- next LINE;
+ print format_diff_line($patch_line);
}
- print format_diff_line($patch_line);
+ } continue {
+ print "</div>\n"; # class="patch"
}
- print "</div>\n" if $in_header; # extended header
-
- print "</div>\n" if $patch_found; # class="patch"
print "</div>\n"; # class="patchset"
}
--
1.4.3.4
^ permalink raw reply related
* [PATCH 1/5] gitweb: Protect against possible warning in git_commitdiff
From: Jakub Narebski @ 2006-11-18 22:35 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1163889342877-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I'm not sure _when_ this eror (warning) occur, as it happened to me
once, but I couldn't repeat it; but I didn't try too hard.
I think it is better coding practice, and more readable.
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7587595..b2482fe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3731,7 +3731,8 @@ sub git_commitdiff {
$hash_parent, $hash, "--"
or die_error(undef, "Open git-diff-tree failed");
- while (chomp(my $line = <$fd>)) {
+ while (my $line = <$fd>) {
+ chomp $line;
# empty line ends raw part of diff-tree output
last unless $line;
push @difftree, $line;
--
1.4.3.4
^ permalink raw reply related
* [PATCH 3/5] gitweb: New improved formatting of chunk header in diff
From: Jakub Narebski @ 2006-11-18 22:35 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1163889342877-git-send-email-jnareb@gmail.com>
If we have provided enough info, and diff is not combined diff,
and if provided diff line is chunk header, then:
* split chunk header into .chunk_info and .section span elements,
first containing proper chunk header, second section heading
(aka. which function), for separate styling: the proper chunk
header is on non-white background, section heading part uses
slightly lighter color.
* hyperlink from-file-range to starting line of from-file, if file
was not created.
* hyperlink to-file-range to starting line of to-file, if file
was not deleted.
Links are of invisible variety (and "list" class).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This version deals correctly with hunks of form "@@ -n +m,l @@" and
friends. The number of lines in from/to part ($from_lines/$to_lines
variables) is not used.
gitweb/gitweb.css | 13 +++++++++++++
gitweb/gitweb.perl | 23 ++++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 974b47f..7177c6e 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -334,11 +334,13 @@ div.diff.extended_header {
padding: 2px 0px 2px 0px;
}
+div.diff a.list,
div.diff a.path,
div.diff a.hash {
text-decoration: none;
}
+div.diff a.list:hover,
div.diff a.path:hover,
div.diff a.hash:hover {
text-decoration: underline;
@@ -362,14 +364,25 @@ div.diff.rem {
color: #cc0000;
}
+div.diff.chunk_header a,
div.diff.chunk_header {
color: #990099;
+}
+div.diff.chunk_header {
border: dotted #ffe0ff;
border-width: 1px 0px 0px 0px;
margin-top: 2px;
}
+div.diff.chunk_header span.chunk_info {
+ background-color: #ffeeff;
+}
+
+div.diff.chunk_header span.section {
+ color: #aa22aa;
+}
+
div.diff.incomplete {
color: #cccccc;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bf58c3b..eadaa31 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -874,8 +874,10 @@ sub format_subject_html {
}
}
+# format patch (diff) line (rather not to be used for diff headers)
sub format_diff_line {
my $line = shift;
+ my ($from, $to) = @_;
my $char = substr($line, 0, 1);
my $diff_class = "";
@@ -891,6 +893,25 @@ sub format_diff_line {
$diff_class = " incomplete";
}
$line = untabify($line);
+ if ($from && $to && $line =~ m/^\@{2} /) {
+ my ($from_text, $from_start, $from_lines, $to_text, $to_start, $to_lines, $section) =
+ $line =~ m/^\@{2} (-(\d+)(?:,(\d+))?) (\+(\d+)(?:,(\d+))?) \@{2}(.*)$/;
+
+ $from_lines = 0 unless defined $from_lines;
+ $to_lines = 0 unless defined $to_lines;
+
+ if ($from->{'href'}) {
+ $from_text = $cgi->a({-href=>"$from->{'href'}#l$from_start",
+ -class=>"list"}, $from_text);
+ }
+ if ($to->{'href'}) {
+ $to_text = $cgi->a({-href=>"$to->{'href'}#l$to_start",
+ -class=>"list"}, $to_text);
+ }
+ $line = "<span class=\"chunk_info\">@@ $from_text $to_text @@</span>" .
+ "<span class=\"section\">" . esc_html($section, -nbsp=>1) . "</span>";
+ return "<div class=\"diff$diff_class\">$line</div>\n";
+ }
return "<div class=\"diff$diff_class\">" . esc_html($line, -nbsp=>1) . "</div>\n";
}
@@ -2372,7 +2393,7 @@ sub git_patchset_body {
next PATCH if ($patch_line =~ m/^diff /);
- print format_diff_line($patch_line);
+ print format_diff_line($patch_line, \%from, \%to);
}
} continue {
--
1.4.3.4
^ permalink raw reply related
* [PATCH 0/5] gitweb: New patchset view corrections and improvements, and few other things
From: Jakub Narebski @ 2006-11-18 22:35 UTC (permalink / raw)
To: git
Table of contents:
[PATCH 1/5] gitweb: Protect against possible warning in git_commitdiff
[PATCH 2/5] gitweb: Buffer diff header to deal with split patches
+ git_patchset_body refactoring
[PATCH 3/5] gitweb: New improved formatting of chunk header in diff
[PATCH 4/5] gitweb: Default to $hash_base or HEAD for $hash
in "commit" and "commitdiff"
[PATCH 5/5] gitweb: Add an option to href() to return full URL
Diffstat:
gitweb/gitweb.css | 13 +++
gitweb/gitweb.perl | 264 ++++++++++++++++++++++++++++++++--------------------
2 files changed, 176 insertions(+), 101 deletions(-)
--
Jakub Narebski
^ permalink raw reply
* [PATCH 5/5] gitweb: Add an option to href() to return full URL
From: Jakub Narebski @ 2006-11-18 22:35 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1163889342877-git-send-email-jnareb@gmail.com>
href subroutine by default generates absolute URL (generated using
CGI::url(-absolute=>1), and saved in $my_uri) using $my_uri as base;
add an option to generate full URL using $my_url as base.
New feature usage: href(..., -full=>1)
To be used in web feeds (RSS, Atom, OPML) and other places which need
full URL rather than absolute or relative.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5875ba0..8739501 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -459,7 +459,8 @@ exit;
sub href(%) {
my %params = @_;
- my $href = $my_uri;
+ # default is to use -absolute url() i.e. $my_uri
+ my $href = $params{-full} ? $my_url : $my_uri;
# XXX: Warning: If you touch this, check the search form for updating,
# too.
--
1.4.3.4
^ permalink raw reply related
* [PATCH 4/5] gitweb: Default to $hash_base or HEAD for $hash in "commit" and "commitdiff"
From: Jakub Narebski @ 2006-11-18 22:35 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1163889342877-git-send-email-jnareb@gmail.com>
Set $hash parameter to $hash_base || "HEAD" if it is not set (if it is
not true to be more exact). This allows [hand-edited] URLs with 'action'
"commit" or "commitdiff" but without 'hash' parameter.
If there is 'h' (hash) parameter provided, then gitweb tries
to use this. HEAD is used _only_ if nether hash, nor hash_base
are provided, i.e. for URL like below
URL?p=project.git;a=commit
i.e. without neither 'h' nor 'hb'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index eadaa31..5875ba0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3450,6 +3450,7 @@ sub git_log {
}
sub git_commit {
+ $hash ||= $hash_base || "HEAD";
my %co = parse_commit($hash);
if (!%co) {
die_error(undef, "Unknown commit object");
@@ -3727,6 +3728,7 @@ sub git_blobdiff_plain {
sub git_commitdiff {
my $format = shift || 'html';
+ $hash ||= $hash_base || "HEAD";
my %co = parse_commit($hash);
if (!%co) {
die_error(undef, "Unknown commit object");
--
1.4.3.4
^ 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