* Re: git, porcelain, darcs, and version 1.0
From: Junio C Hamano @ 2005-07-18 19:11 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42DB341D.6050506@gmail.com>
Bryan Larsen <bryan.larsen@gmail.com> writes:
> ... Darcs and git work together to determine the minimal amount
> that needs to go into libgit1.so. It gets blessed by being
> documented, and doesn't change until libgit2.so.
>
> I'd like to see this added to Junio's list of "1.0" goals.
I should mention that I liked the libification work Brad Roberts
did around late April. Unfortunately the things have been
always in great flux for the last couple of months, and it was
too hard to include that and maintain it back then.
I fully agree that supporting C-level linkage is worthy, and
should be one of our longer term goals.
> A similar 1.0 goal would be to document porcelain's use of the .git
> directory. For instance, stacked git uses .git/patches,
> .git/patchdescr.tmpl and .git/patchexport.tmpl. If Linus does not
> accept a patch documenting this usage, stacked git should use .stgit
> instead.
I agree that coordinating the namespace under $GIT_DIR among
Porcelains is something we need (it was what prompted me to
steal the branches/ convention from Cogito). The job of the
core should be to help Porcelains avoid stepping on each other's
toes.
The documentation of the internals for $GIT_DIR/patches is
probably better left to StGIT documentation, though, at the
moment. When other Porcelains start wishing to access the
"series of patches expressed as a set of commit chain" expressed
by StGIT there (e.g. show patch series in addition to regular
commit chain in gitk), the core should help the Porcelains to
work well with each other, to do things in a compatible way.
This may involve moving some common things to core side and
mention the convention for Porcelains to work well together in
the core documentation.
However, I am slightly negative about suggesting these two to be
part of the 1.0 goals. Linus wanted to make 1.0 how many weeks
ago? I personally think that a usable baseline, stable enough
to allow stripping out the core part currently shipped as part
of Cogito, would be a good place to stop and declare 1.0. My
list was meant to enumuerate what might be missing from the
"usable baseline".
^ permalink raw reply
* Re: git, porcelain, darcs, and version 1.0
From: Juliusz Chroboczek @ 2005-07-18 19:49 UTC (permalink / raw)
To: Bryan Larsen; +Cc: Juliusz Chroboczek, darcs-devel, git
In-Reply-To: <42DB341D.6050506@gmail.com>
> I certainly don't think the lib interface is anywhere near stable:
> Linus accepted my change to index_fd far too easily.
Noted, thanks for the info.
(This makes a lot of sense, Git is evolving very fast. I haven't
looked at Git since mid-April, and I'm very much impressed at the
difference between 0.6 and 0.99.)
> Ugh. That's what they do in the commercial world. We have it so much
> better here in Linux & BSD land: you just add a "depends libgit1" line
> to your package, and the right thing happens: minor updates happen
> automatically and changes that break the interface don't.
This is, of course, only possible when there are stable interfaces,
which in turn make change problematic. (Which, as far as I
understand, is the very reason why the Linux kernel tree contains
everyone's and his brother's driver rather than having a stable module
ABI, but that's besides the point.)
> Darcs and git work together to determine the minimal amount
> that needs to go into libgit1.so.
Hold on... Nobody is speaking about *binary* compatibility, it's
source-level compatibility that we need. There is absolutely no
reason to introduce the complexities of shared libraries into the
picture.
Juliusz
^ permalink raw reply
* Re: git, porcelain, darcs, and version 1.0
From: Bryan Larsen @ 2005-07-18 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslycnd42.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I fully agree that supporting C-level linkage is worthy, and
> should be one of our longer term goals.
Excellent.
>
>
>>A similar 1.0 goal would be to document porcelain's use of the .git
>>directory. For instance, stacked git uses .git/patches,
>>.git/patchdescr.tmpl and .git/patchexport.tmpl. If Linus does not
>>accept a patch documenting this usage, stacked git should use .stgit
>>instead.
>
>
> I agree that coordinating the namespace under $GIT_DIR among
> Porcelains is something we need (it was what prompted me to
> steal the branches/ convention from Cogito). The job of the
> core should be to help Porcelains avoid stepping on each other's
> toes.
>
> The documentation of the internals for $GIT_DIR/patches is
> probably better left to StGIT documentation, though, at the
> moment. When other Porcelains start wishing to access the
> "series of patches expressed as a set of commit chain" expressed
> by StGIT there (e.g. show patch series in addition to regular
> commit chain in gitk), the core should help the Porcelains to
> work well with each other, to do things in a compatible way.
> This may involve moving some common things to core side and
> mention the convention for Porcelains to work well together in
> the core documentation.
I think we want the same thing, you're just expressing it explicitly:
stgit's usage of the .git namespace should be mentioned in git
documentation. actual details belong in stgit, either explicitly in
documentation or implicitly in the code.
>
> However, I am slightly negative about suggesting these two to be
> part of the 1.0 goals. Linus wanted to make 1.0 how many weeks
> ago? I personally think that a usable baseline, stable enough
> to allow stripping out the core part currently shipped as part
> of Cogito, would be a good place to stop and declare 1.0. My
> list was meant to enumuerate what might be missing from the
> "usable baseline".
All I'm looking for is a statement like "once we're at 1.0, darcs
doesn't break until 2.0". If we don't actually break out a blessed lib
interface until 1.1, that's fine with me. To me, 1.0 implies core
stability.
thanks,
Bryan
^ permalink raw reply
* Re: git, porcelain, darcs, and version 1.0
From: Bryan Larsen @ 2005-07-18 20:28 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: darcs-devel, git
In-Reply-To: <7id5pfx5ci.fsf@lanthane.pps.jussieu.fr>
>>Darcs and git work together to determine the minimal amount
>>that needs to go into libgit1.so.
>
>
> Hold on... Nobody is speaking about *binary* compatibility, it's
> source-level compatibility that we need. There is absolutely no
> reason to introduce the complexities of shared libraries into the
> picture.
>
Source level compatibility and stability is the big deal. Compared to
that, shared libraries are an implementation detail, in my opinion.
Sometimes those details get "interesting", but they are soluble.
I could care less whether you use libgit.a or a libgit.so. Just as long
as distros or anybody else can update their darcs if a major data-loss
bug is found in git. A recompile is acceptable. Dealing with the
addition of a parameter to index_fd() is not.
Bryan
^ permalink raw reply
* OLS?
From: Bryan Larsen @ 2005-07-18 20:43 UTC (permalink / raw)
To: git
Hi gitsters,
I'm currently living in Ottawa, and will be attending OLS. I would like
to meet people involved with git. I can offer my house (walking
distance from OLS), my BBQ, my beer or my recommendations on good
restaurants to facilitate an informal BOF.
Bryan
^ permalink raw reply
* Re: Barebone Porcelain. Where to stop?
From: Frank Sorenson @ 2005-07-18 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, Bryan Larsen, git
In-Reply-To: <7v8y04q6sj.fsf@assigned-by-dhcp.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Junio C Hamano wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
>>I don't see git going towards stgit at all. Indeed, it gets closer to
>>cogito but I still like cogito over plain git since it's easier to use
>>(my goal, though, is to add pull/clone commands to stgit so that one
>>doesn't need to rely on directly using other tools).
>
> All good to hear. I do not speak for Linus, but I think core
> should not be competing with Porcelain. To me, there are four
> purposes for the barebone Porcelain layer:
>
> (1) provide the end user a minimum UI to do essential things.
>
> (2) codify the BCP/convention to use the core by higher level
> SCMs to help them stay compatible with each other where
> possible (e.g. "what .git/HEAD means, when it gets updated,
> and to what" was discussed recently).
>
> (3) serve as an example for people interested in learning the
> core GIT (i.e. they may be starting their own Porcelain).
>
> (4) implement operations that are heavy on logic/convention but
> does not have much UI need so that higher level SCMs can
> implement their own UI by just being a thin wrapper around
> them (e.g. clone/fetch and push).
These all sound good. Along the lines of #4, one potential purpose I've
been curious about is the possibility of pulling these core operations
out into a library that Porcelain could use directly. This way,
Porcelain, including the minimum git UI (your #1), could directly link
in and call the needed functions, and rather than stringing sequences of
git-whatever commands together in a shell script.
This would allow Porcelain to take advantage of the core git more
directly, and would improve the speed of Porcelain. The minimum UI (#1)
would be a much simpler example (#3), since it would only be the
front-end, rather than the front-end/back-end combination it is now.
Is this something we want to consider, or am I out in left field? :)
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC3BfFaI0dwg4A47wRApyQAKD3yXqYfcm7TgJ5GnIZsw5ZcB+P/wCgpM75
cjPHXi8jd0VthQjKNFITFxU=
=Jxx/
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: OLS?
From: Ryan Anderson @ 2005-07-18 23:31 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42DC1474.8030307@gmail.com>
On Mon, Jul 18, 2005 at 04:43:32PM -0400, Bryan Larsen wrote:
> Hi gitsters,
>
> I'm currently living in Ottawa, and will be attending OLS. I would like
> to meet people involved with git. I can offer my house (walking
> distance from OLS), my BBQ, my beer or my recommendations on good
> restaurants to facilitate an informal BOF.
I'll be getting in tomorrow afternoon. I'll keep an eye out for you.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Barebone Porcelain. Where to stop?
From: Junio C Hamano @ 2005-07-19 0:10 UTC (permalink / raw)
To: Frank Sorenson; +Cc: Catalin Marinas, Bryan Larsen, git
In-Reply-To: <42DC17C5.80000@tuxrocks.com>
Frank Sorenson <frank@tuxrocks.com> writes:
> Is this something we want to consider, or am I out in left field? :)
I do not think so. You just more clearly and explicitly stated
what I wanted to see; we share the same vision of the ideal
world.
I do however think your sights are probably focused at somewhere
a lot further then mine ;-). C level interfaces to those
aggregated common operations would happen once after we identify
what kind of common operations are useful to have, prototyping
them (most likely in scripting environment), and if it turns out
to be useful and performance critical. I personally do not
think we are there yet.
^ permalink raw reply
* Re: 2.6.12 hangs on boot
From: Alexander Y. Fomichev @ 2005-07-19 11:53 UTC (permalink / raw)
To: Andi Kleen; +Cc: Linus Torvalds, Kernel Mailing List, admin, Git Mailing List
In-Reply-To: <20050718125857.GF8459@wotan.suse.de>
On Monday 18 July 2005 16:58, Andi Kleen wrote:
> Can you please test if this patch fixes it?
>
> -Andi
>
>
> Don't compare linux processor index with APICID
>
> Fixes boot up lockups on some machines where CPU apic ids
> don't start with 0
>
> Signed-off-by: Andi Kleen <ak@suse.de>
>
> Index: linux/arch/x86_64/kernel/smpboot.c
> ===================================================================
> --- linux.orig/arch/x86_64/kernel/smpboot.c
> +++ linux/arch/x86_64/kernel/smpboot.c
> @@ -211,7 +211,7 @@ static __cpuinit void sync_master(void *
> {
> unsigned long flags, i;
>
> - if (smp_processor_id() != boot_cpu_id)
> + if (smp_processor_id() != 0)
> return;
>
> go[MASTER] = 0;
No, sorry, the same result -- hangs just after:
Booting processor 2/1 rip 6000 rsp ffff8100dff7df58
Initializing CPU#2
(hmm... as i can see one string above [and if i understand correctly]
boot_cpu_id == 0 in my case:
CPU 1: Syncing TSC to CPU 0 )
--
Best regards.
Alexander Y. Fomichev <gluk@php4.ru>
Public PGP key: http://sysadminday.org.ru/gluk.asc
^ permalink raw reply
* Re: cg update failing
From: Petr Baudis @ 2005-07-20 1:07 UTC (permalink / raw)
To: James Cloos; +Cc: git, Darrin Thompson
In-Reply-To: <m3eka04shr.fsf@lugabout.cloos.reno.nv.us>
Dear diary, on Fri, Jul 15, 2005 at 06:12:48AM CEST, I got a letter
where James Cloos <cloos+vger-git@jhcloos.com> told me that...
> Well, it wasn't as Ok as I first thought. There were several .rej and
> backup files as left behind by patch(1). cg update HEAD says: Branch
> already fully merged but Makefile still says 2.6.12.
>
> I'm cloning now to a remote uml and will try and rsync from there to
> the laptop. Perhaps *that* will get me a working repo.
Huh. Well, you had to do uberweird things with your repository - why did
you cg-seek at all? What Cogito version is it?
Anyway, cg-reset (or cg-cancel in "older" Cogito) should bring
everything in shape.
--
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: Cannot get git any more?
From: Petr Baudis @ 2005-07-19 23:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050717224904.D1ED735258B@atlas.denx.de>
Dear diary, on Mon, Jul 18, 2005 at 12:49:04AM CEST, I got a letter
where Wolfgang Denk <wd@denx.de> told me that...
> -> cd ..
> -> mv git git.OLD
> -> cg-clone rsync://rsync.kernel.org/pub/scm/git/git.git
> /usr/local/src/git
> defaulting to local storage area
> @ERROR: Unknown module 'pub'
> rsync: connection unexpectedly closed (41 bytes read so far)
> rsync error: error in rsync protocol data stream (code 12) at io.c(342)
> cg-pull: unable to get the head pointer of branch master
> cg-init: pull failed
That's puzzling. Try just
rsync -a rsync://rsync.kernel.org/pub/scm/git/git.git /usr/local/src/git
which should fail too and indicates that something must be weird on your
side since it apparently works for the rest of the world. ;-) Try
upgrading rsync, check if it really connects to the real
rsync.kernel.org and such...
> -> rm -fr git
> -> cg-clone http://www.kernel.org/pub/scm/git/git.git
> /usr/local/src/git
> defaulting to local storage area
> 00:44:43 URL:http://www.kernel.org/pub/scm/git/git.git/refs/heads/master [41/41] -> "refs/heads/origin" [1]
> progress: 2 objects, 4252 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
This is unfortunately normal now.
--
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.12.1
From: Petr Baudis @ 2005-07-19 23:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Russell King, Linus Torvalds, git
In-Reply-To: <tnxzmsrc61b.fsf@arm.com>
Dear diary, on Wed, Jul 13, 2005 at 01:13:52PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> Russell King <rmk@arm.linux.org.uk> wrote:
> > I won't bother trying to explain, I'll just paste the errors. We've been
> > here before in a previous cogito revision.
> >
> > rmk@dyn-67:[linux-2.6-rmk]:<1038> cg-branch-ls
> > origin ../linux-2.6
> > smp ../linux-2.6-smp
>
> I noticed that Cogito doesn't work well with relative paths. Run
> cg-branch-chg and put absolute paths, it might work (it did for me).
Yes, that's it. Will be fixed in Cogito-0.12.2 (or 0.13, whichever comes
first), 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: Cannot get git any more?
From: Wolfgang Denk @ 2005-07-19 23:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050719233839.GC2255@pasky.ji.cz>
In message <20050719233839.GC2255@pasky.ji.cz> you wrote:
>
> > -> cg-clone rsync://rsync.kernel.org/pub/scm/git/git.git
> > /usr/local/src/git
> > defaulting to local storage area
> > @ERROR: Unknown module 'pub'
> > rsync: connection unexpectedly closed (41 bytes read so far)
> > rsync error: error in rsync protocol data stream (code 12) at io.c(342)
> > cg-pull: unable to get the head pointer of branch master
> > cg-init: pull failed
>
> That's puzzling. Try just
>
> rsync -a rsync://rsync.kernel.org/pub/scm/git/git.git /usr/local/src/git
Thanks for the tip. You are right. This was caused by an unlucky
change to one of our firewall rules ;-(
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Applying computer technology is simply finding the right wrench to
pound in the correct screw.
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Petr Baudis @ 2005-07-19 23:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Russell King, git
In-Reply-To: <Pine.LNX.4.58.0507140813150.19183@g5.osdl.org>
Dear diary, on Thu, Jul 14, 2005 at 05:26:07PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> It's quite possible that some path in cg-update ends up not updating the
> index properly. For example, I notice that the "fast-forward" uses
> "git-checkout-cache -f -a", which can do so (lack of "-u" fila), but then
> it does do a "git-update-cache --refresh" later, so that doesn't seem to
> be it either.
Just a side note for casual readers, Cogito could use a cleanup here -
from large part it ignores things like git-checkout-cache -u simply
because there was no such option at the time that part of Cogito was
written. I myself am not even too familiar about those gazillions of
funny new options, and as long as it works, I prefer not to touch that
code, but if someone is bored and wants to get familiar with core git
usage as well as Cogito internals...
--
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] Gct-0.1, a GUI enabled Git commit tool
From: Petr Baudis @ 2005-07-19 23:58 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <914f22914f26.914f26914f22@liu.se>
Dear diary, on Fri, Jul 15, 2005 at 02:46:42AM CEST, I got a letter
where Fredrik Kuivinen <freku045@student.liu.se> told me that...
> Hi,
Hello from a lazy reader who didn't actually try it,
> Gct v0.1 has been released and can be downloaded from
> http://www.cyd.liu.se/~freku045/gct/gct-0.1.tar.gz
>
> What follows is an excerpt from the README in the tarball:
>
> Introduction
> ------------
>
> Git Commit Tool or gct is a simple GUI enabled Git commit tool. It
> allows the user to select which files should be committed, write
> commit messages and perform the commit. It also has some support for
> controlling the synchronisation between the Git cache and the working
> directory.
do you have any screenshots please? From the description it appears it
is actually not any more powerful than cg-commit. Does it let you see
the diff, actually prune the changes to be committed and such?
--
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: Why fetching latest kernel sources is failing?
From: Petr Baudis @ 2005-07-20 0:00 UTC (permalink / raw)
To: Paolo 'Blaisorblade' Giarrusso; +Cc: git
In-Reply-To: <loom.20050713T182418-822@post.gmane.org>
Dear diary, on Wed, Jul 13, 2005 at 07:22:22PM CEST, I got a letter
where "Paolo \\'Blaisorblade\\' Giarrusso" <blaisorblade@yahoo.it> told me that...
> cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Please use rsync, http is broken for the time being and not trivially
fixable (patches pending, though).
--
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
* [RFD] server-info to help clients
From: Junio C Hamano @ 2005-07-20 0:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Eric W. Biederman
In-Reply-To: <m1u0iuo63i.fsf@ebiederm.dsl.xmission.com>
While things are quiet (I envy everybody having fun at OLS),
I've been cooking something to help clients to pull from dumb
servers.
I assume that:
- The object database is packed, following the recommendations
in the "Working with Others" section of the tutorial.
- The repository owner _may_ further create throw-away
incremental packs. There can be the following in one object
database:
- one baseline pack.
- permanent incremental packs #1 .. #N
- one throw-away incremental pack.
- unpacked files under objects/??/.
Baseline and permanent incremental packs are built by "git
repack", just like Linus recommended from the beginning. The
throwaway pack is built periodically (say every hour) to
collect all objects that are not in the baseline nor
permanent incrementals. Building of such a throw-away pack
involves:
- unpacking and removal of the current throw-away pack.
- running "git repack".
- running "git prune-packed".
- The server could be truly dumb and can even refuse to serve
dirindex; parsing autogenerated index.html is a pain anyway.
First, a somewhat related change I did was to write a script
called "git ls-remote". It is used this way:
$ git ls-remote origin
17c0bd743c1c8113cd0ed72b7ca1776d13c27e01 HEAD
17c0bd743c1c8113cd0ed72b7ca1776d13c27e01 refs/heads/master
f0b32737ad5a35cc047db47353a75faccfe5939e refs/heads/linus
4d9ae497491fd838dafd7fcbd11c4aa678a726f1 refs/heads/pu
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
It slurps the set of refs from a remote repository (the same
short-hand we stole from Cogito using .git/branches/ can be used
here) and optionally it can be told to store tags under local
refs/.
This is produced by connecting directly to the git-daemon
running on the remote side and talking upload-pack protocol with
it. A new helper program "git-peek-remote" is used to do this
when we use git:// URL. From an rsync URL, everything under its
refs/ is copied to a temporary directory to produce the same
information.
To support the same on a dumb transport, I gave the server side
a new command, "git update-server-info", which prepares this
information in "$repo/info/refs", so writing http support for
"git ls-remote" using curl is trivial. I arranged things so
that update-server-info is run whenever you push into the
repository via "git push". You can of course run it by hand
from the command line.
The other file that update-server-info produces is to help dumb
pullers. It is stored in "$repo/objects/info/pack", and looks
like this:
P pack-c60dc6f7486e34043bd6861d6b2c0d21756dde76.pack
P pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
D 0 1
D 1
T 0 9fb1759a3102c26cd8f64254a7c3e532782c2bb8 commit
T 0 a339981ec18d304f9efeb9ccf01b1f04302edf32 tag
T 1 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a tag
T 1 043d051615aa5da09a7e44f1edbb69798458e067 commit
T 1 06f6d9e2f140466eeb41e494e14167f90210f89d tag
T 1 26791a8bcf0e6d33f43aef7682bdb555236d56de tag
T 1 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c tag
T 1 701d7ecec3e0c6b4ab9bb824fd2b34be4da63b7e tag
T 1 733ad933f62e82ebc92fed988c7f0795e64dea62 tag
T 1 9e734775f7c22d2f89943ad6c745571f1930105f tag
T 1 c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19 tag
T 1 ebb5573ea8beaf000d4833735f3e53acb9af844c tag
The lines that start with a 'P' list all the packs available in
this object database (relative to $repo/objects/pack). These
packs are implicitly numbered starting at 0 in the order they
appear in the file; in the above, the pack c60dc6... is pack #0
and e3117b... is pack #1.
The lines that start with a 'D' list the dependencies. "D 0 1"
says, pack #0 is not complete and refers to objects found in
pack #1 (e.g. a commit object in pack #0 has a subtree that is
the same one found in pack #1 hence pack #0 does not contain
that tree). "D 1" shows that the pack #1 is self sufficient and
does not depend on anything (it is the linux-2.6 baseline pack).
Of course, you could have a pack that depends on more than one
packs, in which case you would see something like "D 4 1 2 3" to
mean pack #4 depending on packs #1, #2 and #3.
If the repository follows the "baseline, permanent incrementals,
and one throw-away" scheme I outlined above, the baseline would
be self sufficient, most likely incremental #i would depend on
the baseline and all the incrementals #j (j < i), and the
throw-away would depend on everybody else.
The lines that start with a 'T' list objects in a pack that are
not referenced by anything else in the same pack (they are
typically branch heads and tags). We can see that pack #0 has
one head commit and a tag in the above example.
This file always resides at a known location. A client can do
something like this to slurp from a dumb server:
(1) Fetch $repo/objects/info/pack file for the above
information.
(2) Look at T lines. If you have all the objects listed there
for a pack, and if your repository is not incomplete to begin
with, you are not interested in that pack. By definition, all
things that are in that pack are reachable from one of those
objects listed on the T lines, and you already have them.
Otherwise, you _may_ be interested in that pack.
(3) Download corresponding .idx files for the packs you are
interested in. Run "git show-index" to see if the heads/tags
you are interested in appear in one of them (you found out
about the heads/tags using "git ls-remote" earlier). If you
find a pack that contains objects you are interested in, look
at D lines to make sure you have all the head objects from
packs that this pack depends on; otherwise you need to slurp
that depended-upon packs as well (needless to say, this goes
recursive).
(4) Download the packs you decided to pick in the previous
step. It is up to you if you unpack those packs, but if
the upstream has it statically packed I would recommend
against unpacking. Next time around you can just look at
the name of the pack and decide you already have that pack.
On the other hand, keeping a throw-away packed may not make
much sense. You can unpack the throw-away and then run
"git prune-packed" in your repository next time you get the
pack info file from the repository, by noticing that the
pack is gone from the remote repository already.
(5) Fill the rest using the commit walker.
The initial client implementation which is _really_ dumb could
even skip steps (2) and (3) and choose to always download/sync
all available packs from the dumb server, and directly go to
step (5) to fall back on the commit walker.
I haven't written the client side, but all the rest that are
necessary to support the above will be sent to the list as
separate patches.
^ permalink raw reply
* Re: [RFD] server-info to help clients
From: David Lang @ 2005-07-20 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, ebiederm
In-Reply-To: <7vu0iqiaz9.fsf@assigned-by-dhcp.cox.net>
i wonder how much benifit there is to the throw-away packs.
if you do permanent incremental packs every day (or every few days) is
there really enough activity to make it worth the added complexities
(specificly including detecting that it is a throw-away pack on the client
side and therefor you probably don't want to keep it) for the slight
performance increase you may get
remember that since deltas only work within a pack the throw-away pack
will only be noticably smaller once you start having one file modified
multiple times before a new incremental pack is created, so you aren't
likly to save much on space, so all you are likly to save is the overhead
of fetching multiple objects compared to one object.
going forward it may be worth a smarter packing program to support HPA's
goal of a cental object storage, one that can make decisions like: 'object
A is part of this 40% of the trees, while object B is part of that
otehr 40% (disjoint set) so it's probably a good idea to put them into
seperate packs'
but that can be done much futher down the road without having to change
the clients at all.
David Lang
On Tue, 19 Jul 2005,
Junio C Hamano wrote:
> Date: Tue, 19 Jul 2005 17:20:58 -0700
> From: Junio C Hamano <junkio@cox.net>
> To: Linus Torvalds <torvalds@osdl.org>
> Cc: git@vger.kernel.org, ebiederm@xmission.com
> Subject: [RFD] server-info to help clients
>
> While things are quiet (I envy everybody having fun at OLS),
> I've been cooking something to help clients to pull from dumb
> servers.
>
> I assume that:
>
> - The object database is packed, following the recommendations
> in the "Working with Others" section of the tutorial.
>
> - The repository owner _may_ further create throw-away
> incremental packs. There can be the following in one object
> database:
>
> - one baseline pack.
> - permanent incremental packs #1 .. #N
> - one throw-away incremental pack.
> - unpacked files under objects/??/.
>
> Baseline and permanent incremental packs are built by "git
> repack", just like Linus recommended from the beginning. The
> throwaway pack is built periodically (say every hour) to
> collect all objects that are not in the baseline nor
> permanent incrementals. Building of such a throw-away pack
> involves:
>
> - unpacking and removal of the current throw-away pack.
> - running "git repack".
> - running "git prune-packed".
>
> - The server could be truly dumb and can even refuse to serve
> dirindex; parsing autogenerated index.html is a pain anyway.
>
> First, a somewhat related change I did was to write a script
> called "git ls-remote". It is used this way:
>
> $ git ls-remote origin
> 17c0bd743c1c8113cd0ed72b7ca1776d13c27e01 HEAD
> 17c0bd743c1c8113cd0ed72b7ca1776d13c27e01 refs/heads/master
> f0b32737ad5a35cc047db47353a75faccfe5939e refs/heads/linus
> 4d9ae497491fd838dafd7fcbd11c4aa678a726f1 refs/heads/pu
> d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
> f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
>
> It slurps the set of refs from a remote repository (the same
> short-hand we stole from Cogito using .git/branches/ can be used
> here) and optionally it can be told to store tags under local
> refs/.
>
> This is produced by connecting directly to the git-daemon
> running on the remote side and talking upload-pack protocol with
> it. A new helper program "git-peek-remote" is used to do this
> when we use git:// URL. From an rsync URL, everything under its
> refs/ is copied to a temporary directory to produce the same
> information.
>
> To support the same on a dumb transport, I gave the server side
> a new command, "git update-server-info", which prepares this
> information in "$repo/info/refs", so writing http support for
> "git ls-remote" using curl is trivial. I arranged things so
> that update-server-info is run whenever you push into the
> repository via "git push". You can of course run it by hand
> from the command line.
>
> The other file that update-server-info produces is to help dumb
> pullers. It is stored in "$repo/objects/info/pack", and looks
> like this:
>
> P pack-c60dc6f7486e34043bd6861d6b2c0d21756dde76.pack
> P pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
> D 0 1
> D 1
> T 0 9fb1759a3102c26cd8f64254a7c3e532782c2bb8 commit
> T 0 a339981ec18d304f9efeb9ccf01b1f04302edf32 tag
> T 1 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a tag
> T 1 043d051615aa5da09a7e44f1edbb69798458e067 commit
> T 1 06f6d9e2f140466eeb41e494e14167f90210f89d tag
> T 1 26791a8bcf0e6d33f43aef7682bdb555236d56de tag
> T 1 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c tag
> T 1 701d7ecec3e0c6b4ab9bb824fd2b34be4da63b7e tag
> T 1 733ad933f62e82ebc92fed988c7f0795e64dea62 tag
> T 1 9e734775f7c22d2f89943ad6c745571f1930105f tag
> T 1 c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19 tag
> T 1 ebb5573ea8beaf000d4833735f3e53acb9af844c tag
>
> The lines that start with a 'P' list all the packs available in
> this object database (relative to $repo/objects/pack). These
> packs are implicitly numbered starting at 0 in the order they
> appear in the file; in the above, the pack c60dc6... is pack #0
> and e3117b... is pack #1.
>
> The lines that start with a 'D' list the dependencies. "D 0 1"
> says, pack #0 is not complete and refers to objects found in
> pack #1 (e.g. a commit object in pack #0 has a subtree that is
> the same one found in pack #1 hence pack #0 does not contain
> that tree). "D 1" shows that the pack #1 is self sufficient and
> does not depend on anything (it is the linux-2.6 baseline pack).
> Of course, you could have a pack that depends on more than one
> packs, in which case you would see something like "D 4 1 2 3" to
> mean pack #4 depending on packs #1, #2 and #3.
>
> If the repository follows the "baseline, permanent incrementals,
> and one throw-away" scheme I outlined above, the baseline would
> be self sufficient, most likely incremental #i would depend on
> the baseline and all the incrementals #j (j < i), and the
> throw-away would depend on everybody else.
>
> The lines that start with a 'T' list objects in a pack that are
> not referenced by anything else in the same pack (they are
> typically branch heads and tags). We can see that pack #0 has
> one head commit and a tag in the above example.
>
> This file always resides at a known location. A client can do
> something like this to slurp from a dumb server:
>
> (1) Fetch $repo/objects/info/pack file for the above
> information.
>
> (2) Look at T lines. If you have all the objects listed there
> for a pack, and if your repository is not incomplete to begin
> with, you are not interested in that pack. By definition, all
> things that are in that pack are reachable from one of those
> objects listed on the T lines, and you already have them.
> Otherwise, you _may_ be interested in that pack.
>
> (3) Download corresponding .idx files for the packs you are
> interested in. Run "git show-index" to see if the heads/tags
> you are interested in appear in one of them (you found out
> about the heads/tags using "git ls-remote" earlier). If you
> find a pack that contains objects you are interested in, look
> at D lines to make sure you have all the head objects from
> packs that this pack depends on; otherwise you need to slurp
> that depended-upon packs as well (needless to say, this goes
> recursive).
>
> (4) Download the packs you decided to pick in the previous
> step. It is up to you if you unpack those packs, but if
> the upstream has it statically packed I would recommend
> against unpacking. Next time around you can just look at
> the name of the pack and decide you already have that pack.
>
> On the other hand, keeping a throw-away packed may not make
> much sense. You can unpack the throw-away and then run
> "git prune-packed" in your repository next time you get the
> pack info file from the repository, by noticing that the
> pack is gone from the remote repository already.
>
> (5) Fill the rest using the commit walker.
>
> The initial client implementation which is _really_ dumb could
> even skip steps (2) and (3) and choose to always download/sync
> all available packs from the dumb server, and directly go to
> step (5) to fall back on the commit walker.
>
> I haven't written the client side, but all the rest that are
> necessary to support the above will be sent to the list as
> separate patches.
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* [PATCH] Make debian/rules executable, and correct the spelling of rsync in debian/control
From: Ryan Anderson @ 2005-07-20 1:17 UTC (permalink / raw)
To: git, Linus Torvalds
Make debian/rules executable, and correct the spelling of rsync in
debian/control
---
debian/control | 2 +-
debian/rules | 0
2 files changed, 1 insertions(+), 1 deletions(-)
mode change 100644 => 100755 debian/rules
d1acec0c9f2f1936528769c76089961cec4a096e
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${shlibs:Depends}, shellutils, diff, rysnc, rcs
+Depends: ${shlibs:Depends}, shellutils, diff, rsync, rcs
Description: The git content addressable filesystem
GIT comes in two layers. The bottom layer is merely an extremely fast
and flexible filesystem-based database designed to store directory trees
diff --git a/debian/rules b/debian/rules
old mode 100644
new mode 100755
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [RFD] server-info to help clients
From: Junio C Hamano @ 2005-07-20 1:53 UTC (permalink / raw)
To: David Lang; +Cc: Linus Torvalds, git, ebiederm
In-Reply-To: <Pine.LNX.4.62.0507191728380.18963@qynat.qvtvafvgr.pbz>
The management of multiple packs and strategy of deciding when
to create the next incremental (be it throw-away or permanent)
is something I am not particularly interested in at this moment,
and as you correctly pointed out, the "single throw-away pack"
is an example of _bad_ strategy [*1*]. I am more interested in
designing a concise way to express what the server side has
(after applying such packing/repacking strategy) to help clients
coming over a dumb transport.
One thing that I forgot to mention is that there is another
per-repository information "$repo/info/revinfo". This lists all
the commit ancestry reachable from "$repo/refs", and is needed
for clients to find out the closest commit from the very tip of
branches, which are likely not packed yet, that appears as a
head in "$repo/objects/info/pack" and go from there.
[Footnote]
*1* As I said, I am not interested in thinking about this at
this moment, but I suspect a scheme that employs the base pack,
permanent incrementals, and N new throw-aways every day for the
N-th day of the month may work reasonably well.
On the N-th day of the month, you create incrementals relative
to what existed on the N-1th, N-2th, ..., 1st of the month. At
the end of the day, create N+1 new throw-aways for the N+1th day
of the month (you can garbage collect older days' throw-away
incrementals whenever you like). At the end of the month, you
mark the throw-away incremental that is relative to the
beginning of the month as the latest permanent incremental.
Bootstrappers can slurp base, permanent incremental and the
throwaway for today that is relative to the last permanent
incremental. Updaters can pick the one relative to the day they
updated last time.
^ permalink raw reply
* Re: cg update failing
From: James Cloos @ 2005-07-20 4:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Darrin Thompson
In-Reply-To: <20050720010712.GB2255@pasky.ji.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> Huh. Well, you had to do uberweird things with your repository -
Petr> why did you cg-seek at all? What Cogito version is it?
All I ever did was track and compile linus’ tree. IIRC, when the
first new tag was added after I cloned the tree I had to seek to
that tag to see the new versions of the files. But obviously
that was long enough before hg’s repo broke that I’d forgotten
how I’d done that....
I forget what version I started with. I’ve been tracking gentoo’s
ebuild since it entered portage.
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply
* Re: cg update failing
From: Petr Baudis @ 2005-07-20 8:12 UTC (permalink / raw)
To: James Cloos; +Cc: git, Darrin Thompson
In-Reply-To: <m3oe8yw0ws.fsf@lugabout.cloos.reno.nv.us>
Dear diary, on Wed, Jul 20, 2005 at 06:34:43AM CEST, I got a letter
where James Cloos <cloos+vger-git@jhcloos.com> told me that...
> >>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
>
> Petr> Huh. Well, you had to do uberweird things with your repository -
> Petr> why did you cg-seek at all? What Cogito version is it?
>
> All I ever did was track and compile linus??? tree. IIRC, when the
> first new tag was added after I cloned the tree I had to seek to
> that tag to see the new versions of the files. But obviously
> that was long enough before hg???s repo broke that I???d forgotten
> how I???d done that....
Ah so. Well, yes, the first tag was IIRC weird since it was a tree tag,
not a commit tag. That confused things, but it shouldn't be necessary
anymore since all new tags are hopefully commits. That might somehow
create the local modifications as well, although I don't have a clear
idea how could be that possible. Well, there were some bugs like this in
Cogito in the past, but that should be long fixed.
Thanks anyway,
--
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: [PATCH 0/6] cogito: compatibility with OS X
From: Petr Baudis @ 2005-07-20 9:19 UTC (permalink / raw)
To: Bryan Larsen; +Cc: bryan.larsen, git
In-Reply-To: <20050718025024.11198.10556.sendpatchset@bryan-larsens-ibook-g4.local>
Dear diary, on Mon, Jul 18, 2005 at 04:50:31AM CEST, I got a letter
where Bryan Larsen <bryanlarsen@yahoo.com> told me that...
> 3) upload Portfile's along with the .tar.gz's.
That's what we do with cogito.spec as well and it's fine. Just send me
an appropriate patch for the dist target.
> 2 of these 5 patches are unchanged from the previous post. I have
> attached them anyways to maintain the series. Please let me know if
> this is poor etiquette.
I think it's fine. :-)
--
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
* [PATCH] cogito: master as the default remote branch
From: Santi Béjar @ 2005-07-20 10:41 UTC (permalink / raw)
To: pasky, git
Recover the old behavior of the remote branch name
... specified in $_git/branches/$name and defaulting to master.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
cg-pull | 2 +-
cg-push | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -249,7 +249,7 @@ name=${ARGS[0]}
[ "$name" ] || die "where to pull from?"
uri=$(cat "$_git/branches/$name" 2>/dev/null) || die "unknown branch: $name"
-rembranch=$_git_head
+rembranch=master
if echo "$uri" | grep -q '#'; then
rembranch=$(echo $uri | cut -d '#' -f 2)
uri=$(echo $uri | cut -d '#' -f 1)
diff --git a/cg-push b/cg-push
--- a/cg-push
+++ b/cg-push
@@ -26,7 +26,7 @@ name=${ARGS[0]}
[ "$name" ] || die "where to push from?"
uri=$(cat "$_git/branches/$name" 2>/dev/null) || die "unknown branch: $name"
-rembranch=$_git_head
+rembranch=master
if echo "$uri" | grep -q '#'; then
rembranch=$(echo $uri | cut -d '#' -f 2)
uri=$(echo $uri | cut -d '#' -f 1)
^ permalink raw reply
* [PATCH] Misc documentation fixes and improvements
From: Jonas Fonseca @ 2005-07-20 12:05 UTC (permalink / raw)
To: Petr Baudis, git
Fix displaying of an error message when cg-help is called with unknown
command and use $USAGE so the correct cg-help usage string is printed.
Drop useless use of cat in print_help(). Improve the asciidoc markup.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -172,7 +172,7 @@ print_help()
which "cg-$1" >/dev/null 2>&1 || exit 1
sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p' < $(which cg-$1)
echo
- cat $(which cg-$1) | sed -n '3,/^$/s/^# *//p'
+ sed -n '3,/^$/s/^# *//p' < $(which cg-$1)
exit
}
diff --git a/cg-admin-uncommit b/cg-admin-uncommit
--- a/cg-admin-uncommit
+++ b/cg-admin-uncommit
@@ -14,14 +14,14 @@
# -t::
# This optional parameter makes `cg-admin-uncommit` to roll back
# the tree as well to the previous commit. Without this option
-# (by default) Cogito keeps the tree in its current state,
+# (by default) 'Cogito' keeps the tree in its current state,
# therefore generating tree with local changes against the target
# commit, consisting of the changes in the rolled back commits.
#
# CAVEATS
# -------
# This command can be dangerous! It is safe to do as long as you do not
-# push the commit out in the meantime, but you should NEVER uncommit an
+# push the commit out in the meantime, but you should 'NEVER' uncommit an
# already pushed out commit. Things will break for the pullers since you
# just broke the fast-forward merging mechanism (the new commit is not
# descendant of the previous one). The future push scripts will refuse
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -17,7 +17,7 @@
# -------
# -C::
# Make `cg-commit` ignore the cache and just commit the thing as-is.
-# Note, this is used internally by Cogito when merging. This option
+# Note, this is used internally by 'Cogito' when merging. This option
# does not make sense when files are given on the command line.
#
# -mMESSAGE::
diff --git a/cg-diff b/cg-diff
--- a/cg-diff
+++ b/cg-diff
@@ -3,7 +3,7 @@
# Make a diff between two GIT trees.
# Copyright (c) Petr Baudis, 2005
#
-# Outputs a diff for converting the first tree to the second one.
+# Outputs a diff for converting between two trees.
# By default compares the current working tree to the state at the
# last commit. The output will automatically be displayed in a pager
# unless it is piped to a program.
diff --git a/cg-help b/cg-help
--- a/cg-help
+++ b/cg-help
@@ -14,7 +14,7 @@
# OPTIONS
# -------
# -c::
-# Colorize to the output.
+# Colorize the output.
USAGE="cg-help [-c] [cg-COMMAND | COMMAND]"
_git_repo_unneeded=1
@@ -76,7 +76,8 @@ colorize() {
if [ "$ARGS" ]; then
cmd=$(echo "${ARGS[0]}" | sed 's/^cg-//')
- ( print_help $cmd | colorize ) && exit
+ print_help $cmd | colorize
+ [ "${PIPESTATUS[0]}" -eq 0 ] && exit
echo "cg-help: no help available for command \"${ARGS[0]}\""
echo "Call cg-help without any arguments for the list of available commands"
exit 1
@@ -90,7 +91,7 @@ ADVANCED_COMMANDS="$(ls $bin_path/cg-adm
colorize <<__END__
The Cogito version control system $(cg-version)
-Usage: cg-COMMAND [ARG]...
+Usage: $USAGE
Available commands:
$(print_command_listing $REGULAR_COMMANDS)
diff --git a/cg-log b/cg-log
--- a/cg-log
+++ b/cg-log
@@ -14,7 +14,7 @@
# cg-log then displays only changes in those files.
#
# -c::
-# Colorize to the output. The used colors are listed below together
+# Colorize the output. The used colors are listed below together
# with information about which log output (summary, full or both)
# they apply to:
# - `author`: 'cyan' (both)
--
Jonas Fonseca
^ 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