* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Nicolas Pitre @ 2006-10-18 23:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0610181542160.3962@g5.osdl.org>
On Wed, 18 Oct 2006, Linus Torvalds wrote:
>
>
> On Wed, 18 Oct 2006, Junio C Hamano wrote:
> >
> > It should not be hard to write another program that generates a
> > packfile like pack-object does but taking a thin pack as its
> > input. Then receive-pack can drive it instead of
> > unpack-objects.
>
> Give me half an hour. It should be trivial to make "unpack-objects" write
> the "unpacked" objects into a pack-file instead.
If you use builtin-unpack-objects.c from next, you'll be able to
generate the pack index pretty easily as well, as all the needed info is
stored in the obj_list array. Just need to append objects remaining on
the delta_list array to the end of the pack, sort the obj_list by sha1
and write the index.
Pretty trivial indeed.
Nicolas
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Junio C Hamano @ 2006-10-18 22:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610181542160.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 18 Oct 2006, Junio C Hamano wrote:
>>
>> It should not be hard to write another program that generates a
>> packfile like pack-object does but taking a thin pack as its
>> input. Then receive-pack can drive it instead of
>> unpack-objects.
>
> Give me half an hour. It should be trivial to make "unpack-objects" write
> the "unpacked" objects into a pack-file instead.
Heh, three people having the same idea that goes in the same
direction at the same time is not necessarily a good sign of
efficient project management...
I am currently fighting with FC5 so please go ahead.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Linus Torvalds @ 2006-10-18 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Nicolas Pitre, git
In-Reply-To: <7vwt6xxofi.fsf@assigned-by-dhcp.cox.net>
On Wed, 18 Oct 2006, Junio C Hamano wrote:
>
> It should not be hard to write another program that generates a
> packfile like pack-object does but taking a thin pack as its
> input. Then receive-pack can drive it instead of
> unpack-objects.
Give me half an hour. It should be trivial to make "unpack-objects" write
the "unpacked" objects into a pack-file instead.
Linus
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Davide Libenzi @ 2006-10-18 22:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610181434510.3962@g5.osdl.org>
On Wed, 18 Oct 2006, Linus Torvalds wrote:
>
>
> On Wed, 18 Oct 2006, Davide Libenzi wrote:
> >
> > The hash value (hence the hash bucket index) simply directs you to the
> > bucket where a real record-compare loop is performed.
>
> As far as I can tell not all loops do a real "record-compare" thing.
>
> Some of the hash loops _only_ look at the hash, and as such a bad hash
> will do more than just cause bad performance, it will actually degrade the
> diff itself. Isn't that what XDL_MAX_EQLIMIT effectively does?
The XDL_MAX_EQLIMIT is used to limit the search for equal records, in the
record-discard phase. Note though, that at that point that "ha" value is a
record-class ID (every different record/line in the input has a unique ID).
Look at what xdl_classify_record() does. So in that case, XDL_HASHLONG can
really simply be a bitmask. So comparing "ha" in the loop in there, does
actually the right thing in any case (equal "ha" means really equal
record).
> Btw, the binary delta generator doesn't seem to have this issue at all: it
> uses "unsigned int" for the hash values, so the xdiff delta generation
> will give the same exact results on 32-bit and 64-bit architectures.
>
> Or was that one of the changes by Nico? (I only looked at the git version
> of that code)
The binary diff in libxdiff uses a chaining hash, so even in that case it
wouldn't have made a difference. I think Nico changed the hash to be a
coalesced hash, and in that case it does change the output.
- Davide
^ permalink raw reply
* Re: Alternate revno proposal (Was: Re: VCS comparison table)
From: Jakub Narebski @ 2006-10-18 22:14 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <20061018214623.GA32725@artax.karlin.mff.cuni.cz>
Jan Hudec wrote:
> Comments?
What about fetching from repository? For revnos you have to assign revno for
all commit you have downloaded; now you need only to unpack received pack
(or not, if you used --keep option). More work.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Junio C Hamano @ 2006-10-18 22:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <20061018214143.GF19194@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Ideally that thin pack would be repacked (along with the other
> existing packs) as quickly as possible into a self-contained pack.
It should not be hard to write another program that generates a
packfile like pack-object does but taking a thin pack as its
input. Then receive-pack can drive it instead of
unpack-objects.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Shawn Pearce @ 2006-10-18 22:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610181455570.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 18 Oct 2006, Shawn Pearce wrote:
> >
> > Actually there is a point to storing thin packs. When I pull from
> > a remote repo (or push to a remote repo) a huge number of objects
> > and the target disk that is about to receive that huge number of
> > loose objects is slooooooooow I would rather just store the thin
> > pack then store the loose objects.
> >
> > Ideally that thin pack would be repacked (along with the other
> > existing packs) as quickly as possible into a self-contained pack.
> > But that of course is unlikely to happen in practice; especially
> > on a push.
>
> I'm really nervous about keeping thin packs around.
>
> But a possibly good (and fairly simple) alternative would be to just
> create a non-thin pack on the receiving side. Right now we unpack into a
> lot of loose objects, but it should be possible to instead "unpack" into a
> non-thin pack.
>
> In other words, we could easily still use the thin pack for communication,
> we'd just "fill it out" on the receiving side.
Funny, I had the same thought. :-)
We already know how many objects are coming in on a thin pack;
its right there in the header. We could just have some threshold
at which we start writing a full pack rather than unpacking.
Writing such a full pack would be a simple matter of copying the
input stream out to a temporary pack, but sticking any delta bases
into a table in memory. At the end of the data stream if we have any
delta bases which weren't actually in that pack then find them and
copy them onto the end, update the header and recompute the checksum.
git-fastimport does some of that already, though its trivial code...
Worst case scenario would be the incoming thin pack is 100% deltas
as we would need to copy in a base object for every object mentioned
in the pack.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Junio C Hamano @ 2006-10-18 22:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610181449290.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think thin packs have been a good idea, and they certainly cut the
> amount of data sent over the network down by a large amount (much more
> than 50%), so I think thin packs are a great idea. Just _not_ when
> indexed.
Ah, I feel quite behind. I was about to say "oh have you been
pushing with --thin option?", and then realized that we made it
default since late March this year.
I need to run memtest86 on myself X-<.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Shawn Pearce @ 2006-10-18 22:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610181449290.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> So I don't object to mmap windows at all. I object to them only in the
> context of "they would allow us to use deltas between two different packs"
> discussion ;)
Having mmap windows or not has no impact on using deltas between
packs. We already map multiple packs at once. We just don't do
delta resolution between them, for the reasons you have already
given.
The two are totally unrelated. I apologize for somehow making
yourself (and others) think they are.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Junio C Hamano @ 2006-10-18 22:02 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061018215219.GG19194@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> However what do we do about the case where we mmap over 1 GiB worth
> of pack data (because the mmap succeeds and we have at least that
> much in .pack and .idx files) and then the application starts to
> demand a lot of memory via malloc?...
>
> The other configuration option is the size of the mmap window.
>...
> Earlier this summer we discussed this exact issue and said this
> value probably needs to be configurable if only to facilitate the
> unit tests.
I see. So you are allowing users to control individual window
size and total mmap memory. That makes sense.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Linus Torvalds @ 2006-10-18 22:00 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20061018214143.GF19194@spearce.org>
On Wed, 18 Oct 2006, Shawn Pearce wrote:
>
> Actually there is a point to storing thin packs. When I pull from
> a remote repo (or push to a remote repo) a huge number of objects
> and the target disk that is about to receive that huge number of
> loose objects is slooooooooow I would rather just store the thin
> pack then store the loose objects.
>
> Ideally that thin pack would be repacked (along with the other
> existing packs) as quickly as possible into a self-contained pack.
> But that of course is unlikely to happen in practice; especially
> on a push.
I'm really nervous about keeping thin packs around.
But a possibly good (and fairly simple) alternative would be to just
create a non-thin pack on the receiving side. Right now we unpack into a
lot of loose objects, but it should be possible to instead "unpack" into a
non-thin pack.
In other words, we could easily still use the thin pack for communication,
we'd just "fill it out" on the receiving side.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Junio C Hamano @ 2006-10-18 21:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610181358200.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> My personal suspicion is that we'll want to have a 64-bit index file some
> day, and THAT is worthy of a format change. That day is not now, btw. It's
> probably not even very close. Even the mozilla repo that was pushing the
> limit was only doing so until it was optimized better, and now it's
> apparently nowhere _near_ that limit.
>
> But even then, we might well want to update _just_ the index file format.
We've tried this already, and I shelved the patch for 64-index
for now due to exactly the same reasoning as yours (and it would
have conflicted heavily with Shawn's windowed-mmap() patch). It
involved updating just the index file format, so you are right
on both counts.
But you are always right anyway, so it may not be a news at all
;-).
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Linus Torvalds @ 2006-10-18 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20061018213225.GD19194@spearce.org>
On Wed, 18 Oct 2006, Shawn Pearce wrote:
>
> My comment that you quoted was about mmap'ing the pack files in
> large chunks (around 64-128 MiB at a time, but configurable from
> .git/config) rather than as an entire massive mapping.
Sure. I agree that we should do that, if only because it's clearly getting
hard to handle large pack-files on a 32-bit architecture.
You just seemed to say that in the _context_ of wanting to support having
multiple pack-files open (in order to allow deltas to refer to things
outside their own pack-file).
I just wanted to head that particular idea off at the pass.
I think thin packs have been a good idea, and they certainly cut the
amount of data sent over the network down by a large amount (much more
than 50%), so I think thin packs are a great idea. Just _not_ when
indexed.
So I don't object to mmap windows at all. I object to them only in the
context of "they would allow us to use deltas between two different packs"
discussion ;)
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Sean @ 2006-10-18 21:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061018213935.GX20017@pasky.or.cz>
On Wed, 18 Oct 2006 23:39:35 +0200
Petr Baudis <pasky@suse.cz> wrote:
> You can use just this single tool from Cogito. ;-)
I'd rather not have to keep two separate tools up to date, i just want
to install Git and have all these features installed. Especially since
there is so much overlap in what these two packages do. That would seem
like the best thing to do for most users in fact, asking them to install
and keep both up to date just doesn't make sense, to me at least.
> The point is, I'll of course prefer doing this stuff in Cogito while I'm
> enhancing Cogito, and I'll work on Cogito while I and others will be
> using it. I didn't move on to pure Git long time ago since I simply
> consider its UI much inferior to Cogito's. Sure, given enough time and
> work, it is fixable - but UI flaws are very hard to fix and I find it
> more effective to work on Cogito for the time being, at least until I
> bring it to 1.0, then I'll see.
>
> Besides, I'm used to Cogito. :-)
>
> So yes, current Git code definitely is a part of the reason, but it is
> certainly not the main part of it.
It's just a shame that your talents are split off from helping the main
project more. Git would be further along today in content and PR if it
had managed to attract you back from your Cogito adventure. Then all
the nice things you're able to say about Cogito might then be said
about Git proper, and maybe we'd attract even more users.
While you've contributed more to Git than many others (including me
obviously), it would sure be nice to see you back full time on Git.
I want to type "git bundle" without having to install more
software damnit ;o) But of course you have to decide what's best
for yourself.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 21:52 UTC (permalink / raw)
To: Sean; +Cc: Shawn Pearce, git
In-Reply-To: <20061018174450.f2108a21.seanlkml@sympatico.ca>
Dear diary, on Wed, Oct 18, 2006 at 11:44:50PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> said that...
> On Wed, 18 Oct 2006 17:37:03 -0400
> Shawn Pearce <spearce@spearce.org> wrote:
>
> > Today Git is typically extended (at least initially in prototyping
> > mode) through Perl, Python, TCL or Bourne shell scripts. Although
> > the first three are available natively on Windows the last requires
> > Cygwin... and we've had some issues with ActiveState Perl on Windows
> > in the past too.
>
> Just for kicks and giggles it would be nice if someone tried out
> one of the native Windows bourne shell ports[1] just to see how much
> is missing. A bunch of command line utilities would have to be ported
> as well; maybe too many. But i've held out booting a Windows box
> for a long time so.... not it!
I think that before starting to think about the porcelain scripts, you
need to port the plumbing. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Shawn Pearce @ 2006-10-18 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkndz4fr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > ... Although it would add
> > a new pair of configuration options to .git/config. Is that change
> > too radical? :-)
>
> I wonder what you would need the configuration options for.
>
> If mmap() pack works well, it works well, and if it is broken
> nobody has reason to enable it. The code should be able to
> adjust the mmap window to appropriate size itself and its
> automatic adjustment does not even have to be the absolute
> optimum (since the user would not know what the optimum would be
> anyway), so maybe your configuration options would not be
> "enable" nor "window-size" -- and I am puzzled as to what they
All very true.
However what do we do about the case where we mmap over 1 GiB worth
of pack data (because the mmap succeeds and we have at least that
much in .pack and .idx files) and then the application starts to
demand a lot of memory via malloc? At some point malloc will return
NULL, xmalloc will die(), and that's the end of the program.
If the user was able to set the maximum threshold of how much data
we mmap then they could initially prevent us from mmap'ing over 1 GiB;
instead using a smaller upper limit like 512 MiB.
Of course as I write this I think the better solution to this
problem is to simply modify xmalloc (and friends) so that if the
underlying malloc returned NULL and we have a large amount of stuff
mmap'd from packs we try releasing some of the unused pack windows
and retry the malloc before die()'ing.
The other configuration option is the size of the mmap window.
This should by default be at least 32 MiB, probably closer to
128 MiB. But its nice to be able to force it as low as a single
system page to setup test cases in the t/ directory for the mmap
window code.
Earlier this summer we discussed this exact issue and said this
value probably needs to be configurable if only to facilitate the
unit tests.
--
Shawn.
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 21:51 UTC (permalink / raw)
To: Sean; +Cc: Aaron Bentley, Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <20061017185622.30fbc6c0.seanlkml@sympatico.ca>
Dear diary, on Wed, Oct 18, 2006 at 12:56:22AM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> said that...
> On Tue, 17 Oct 2006 18:44:11 -0400
> Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> > Plugins also don't have a Bazaar's rigid release cycle, testing
> > requirements and coding conventions, so they are a convenient way to try
> > out an idea, before committing to the effort of getting it merged into
> > the core.
>
> Hmm.. It's pretty easy to test out Git ideas too. People do it all
> the time, and without plugins. Junio maintains several such trees
> for instance. Dunno.. I just think plugs _sounds_ good to developers
> without much real benefit to users over regular ole source code.
I think this is just another cultural difference. Git comes from the
kernel environment (although it is currently used in far more
environments than just the kernel and kernel-related stuff) and the
_kernel_'s development style is that you want to get as much stuff as
possible inside the kernel, and on the other hand don't care at all
about breaking in-kernel APIs and such.
The Git "plumbing" is very much the "kernel". We aren't as much
interested in having support for external bits of code poking in the Git
innards, we would much rather have them integrated into Git as soon as
possible rather than live around externally. OTOH, the "kernel" gives a
very flexible ("UNIXy") API to the writhing mass of porcelain scripts you
may call the "userland".
I'm not saying it must be always sharply better approach than the
plugin-encouraging approach. It's just as it is. (Also, another reason
is probably a purely technical one, it is much easier to have pluggable
functions in scripting languages that support "monkey-patching", than
have them in C, since you actually need to explicitly add all the hooks
etc. So in Python, from a large part you get the plugin support for
free.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Linus Torvalds @ 2006-10-18 21:48 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Nicolas Pitre, Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610181407040.18885@alien.or.mcafeemobile.com>
On Wed, 18 Oct 2006, Davide Libenzi wrote:
>
> The hash value (hence the hash bucket index) simply directs you to the
> bucket where a real record-compare loop is performed.
As far as I can tell not all loops do a real "record-compare" thing.
Some of the hash loops _only_ look at the hash, and as such a bad hash
will do more than just cause bad performance, it will actually degrade the
diff itself. Isn't that what XDL_MAX_EQLIMIT effectively does?
Btw, the binary delta generator doesn't seem to have this issue at all: it
uses "unsigned int" for the hash values, so the xdiff delta generation
will give the same exact results on 32-bit and 64-bit architectures.
Or was that one of the changes by Nico? (I only looked at the git version
of that code)
Linus
^ permalink raw reply
* Alternate revno proposal (Was: Re: VCS comparison table)
From: Jan Hudec @ 2006-10-18 21:46 UTC (permalink / raw)
To: Robert Collins; +Cc: Petr Baudis, bazaar-ng, git
In-Reply-To: <1161149200.3423.34.camel@localhost.localdomain>
On Wed, Oct 18, 2006 at 03:26:40PM +1000, Robert Collins wrote:
> revnos visibly change as your work is merged into the mainline - we've
> been doing this for years without trouble: ones own commits to a branch
> get '3', '4', '5' etc as revnos, and when they are merged to the
> mainline they used to stop having revnos at all, but now they will be
> given this dotted decimal revno. If you pull from the mainline after the
> merge, you see the new numbers, and when you look at mainline you can
> see the difference. So while I agree that the surprise the user gets is
> inversely related to the frequency with which they see the behaviour, I
> think our users see it a lot, so are not surprised much.
>
> FWIW, we're not optimising for mostly straight histories as I understand
> such things : our own history has 3 commits on branches to every one on
> the mainline.
Reading this thread I came to think, that the revnos should be assigned
to _all_ revisions _available_, in order of when they entered the
repository (there are some possible variations I will mention below)
- Such revnos would be purely local, but:
- Current revnos are not guaranteed to be the same in different
branches either.
- They could be done so that mirror has the same revnos as the
master.
- They would be easier to use than the dotted ones. What (at least as
far as I understand) makes revnos easier to use than revids is, that
you can remember few of them for short time while composing some
operation. Ie. look up 2 or 3 revisions in the log and than do some
command on them. And a 4 to 5-digit number like 10532 is easier to
remember than something like 3250.2.45.86.
- Their ordering would be an (arbitrary) superset of the partial
ordering by descendance, ie. if revision A is ancestor of B, it would
always have lower revno.
- The intuition that lower revno means older revision would be always
valid for related revisions and approximately valid for unrelated
ones.
- They would be *localy stable*. That is once assigned the revno would
always mean the same revision in given branch (as determined by
location, not tip).
- This is more than the current scheme can give, since now pull can
renumber revisions.
- They wouldn't make any branch special, so the objections Linus raised
does not apply.
- They would be the same as subversion and svk, and IIRC mercurial as
well, use, so:
- They would already be familiar to users comming from those systems.
- They are known to be useful that way. In fact for svk it's the only
way to refer to revisions and seem to work satisfactorily (though
note that svk is not really suitable to ad-hoc topologies).
Now I said there are two options how to assign them. These are:
- Repository-wide: Number would be assigned to each revision entering
the repository, even when it is not in ancestry of any branch (ie.
if one starts a merge, but than reverts it).
- Advantages:
- Simpler to implement (just log every written-out revision).
- All branches in the same repository use the same revision
numbers, so if you keep branches in a shared repo, it makes
easier to look up one revision in log of one branch, other in log
of other branch and run diff on them.
- Disadvantages:
- Mirror only has the same revnos if both master and the mirror are
stand-alone branches.
- Branch-wide: Nuber would be assigned to each revision that becomes
ancestor of the current head revision.
- Advantages:
- Mirror (always updated by push from the same source) always have
the same revision numbers.
- The revno assignment list could be reused for refering to state
at particular point in time (in fact, it would be exactly the
same thing as git reflog).
- Bound branches could be forced to have the same revnos.
- Disadvantages:
- More complex to implement.
- More work at runtime and more space needed in a shared
repository, since each branch has it's own mapping.
Both ways, it would be implemented the way revision-history currently
is, just it would list all revisions, not just the path along the
leftmost parent.
Comments?
(Should I put it on the wiki?)
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-18 21:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061018213703.GE19194@spearce.org>
On Wed, 18 Oct 2006 17:37:03 -0400
Shawn Pearce <spearce@spearce.org> wrote:
> Today Git is typically extended (at least initially in prototyping
> mode) through Perl, Python, TCL or Bourne shell scripts. Although
> the first three are available natively on Windows the last requires
> Cygwin... and we've had some issues with ActiveState Perl on Windows
> in the past too.
Just for kicks and giggles it would be nice if someone tried out
one of the native Windows bourne shell ports[1] just to see how much
is missing. A bunch of command line utilities would have to be ported
as well; maybe too many. But i've held out booting a Windows box
for a long time so.... not it!
Sean
[1] For example, http://www.steve.org.uk/Software/bash/
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Junio C Hamano @ 2006-10-18 21:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061018213225.GD19194@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> ... Although it would add
> a new pair of configuration options to .git/config. Is that change
> too radical? :-)
I wonder what you would need the configuration options for.
If mmap() pack works well, it works well, and if it is broken
nobody has reason to enable it. The code should be able to
adjust the mmap window to appropriate size itself and its
automatic adjustment does not even have to be the absolute
optimum (since the user would not know what the optimum would be
anyway), so maybe your configuration options would not be
"enable" nor "window-size" -- and I am puzzled as to what they
are.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Shawn Pearce @ 2006-10-18 21:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610181358200.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> There are bigger reasons to _never_ allow packs to contain deltas to
> outside of themselves:
>
> - there's no point.
Actually there is a point to storing thin packs. When I pull from
a remote repo (or push to a remote repo) a huge number of objects
and the target disk that is about to receive that huge number of
loose objects is slooooooooow I would rather just store the thin
pack then store the loose objects.
Ideally that thin pack would be repacked (along with the other
existing packs) as quickly as possible into a self-contained pack.
But that of course is unlikely to happen in practice; especially
on a push.
> - it's a bad design.
>
> In other words, it has potentially _serious_ downsides.
Yes, it does.
But it could also be useful when you fetch 20k+ objects onto a
Windows system or push 1k+ objects onto the slowest NFS system I
have ever seen... where writing file data (aka packs) is reasonable
but creating or deleting files takes nearly 1 second per file.
I don't want to kill the better part of an hour waiting for a push
to complete!
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Nicolas Pitre @ 2006-10-18 21:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610181358200.3962@g5.osdl.org>
On Wed, 18 Oct 2006, Linus Torvalds wrote:
> There are bigger reasons to _never_ allow packs to contain deltas to
> outside of themselves:
>
> - there's no point.
Remember what I said earlier: "If there are advantages to do so then
maybe." So far there are none.
> You could end up with a situation where you get two packs from two
> different sources, and they contain deltas to _each_other_, and you
> have no way of actually generating the object itself any more.
To me this is the real killer.
Shawn was talking about a different issue though.
Nicolas
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Petr Baudis @ 2006-10-18 21:39 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20061018165341.bcece11f.seanlkml@sympatico.ca>
(Trimmed Cc' list, this is offtopic for bazaar-ng.)
Dear diary, on Wed, Oct 18, 2006 at 10:53:41PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> said that...
> On Wed, 18 Oct 2006 22:46:18 +0200
> Petr Baudis <pasky@suse.cz> wrote:
>
> > They could be written, but certainly not "just as easily". I'm more used
> > to coding Cogito, I find it much more convenient than hacking git's
> > shell scripts (those two may be interconnected ;), and there's plenty of
> > infrastructure in Cogito missing in Git - Cogito has more flexible
> > arguments parsing, documentation bundled with code, I could just
> > cut'n'paste the code to handle -m arguments and message editor (and most
> > of it is libified anyway) so I got that basically for free, and I think
> > Cogito beats Git hands down in code readability.
>
> Hmmm, if I get some time over the weekend i'll take a look at porting
> them to Git. But maybe some of the items you mentioned above deserve
> to become part of Git proper? It would definitely be nice to see
> something like what you just did put into the hands of more users than
> just those using Cogito, and its unfortunate that the current state
> of Git code kept you from going that route.
You can use just this single tool from Cogito. ;-)
The point is, I'll of course prefer doing this stuff in Cogito while I'm
enhancing Cogito, and I'll work on Cogito while I and others will be
using it. I didn't move on to pure Git long time ago since I simply
consider its UI much inferior to Cogito's. Sure, given enough time and
work, it is fixable - but UI flaws are very hard to fix and I find it
more effective to work on Cogito for the time being, at least until I
bring it to 1.0, then I'll see.
Besides, I'm used to Cogito. :-)
So yes, current Git code definitely is a part of the reason, but it is
certainly not the main part of it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Shawn Pearce @ 2006-10-18 21:37 UTC (permalink / raw)
To: Sean; +Cc: Charles Duffy, git, bazaar-ng
In-Reply-To: <20061018172945.c0c58c38.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Wed, 18 Oct 2006 16:04:52 -0500
> Charles Duffy <cduffy@spamcop.net> wrote:
>
> > Example time!
> >
> > There's a plugin for Bzr which adds support for Cygwin-compatible
> > symlink support on Windows. (IIRC, this involves monkey-patching some of
> > the Python standard library bits).
> >
> > Now, this is something which is *proposed* as a feature to be merged
> > into upstream bzr, and it may happen at some point. That said, when I
> > have a Windows-using coworker who wants to check out a repository that
> > has symlinks in it (with his win32-native, no-cygwin-required bzr
> > upstream binary), I don't need to tell him to go download and build bzr
> > from a third party; instead, I just need to tell him to run a single
> > command to check out the plugin in question into the bzr plugins folder.
> >
> > From an end-user convenience perspective, it's a pretty significant win.
>
> You'll need a better example than that. Git has supported a version
> of Cygwin-compatible symlink support on Windows for quite some time.
> And no plugins were needed.
Actually I think the only part of that example that was really
interesting was that Bzr runs natively on Windows and that Bzr's
native method of extending the tool with additional features doesn't
require Cygwin.
Today Git doesn't run natively on Windows. It runs slowly through
Cygwin, thanks to lots of various overheads in different places.
And due to the crappy disk drive in my Windows box. :-)
Today Git is typically extended (at least initially in prototyping
mode) through Perl, Python, TCL or Bourne shell scripts. Although
the first three are available natively on Windows the last requires
Cygwin... and we've had some issues with ActiveState Perl on Windows
in the past too.
--
Shawn.
^ 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