* Re: [PATCH] handle https:// protocol in git-clone
From: Junio C Hamano @ 2006-08-07 18:35 UTC (permalink / raw)
To: Michael Krelin; +Cc: git
In-Reply-To: <20060807151021.GF21051@argo.zzZZzz.net>
Michael Krelin <hacker@klever.net> writes:
> ---
> git-clone.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks. git-fetch and git-ls-remote already do so and it was a
stupid omission not to do this in git-clone.
^ permalink raw reply
* Re: fast-import and unique objects.
From: Jon Smirl @ 2006-08-07 18:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eb7jr2$4ar$1@sea.gmane.org>
On 8/7/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Jon Smirl wrote:
>
> > How about sending out a stream of add/change/delete operations
> > interspersed with commits? That would let fast-import track the tree
> > and only generate tree nodes when they change.
>
> The problem with CVS, which cvsps (CVS PatchSet) tries to address is that
> changes are to a file, and reconstructing which changes go together to make
> _one_ commit...
The cvs2svn code is also gathering CVS commits into change sets. The
advantage of the cvs2svn code is that it is written by some of the
original CVS developers. Those developers are familiar with the 1,000
different ways to break a CVS repository and cvs2svn tries to deal
with the breakage.
cvsps works for some repositories but it fails on the Mozilla one.
There is something about branches in the Mozilla repository that
confuses it. cvs2svn handles the Mozilla repository correctly as far
as I can tell.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RE: Problem with clone hanging
From: Tziporet Koren @ 2006-08-07 18:57 UTC (permalink / raw)
To: Bryan O'Sullivan, Erik Mouw; +Cc: git, Michael S. Tsirkin
OK we will upgrade our git installation (but it will be only tomorrow)
You are correct - we have not set HTTP interface. Really we wanted that
this git will be hosted by Sandia server but their system admin has not
yet set it up.
Meanwhile I can send you all sources in a tarball if you want.
Tziporet
-----Original Message-----
From: Bryan O'Sullivan [mailto:bos@serpentine.com]
Sent: Monday, August 07, 2006 8:22 PM
To: Erik Mouw
Cc: git@vger.kernel.org; Tziporet Koren
Subject: Re: Problem with clone hanging
On Mon, 2006-08-07 at 19:12 +0200, Erik Mouw wrote:
> Looks like the same problem that kernel.org used to have. The other
> side probably runs git-1.4.0, they should upgrade to 1.4.1.
OK, thanks for the helpful response.
> In the mean
> time, you could clone using http and later on switch to git transport.
It seems like Mellanox doesn't publish that repository over HTTP, so I'm
stuck. Tziporet, can you upgrade your git installation, please?
<b
^ permalink raw reply
* Re: [PATCH 2/2] annotate: Fix bug when parsing merges with differing real and logical parents.
From: Junio C Hamano @ 2006-08-07 19:16 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11549526841904-git-send-email-ryan@michonline.com>
This does stop it from dying on Jeff King's bug report
(<20060803203848.GA15121@coredump.intra.peff.net>) to annotate
builtin-read-tree.c. However,...
Comparing output between "annotate" and "blame -c" on the same
file shows a rather interesting differences.
(1) "annotate" blames the first line "/*" to d147e501 made on
2006-05-23, while "blame" annotates it with 8bc9a0c7 made on
2005-04-07. As far as I remember this line has never been
touched by anybody during the life of the file, so the
latter sounds more plausible.
(2) The 13th line to #include "cache-tree.h" is blamed on
3f69d405 by "annotate", while annotation by "blame" reads
that it came from bad68ec9.
3f69d405 is a merge to incorporate the line into "master"
branch. "git show -M 3f69d405 -- builtin-read-tree.c read-tree.c"
starts with:
diff --cc builtin-read-tree.c
index ec40d01,99e7c75..716f792
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@@ -9,9 -9,9 +9,10 @@@
#include "object.h"
#include "tree.h"
+ #include "cache-tree.h"
#include <sys/time.h>
Which means the line is new from the point of view of the
"master" branch, but existed in the branch that this commit
merges from (namely, jc/cache-tree) already.
"git show -M bad68ec9 -- read-tree.c" shows that it is the
one that added the #include line to the history.
(3) The 14th line to #include <sys/time.h> is blamed on d147e501
by "annotate" but "blame" says it came from 744633cb. It is
obvious the latter is correct, if you look at "git show" on
these commits. The eye-candy was what made <sys/time.h>
necessary (it needed to do the progress-signal stuff).
In fact, "annotate" attributes too many lines to d147e501 (839
lines).
Given that "git show -M d147e501 -- read-tree.c builtin-read-tree.c"
shows only 2 insertions and 1 deletion, it does not sound
right. The commit adds #include "builtin.h" and changes the
function name "main" to "cmd_read_tree".
On the other hand, "blame" attributes only 1 line to this
commit; the line to #include "builtin.h". The other change this
commit introduces (main -> cmd_read_tree) is not counted because
the third parameter to the function changes after this commit by
a91af794 (which, by the way, both "annotate" and "blame" get
right), and the line this commit introduces did not survive.
^ permalink raw reply
* [PATCH] Documentation: explain "--pretty"
From: Michael @ 2006-08-07 19:32 UTC (permalink / raw)
To: git
Signed-off-by: Michael <barra_cuda@katamail.com>
---
Documentation/git-diff-tree.txt | 4 ++--
Documentation/git-log.txt | 2 ++
Documentation/git-rev-list.txt | 4 +++-
Documentation/git-show.txt | 2 +-
Documentation/git-whatchanged.txt | 2 +-
5 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index f7e8ff2..11d4f48 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -73,9 +73,9 @@ separated with a single space are given.
This flag causes "git-diff-tree --stdin" to also show
the commit message before the differences.
---pretty[=(raw|medium|short)]::
+--pretty[=(raw|medium|short|full|oneline)]::
This is used to control "pretty printing" format of the
- commit message. Without "=<style>", it defaults to
+ commit message. Without "=<format>", it defaults to
medium.
--no-commit-id::
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index c9ffff7..cd46580 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -26,6 +26,8 @@ OPTIONS
-------
--pretty=<format>::
Controls the way the commit log is formatted.
+ <format> can be one of 'raw', 'medium', 'short', 'full',
+ and 'oneline'. Without "=<format>", it defaults to medium.
--max-count=<n>::
Limits the number of commits to show.
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index f60eacd..761891e 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -49,8 +49,10 @@ between the two operands. The following
OPTIONS
-------
---pretty::
+--pretty=<format>::
Print the contents of the commit changesets in human-readable form.
+ <format> can be one of 'raw', 'medium', 'short', 'full',
+ and 'oneline'. Without "=<format>", it defaults to medium.
--header::
Print the contents of the commit in raw-format; each
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 2b4df3f..58c64ff 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -29,7 +29,7 @@ OPTIONS
--pretty=<format>::
Controls the output format for the commit logs.
<format> can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'.
+ and 'oneline'. Without "=<format>", it defaults to medium.
Author
------
diff --git a/Documentation/git-whatchanged.txt
b/Documentation/git-whatchanged.txt
index e8f21d0..4d7d45f 100644
--- a/Documentation/git-whatchanged.txt
+++ b/Documentation/git-whatchanged.txt
@@ -41,7 +41,7 @@ OPTIONS
--pretty=<format>::
Controls the output format for the commit logs.
<format> can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'.
+ and 'oneline'. Without "=<format>", it defaults to medium.
-m::
By default, differences for merge commits are not shown.
--
1.4.2.rc3
^ permalink raw reply related
* Re: Multiple pulls from the same branch in .git/remotes/origin
From: Michael S. Tsirkin @ 2006-08-07 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5bc4czr.fsf@assigned-by-dhcp.cox.net>
Quoting r. Junio C Hamano <junkio@cox.net>:
> Subject: Re: Multiple pulls from the same branch in .git/remotes/origin
>
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>
> > I get remote linus_master properly fetched into local origin.
> > Two questions:
>
> > 1. Isn't is possible to pull from the same remote branch into multiple local
> > branches?
>
> Currently, no. The underlying git-fetch-pack makes sure you do
> not give the same branches twice on the command line. I think
> what the code actually tries to do is to make sure each of the
> given refspecs is not ambiguous and matches something, but while
> doing so it marks the remote ref that matched ineligible to
> match again, which ends up showing the error message you saw.
>
> It might not be too difficult to change it though. This part of
> the code is relatively old and I do not remember the details
> offhand, other than I remember that the first time I saw it I
> had the same confused "Huh? we do not let a ref fetched twice?"
> reaction ;-).
At least, fix the error message?
--
MST
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Junio C Hamano @ 2006-08-07 19:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200608071626.52655.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This RFC is about better naming of subroutines in gitweb. The patch was
> generated on top of 'next' (7c7e45d0cc0f482aeb19ecb0b56e9e7b65472c56)
> using embedded gitweb-rename.sh script.
> Subroutines name guideline:
> * git_ prefix for subroutines related to git commands,
> or to gitweb actions
> * git_get_ prefix for subroutines calling git command
> and returning some output
> * git_read_ prefix for subroutines directly accessing git
> repository files
- (I am not complaining or objecting yet -- this is just an
observation. ) The distinction between git_get_foo and
git_read_foo is an implementation detail. The latter could
signal that the implementation bypasses the published
interface but depends on the implementation detail of the
low-level git, so it might be a good idea, but on the other
hand the only instance is git_read_info_refs which reads from
.git/info/refs -- and its format is part of the published
interface -- so I am not so sure this distinction is worth
it. And certainly we would not want to rely too heavily on
the current implementation of the low-level git, so we
obviously do not want to add more git_read_foo's needlessly,
which makes me feel even less sure if we would want
git_read_foo...
> * parse_ prefix for subroutines parsing some text, or reading and
> parsing some text into hash or list
> * format_ prefix for subroutines formatting/post-processing some
> HTML/text fragment
> * _get_ infix for subroutines which return result
> * _print_ infix for subroutines which print fragment of output
> * _body suffix for subroutines which outputs main part (body)
> of related action
> * _nav suffix for subroutines related to navigation bars
> * _div suffix for subroutines returning or ptinting div element
- All of these sound sane.
> How should subroutines be named? Do you agree with proposal, or not?
I suspect that the list may disagree with some minor details on
the naming guidelines but I hope that everybody would in
principle be in favor of this.
> Is such renaming usefull?
If we are to have many more fixes and clean-ups on gitweb,
readable and consistent names would be very helpful.
The problem is when. If we are going to apply this, we need to
pick a point of time when not many patches on gitweb are in
flight; otherwise I'd end up asking people to resend using new
names.
^ permalink raw reply
* Re: [PATCH 1/2] log-tree: show_log() should respect the setting of diffopt->line_termination
From: Junio C Hamano @ 2006-08-07 19:38 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git, Jeff King
In-Reply-To: <1154952684908-git-send-email-ryan@michonline.com>
Thanks. This indeed was a regression from 1.0 codebase.
^ permalink raw reply
* Re: Problem with clone hanging
From: Michael S. Tsirkin @ 2006-08-07 19:41 UTC (permalink / raw)
To: Tziporet Koren; +Cc: Bryan O'Sullivan, Erik Mouw, git
In-Reply-To: <6AB138A2AB8C8E4A98B9C0C3D52670E301FA761E@mtlexch01.mtl.com>
BTW, it makes sense (much faster to) clone Linus' tree, then pull
ofed_1_1 from www.mellanox.co.il
Quoting r. Tziporet Koren <tziporet@mellanox.co.il>:
Subject: RE: Problem with clone hanging
OK we will upgrade our git installation (but it will be only tomorrow)
You are correct - we have not set HTTP interface. Really we wanted that this git will be hosted by Sandia server but their system admin has not yet set it up.
Meanwhile I can send you all sources in a tarball if you want.
Tziporet
-----Original Message-----
From: Bryan O'Sullivan [mailto:bos@serpentine.com]
Sent: Monday, August 07, 2006 8:22 PM
To: Erik Mouw
Cc: git@vger.kernel.org; Tziporet Koren
Subject: Re: Problem with clone hanging
On Mon, 2006-08-07 at 19:12 +0200, Erik Mouw wrote:
> Looks like the same problem that kernel.org used to have. The other
> side probably runs git-1.4.0, they should upgrade to 1.4.1.
OK, thanks for the helpful response.
> In the mean
> time, you could clone using http and later on switch to git transport.
It seems like Mellanox doesn't publish that repository over HTTP, so I'm
stuck. Tziporet, can you upgrade your git installation, please?
<b
--
MST
^ permalink raw reply
* Re: [PATCH 2/2] annotate: Fix bug when parsing merges with differing real and logical parents.
From: Ryan Anderson @ 2006-08-07 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
In-Reply-To: <7virl42w6s.fsf@assigned-by-dhcp.cox.net>
On Mon, Aug 07, 2006 at 12:16:27PM -0700, Junio C Hamano wrote:
> This does stop it from dying on Jeff King's bug report
> (<20060803203848.GA15121@coredump.intra.peff.net>) to annotate
> builtin-read-tree.c. However,...
>
> Comparing output between "annotate" and "blame -c" on the same
> file shows a rather interesting differences.
Yes, annotate is still mis-attributing things to merges that it should
not. I was kind of hoping this fix would have a side-effect of fixing
it, but I had no logical reason to think it would. I'm going to try
again at fixing it later this week, maybe the weekend, but I'm starting
to think that maybe blame has won. :)
>
> (1) "annotate" blames the first line "/*" to d147e501 made on
> 2006-05-23, while "blame" annotates it with 8bc9a0c7 made on
> 2005-04-07. As far as I remember this line has never been
> touched by anybody during the life of the file, so the
> latter sounds more plausible.
>
> (2) The 13th line to #include "cache-tree.h" is blamed on
> 3f69d405 by "annotate", while annotation by "blame" reads
> that it came from bad68ec9.
>
> 3f69d405 is a merge to incorporate the line into "master"
> branch. "git show -M 3f69d405 -- builtin-read-tree.c read-tree.c"
> starts with:
>
> diff --cc builtin-read-tree.c
> index ec40d01,99e7c75..716f792
> --- a/builtin-read-tree.c
> +++ b/builtin-read-tree.c
> @@@ -9,9 -9,9 +9,10 @@@
>
> #include "object.h"
> #include "tree.h"
> + #include "cache-tree.h"
> #include <sys/time.h>
>
> Which means the line is new from the point of view of the
> "master" branch, but existed in the branch that this commit
> merges from (namely, jc/cache-tree) already.
>
> "git show -M bad68ec9 -- read-tree.c" shows that it is the
> one that added the #include line to the history.
>
> (3) The 14th line to #include <sys/time.h> is blamed on d147e501
> by "annotate" but "blame" says it came from 744633cb. It is
> obvious the latter is correct, if you look at "git show" on
> these commits. The eye-candy was what made <sys/time.h>
> necessary (it needed to do the progress-signal stuff).
>
> In fact, "annotate" attributes too many lines to d147e501 (839
> lines).
>
> Given that "git show -M d147e501 -- read-tree.c builtin-read-tree.c"
> shows only 2 insertions and 1 deletion, it does not sound
> right. The commit adds #include "builtin.h" and changes the
> function name "main" to "cmd_read_tree".
>
> On the other hand, "blame" attributes only 1 line to this
> commit; the line to #include "builtin.h". The other change this
> commit introduces (main -> cmd_read_tree) is not counted because
> the third parameter to the function changes after this commit by
> a91af794 (which, by the way, both "annotate" and "blame" get
> right), and the line this commit introduces did not survive.
>
>
>
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Multiple pulls from the same branch in .git/remotes/origin
From: Junio C Hamano @ 2006-08-07 19:53 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20060807193809.GA24013@mellanox.co.il>
"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>> It might not be too difficult to change it though. This part of
>> the code is relatively old and I do not remember the details
>> offhand, other than I remember that the first time I saw it I
>> had the same confused "Huh? we do not let a ref fetched twice?"
>> reaction ;-).
>
> At least, fix the error message?
That would touch the same vicinity of code so if I were to do
that myself I would rather see if the restriction can be
loosened properly first.
^ permalink raw reply
* Annotate another problem report
From: Junio C Hamano @ 2006-08-07 20:00 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <7virl42w6s.fsf@assigned-by-dhcp.cox.net>
"git annotate Makefile v1.4.0" outputs this:
...
58e60dd2 (Nick Hengeveld 2005-11-02 11:19:24 -0800 13)# git.......
58e60dd2 (Nick Hengeveld 2005-11-02 11:19:24 -0800 14)# tra.......
( 1970-01-01 00:00:00 15)#
6d9bbc50 (Patrick Mauritz 2005-09-19 16:11:19 +0200 16)# ..
6d9bbc50 (Patrick Mauritz 2005-09-19 16:11:19 +0200 17)# ..
...
There are a handful lines it couldn't tell where they came from:
( 1970-01-01 00:00:00 15)#
( 1970-01-01 00:00:00 179)
( 1970-01-01 00:00:00 182)
( 1970-01-01 00:00:00 274)endif
( 1970-01-01 00:00:00 323)
( 1970-01-01 00:00:00 384)else
( 1970-01-01 00:00:00 385) LIB_4_ICONV =
^ permalink raw reply
* Re: Problem with clone hanging
From: Michael S. Tsirkin @ 2006-08-07 20:05 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Bryan O'Sullivan, Erik Mouw, git
In-Reply-To: <20060807183230.GA14955@procyon.home>
Quoting r. Sergey Vlasov <vsu@altlinux.ru>:
> Subject: Re: Problem with clone hanging
>
> On Mon, Aug 07, 2006 at 11:23:20AM -0700, Bryan O'Sullivan wrote:
> > On Mon, 2006-08-07 at 21:52 +0400, Sergey Vlasov wrote:
> >
> > > In the meantime, you can try to specify a local clone of the mainline
> > > Linux repository with the --reference=... option to git-clone.
> >
> > Thanks. I don't know if what I'm cloning is actually a kernel tree,
> > unfortunately.
>
> At least git ls-remote git://www.mellanox.co.il/~git/infiniband
> suggests this. Of course, it might contains some completely unrelated
> branches (with git this is possible), but at least you won't need to
> download the whole kernel history since 2.6.12-rc2.
Exactly. It's a kernel-tree + other stuff.
--
MST
^ permalink raw reply
* Re: Annotate another problem report
From: Ryan Anderson @ 2006-08-07 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
In-Reply-To: <7vpsfc1fkt.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, Aug 07, 2006 at 01:00:34PM -0700, Junio C Hamano wrote:
> "git annotate Makefile v1.4.0" outputs this:
Known. I think this is related to the merge-parsing bug.
Unfortunately, the only test cases I've found for this involve things
with both a lot of revisions and a lot of lines, so it's a bit hard to
manually see what's going wrong.
> ...
> 58e60dd2 (Nick Hengeveld 2005-11-02 11:19:24 -0800 13)# git.......
> 58e60dd2 (Nick Hengeveld 2005-11-02 11:19:24 -0800 14)# tra.......
> ( 1970-01-01 00:00:00 15)#
> 6d9bbc50 (Patrick Mauritz 2005-09-19 16:11:19 +0200 16)# ..
> 6d9bbc50 (Patrick Mauritz 2005-09-19 16:11:19 +0200 17)# ..
> ...
>
> There are a handful lines it couldn't tell where they came from:
>
> ( 1970-01-01 00:00:00 15)#
> ( 1970-01-01 00:00:00 179)
> ( 1970-01-01 00:00:00 182)
> ( 1970-01-01 00:00:00 274)endif
> ( 1970-01-01 00:00:00 323)
> ( 1970-01-01 00:00:00 384)else
> ( 1970-01-01 00:00:00 385) LIB_4_ICONV =
>
>
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH] make git compile on old version of engarde linux
From: Michael S. Tsirkin @ 2006-08-07 20:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The following makes git build on my instance of Engarde Linux 1.x
The definition of S_IFLNK and S_ISLNK seems to be mising in the headers,
but a simple test showed that the correct value for it is still 0120000,
same as on more modern systems.
With this patch, git built with
$make NO_CURL=1 NO_SYMLINK_HEAD=1 NO_PYTHON=1
seems to work with no issues so far (more than a week now).
---
Make git build on Engarde Linux 1.x (which is missing
the definition for S_IFLNK/S_ISLNK)
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
--- git/cache.h.orig Thu Jun 29 11:43:45 2006
+++ git/cache.h Thu Jun 29 11:45:13 2006
@@ -6,6 +6,13 @@
#include SHA1_HEADER
#include <zlib.h>
+#ifndef S_IFLNK
+#define S_IFLNK 0120000
+#endif
+#ifndef S_ISLNK
+#define S_ISLNK(m) (((m) & S_IFMT) == S_IFLNK)
+#endif
+
#if ZLIB_VERNUM < 0x1200
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
#endif
--
MST
^ permalink raw reply
* Re: Multiple pulls from the same branch in .git/remotes/origin
From: Michael S. Tsirkin @ 2006-08-07 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu04o1fwm.fsf@assigned-by-dhcp.cox.net>
Quoting r. Junio C Hamano <junkio@cox.net>:
> Subject: Re: Multiple pulls from the same branch in .git/remotes/origin
>
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>
> >> It might not be too difficult to change it though. This part of
> >> the code is relatively old and I do not remember the details
> >> offhand, other than I remember that the first time I saw it I
> >> had the same confused "Huh? we do not let a ref fetched twice?"
> >> reaction ;-).
> >
> > At least, fix the error message?
>
> That would touch the same vicinity of code so if I were to do
> that myself I would rather see if the restriction can be
> loosened properly first.
It seems that have to make path_match in connect.c return an array
of indexes for that to work. Right?
--
MST
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-07 21:47 UTC (permalink / raw)
To: git
In-Reply-To: <7v3bc82v7l.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> This RFC is about better naming of subroutines in gitweb. The patch was
>> generated on top of 'next' (7c7e45d0cc0f482aeb19ecb0b56e9e7b65472c56)
>> using embedded gitweb-rename.sh script.
[...]
>> * git_read_ prefix for subroutines directly accessing git
>> repository files
>
> - (I am not complaining or objecting yet -- this is just an
> observation. ) The distinction between git_get_foo and
> git_read_foo is an implementation detail. The latter could
> signal that the implementation bypasses the published
> interface but depends on the implementation detail of the
> low-level git, so it might be a good idea, but on the other
> hand the only instance is git_read_info_refs which reads from
> .git/info/refs -- and its format is part of the published
> interface -- so I am not so sure this distinction is worth
> it. And certainly we would not want to rely too heavily on
> the current implementation of the low-level git, so we
> obviously do not want to add more git_read_foo's needlessly,
> which makes me feel even less sure if we would want
> git_read_foo...
Currently after rename we have the following git_read_* functions
* git_read_info_refs, which reads .git/info/refs directly and relies on it's
format
* git_read_hash which translates ref to hash by reading ref file
(e.g. .git/refs/heads/master) which means that it doesn't support symrefs
yet; but first, it should be easy to implement without invoking any git
command, and second, there are usually no symrefs beside HEAD, and I'm not
sure that git would work with non-HEAD symref.
* git_read_refs (or rather git_readdir_refs) which reads .git/refs directory
* git_read_projects (or rather git_readdir_projects) which checks for
projects checking if HEAD file exists
* git_read_description which reads .git/description; but in the future
description might be stored in repository config
What is also important is the fast that git_read_* functions are fast,
with exception of git_read_info_refs...
[...]
> If we are to have many more fixes and clean-ups on gitweb,
> readable and consistent names would be very helpful.
>
> The problem is when. If we are going to apply this, we need to
> pick a point of time when not many patches on gitweb are in
> flight; otherwise I'd end up asking people to resend using new
> names.
With two scripts attached to the first post in this thread it would be
simple to apply pre-rename patch, by converting gitweb to pre-rename using
gitweb-unrename.sh script, then applying patch, then restoring new names
using gitweb-rename.sh script, and finally comitting changes (or amending
commit).
But I agree that it would be best to do "subroutine renaming" during lull in
gitweb development.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-07 21:52 UTC (permalink / raw)
To: git
In-Reply-To: <eb8cdh$s6n$1@sea.gmane.org>
Jakub Narebski wrote:
> What is also important is the fast that git_read_* functions are fast,
> with exception of git_read_info_refs...
I meant git_read_refs, which also does refs parsing, which is needed only to
get epoch information to sort refs by epoch, and discard most of them. This
makes summary and tags slow, so matled proposed caching (or extending
info/refs, or making equivalent of info/refs) this information on #git.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Junio C Hamano @ 2006-08-07 22:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eb8cdh$s6n$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Currently after rename we have the following git_read_* functions
>
> * git_read_info_refs, which reads .git/info/refs directly and relies on it's
> format
> * git_read_hash which translates ref to hash by reading ref file
> (e.g. .git/refs/heads/master) which means that it doesn't support symrefs
> yet; but first, it should be easy to implement without invoking any git
> command, and second, there are usually no symrefs beside HEAD, and I'm not
> sure that git would work with non-HEAD symref.
> * git_read_refs (or rather git_readdir_refs) which reads .git/refs directory
> * git_read_projects (or rather git_readdir_projects) which checks for
> projects checking if HEAD file exists
> * git_read_description which reads .git/description; but in the future
> description might be stored in repository config
>
> What is also important is the fast that git_read_* functions are fast,
> with exception of git_read_info_refs...
Hmph. readdir-refs is quite bad for future compatibility, so is
read_hash.
If you want _fast_ then make the implementation fast (or leave
room to make it fast later); encoding the fastness assumption in
the name IS WRONG.
For example, sub git_get_hash (not git_read_hash) can stay as
(potentially buggy wrt symrefs) "reading from .git/refs/$thing"
or could even be fixed to read from git-rev-parse (which is the
kosher way). If it turns out to be a bottleneck, it could be
rewritten using Git.xs. The same thing for read_refs which I
think should be doing ls-remote on the repository if it wants to
be kosher.
>> The problem is when...
>
> With two scripts attached to the first post in this thread it would be
> simple to apply pre-rename patch, by converting gitweb to pre-rename using
> gitweb-unrename.sh script, then applying patch, then restoring new names
> using gitweb-rename.sh script, and finally comitting changes (or amending
> commit).
That assumes the rename be done now, and nobody introduces new
functions following old naming convention in the meantime.
^ permalink raw reply
* Re: Multiple pulls from the same branch in .git/remotes/origin
From: Junio C Hamano @ 2006-08-07 22:04 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20060807210545.GC24206@mellanox.co.il>
"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> It seems that have to make path_match in connect.c return an array
> of indexes for that to work. Right?
I do not recall why Linus placed that "*s = 0" in there. That
is the one that makes the same ref not match more than once.
It _could_ be that the fix is just the matter of removing that
line, but it may have interesting consequences; I dunno offhand.
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-07 22:15 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pwo1a0r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> What is also important is the fast that git_read_* functions are fast,
>> with exception of git_read_info_refs...
>
> Hmph. readdir-refs is quite bad for future compatibility, so is
> read_hash.
Fast = doesn't call git commands, so no delay for fork+exec.
> If you want _fast_ then make the implementation fast (or leave
> room to make it fast later); encoding the fastness assumption in
> the name IS WRONG.
Matthias Lederhofer has noticed that parsing all the tags in "summary" and
"tags" views, while we use only epoch/timestamp information to sort them
and discard most of parsed input, is bottleneck due to the fact that
usually number of tags is linear with history (version tags) and the fact
that for each tag is one invocation of git (one fork, two execs).
> For example, sub git_get_hash (not git_read_hash) can stay as
> (potentially buggy wrt symrefs) "reading from .git/refs/$thing"
> or could even be fixed to read from git-rev-parse (which is the
> kosher way). If it turns out to be a bottleneck, it could be
> rewritten using Git.xs. The same thing for read_refs which I
> think should be doing ls-remote on the repository if it wants to
> be kosher.
True. So _read_ based on actually reading the files is out.
git_get_hash_by_ref, git_get_HEAD_hash (or just git_get_ref, git_get_head)
return single scalar value; git_read_info_refs and git_read_refs return
reference to hash or array, while git_read_projects returns array.
So the new guidelines would be:
* git_get_ prefix for subroutines related to git repository
and returning single scalar (single value).
* git_read_ prefix for subroutines related to git repository, reading some
files or multiline output, and returning hash reference, or list
reference, or list.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Multiple refs from the same remote in one git fetch
From: Michael S. Tsirkin @ 2006-08-07 22:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu04o1fwm.fsf@assigned-by-dhcp.cox.net>
Quoting r. Junio C Hamano <junkio@cox.net>:
> > At least, fix the error message?
>
> That would touch the same vicinity of code so if I were to do
> that myself I would rather see if the restriction can be
> loosened properly first.
The following seems to fix this issue: simply scan the full
refspec list for each remote instead of breaking on the first match.
I had to touch the git-fetch.sh script as well as it is scanning
the remote list, too. Works for me.
---
Fix git fetch for when multiple refspecs reference the same remote head.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
diff --git a/Makefile b/Makefile
diff --git a/connect.c b/connect.c
index 4422a0d..3880191 100644
--- a/connect.c
+++ b/connect.c
@@ -115,6 +115,7 @@ int get_ack(int fd, unsigned char *resul
int path_match(const char *path, int nr, char **match)
{
int i;
+ int found = 0;
int pathlen = strlen(path);
for (i = 0; i < nr; i++) {
@@ -128,9 +129,9 @@ int path_match(const char *path, int nr,
if (pathlen > len && path[pathlen - len - 1] != '/')
continue;
*s = 0;
- return (i + 1);
+ found = i + 1;
}
- return 0;
+ return found;
}
struct refspec {
diff --git a/fetch-pack.c b/fetch-pack.c
diff --git a/git-fetch.sh b/git-fetch.sh
index c2eebee..c35bae6 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -373,26 +373,22 @@ fetch_main () {
+$remote_name:*)
single_force=t
not_for_merge=
- found="$ref"
- break ;;
+ found="$ref";;
.+$remote_name:*)
single_force=t
not_for_merge=t
- found="$ref"
- break ;;
+ found="$ref";;
.$remote_name:*)
not_for_merge=t
- found="$ref"
- break ;;
+ found="$ref";;
$remote_name:*)
not_for_merge=
- found="$ref"
- break ;;
+ found="$ref";;
esac
- done
- local_name=$(expr "z$found" : 'z[^:]*:\(.*\)')
- append_fetch_head "$sha1" "$remote" \
+ local_name=$(expr "z$found" : 'z[^:]*:\(.*\)')
+ append_fetch_head "$sha1" "$remote" \
"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
+ done
done
) || exit ;;
esac
--
MST
^ permalink raw reply related
* Re: Problem with clone hanging
From: Bryan O'Sullivan @ 2006-08-07 22:26 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Erik Mouw, git
In-Reply-To: <20060807183230.GA14955@procyon.home>
On Mon, 2006-08-07 at 22:32 +0400, Sergey Vlasov wrote:
> On Mon, Aug 07, 2006 at 11:23:20AM -0700, Bryan O'Sullivan wrote:
> > On Mon, 2006-08-07 at 21:52 +0400, Sergey Vlasov wrote:
> >
> > > In the meantime, you can try to specify a local clone of the mainline
> > > Linux repository with the --reference=... option to git-clone.
> >
> > Thanks. I don't know if what I'm cloning is actually a kernel tree,
> > unfortunately.
>
> At least git ls-remote git://www.mellanox.co.il/~git/infiniband
> suggests this.
Thanks. This got me unwedged.
<b
^ permalink raw reply
* Re: Multiple pulls from the same branch in .git/remotes/origin
From: Michael S. Tsirkin @ 2006-08-07 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmegyzgb.fsf@assigned-by-dhcp.cox.net>
Quoting r. Junio C Hamano <junkio@cox.net>:
> Subject: Re: Multiple pulls from the same branch in .git/remotes/origin
>
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>
> > It seems that have to make path_match in connect.c return an array
> > of indexes for that to work. Right?
>
> I do not recall why Linus placed that "*s = 0" in there. That
> is the one that makes the same ref not match more than once.
Hmm, as I read it, this marks the *match* as already found.
This seems to be what makes the sanity check in main work:
/* If the heads to pull were given, we should have
* consumed all of them by matching the remote.
* Otherwise, 'git-fetch remote no-such-ref' would
* silently succeed without issuing an error.
*/
What stops it is return i + 1 in path_match, no?
I think the issue is that path_match will stop at first match and not
label multiple matches, so later sanity check in main errors out.
> It _could_ be that the fix is just the matter of removing that
> line, but it may have interesting consequences; I dunno offhand.
>
>
What I did is just scan the full list of refspecs instead of breaking
out at the first match.
--
MST
^ permalink raw reply
* RE: Problem with clone hanging
From: Bryan O'Sullivan @ 2006-08-07 22:34 UTC (permalink / raw)
To: Tziporet Koren; +Cc: Erik Mouw, git, Michael S. Tsirkin
In-Reply-To: <6AB138A2AB8C8E4A98B9C0C3D52670E301FA761E@mtlexch01.mtl.com>
On Mon, 2006-08-07 at 21:57 +0300, Tziporet Koren wrote:
> OK we will upgrade our git installation (but it will be only tomorrow)
> You are correct - we have not set HTTP interface.
It's OK - Sergey's workaround did the trick for me.
<b
^ 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