* Re: garbage in the cogito.git repository
From: Petr Baudis @ 2005-08-05 0:06 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20050731124228.GB11570@procyon.home>
Dear diary, on Sun, Jul 31, 2005 at 02:42:28PM CEST, I got a letter
where Sergey Vlasov <vsu@altlinux.ru> told me that...
> Hello!
Hi,
> Today's pull from rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> downloaded more than 10 MB. It seems that the cogito.git repository
> currently contains all objects in unpacked form, even though most of
> that objects are already in pack files.
>
> Also there are two mysterious files:
>
> objects/base.idx
> objects/base.pack
>
> Could this be fixed?
yes, sorry about this. Packs got there through rsyncs all the way from
git-core, and my immediate naive git-unpack-objects didn't actually do
anything since all the objects were, well, in
.git/objects/pack/thatpackfile. Obviously, this behaviour is reasonable
when you think about it, but rather pitfallous, I would say. At least
documenting it might be worthwhile.
BTW, if you pull now, be prepared to get git-core from elsewhere, since
it will disappear from under your hands as I just unbundled it from
Cogito. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: garbage in the cogito.git repository
From: Petr Baudis @ 2005-08-05 0:10 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20050805000613.GD3900@pasky.ji.cz>
Dear diary, on Fri, Aug 05, 2005 at 02:06:13AM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
> yes, sorry about this. Packs got there through rsyncs all the way from
> git-core, and my immediate naive git-unpack-objects didn't actually do
> anything since all the objects were, well, in
> .git/objects/pack/thatpackfile. Obviously, this behaviour is reasonable
> when you think about it, but rather pitfallous, I would say. At least
> documenting it might be worthwhile.
To clarify, I want to use packs, yes. But plenty of Cogito users are
using HTTP and I want to give them some time to upgrade to the latest
Git which supports pulling packs over HTTP. I'd say at least two to
three weeks or me getting near the top of kernel.org object users,
whichever comes first. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: cg-clone failing to get cogito latest tree.
From: Petr Baudis @ 2005-08-05 0:15 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f905073119492e521bde@mail.gmail.com>
Dear diary, on Mon, Aug 01, 2005 at 04:49:37AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> On a new machine, trying to boostrap into latest cogito, I download
> and make cogito 0.12.1, and then...
>
> $ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git cogito
> defaulting to local storage area
> 14:48:53 URL:http://www.kernel.org/pub/scm/cogito/cogito.git/refs/heads/master
> [41/41] -> "refs/heads/origin" [1]
> progress: 34 objects, 45126 bytes
> error: File d2072194059c65f92487c84c53b9f6b5da780d14
> (http://www.kernel.org/pub/scm/cogito/cogito.git/objects/d2/072194059c65f92487c84c53b9f6b5da780d14)
> corrupt
>
> Cannot obtain needed blob d2072194059c65f92487c84c53b9f6b5da780d14
> while processing commit 0000000000000000000000000000000000000000.
> cg-pull: objects pull failed
> cg-init: pull failed
>
> any hints? I have a similar problem fetching git with cg-clone:
That was caused by inadvertent packs appearance in the Cogito
repository. Should be fixed now, sorry about any trouble.
> $ cg-clone http://www.kernel.org/pub/scm/git/git.git git
> defaulting to local storage area
> 14:53:44 URL:http://www.kernel.org/pub/scm/git/git.git/refs/heads/master
> [41/41] -> "refs/heads/origin" [1]
> progress: 2 objects, 4666 bytes
> error: File 6ff87c4664981e4397625791c8ea3bbb5f2279a3
> (http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3)
> corrupt
>
> Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3
> while processing commit 0000000000000000000000000000000000000000.
> cg-pull: objects pull failed
> cg-init: pull failed
>
> Probably doing somethginf hopelessly wrong...
Newer Git version should cure that. If you want to get it by Git,
though, you might want to defer to rsync transport for a moment.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: Tree tags again..
From: Junio C Hamano @ 2005-08-05 0:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508041702180.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio, maybe there should be some test-case for this:
>
> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
> error: remote ref 'refs/tags/v2.6.11' is not a strict subset of local ref 'refs/tags/v2.6.11'.
I assume this is syncing two linux-2.6 repo which both have the
same refs/tags/v2.6.11 (tree tag).
Sorry, in send_pack(), up-to-date check should be made first
before ref_newer() check. My mistake.
A more interesting question is what to do if they are indeed
different trees. More realistically, you may decide to
retroactively create a commit that wraps the same v2.6.11 tree,
perhaps grafting it in front of the current 2.6.12-rcX based
history, and replace 'refs/tags/v2.6.11' with a tag to that
commit. What should happen?
I do not have a good answer to that. From the end-user point of
view, we _could_ treat tags differently from heads in that we
always omit the ref_newer() check, but from the machinery point
of view, I think the plumbing should just ask the user to use
the --force when such a tag is involved.
------------
diff --git a/send-pack.c b/send-pack.c
--- a/send-pack.c
+++ b/send-pack.c
@@ -173,6 +173,10 @@ static int send_pack(int in, int out, in
char old_hex[60], *new_hex;
if (!ref->peer_ref)
continue;
+ if (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {
+ fprintf(stderr, "'%s': up-to-date\n", ref->name);
+ continue;
+ }
if (!is_zero_sha1(ref->old_sha1)) {
if (!has_sha1_file(ref->old_sha1)) {
error("remote '%s' object %s does not "
@@ -188,10 +192,6 @@ static int send_pack(int in, int out, in
continue;
}
}
- if (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {
- fprintf(stderr, "'%s': up-to-date\n", ref->name);
- continue;
- }
memcpy(ref->new_sha1, ref->peer_ref->new_sha1, 20);
if (is_zero_sha1(ref->new_sha1)) {
error("cannot happen anymore");
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Junio C Hamano @ 2005-08-05 0:20 UTC (permalink / raw)
To: git; +Cc: barkalow, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.62.0508041804120.23721@iabervon.org>
barkalow@iabervon.org writes:
> ... I seem to recall a patch to create subdirectories of
> .git/refs on demand (needed for tags/v99/1). I'd say just
> .git/objects/(everything), .git/refs, and .git/info.
Having thought about this a bit more, I am inclined to drop
this. I see the template mechanism to be something that lets
site and project policy makers set up the repositories to suit
their taste, by having their users point their own template
directory via the GIT_TEMPLATE_DIRECTORY environment variable.
How $GIT_DIR/refs/heads/ and $GIT_DIR/refs/tags/ are used are
quite deeply ingrained in the core tools, and there is no point
pretending as if they can be overridden; they are not.
As Daniel says, refs/*/ are created mostly on-demand [*1*], so
it is not strictly necessary to create "heads" and "tags"
upfront, but they are so basic that I'd feel comfortable to keep
them part of what are done by git-init-db.
[Footnote]
*1* I fixed one in receive-pack recently, but please fix things
if you find any of the core tools assume that the leading paths
already exist.
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Johannes Schindelin @ 2005-08-05 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmznxwfka.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 4 Aug 2005, Junio C Hamano wrote:
> Oh, I see. Then the "templates/Makefile building into
> templates/blt and then installing if you say make install"
> approach I described earlier would hopefully work perfectly well
> for you. Just like you tack the $src to your $PATH, you can
> define GIT_TEMPLATE_DIRECTORY to $src/templates/blt. Problem
> solved.
Yes. Call me an idiot.
Yours truly,
Dscho
^ permalink raw reply
* [RFC] git homepage
From: Petr Baudis @ 2005-08-05 1:27 UTC (permalink / raw)
To: git
Hello,
as I promised some time ago, I finally put together a simple GIT
homepage proposal now available at:
http://git.or.cz/
Basically, I took r3 of Ryan Anderson's synopsis, pruned and rewrote
it a bit, added some hypertext and tried to very briefly cover the
porcelain as well. Please tell me what you think, and if you happen to
be author of some porcelain, already mentioned or not, feel encouraged
to send me updates to your description (which should stay brief, though)
etc. And if you don't author any porcelain, send me updates anyway. :-)
If you like it, it's only up to Junio to decide how official to make
it and possibly/probably take over its maintenance (or designate someone
more suitable than me to do that).
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [RFC] git homepage
From: Junio C Hamano @ 2005-08-05 2:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050805012728.GO24479@pasky.ji.cz>
Petr Baudis <pasky@ucw.cz> writes:
> http://git.or.cz/
Wonderful.
Once the page contents stabilizes, it would be a good idea to
get it added in the page top links of http://www.kernel.org/git
page. Sorry, I do not know who is in charge of configuring the
gitweb there.
BTW, it may be technically correct, but the combination of
"rsync" and "www" on the 3rd line of http://www.kernel.org/git
caught my attention there ;-).
cg-clone rsync://www.kernel.org/pub/scm/ + project path
^ permalink raw reply
* [ANNOUNCE] Cogito-0.13
From: Petr Baudis @ 2005-08-05 2:03 UTC (permalink / raw)
To: git
Hi,
I'm happy to announce release 0.13 of the Cogito SCMish layer over the
GIT Tree History Storage tool. As usual, get it at:
http://www.kernel.org/pub/software/scm/cogito
Highlights:
* Cogito is now alone!
GIT is no longer part of Cogito distribution.
That means you need to get and install it separately.
It is recommended to use at least 0.99.3. The newer
the better (hopefully).
* Partial support for invoking commands from subdirectories
This works only for very few commands yet
(cg-diff, cg-status, cg-add, cg-rm), but I'm working
on it. Other commands will just refuse to run if you
call them from a subdirectory.
* .gitignore support in cg-status
* cg-info is not anymore; its output is part of cg-status
* cg-restore -f will overwrite even local modifications
* Portability fixes
* Plenty of other bugfixes
Have fun,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [RFC] git homepage
From: Petr Baudis @ 2005-08-05 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kay Sievers, git
In-Reply-To: <7v64ulqh24.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Aug 05, 2005 at 04:00:03AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@ucw.cz> writes:
>
> > http://git.or.cz/
>
> Wonderful.
>
> Once the page contents stabilizes, it would be a good idea to
> get it added in the page top links of http://www.kernel.org/git
> page. Sorry, I do not know who is in charge of configuring the
> gitweb there.
I tend to harass Kay Sievers, with measurable effects. :-)
> BTW, it may be technically correct, but the combination of
> "rsync" and "www" on the 3rd line of http://www.kernel.org/git
> caught my attention there ;-).
>
> cg-clone rsync://www.kernel.org/pub/scm/ + project path
Actually, HTTP should be working again now; but it's rather fresh yet so
we should keep it rsync anyway for a while yet for the users of older
GIT/Cogito versions.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.13
From: Chris Wright @ 2005-08-05 2:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050805020307.GP24479@pasky.ji.cz>
* Petr Baudis (pasky@suse.cz) wrote:
> * Cogito is now alone!
> GIT is no longer part of Cogito distribution.
> That means you need to get and install it separately.
> It is recommended to use at least 0.99.3. The newer
> the better (hopefully).
That's great. RPMs uploading to:
http://www.kernel.org/pub/software/scm/cogito/RPMS
I think we can make this a noarch rpm since it's scripts only now.
thanks,
-chris
^ permalink raw reply
* Re: [RFC] git homepage
From: Junio C Hamano @ 2005-08-05 3:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <20050805021214.GQ24479@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Actually, HTTP should be working again now; but it's rather fresh yet so
> we should keep it rsync anyway for a while yet for the users of older
> GIT/Cogito versions.
My point being rsync://rsync.kernel.org/ vs http://www.kernel.org/.
^ permalink raw reply
* Re: Experiences with git-clone-pack and rsync
From: Junio C Hamano @ 2005-08-05 6:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508042230150.24657@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But maybe I just cried "wolf"...
I do not think you are crying wolf. I shared the same concern
from the beginning and that was partly why I was pushing for
the dumb server approach.
^ permalink raw reply
* Re: gitweb: not all files listed in commit list
From: Sven Verdoolaege @ 2005-08-04 8:39 UTC (permalink / raw)
To: Olof Johansson; +Cc: git, H. Peter Anvin
In-Reply-To: <20050804014916.GB10556@austin.ibm.com>
On Wed, Aug 03, 2005 at 08:49:16PM -0500, Olof Johansson wrote:
> Hi,
>
> My apologies if this has already been found and reported; I'm not
> tracking the list closely.
>
> It seems that newly introduced files are not shown in gitweb.
> For example, see the following commit:
>
> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fce0d5740322b98b863f9e609f5a9bd4c06703af
That's probably because either git-core or gitweb needs updating.
New files used to be indicated by an 'N', whereas an 'A' is used now.
skimo
^ permalink raw reply
* Re: gitweb: not all files listed in commit list
From: Kay Sievers @ 2005-08-04 9:02 UTC (permalink / raw)
To: Olof Johansson, git, H. Peter Anvin
In-Reply-To: <20050804083916.GL991MdfPADPa@garage.linux.student.kuleuven.ac.be>
On Thu, Aug 04, 2005 at 10:39:16AM +0200, Sven Verdoolaege wrote:
> On Wed, Aug 03, 2005 at 08:49:16PM -0500, Olof Johansson wrote:
> > Hi,
> >
> > My apologies if this has already been found and reported; I'm not
> > tracking the list closely.
> >
> > It seems that newly introduced files are not shown in gitweb.
> > For example, see the following commit:
> >
> > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fce0d5740322b98b863f9e609f5a9bd4c06703af
>
> That's probably because either git-core or gitweb needs updating.
> New files used to be indicated by an 'N', whereas an 'A' is used now.
Gitweb already expects the new format. The git binaries need to be updated.
Kay
^ permalink raw reply
* Re: [RFC] git homepage
From: Kay Sievers @ 2005-08-05 9:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20050805021214.GQ24479@pasky.ji.cz>
On Fri, Aug 05, 2005 at 04:12:14AM +0200, Petr Baudis wrote:
> Dear diary, on Fri, Aug 05, 2005 at 04:00:03AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
> > Petr Baudis <pasky@ucw.cz> writes:
> >
> > > http://git.or.cz/
> >
> > Wonderful.
> >
> > Once the page contents stabilizes, it would be a good idea to
> > get it added in the page top links of http://www.kernel.org/git
> > page. Sorry, I do not know who is in charge of configuring the
> > gitweb there.
>
> I tend to harass Kay Sievers, with measurable effects. :-)
You are welcome to do so. :)
> > BTW, it may be technically correct, but the combination of
> > "rsync" and "www" on the 3rd line of http://www.kernel.org/git
> > caught my attention there ;-).
> >
> > cg-clone rsync://www.kernel.org/pub/scm/ + project path
>
> Actually, HTTP should be working again now; but it's rather fresh yet so
> we should keep it rsync anyway for a while yet for the users of older
> GIT/Cogito versions.
Changed both to rsync now. Let me know, when we want to switch to http
again.
Best,
Kay
^ permalink raw reply
* Re: Tree tags again..
From: Junio C Hamano @ 2005-08-05 9:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508041702180.3258@g5.osdl.org>
Sorry about the breakage. I pushed out a fix.
Since you always give me hard time with this "tree-tag", I
decided to trump it with an even weirder tag myself. We will
see what else would break shortly ;-).
^ permalink raw reply
* Template files location
From: Petr Baudis @ 2005-08-05 9:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Wright, Linus Torvalds, git
In-Reply-To: <7vd5otov7s.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Aug 05, 2005 at 06:37:11AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> We install files in $(HOME)/etc/git-core/templates/ directory.
>
> In the standard binary distribution scheme, it should probably
> go to either /usr/share or /etc; the former if the distribution
> prefers static boilerplate files in /usr/share, latter if we
> consider them site-specific conffiles. I just discussed this
> privately with a Debian person on the list today, and we are in
> favor of installing it under /usr/share/git-core/templates,
> because we do not expect the contents of the standard templates
> directory will not be a per-site customization [*1*].
>
> In any case, this means that the make drivers like spec.in and
> debian/rules would need to override some make variables when
> they invoke the main Makefile.
Any reason why that's not the default destination then?
Or you can try /etc/git-core/ and fall back to /usr/share/git-core :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* git-cvs-import-script problems
From: David Kågedal @ 2005-08-05 10:14 UTC (permalink / raw)
To: git
I just tried importing a large CVS repository to git, using "git
cvsimport". It managed to import a lot of files and revisions, but
half-way through, it stopped with this message:
Unknown: F
As far as I can till, this "F" probably came from the CVS server
process. Could it be that my CVS is too new or too old?
I'm using git b03e2d2091153d239063cfc086a840d74a9eadde, cvs 1.11.20,
cvsps 2.1, and the CVS repository is a local directory.
Also, when the process stops, I have .git/HEAD pointing to
refs/heads/master (which doesn't exist). I thought it would be
pointing to refs/heads/origin.
--
David Kågedal
^ permalink raw reply
* Re: Display of merges in gitk
From: Linus Torvalds @ 2005-08-05 14:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17130.56620.137642.941175@cargo.ozlabs.ibm.com>
On Fri, 29 Jul 2005, Paul Mackerras wrote:
>
> I have reworked the way gitk displays merges.
Ok, goodie. It works fine in my environment, with most merges showing up
as not interesting. But a merge like
3e0777b8fa96f7073ed5d13d3bc1d573b766bef9
shows an example of where there was actually both real content merges, and
some real clashes.
However, most of the content merges were trivial, and they often hide the
real clashes. For example, if you click on that merge, a _lot_ of it looks
like it might be clashes, even though most of it was auto-merged. This is
not really a problem, but I get the feeling that it could be improved
somehow - maybe a button that hides the parts that don't have clashes?
> In the usual case of two parents, lines from the first parent are in red
> and lines from the second parent are in blue. Lines in the result that
> don't correspond to either parent are in bold black.
To get the alternate output, maybe something like:
- run "merge" on the original/parent1/parent2 (the same way the
git-merge-one-file-script does)
- anything that merged fine is in black (regardless of which parent it
came from), and then mark the merge rejects are in red/blue depending
on parent?
I don't know how doable that would be.
Linus
^ permalink raw reply
* gitk "hyperlinks" (was Re: Display of merges in gitk)
From: Linus Torvalds @ 2005-08-05 14:37 UTC (permalink / raw)
To: Paul Mackerras, Kay Sievers; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508050658260.3258@g5.osdl.org>
[ Also Kay Sievers, because the clickability thing sounds like a
potentially good thing for webgit too.. ]
For 2.6.13 we've been reverting some stuff lately, to make sure we get a
stable release. That's fine, and when I revert something I try to mention
the commit ID of the thing I revert in the message. Apparently others do
too, as indicated by a patch I just got from Petr Vandovec. So we've got
for example:
889371f61fd5bb914d0331268f12432590cf7e85:
Author: Linus Torvalds <torvalds@g5.osdl.org> 2005-07-30 13:41:56
Committer: Linus Torvalds <torvalds@g5.osdl.org> 2005-07-30 13:41:56
Revert "yenta free_irq on suspend"
ACPI is wrong. Devices should not release their IRQ's on suspend and
re-aquire them on resume. ACPI should just re-init the IRQ controller
instead of breaking most drivers very subtly.
Breakage reported by Hugh Dickins <hugh@veritas.com>
Undo: d8c4b4195c7d664baf296818bf756775149232d3
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
and
403fe5ae57c831968c3dbbaba291ae825a1c5aaa:
Author: Petr Vandrovec <vandrove@vc.cvut.cz> 2005-08-05 06:50:07
Committer: Linus Torvalds <torvalds@g5.osdl.org> 2005-08-05 06:57:44
[PATCH] rtc: msleep() cannot be used from interrupt
Since the beginning of July my Opteron box was randomly crashing and
being rebooted by hardware watchdog. Today it finally did it in front
of me, and this patch will hopefully fix it.
The problem is that at the end of June (the 28th, to be exact: commit
47f176fdaf8924bc83fddcf9658f2fd3ef60d573, "[PATCH] Using msleep()
instead of HZ") rtc_get_rtc_time ...
and when I use gitk, it would be just too damn cool for words if I could
easily follow the SHA1's mentioned in the commit message.
I can just cut-and-paste the SHA1, and I've verified that it works fine.
However, as you'v enoticed, I'm of the whiny kind, and I thought it could
be easier. So I'm whining again.
<whine>Mommy, mommy, can you make my life easier</whine>
So I noticed that I really would like two things:
- "clickable" SHA1's in commit messages would be really really cool if
something like that is even possible with tcl/tk.
Now, if you can highlight them when showing the message, that would be
extra cool, but even without any highlighing, the thing actually
_almost_ works fine already: you can double-click the SHA1, and it will
select it. You then have to move the mouse to the "goto" window, and
paste in the SHA1 there. And this is where it would be good if this
sequence could be simplified a bit.
Even if it's something as simple as accepting the SHA1 paste into the
same window (not having to go to the "goto" window: just double-click
on the SHA1, and then right-click to "paste it back").
- I'd like to have a "back button". Not just for the above kind of thing,
but in general too: when searching for something, it would just be very
nice if gitk just kept a list of the <n> last commits that have
been selected, and there was a web-browser-like button that went
back/forward in history.
But especially when looking at a revert, I just want to first go to the
thing we revert, see what's going on there (get the "historical
perspective" - commit log for why the original was done etc), and then
I'd want to go back (and possibly forth and back again ;). And while
the revert mentioned the thing it reverted (so I could cut-and-paste),
the thing it reverted obviously does _not_ mention the thing that
reverted it, so now I have to manually just scroll back.
This same thing happens for a failed search (I search for xyz, and it
actually finds it, and I realize that that was the wrong search, but
now I'm two months back..)
<whine>Mommy, mommy, pleeeease</whine>
Linus
^ permalink raw reply
* Re: Terminology
From: Johannes Schindelin @ 2005-08-05 14:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhdeaj05n.fsf@assigned-by-dhcp.cox.net>
Hi,
I am finally finished with my preliminary survey: I took what you sent as
a strawman, and inserted what I found (I tried to say only something about
ambiguous naming):
- The unit of storage in GIT is called "object"; no other word
is used and the word "object" is used only for this purpose
so this one is OK.
- A 20-byte SHA1 to uniquely identify "objects"; README and
early Linus messages call this "object name" so does
tutorial. Many places say "object SHA1" or just "SHA1".
"Object" is short for "immutable object". git-cat-file.txt says
"repository object".
- An "object database" stores a set of "objects", and an
individial object can be retrieved by giving it its object
name.
Tutorial calls it an "object store". git-fsck-cache.txt names it
"database" at first, but then also uses "object pool".
- Storing a regular file or a symlink in the object database
results in a "blob object" created. You cannot directly
store filesystem directory, but a collection of blob objects
and other tree objects can be recorded as a "tree object"
which corresponds to this notion.
- $GIT_INDEX_FILE is "index file", which is a collection of
"cache entries". The former is sometimes called "cache
file", the latter just "cache".
Tutorial says "cache" aka "index". Though technically, a cache
is the index file _plus_ the related objects in the object database.
git-update-cache.txt even makes the difference between the "index"
and the "directory cache".
- the directory which corresponds to the top of the hierarchy
described in the index file; I've seen words like "working
tree", "working directory", "work tree" used.
The tutorial initially says "working tree", but then "working
directory". Usually, a directory does not include its
subdirectories, though. git-apply-patch-script.txt, git-apply.txt,
git-hash-object.txt, git-read-tree.txt
use "work tree". git-checkout-cache.txt, git-commit-tree.txt,
git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain
"working directory". git-diff-files.txt talks about a "working tree".
- When the stat information a cache entry records matches what
is in the work tree, the entry is called "clean" or
"up-to-date". The opposite is "dirty" or "not up-to-date".
- An index file can be in "merged" or "unmerged" state. The
former is when it does not have anything but stage 0 entries,
the latter otherwise.
That seems to be unambiguous (sometimes it's called "index",
sometimes "index file"; I don't think that matters).
- An merged index file can be written as a "tree object", which
is technically a set of interconnected tree objects but we
equate it with the toplevel tree object with this set.
- A "tree object" can be recorded as a part of a "commit
object". The tree object is said to be "associated with" the
commit object.
In diffcore.txt, "changeset" is used in place of "commit".
- A "tag object" can be recorded as a pointer to another object
of any type. The act of following the pointer a tag object
holds (this can go recursively) until we get to a non-tag
object is sometimes called "resolving the tag".
- The following objects are collectively called "tree-ish": a
tree object, a commit object, a tag object that resolves to
either a commit or a tree object, and can be given to
commands that expect to work on a tree object.
We could call this category an "ent".
- The files under $GIT_DIR/refs record object names, and are
called "refs". What is under refs/heads/ are called "heads",
refs/tags/ "tags". Typically, they are either object names
of commit objects or tag objects that resolve to commit
objects, but a tag can point at any object.
The tutorial never calls them "refs", but instead "references".
- A "head" is always an object name of a commit, and marks the
latest commit in one line of development. A line of
development is often called a "branch". We sometimes use the
word "branch head" to stress the fact that we are talking
about a single commit that is the latest one in a "branch".
In the tutorial, the latter is used in reverse: it talks about a
"HEAD development branch" and a "HEAD branch".
I find it a little bit troublesome that $GIT_DIR/branches does not
really refer to a branch, but rather to a (possibly remote) repository.
- Combining the states from more than one lines of developments
is called "merging" and typically done between two branch
heads. This is called "resolving" in the tutorial and there
is git-resolve-script command for it.
- A set of "refs" with the set of objects reachable from them
constitute a "repository". Although currently there is no
provision for a repository to say that its objects are stored
in this and that object database, multiple repositories can
share the same object database, and there is not a conceptual
limit that a repository must retrive its objects from a
single object database.
This is referred to as "git archive" in the tutorial at first,
and later as "repository". However, in "Copying archives", a
very confusing explanation tells us that a "repository" normally
is a "working tree", where I would rather say that the repository
lives inside a hidden subdirectory of the working tree.
git-fsck-cache.txt talks about an "archive", too. However, it then
says "valid tree", when sureley a repository is meant.
Everywhere else, it is called "repository".
- The act of finding out the object names recorded in "refs" a
different repository records, optionally updating a local
"refs" with their values, and retrieving the objects
reachable from them is called "fetching". Fetching immediately
followed by merging is called "pulling".
In that sense, git-http-pull would be more appropriately named
git-http-fetch, and analogous git-ssh-pull.
Also, git-pull-script.txt says "Pull and merge", contradicting this
definition.
- The act of updating "refs" in a different repository with new
value and populating the object database(s) associated with
the repository is called "pushing".
- Currently refs/heads records branch heads of both locally
created branches and branches fetched from other
repositories.
- Currently, fetching always happen against a single branch
head on a remote repository, and (a remote repository, name
of the branch) is stored in $GIT_DIR/branches/ as a
short-hand mechanism. A file in this directory identifies
a remote repository by its URL, and the branch to fetch/pull
from is identified with the URL fragment notation, absense of
which makes it default to "master".
- a "pack" usually consists of two files: a file containing objects
in a compressed format, and an index to the first file. If the
pack is uncompressed at once (e.g. when git-clone is called), the
index is not necessary.
git-pack-objects calls this a "packed archive" first, but then reverts
to "pack". git-show-index.txt and git-verify-pack.txt call the .pack file
"packed GIT archive", and the index "idx file". git-unpack-objects.txt
calls the .pack file "pack archive".
I'd also add a short explanation of the following unambiguous terms:
"plumbing", also referred to as "core": the basic set of programs and
scripts usable to half-gods like Linus.
"porcelain", also referred to as "SCM": a thin layer over the plumbing
making GIT usage nice to regular people.
"type": one of the identifiers "commit","tree","tag" and "blob" describing
the type of an object.
Ciao,
Dscho
^ permalink raw reply
* Re: git-cvs-import-script problems
From: David Kågedal @ 2005-08-05 14:46 UTC (permalink / raw)
To: git
In-Reply-To: <u5tfytoitbw.fsf@fidgit.hq.vtech>
David Kågedal <davidk@lysator.liu.se> writes:
> I just tried importing a large CVS repository to git, using "git
> cvsimport". It managed to import a lot of files and revisions, but
> half-way through, it stopped with this message:
>
> Unknown: F
>
> As far as I can till, this "F" probably came from the CVS server
> process. Could it be that my CVS is too new or too old?
Upgrading to CVS 1.12.1 seems to have helped.
--
David Kågedal
^ permalink raw reply
* [PATCH] Assorted documentation patches
From: Johannes Schindelin @ 2005-08-05 15:05 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 344 bytes --]
Hi,
while sifting through the documentation to find different namings for the
same concepts, I saw a few things here and there, which I fixed. Since the
sifting was quite numbing, there might be some wrong "fixes".
Sorry, patch is attached, because I still can't convince my pine (version
4.63) to send single space lines :-(
Ciao,
Dscho
[-- Attachment #2: Type: TEXT/plain, Size: 15615 bytes --]
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -62,7 +62,7 @@ customization also applies to "git-diff-
1. When the environment variable 'GIT_EXTERNAL_DIFF' is not set,
these commands internally invoke "diff" like this:
- diff -L a/<path> -L a/<path> -pu <old> <new>
+ diff -L a/<path> -L b/<path> -pu <old> <new>
+
For added files, `/dev/null` is used for <old>. For removed
files, `/dev/null` is used for <new>
@@ -101,7 +101,7 @@ For a path that is unmerged, 'GIT_EXTERN
parameter, <path>.
-Git specific extention to diff format
+Git specific extension to diff format
-------------------------------------
What -p option produces is slightly different from the
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -5,9 +5,9 @@
Synonym for "-p".
-r::
- Look recursivelly in subdirectories; this flag does not
+ Look recursively in subdirectories; this flag does not
mean anything to commands other than "git-diff-tree";
- other commands always looks at all the subdirectories.
+ other diff commands always look at all the subdirectories.
-z::
\0 line termination on output
diff --git a/Documentation/git-diff-cache.txt b/Documentation/git-diff-cache.txt
--- a/Documentation/git-diff-cache.txt
+++ b/Documentation/git-diff-cache.txt
@@ -50,13 +50,13 @@ Cached Mode
-----------
If '--cached' is specified, it allows you to ask:
- show me the differences between HEAD and the current index
+ show me the differences between HEAD and the current cache
contents (the ones I'd write with a "git-write-tree")
-For example, let's say that you have worked on your index file, and are
-ready to commit. You want to see eactly *what* you are going to commit is
-without having to write a new tree object and compare it that way, and to
-do that, you just do
+For example, let's say that you have worked on your working directory, updated
+some files in the cache and are ready to commit. You want to see eactly
+*what* you are going to commit is without having to write a new tree
+object and compare it that way, and to do that, you just do
git-diff-cache --cached $(cat .git/HEAD)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -86,7 +86,7 @@ Or if you are searching for what changed
and it will ignore all differences to other files.
The pattern is always the prefix, and is matched exactly. There are no
-wildcards. Even stricter, it has to match complete path comonent.
+wildcards. Even stricter, it has to match a complete path component.
I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h`
so it can be used to name subdirectories.
diff --git a/Documentation/git-fsck-cache.txt b/Documentation/git-fsck-cache.txt
--- a/Documentation/git-fsck-cache.txt
+++ b/Documentation/git-fsck-cache.txt
@@ -39,17 +39,17 @@ OPTIONS
--standalone::
Limit checks to the contents of GIT_OBJECT_DIRECTORY
- (.git/objects), making sure that it is consistent and
+ ($GIT_DIR/objects), making sure that it is consistent and
complete without referring to objects found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
- nor packed GIT archives found in .git/objects/pack;
+ nor packed GIT archives found in $GIT_DIR/objects/pack;
cannot be used with --full.
--full::
Check not just objects in GIT_OBJECT_DIRECTORY
- (.git/objects), but also the ones found in alternate
+ ($GIT_DIR/objects), but also the ones found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
- and in packed GIT archives found in .git/objects/pack
+ and in packed GIT archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
object pools; cannot be used with --standalone.
@@ -69,11 +69,7 @@ that aren't readable from any of the spe
So for example
- git-fsck-cache --unreachable $(cat .git/HEAD)
-
-or, for Cogito users:
-
- git-fsck-cache --unreachable $(cat .git/refs/heads/*)
+ git-fsck-cache --unreachable $(cat .git/HEAD .git/refs/heads/*)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
@@ -122,18 +118,18 @@ sha1 mismatch <object>::
The database has an object who's sha1 doesn't match the
database value.
This indicates a serious data integrity problem.
- (note: this error occured during early git development when
- the database format changed.)
Environment Variables
---------------------
GIT_OBJECT_DIRECTORY::
- used to specify the object database root (usually .git/objects)
+ used to specify the object database root (usually $GIT_DIR/objects)
GIT_INDEX_FILE::
- used to specify the cache
+ used to specify the index file of the cache
+GIT_ALTERNATE_OBJECT_DIRECTORIES:
+ used to specify additional object database roots (usually unset)
Author
------
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -21,6 +21,14 @@ This is used by "git-cvsimport-script" t
without modifying files in the work tree. When <type> is not
specified, it defaults to "blob".
+OPTIONS
+-------
+
+-t <type>::
+ Specify the type (default: "blob").
+
+-w::
+ Actually write the object into the object database.
Author
------
diff --git a/Documentation/git-http-pull.txt b/Documentation/git-http-pull.txt
--- a/Documentation/git-http-pull.txt
+++ b/Documentation/git-http-pull.txt
@@ -23,8 +23,9 @@ Downloads a remote GIT repository via HT
Get all the objects.
-v::
Report what is downloaded.
--w::
- Writes the commit-id into the filename under $GIT_DIR/refs/ on
+
+-w <filename>::
+ Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on
the local end after the transfer is complete.
Author
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -4,7 +4,7 @@ v0.1, May 2005
NAME
----
-git-init-db - Creates an empty git object database
+git-init-db - Creates an empty git repository
SYNOPSIS
@@ -13,15 +13,16 @@ SYNOPSIS
DESCRIPTION
-----------
-This simply creates an empty git object database - basically a `.git`
-directory and `.git/object/??/` directories.
+This simply creates an empty git repository - basically a `.git` directory
+and `.git/object/??/`, `.git/refs/heads` and `.git/refs/tags` directories,
+and links `.git/HEAD` symbolically to `.git/refs/heads/master`.
If the 'GIT_DIR' environment variable is set then it specifies a path
to use instead of `./.git` for the base of the repository.
If the object storage directory is specified via the 'GIT_OBJECT_DIRECTORY'
environment variable then the sha1 directories are created underneath -
-otherwise the default `.git/objects` directory is used.
+otherwise the default `$GIT_DIR/objects` directory is used.
"git-init-db" won't hurt an existing repository.
diff --git a/Documentation/git-local-pull.txt b/Documentation/git-local-pull.txt
--- a/Documentation/git-local-pull.txt
+++ b/Documentation/git-local-pull.txt
@@ -25,8 +25,9 @@ OPTIONS
Get all the objects.
-v::
Report what is downloaded.
--w::
- Writes the commit-id into the filename under $GIT_DIR/refs/ on
+
+-w <filename>::
+ Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on
the local end after the transfer is complete.
Author
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -87,7 +87,7 @@ detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA1 pair,
the dircache records up to three such pairs; one from tree O in stage
1, A in stage 2, and B in stage 3. This information can be used by
-the user (or Cogito) to see what should eventually be recorded at the
+the user (or the porcelain) to see what should eventually be recorded at the
path. (see read-cache for more information on state)
@@ -130,7 +130,7 @@ time. They are built and ordered in the
are popped off when leaving the directory.
Each pattern in the pattern list specifies "a match pattern" and
-optionally the fate;n either a file that matches the pattern is
+optionally the fate; either a file that matches the pattern is
considered excluded or included. A filename is matched against
the patterns in the three lists; the --exclude-from list is
checked first, then the --exclude-per-directory list, and then
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -19,7 +19,7 @@ in the current working directory.
OPTIONS
-------
<tree-ish>::
- Id of a tree.
+ Id of a tree-ish.
-d::
show only the named tree entry itself, not its children
@@ -31,7 +31,7 @@ OPTIONS
\0 line termination on output
paths::
- When paths are given, shows them. Otherwise implicitly
+ When paths are given, show them. Otherwise implicitly
uses the root level of the tree as the sole path argument.
diff --git a/Documentation/git-merge-cache.txt b/Documentation/git-merge-cache.txt
--- a/Documentation/git-merge-cache.txt
+++ b/Documentation/git-merge-cache.txt
@@ -21,7 +21,7 @@ files are passed as arguments 5, 6 and 7
OPTIONS
-------
--::
- Interpret all future arguments as filenames.
+ Interpret all following arguments as filenames.
-a::
Run merge against all files in the cache that need merging.
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -29,7 +29,7 @@ one-object" format; this is typically do
commands when a pack is created on-the-fly for efficient network
transport by their peers.
-Placing both in pack subdirectory of $GIT_OBJECT_DIRECTORY (or
+Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
enables GIT to read from such an archive.
diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt
--- a/Documentation/git-peek-remote.txt
+++ b/Documentation/git-peek-remote.txt
@@ -4,7 +4,7 @@ v0.1, July 2005
NAME
----
-git-peek-remote - Lists the references on a remote repository.
+git-peek-remote - Lists the references in a remote repository.
SYNOPSIS
@@ -20,14 +20,14 @@ OPTIONS
-------
--exec=<git-upload-pack>::
Use this to specify the path to 'git-upload-pack' on the
- remote side, if is not found on your $PATH.
- Installations of sshd ignores the user's environment
+ remote side, if it is not found on your $PATH. Some
+ installations of sshd ignores the user's environment
setup scripts for login shells (e.g. .bash_profile) and
your privately installed GIT may not be found on the system
default $PATH. Another workaround suggested is to set
up your $PATH in ".bashrc", but this flag is for people
who do not want to pay the overhead for non-interactive
- shells by having a lean .bashrc file (they set most of
+ shells, but prefer having a lean .bashrc file (they set most of
the things up in .bash_profile).
<host>::
diff --git a/Documentation/git-prune-script.txt b/Documentation/git-prune-script.txt
--- a/Documentation/git-prune-script.txt
+++ b/Documentation/git-prune-script.txt
@@ -14,8 +14,9 @@ SYNOPSIS
DESCRIPTION
-----------
This runs "git-fsck-cache --unreachable" program using the heads specified
-on the command line (or `.git/refs/heads/\*` and `.git/refs/tags/\*` if none is
-specified), and prunes all unreachable objects from the object database.
+on the command line (or `$GIT_DIR/refs/heads/\*` and `$GIT_DIR/refs/tags/\*`
+if none is specified), and prunes all unreachable objects from the object
+database.
Author
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -41,7 +41,7 @@ OPTIONS
Merging
-------
-If '-m' is specified, "git-read-tree" can performs 3 kinds of
+If '-m' is specified, "git-read-tree" can perform 3 kinds of
merge, a single tree merge if only 1 tree is given, a
fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
provided.
@@ -51,9 +51,9 @@ Single Tree Merge
~~~~~~~~~~~~~~~~~
If only 1 tree is specified, git-read-tree operates as if the user did not
specify '-m', except that if the original cache has an entry for a
-given pathname; and the contents of the path matches with the tree
+given pathname, and the contents of the path matches with the tree
being read, the stat info from the cache is used. (In other words, the
-cache's stat()s take precedence over the merged tree's)
+cache's stat()s take precedence over the merged tree's).
That means that if you do a "git-read-tree -m <newtree>" followed by a
"git-checkout-cache -f -u -a", the "git-checkout-cache" only checks out
@@ -184,7 +184,7 @@ populated. Here is an outline of how th
automatically collapse to "merged" state by git-read-tree.
- a file that has _any_ difference what-so-ever in the three trees
- will stay as separate entries in the index. It's up to "script
+ will stay as separate entries in the index. It's up to "porcelain
policy" to determine how to remove the non-0 stages, and insert a
merged version.
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -14,7 +14,7 @@ SYNOPSIS
DESCRIPTION
-----------
Creates a tar archive containing the tree structure for the named tree.
-When <base> is specified it is added as a leading path as the files in the
+When <base> is specified it is added as a leading path to the files in the
generated tar archive.
git-tar-tree behaves differently when given a tree ID versus when given
diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt
--- a/Documentation/git-update-server-info.txt
+++ b/Documentation/git-update-server-info.txt
@@ -16,7 +16,7 @@ DESCRIPTION
A dumb server that does not do on-the-fly pack generations can
have some auxiliary information files in $GIT_DIR/info and
$GIT_OBJECT_DIRECTORY/info directories to help clients discover
-what references and packs the server has and make an optimized
+what references and packs the server has and make optimized
pull decisions. This command generates such auxiliary files.
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
--- a/Documentation/git-write-tree.txt
+++ b/Documentation/git-write-tree.txt
@@ -4,7 +4,7 @@ v0.1, May 2005
NAME
----
-git-write-tree - Creates a tree from the current cache
+git-write-tree - Creates a tree object from the current cache
SYNOPSIS
^ permalink raw reply
* Re: bisect gives strange answer
From: Sanjoy Mahajan @ 2005-08-05 15:38 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Greg KH, Junio C Hamano, git
In-Reply-To: <20050804192838.GB26714@mars.ravnborg.org>
> If you see any sort of evidence that this would hold true I really like
> to know.
I haven't found any evidence. When I rebuilt the kernels from scratch
(exporting them into an empty directory using cg-export), I got
reliable data and bisected down to a patch that probably was a problem.
I will redo those tests but rebuilding in place after each bisection
(with -f added to all the git checkout uses in git-bisect-script) and
see whether I get the same results. If I don't, it could be due to
git or git-bisect (but not so likely with the -f switch) or to the
build system. Will keep you and Junio posted.
-Sanjoy
^ 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