* Rename detection at git log
From: Alexander Litvinov @ 2006-11-20 5:57 UTC (permalink / raw)
To: git
How can I see all changes for one file ? Including renames/copies ? Currently
I don't known how to see them :
> mkdir 1 && cd 1 && git init-db
defaulting to local storage area
> date >> a
> git add a
> git commit -a -m "1"
Committing initial tree c47d83a6544612309aad57519ca831cf62a489d5
> mkdir b
> git mv a b/
> git commit -a -m "2"
> PAGER=cat git log -M -C --pretty=oneline b/a
3b591f7147ee8dbe15fdf456db5730072d41bed8 2
>
At lastline I would like to see two commits : renaming a -> b/a and creation
of a. By the way, how can I see commit message with git log ?
Thanks for help.
^ permalink raw reply
* Re: Feature request: git-pull -e/--edit
From: Junio C Hamano @ 2006-11-20 3:21 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061120024308.18620.qmail@science.horizon.com>
linux@horizon.com writes:
>> How often is this desired, when the merge is clean?
>
> Well, if I could quote your own words:
>
>>> I use "git pull . topicA topicB" for a tetrapus, so that is not
>>> a reason for me, but when a topicA's older parts are worthy to
>>> be in 'next' while later parts are not yet, I often do (on 'next'):
>>>
>>> git merge "Merge early part of branch 'topicA'" HEAD topicA~3
>
> I can't speak from personal experience, but a merge can bring in a lot
> of changes, and sometimes the auto-generated message doesn't say quite
> as much as you'd like.
That is more or less irrelevant example. I was only saying that
it is a workaround to emulate "git pull . topicA~3"; if that
form worked, I would keep the automated fmt-merge-msg output
that is currently recorded in the merge and I do not see any
need to edit it further.
> (Indeed, it might be nice to come up with a way of including a piece of
> the "please pull" e-mail, similar to the way that git-applypatch works.)
That is a lot more relevant example. For example, I could
imagine that Linus coming up with a wrapper that is fed a series
of e-mails and:
* if it is a patch, run git-applymbox on it as before,
* if it is a pull request, then extract the URL and branch, run
"git pull" on that, match the "diff ORIG_HEAD" output against
what is in the pull request and,
- warn if there are huge discrepancies;
- otherwise annotate the commit message with the explanation
of the series taken from the pull request message.
But even in that workflow, "annotate the commit" comes after
pull happens and the merge result is verified, so I do not quite
see "commit --amend" as a "workaround" as you said.
Having said that, I think the real reason that the whole "merge"
message generation feels awkward comes from the historical
division of labor between pull and merge.
"git merge" started its life as the first level command (with a
funny syntax that does not even take command line option -m,
because you are supposed to give the whole merge message and
"git merge" itself does not do anything to affect the merge
message on its own). When it was pushed further back to the
"worker behind the scene" status, the task of coming up with a
fancier automated merge message were still left to the "git
pull" command which (1) is the UI level command that the users
are expected to use, and (2) knows much more about the context
where the merge is generated than "git merge" itself. As a
result, "git merge" still takes the whole message prepared and
it does not do anything on its own.
So if we rename the current "git merge" to "git-merge--record"
(or any name "git pull" uses internally to record the merge
commit), and make "git merge" a synonym to "git pull .", and
give a command line option -m to "git pull" to _affect_ the
resulting merge message, I would think everybody would become
quite happy. It means:
- People can say "git merge this-branch" (which is internally
translated to "git pull . this-branch");
- People can say "git pull -m 'I am doing this merge for such
and such reason' $URL $branch" to _include_ that message in
the resulting merge commit;
- The same can be said about "git merge -m 'comment' $branch".
I said _affect_ and _include_ in the above because I suspect
that most of the time you do not want to _replace_ the
autogenerated part ("Merge branch of repo", and if you are
pulling from your subordinate trees the merge summary message as
well).
^ permalink raw reply
* Re: Feature request: git-pull -e/--edit
From: linux @ 2006-11-20 2:43 UTC (permalink / raw)
To: junkio, linux; +Cc: git
In-Reply-To: <7vy7q67tf2.fsf@assigned-by-dhcp.cox.net>
> How often is this desired, when the merge is clean?
Well, if I could quote your own words:
>> I use "git pull . topicA topicB" for a tetrapus, so that is not
>> a reason for me, but when a topicA's older parts are worthy to
>> be in 'next' while later parts are not yet, I often do (on 'next'):
>>
>> git merge "Merge early part of branch 'topicA'" HEAD topicA~3
I can't speak from personal experience, but a merge can bring in a lot
of changes, and sometimes the auto-generated message doesn't say quite
as much as you'd like.
The commits on the branch speak for themselves, of course, but sometimes
it's nice to add the same sort of overview that appears in a [PATCH 0/13]
e-mail. We wouldn't have that convention if there wasn't a frequent
desire for it.
(Indeed, it might be nice to come up with a way of including a piece of
the "please pull" e-mail, similar to the way that git-applypatch works.)
> If the answer is "not so often", you can already use "commit
> --amend" after "pull" creates an automated merge commit.
It's not done very often right now, but how much of that is due to
the awkwardness? I agree it works perfectly, but "commit --amend"
has very much the feel of a workaround.
I'm not going to besiege Troy for a decade over the idea, but it seemed
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Junio C Hamano @ 2006-11-20 2:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611191527270.3692@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So I'd suggest adding - at the very top of the ref-pack file - a line line
>
> # Ref-pack version 2
>
> which will be ignored by the current ref-pack reader (again, because it's
> not a valid ref line), but we can use it in the future to specify further
> extensions if we want to.
>
> Now somebody would just need to implement that ;)
For this particular one, there is no need for version 2.
My current wip does:
SHA-1 SP name LF
SHA-1 SP SP name^{} LF
the latter of which is ignored by code in the wild and the new
code can take advantage of (and fall back the usual deref_tag
when it is not available).
I need to rebase it on top of a minor update to refs.c before
pushing it out.
^ permalink raw reply
* Re: gitweb install
From: lamikr @ 2006-11-20 2:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejr0gi$ea8$1@sea.gmane.org>
Jakub Narebski wrote:
> lamikr wrote:
>
>
>> Hi
>>
>> Following dummyuser test case (me :-) might be usefull for improving docs.
>> I have read the gitweb/README but in addition of that I find out that
>> there is really little documentation about installing gitweb
>> except the Makefile & git-instaweb.sh itself.
>>
>> I would like to install gitweb to /var/run/html/gitweb directory and
>> after reading the git/INSTALL & gitweb/README
>> I came to conclusion that something like following could work
>>
>> 1) build git by changing some of the default gitweb configs as a user
>> make prefix=/usr all doc GITWEB_SITENAME='gitweb test' \
>> GITWEB_PROJECTROOT=/var/www/html/gitweb
>> 2) install git as a root after build
>> make prefix=/usr install install-doc
>> 3) add following to apache config
>> <VirtualHost www:80>
>> ServerName my-web-page
>> DocumentRoot /gitweb
>> RewriteEngine on
>> RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
>> SetEnv GITWEB_CONFIG /etc/gitweb.conf
>> </VirtualHost>
>> 4) move git repository (kernel for example) to /var/www/html/gitweb
>>
> It should be enough to symlink it, given appropriate setup.
>
Are people usually using symlinks to their "real development"
repositories? Or is it more common to have personal working repository
for example in the own home directory and then the second "public copy"
for http pages? And then configure the personal repository to push the
changes somehow to public one?
That would seem to be more secure even it rises the gap between real and
published changes.
>> 5) restart apache
>> 6) open browser to http://my-web-page/gitweb
>>
>> Obviously something failed, as after step 2, I do not have either the
>> /etc/gitweb.conf or gitweb scripts under directory /var/www/html/gitweb
>>
>
> First, "make install" does not install the gitweb, as the place where
> it should be installed depends from configuration to configuration.
> By the way, you may compile ony gitweb using "make gitweb/gitweb.cgi"
> with appropriate params. So 2.1) step would be to manually copy
> gitweb.cgi and gitweb.css at least, perhaps also git-logo.png and
> git-favicon.png.
>
Ok, I did that.
> Second, you have to set up gitweb.cgi as a CGI script, or as legacy
> mod_perl script. I have for example in /var/www/cgi-bin symlink named
> gitweb to directory with gitweb.cgi, gitweb.css etc. and in
> /var/www/perl symplink to the same place.
>
> The CGI configuration for Apache2 is (simplest case, I'd appreciate
> better solutions):
>
> LoadModule cgi_module modules/mod_cgi.so
> ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
> <Directory "/var/www/cgi-bin">
> Options Indexes FollowSymlinks ExecCGI
> AllowOverride None
> Order allow,deny
> Allow from all
> </Directory>
>
Thanks, it seems that in Mandriva the preferred way it to put each of
these to own files under webapps.d directory.
So I created following /etc/httpd/conf/webapps.d/gitweb.conf by using
your script and cgi-script examples from httpd.conf as a help and got
things working.
# gitweb Apache configuration file
Alias /gitweb /var/www/gitweb
<Directory "/var/www/gitweb">
AllowOverride All
Options ExecCGI FollowSymLinks SymLinksifOwnerMatch
Order allow,deny
Allow from all
RewriteEngine on
RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$
/cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
SetEnv GITWEB_CONFIG /etc/gitweb.conf
</Directory>
Is there btw, any examples from the /etc/gitweb.conf file?
^ permalink raw reply
* Re: Feature request: git-pull -e/--edit
From: Junio C Hamano @ 2006-11-20 2:17 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061119212611.13038.qmail@science.horizon.com>
linux@horizon.com writes:
> The last end-user use I can think of for git-merge instead
> of git-pull is providing a custom commit message.
>
> Would it be possible to add -m and -e options to git-pull?
>
> The problem I can see is that the latter would have to be added to
> git-merge, and the guts there are a bit intricate; it uses git-commit-tree
> directly rather than git-commit, so I can't just pass through the
> arguments.
How often is this desired, when the merge is clean?
If the answer is "not so often", you can already use "commit
--amend" after "pull" creates an automated merge commit.
^ permalink raw reply
* Re: gitweb install
From: Jakub Narebski @ 2006-11-20 1:32 UTC (permalink / raw)
To: git
In-Reply-To: <45610199.4030502@cc.jyu.fi>
lamikr wrote:
> Hi
>
> Following dummyuser test case (me :-) might be usefull for improving docs.
> I have read the gitweb/README but in addition of that I find out that
> there is really little documentation about installing gitweb
> except the Makefile & git-instaweb.sh itself.
>
> I would like to install gitweb to /var/run/html/gitweb directory and
> after reading the git/INSTALL & gitweb/README
> I came to conclusion that something like following could work
>
> 1) build git by changing some of the default gitweb configs as a user
> make prefix=/usr all doc GITWEB_SITENAME='gitweb test' \
> GITWEB_PROJECTROOT=/var/www/html/gitweb
> 2) install git as a root after build
> make prefix=/usr install install-doc
> 3) add following to apache config
> <VirtualHost www:80>
> ServerName my-web-page
> DocumentRoot /gitweb
> RewriteEngine on
> RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
> SetEnv GITWEB_CONFIG /etc/gitweb.conf
> </VirtualHost>
> 4) move git repository (kernel for example) to /var/www/html/gitweb
It should be enough to symlink it, given appropriate setup.
> 5) restart apache
> 6) open browser to http://my-web-page/gitweb
>
> Obviously something failed, as after step 2, I do not have either the
> /etc/gitweb.conf or gitweb scripts under directory /var/www/html/gitweb
First, "make install" does not install the gitweb, as the place where
it should be installed depends from configuration to configuration.
By the way, you may compile ony gitweb using "make gitweb/gitweb.cgi"
with appropriate params. So 2.1) step would be to manually copy
gitweb.cgi and gitweb.css at least, perhaps also git-logo.png and
git-favicon.png.
Second, you have to set up gitweb.cgi as a CGI script, or as legacy
mod_perl script. I have for example in /var/www/cgi-bin symlink named
gitweb to directory with gitweb.cgi, gitweb.css etc. and in
/var/www/perl symplink to the same place.
The CGI configuration for Apache2 is (simplest case, I'd appreciate
better solutions):
LoadModule cgi_module modules/mod_cgi.so
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
<Directory "/var/www/cgi-bin">
Options Indexes FollowSymlinks ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
and can use for example http://localhost/cgi-bin/gitweb/gitweb.cgi
The mod_perl configuration for Apache2 is (again, I'd appreciate
pointing out better solution):
# mod_perl configuration, c.f. CGI version
#
Alias /perl "/var/www/perl"
<Directory "/var/www/perl">
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options Indexes FollowSymlinks +ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
If you don't have conf.d/perl.conf, then you have also to add to
your apache config the line
LoadModule perl_module modules/mod_perl.so
Well, mod_perl configuration could also be in the conf.d/perl.conf file.
I can use http://localhost/perl/gitweb/gitweb.cgi for mod_perl driven
gitweb.
HTH
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* gitweb install
From: lamikr @ 2006-11-20 1:15 UTC (permalink / raw)
To: Git Mailing List
Hi
Following dummyuser test case (me :-) might be usefull for improving docs.
I have read the gitweb/README but in addition of that I find out that
there is really little documentation about installing gitweb
except the Makefile & git-instaweb.sh itself.
I would like to install gitweb to /var/run/html/gitweb directory and
after reading the git/INSTALL & gitweb/README
I came to conclusion that something like following could work
1) build git by changing some of the default gitweb configs as a user
make prefix=/usr all doc GITWEB_SITENAME='gitweb test'
GITWEB_PROJECTROOT=/var/www/html/gitweb
2) install git as a root after build
make prefix=/usr install install-doc
3) add following to apache config
<VirtualHost www:80>
ServerName my-web-page
DocumentRoot /gitweb
RewriteEngine on
RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$
/cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
SetEnv GITWEB_CONFIG /etc/gitweb.conf
</VirtualHost>
4) move git repository (kernel for example) to /var/www/html/gitweb
5) restart apache
6) open browser to http://my-web-page/gitweb
Obviously something failed, as after step 2, I do not have either the
/etc/gitweb.conf or gitweb scripts under directory /var/www/html/gitweb
regards
Mika
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Linus Torvalds @ 2006-11-19 23:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejqhvi$9kc$1@sea.gmane.org>
On Sun, 19 Nov 2006, Jakub Narebski wrote:
>
> So the only reason against this format (IMHO more reasonable, more readable
> and more readable, and even easy extendable to the whole chain of derefs)
> is code in the wild?
>
> By the way, do we copy packed refs literaly when fetching or cloning?
The packed refs format is _purely_ a local format. So in that sense, we
can change it any way we want, and nobody really cares.
HOWEVER, even on a local machine, we generally want to be able to upgrade
and downgrade git versions without having to worry about things like this,
and having to convert one format to another. So using a format that "just
works" with any version of git that understands packed refs is _wildly_
more preferable over changing the format.
Btw, the simplest and best format is probably to make the new extension
look something like
8ba130df4b67fa40878ccf80d54615132d24bc68 refs/tags/v2.6.17
^427abfa28afedffadfca9dd8b067eb6d36bac53f
d882e0c80e6e3c60640492b83395e6fbbae04276 refs/tags/v2.6.17-rc1
^6246b6128bbe34d0752f119cf7c5111c85fe481d
which is basically almost as dense as having a space on the same line, and
will also trigger the old "that's not a valid line, just ignore it"
reaction from older versions.
So the parsing rules for that would simply be:
- if you see a line that starts with a "^<sha1>", then that is the
"unpeeling" of the previous packed entry (which in turn might have been
an unpeeling itself)
So if you were to have tags pointing to tags, you migt have
<sha1> refs/tags/tagname
^<sha1-unpeeled>
^<sha1-unpeeled-of-unpeeled>
...
<sha1> refs/tags/othertag
In addition, we'd need a line at the top of the file that says "this has
unpeeled information", because otherwise we have no way to distinguish
between the case of "no actual tag objects" and "old-fashioned ref-pack
file without any unpeeling info" - since they'd look identical.
So I'd suggest adding - at the very top of the ref-pack file - a line line
# Ref-pack version 2
which will be ignored by the current ref-pack reader (again, because it's
not a valid ref line), but we can use it in the future to specify further
extensions if we want to.
Now somebody would just need to implement that ;)
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Linus Torvalds @ 2006-11-19 23:26 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550611191425g30d02b98l71cfdc6439d2e09f@mail.gmail.com>
On Sun, 19 Nov 2006, Marco Costalba wrote:
>
> Excuse me for my ignorance, but isn' it the job of OS disk schedulers?
The OS disk scheduler does exactly that but
ONLY IF IT'S GIVEN DATA TO WORK ON IN PARALLEL
If an application gives it read requests one by one, the OS has no choice
but to just do the accesses one by one.
Writes are easier, since you can just buffer them. But you can't "buffer"
a read. When the user asks for a readdir(), you'd better give it to the
user, and there's not anything you can do about it.
So disk schedulers only work for
- parallel workloads
- writes
(where "parallel workloads" can be asynchronous reads - where the user
says "I will _start_ this read, notify me when it's done" and then gives
multiple independent reads to do in parallel).
So the OS cannot add parallelism - it can only take advantage of what
parallelism the application gives it.
^ permalink raw reply
* following Documentation/howto/update-hook-example.txt
From: Nicolas Vilz @ 2006-11-19 23:10 UTC (permalink / raw)
To: git
hello guys,
I tested the script mentioned in update-hook-example.txt and noticed,
that the following line in allowed-users
refs/heads/tmp/ *
and the if-clause above
matchlen=$(expr "$1" : "$head_pattern")
if [ "$matchlen" == "${#1}" ]; then
does not recognize the header
refs/heads/tmp/blah
... so, all users trying to update or create branches named
tmp/<insert_fancy_name_here> are denied, because nothing matches.
also the example case in which linus should be allowed to push and
create branches bw/blah and bw/blupp doesn't work.
If I try following rule in allowed-users
refs/heads/tmp *
and someone tries to commit refs/heads/tmp, it works as intended.
This is at least in bash 3.1.2.5 ... (i tested that on my powerbook this
week end). Perhaps it worked in November 2005. I don't know which
version of bash was the latest then.
For all other examples in this document, it grants and denies pushing
and creating branches as intended.
I haven't tried the tag-case yet.... could be, that this also doesn't
work anymore.
Greetings
Nicolas
^ permalink raw reply
* Re: Patch to tutorial.txt
From: Jakub Narebski @ 2006-11-19 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30611191444r710f23e5uc488d35aa4abaf06@mail.gmail.com>
Paolo Ciarrocchi wrote:
> From 0b98769dfe16e3ba8cde698b75cb1067658c38e7 Mon Sep 17 00:00:00 2001
I think you should remove this line.
> From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
> Date: Sun, 19 Nov 2006 23:41:31 +0100
> Subject: [PATCH] One of the comment was not really clear, rephrased to
> make it easier to be understood by the reader
Wordwrap. Perhaps it would be better to split description into short line,
and two-line description.
[...]
> ------------------------------------------------
>
> at this point the two branches have diverged, with different changes
> -made in each. To merge the changes made in the two branches, run
> +made in each. To merge the changes made in experimental into master run
I would rather say:
To merge the changes made in the two branches into master, run
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Patch to tutorial.txt
From: Paolo Ciarrocchi @ 2006-11-19 22:44 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I'm reading the tutorial and trying to improve it while studying git.
First attempt here:
From 0b98769dfe16e3ba8cde698b75cb1067658c38e7 Mon Sep 17 00:00:00 2001
From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Date: Sun, 19 Nov 2006 23:41:31 +0100
Subject: [PATCH] One of the comment was not really clear, rephrased to
make it easier to be understood by the reader
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
Documentation/tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 554ee0a..6edfb5a 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -141,7 +141,7 @@ $ git commit -a
------------------------------------------------
at this point the two branches have diverged, with different changes
-made in each. To merge the changes made in the two branches, run
+made in each. To merge the changes made in experimental into master run
------------------------------------------------
$ git pull . experimental
--
1.4.4.ge3d4
Regards,
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
http://www.linkedin.com/pub/0/132/9a3
Non credo nelle otto del mattino. Però esistono. Le otto del mattino
sono l'incontrovertibile prova della presenza del male nel mondo.
^ permalink raw reply related
* Re: [WISH] Store also tag dereferences in packed-refs
From: Marco Costalba @ 2006-11-19 22:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611191219350.3692@woody.osdl.org>
On 11/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
>
> For example, it's often (but not always) faster to do all the readdir's
> separately, and then sort the thing by inode number, and try to avoid
> back-and-forth movement. But quite frankly, that kind of stuff probably
> isn't sane to do in "git show-refs".
Excuse me for my ignorance, but isn' it the job of OS disk schedulers?
>
> Anyway, I think that if we really want to make "git show-refs" go fast
> when things are cold in the cache, and with lots ot tags and "-d" (which
> is a reasonable case to optimize for: it's probably exactly what we end up
> doing both for gitweb _and_ for "git-send-pack"), we'd need to expand the
> packed-refs file with the deref cache.
>
Probably also gitk, currently it uses (the slower) "git ls-remote"
instead of "git peek-remote" or "git show-refs" but the concept seems
the same.
^ permalink raw reply
* [PATCH] gitweb: Finish restoring "blob" links in git_difftree_body
From: Jakub Narebski @ 2006-11-19 21:51 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Jakub Narebski
This finishes work started by commit 4777b0141a4812177390da4b6ebc9d40ac3da4b5
"gitweb: Restore object-named links in item lists"
by Petr Baudis. It brings back rest of "blob" links in difftree-raw
like part of "commit" and "commitdiff" views, namely in
git_difftree_body subroutine.
Now the td.link table cell has the following links:
* link to diff ("blobdiff" view) in "commit" view, if applicable
(there is no link to uninteresting creation/deletion diff), or
link to patch anchor in "commitdiff" view.
* link to current version of file ("blob" view), with the obvious
exception of file deletion, where it is link to the parent
version.
* link to "blame" view, if it is enabled, and file was not just
created (i.e. it has any history).
* link to history of the file ("history" view), again with sole
exception of the case of new file.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This goes in the opposite version to the previous patch
" gitweb: Remove redundant "blob" links from git_difftree_body"
in the 10/n series.
gitweb/gitweb.perl | 42 +++++++++++++++++++++---------------------
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a32a6b7..ce185d9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2092,7 +2092,11 @@ sub git_difftree_body {
# link to patch
$patchno++;
print $cgi->a({-href => "#patch$patchno"}, "patch");
+ print " | ";
}
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
+ hash_base=>$hash, file_name=>$diff{'file'})},
+ "blob") . " | ";
print "</td>\n";
} elsif ($diff{'status'} eq "D") { # deleted
@@ -2112,13 +2116,11 @@ sub git_difftree_body {
}
print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
hash_base=>$parent, file_name=>$diff{'file'})},
- "blob") . " | ";
+ "blob") . " | ";
if ($have_blame) {
- print $cgi->a({-href =>
- href(action=>"blame",
- hash_base=>$parent,
- file_name=>$diff{'file'})},
- "blame") . " | ";
+ print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
+ file_name=>$diff{'file'})},
+ "blame") . " | ";
}
print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
file_name=>$diff{'file'})},
@@ -2163,13 +2165,12 @@ sub git_difftree_body {
" | ";
}
print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
- hash_base=>$hash, file_name=>$diff{'file'})},
- "blob") . " | ";
+ hash_base=>$hash, file_name=>$diff{'file'})},
+ "blob") . " | ";
if ($have_blame) {
- print $cgi->a({-href => href(action=>"blame",
- hash_base=>$hash,
- file_name=>$diff{'file'})},
- "blame") . " | ";
+ print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
+ file_name=>$diff{'file'})},
+ "blame") . " | ";
}
print $cgi->a({-href => href(action=>"history", hash_base=>$hash,
file_name=>$diff{'file'})},
@@ -2208,17 +2209,16 @@ sub git_difftree_body {
"diff") .
" | ";
}
- print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
- hash_base=>$parent, file_name=>$diff{'from_file'})},
- "blob") . " | ";
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
+ hash_base=>$parent, file_name=>$diff{'to_file'})},
+ "blob") . " | ";
if ($have_blame) {
- print $cgi->a({-href => href(action=>"blame",
- hash_base=>$hash,
- file_name=>$diff{'to_file'})},
- "blame") . " | ";
+ print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
+ file_name=>$diff{'to_file'})},
+ "blame") . " | ";
}
- print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
- file_name=>$diff{'from_file'})},
+ print $cgi->a({-href => href(action=>"history", hash_base=>$hash,
+ file_name=>$diff{'to_file'})},
"history");
print "</td>\n";
--
1.4.3.4
^ permalink raw reply related
* Feature request: git-pull -e/--edit
From: linux @ 2006-11-19 21:26 UTC (permalink / raw)
To: git; +Cc: linux
The last end-user use I can think of for git-merge instead
of git-pull is providing a custom commit message.
Would it be possible to add -m and -e options to git-pull?
The problem I can see is that the latter would have to be added to
git-merge, and the guts there are a bit intricate; it uses git-commit-tree
directly rather than git-commit, so I can't just pass through the
arguments.
Assuming it's just as much of a pain for someone else, would it
still be worth the effort? Can git-merge be cleaned up?
The manual option is to use "git merge --no-commit" and then supply the
arguments to git-commit in the usual way.
But I notice that --no-commit actually changes git's merging
technique. If it's specified, the trivial in-index merge doesn't
appear to be attempted. I don't think it makes a huge difference,
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Jakub Narebski @ 2006-11-19 21:24 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611191310430.3692@woody.osdl.org>
Linus Torvalds wrote:
> On Sun, 19 Nov 2006, Junio C Hamano wrote:
>>
>> Did you do this "if (isspace(*line)) return NULL" to have
>> extensibility later, I wonder...
>
> No, but I try to have a policy of not accepting anything that is even
> slightly questionable, so it was unintentional in the details but a result
> of a higher-level principle..
>
> Of course, even when I wrote it I _also_ knew that I should check
> everything else too (not just the first character), but I was lazy. That
> would have been even better - then we could have made the thing be
> something like
>
> <sha1><space><name>[<space><sha1-of-deref>]*
>
> instead.
So the only reason against this format (IMHO more reasonable, more readable
and more readable, and even easy extendable to the whole chain of derefs)
is code in the wild?
By the way, do we copy packed refs literaly when fetching or cloning?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Linus Torvalds @ 2006-11-19 21:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Marco Costalba
In-Reply-To: <7vbqn38831.fsf@assigned-by-dhcp.cox.net>
On Sun, 19 Nov 2006, Junio C Hamano wrote:
>
> Did you do this "if (isspace(*line)) return NULL" to have
> extensibility later, I wonder...
No, but I try to have a policy of not accepting anything that is even
slightly questionable, so it was unintentional in the details but a result
of a higher-level principle..
Of course, even when I wrote it I _also_ knew that I should check
everything else too (not just the first character), but I was lazy. That
would have been even better - then we could have made the thing be
something like
<sha1><space><name>[<space><sha1-of-deref>]*
instead.
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Junio C Hamano @ 2006-11-19 21:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Marco Costalba
In-Reply-To: <Pine.LNX.4.64.0611191219350.3692@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So the optimizations that _can_ be done are:
>
> - add dereference info to .git/packed-refs
>
> This would allow us to simply not do the expensive object lookup for
> every single tag. We'd still have to do it for non-packed objects, of
> course, but the cost here tends to be that over time you might have
> hundreds of tags, and even if each tag only takes 0.02s to look up,
> you're going to be slow.
>
> - avoid the references for "heads/" (which we know are supposed to be
> commits, and cannot be tags) and when not specifying "-d". This won't
> help your case very much, though. If you want "-d", you want it, and
> the _big_ number of refs tends to be in tags, not branches, anyway.
>
> - using a filesystem wih nicer locality behaviour for directory entries
> and inodes. This can cut down costs of cold-cache case by a factor of
> two, but right now there are no good filesystems that do this (but see
> for example "spadfs" that Mikulas Patocka announced a few weeks ago on
> linux-kernel - it would seem to have the possibility of being better in
> this area. I looked at the code and it looked like it could become
> very reasonable, but I've not actually _tested_ it, soo...)
>
> Anyway, I think that if we really want to make "git show-refs" go fast
> when things are cold in the cache, and with lots ot tags and "-d" (which
> is a reasonable case to optimize for: it's probably exactly what we end up
> doing both for gitweb _and_ for "git-send-pack"), we'd need to expand the
> packed-refs file with the deref cache.
>
> Junio?
Yes; the "for discussion only" WIP patch from yesterday was
about the first point and half of the second point.
One downside about storing the peeled refs in .git/packed-refs
is that the code in the wild does not have safety guard against
them, so the version of show-ref from v1.4.4 recently released
will list tags/v2.6.19^{} as if it is a true tag and worse yet
it might even show tags/v2.6.19^{}^{} under -d option after the
repository's refs are packed in the new format.
But I think we can avoid that problem by using a format slightly
different from the WIP patch. We can for example use two spaces
between SHA-1 and the name for them. refs.c::parse_ref_line()
in existing code will say "oh, this line is nonsense" and skip
them, while the updated code can say "ok, this is a peeled ref",
since it has a seemingly incomplete "check for valid refname"
there that only checks "isspace(*line)".
Did you do this "if (isspace(*line)) return NULL" to have
extensibility later, I wonder...
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Linus Torvalds @ 2006-11-19 20:44 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611191219350.3692@woody.osdl.org>
On Sun, 19 Nov 2006, Linus Torvalds wrote:
>
> So the optimizations that _can_ be done are:
Of course, doing a "git repack -a -d && git prune" is always the #1
optimization. It will still look up the objects, but it will be a lot
faster about it, and avoid a lot of the really bad IO patterns.
If you don't want to repack, you could try just doing a "git clone" and
then doing the "git pack-refs --prune" in the clone too. And compare
cold-cache times between the two "identical" repositories.
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Linus Torvalds @ 2006-11-19 20:36 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550611191209s63982818vd3999b543e68e8df@mail.gmail.com>
On Sun, 19 Nov 2006, Marco Costalba wrote:
>
> It does not seems there are strange delays, but total time it's high
> (very I/O bound)
This looks more normal. No truly horrid IO times. With your disk, having
an uncached "stat64()" taking ~50ms is not at all impossible, if you just
end up having to do a few seeks for directory/inode information.
> $ time strace -o tracefile -Ttt git show-ref -d >> /dev/null
> 0.02user 0.01system 0:02.39elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (127major+894minor)pagefaults 0swaps
So in addition to the "stat()" calls on all the objects you have
referenced, you also had 127 page faults that needed to do IO (probably a
combination of executable and pack-file accesses).
I think the only way to avoid this is likely to try to either not do the
object lookups at all (which you really cannot currently avoid with "-d",
since the whole point is to dereference the objects if they are tags), or
to do some silly optimizations like fsck does.
For example, it's often (but not always) faster to do all the readdir's
separately, and then sort the thing by inode number, and try to avoid
back-and-forth movement. But quite frankly, that kind of stuff probably
isn't sane to do in "git show-refs".
So the optimizations that _can_ be done are:
- add dereference info to .git/packed-refs
This would allow us to simply not do the expensive object lookup for
every single tag. We'd still have to do it for non-packed objects, of
course, but the cost here tends to be that over time you might have
hundreds of tags, and even if each tag only takes 0.02s to look up,
you're going to be slow.
- avoid the references for "heads/" (which we know are supposed to be
commits, and cannot be tags) and when not specifying "-d". This won't
help your case very much, though. If you want "-d", you want it, and
the _big_ number of refs tends to be in tags, not branches, anyway.
- using a filesystem wih nicer locality behaviour for directory entries
and inodes. This can cut down costs of cold-cache case by a factor of
two, but right now there are no good filesystems that do this (but see
for example "spadfs" that Mikulas Patocka announced a few weeks ago on
linux-kernel - it would seem to have the possibility of being better in
this area. I looked at the code and it looked like it could become
very reasonable, but I've not actually _tested_ it, soo...)
Anyway, I think that if we really want to make "git show-refs" go fast
when things are cold in the cache, and with lots ot tags and "-d" (which
is a reasonable case to optimize for: it's probably exactly what we end up
doing both for gitweb _and_ for "git-send-pack"), we'd need to expand the
packed-refs file with the deref cache.
Junio?
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Linus Torvalds @ 2006-11-19 20:18 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550611191107o63d89d8bp5ff4080803a0d784@mail.gmail.com>
On Sun, 19 Nov 2006, Marco Costalba wrote:
>
> But why my numbers are bad both in git, in Linux and also qgit (not
> posted) local repo? If it is a single case other repos should load
> fast.
Well, it's almost guaranteed to not really be a "single" case.
An inode on disk is usually ~128 bytes or so, which means that you'll be
able to fit quite a number of inodes in a page-sized allocation of disk
cache. If _any_ of the sectors was slow to access (because of IO retries,
disk sector remapping, whatever), all those inodes will be slow to access.
(It might also be a specific area on the disk, or something).
> Its a Thinkpad 2.5 inches HD, 2 years old (IBM/Hitachi Travelstar 40GNX
> family)
That's a 5400rpm disk with an average seektime of 12ms, and full stroke
typical seek of 23ms.
A "stat64()" will do more than a single IO when it's cold-cache (the
kernel will have to look up the directory entry and the inode, of course),
but you _should_ see just a few IO's (2-3), so quite frankly, normally I'd
expect to see times in the 0.03s - 0.05s range _maximum_. You'd see less
if even just part of it was cached (which is normal, exactly because
things like directory entries are contiguous on disk etc).
And that seems to match your other numbers.
The 0.8s number really is an outlier. It sounds like the drive didn't find
the sector at first, perhaps had to go to its remapping table, seek around
a bit more, take a break just to calm down, and then perhaps recalibrate
itself (or write a SMART record entry).
> > - your disk is failing, and ends up doing error recovery etc.
>
> No recent errors are reported:
>
> Stripped from smartctl -a /dev/hda
Ok, I'm not actually all that familiar with all the SMART error codes, but
it _looks_ healthy. You do have one Spin_Up_Time event (that is
marked pre-fail), and those two IDNF errors you have:
> 10 51 01 0f 8e a8 e4 Error: IDNF at LBA = 0x04a88e0f = 78155279
> 10 51 01 0f 8e a8 e4 Error: IDNF 1 sectors at LBA = 0x04a88e0f = 78155279
makes me wonder a bit, but for all I know, it's not actually serious. I
_think_ the IDNF error means that it couldn't find a sector, but..
^ permalink raw reply
* Re: [WISH] Store also tag dereferences in packed-refs
From: Marco Costalba @ 2006-11-19 20:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550611191107o63d89d8bp5ff4080803a0d784@mail.gmail.com>
On 11/19/06, Marco Costalba <mcostalba@gmail.com> wrote:
>
> When finished I will do additional cold chache (reboot) tests.
>
Previous delay was not reproduced. This time I tested also with git
show-ref -d (dereferencing tags), always with cold-cache.
It does not seems there are strange delays, but total time it's high
(very I/O bound)
- LINUX TREE
$ pwd
/git/linux-2.6
$ time strace -o tracefile -Ttt git show-ref -d >> /dev/null
0.02user 0.01system 0:02.39elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (127major+894minor)pagefaults 0swaps
$ grep -v ' <0.0[012]' tracefile >> tracefile_slowest.txt
$ cat tracefile_slowest.txt
20:51:49.695511 execve("/home/marco/bin/git", ["git", "show-ref",
"-d"], [/* 78 vars */]) = 0 <0.065006>
20:51:49.946258 open(".git/objects/info/alternates", O_RDONLY) = -1
ENOENT (No such file or directory) <0.091447>
20:51:50.070555
stat64(".git/objects/e0/30f8294a5b9f8179dae10cdbf9dcf32aa64110",
{st_mode=S_IFREG|0444, st_size=284, ...}) = 0 <0.037669>
20:51:51.822469
stat64(".git/objects/7a/9d289b6650bf78df77ab463bedc2919df89833",
{st_mode=S_IFREG|0444, st_size=285, ...}) = 0 <0.048868>
20:51:51.930582
stat64(".git/objects/80/c218812786f619c9a1ce50d0e7c32c7afde4de",
{st_mode=S_IFREG|0444, st_size=210, ...}) = 0 <0.030057>
20:51:51.981951
stat64(".git/objects/44/597f65f6af3c692560a639f61d25398d13d1b6",
{st_mode=S_IFREG|0444, st_size=249, ...}) = 0 <0.037440>
20:51:52.023469 exit_group(0) = ?
- GIT TREE
$cd /home/marco/programmi/git
$ time strace -o tracefile -Ttt git show-ref -d >> /dev/null
0.04user 0.04system 0:02.47elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (91major+794minor)pagefaults 0swaps
$ grep -v ' <0.0[012]' tracefile >> tracefile_slowest.txt
$ cat tracefile_slowest.txt
20:55:04.844584
stat64(".git/objects/d0/f877fb601ac0076fd69ec4f48f71f9247771c8",
{st_mode=S_IFREG|0444, st_size=190, ...}) = 0 <0.046100>
20:55:04.944839
stat64(".git/objects/e2/67c2f6f0784e242883b7d3fe5f36ef63d6950d",
{st_mode=S_IFREG|0444, st_size=179, ...}) = 0 <0.033536>
20:55:05.057966
stat64(".git/objects/41/292ddd37202ff6dce34986c87a6000c5d3fbfa",
{st_mode=S_IFREG|0444, st_size=180, ...}) = 0 <0.072937>
20:55:05.432107
stat64(".git/objects/7d/09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019",
{st_mode=S_IFREG|0444, st_size=396, ...}) = 0 <0.035952>
20:55:05.592877
stat64(".git/objects/92/d7605b6d9312a29efa30b1baa4d7c880a0be41",
{st_mode=S_IFREG|0444, st_size=280, ...}) = 0 <0.032139>
20:55:05.738173
stat64(".git/objects/05/56a11a0df6b4119e01aa77dfb795561e62eb34",
{st_mode=S_IFREG|0444, st_size=557, ...}) = 0 <0.031572>
20:55:06.176786
stat64(".git/objects/88/3653babd8ee7ea23e6a5c392bb739348b1eb61",
{st_mode=S_IFREG|0444, st_size=442, ...}) = 0 <0.030382>
20:55:06.549025
stat64(".git/objects/95/f1e36cc34e8738e5c431aac47d6fea18913db0",
{st_mode=S_IFREG|0444, st_size=395, ...}) = 0 <0.031731>
20:55:06.844432
stat64(".git/objects/ba/f0bfcb4b335438e9359835f2c27cccf20e54a3",
{st_mode=S_IFREG|0444, st_size=182, ...}) = 0 <0.033688>
20:55:06.922993 exit_group(0) = ?
^ permalink raw reply
* Re: Git manuals
From: Robin Rosenberg @ 2006-11-19 19:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejq6ul$7co$1@sea.gmane.org>
söndag 19 november 2006 19:16 skrev Jakub Narebski:
> Petr Baudis wrote:
> > Your approach is fine for something you would call "Git Reference
> > Manual", but it is something really different from "The Git Book" or
> > "Git User's Manual".
>
> By the way, does AsciiDoc support conversion to texinfo (and then to info)
> format? It would be nice to have "The Git Book" aka "GUM - Git User's
> Manual" in texinfo, HTML and perhaps also PDF (HTML and PDF with
> graphs/images).
Not sure if there is a texinfo translator, but HTML, PDF and anything else
that DocBook can be used for is possible.
^ permalink raw reply
* Re: Git manuals
From: J. Bruce Fields @ 2006-11-19 19:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Theodore Tso, linux, git
In-Reply-To: <20061119175952.GX7201@pasky.or.cz>
On Sun, Nov 19, 2006 at 06:59:52PM +0100, Petr Baudis wrote:
> On Sun, Nov 19, 2006 at 06:50:40PM CET, J. Bruce Fields wrote:
> > In fact, I'm tempted to submit a patch that just assigns a chapter
> > number to everything under Documentation/, slaps a single table of
> > contents on the front, and calls the result "the git user's manual."
> >
> > Of course, the moment people started trying to read the thing they'd
> > complain that it was a mess--some stuff referenced without being
> > introduced, other stuff introduced too many times. But then over time
> > maybe that'd force us to mold it into some sort of logical sequence.
>
> Sequencing isn't the only problem. A _manual_ is different from
> _reference documentation_ in that it does not usually describe command
> after command, but rather concept after concept. So instead of slamming
> git-*-pack commands together, you have a section "Handling Packs" where
> you try to coherently describe the commands together.
>
> Your approach is fine for something you would call "Git Reference
> Manual", but it is something really different from "The Git Book" or
> "Git User's Manual".
Yeah, of course, but I wasn't actually thinking of the man pages so much
as:
everyday.txt
tutorial.txt
tutorial-2.txt
core-tutorial.txt
howto/
hooks.txt
README
glossary.txt
etc.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox