On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> Looking closer it appears that commit_list_insert is recursive
> and that is what I missed.
Actually, it's "pop_most_recent_commit()" that ends up being the
"recursive" part: it will pop the top-most entry, but as it is popping it
it will push
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>>
>> The question:
>> Does git-upload-pack which gets it's list of objects
>> with "git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3"
>> get any history beyond the top of tree of each branc
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> The question:
> Does git-upload-pack which gets it's list of objects
> with "git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3"
> get any history beyond the top of tree of each branch.
>
> As I read the code it does not.
It d
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>> > So if you only get one branch, it will leave the objects that are specific
>> > to other branches alone.
>>
>> Hmm. As I recall reading the code it grabs everything that is
>> in .git/refs/*.
>
> Onl
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> Ok. Only the dumb methods are allowed.
Well, no, you can actually do git-clone-pack by hand in that git archive,
and it will use the smart packing to get the other end, even if it is
totally unrelated to the current project.
But you have to do
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>>
>> I guess I was expecting to pull from one tree into another unrelated
>> tree. Getting a tree with two heads and then be able to merge them
>> together.
>
> You can do it, but you have to do it by han
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> I'm having the worst time putting together a mental model of how git
> works, and the documentation is spotty enough that it hasn't been
> helpful. So I am wading through the code. It seems every time I turn
> a corner there is another rough sp
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> I guess I was expecting to pull from one tree into another unrelated
> tree. Getting a tree with two heads and then be able to merge them
> together.
You can do it, but you have to do it by hand. It's a valid operation, but
it's not an operati
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>>
>> The current intelligent fetch currently has a problem that it cannot
>> be used to bootstrap a repository. If you don't have an ancestor
>> of what you are fetching you can't fetch it.
>
> Sure you ca
On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>
> The current intelligent fetch currently has a problem that it cannot
> be used to bootstrap a repository. If you don't have an ancestor
> of what you are fetching you can't fetch it.
Sure you can.
See the current "git clone". It's actually quit
On Sat, Jul 09, 2005 at 03:09:02PM -0600, Eric W. Biederman wrote:
> The current intelligent fetch currently has a problem that it cannot
> be used to bootstrap a repository. If you don't have an ancestor
> of what you are fetching you can't fetch it.
>
Not sure if this is what you want, but you
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
>> On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>> I assume the commit graph information will be fairly modest.
That is true. My experience from the one I have been cooking,
Gitified 2.4.0->2.6.12-rc2 BKCVS export results in a bit shy of
60
On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>
> I assume the problem with the mirror it model was simply there were
> to many objects?
Yes.
> > And then you really can use just rsync or wget or ncftpget or anything
> > else that has a "fetch recursively, optimizing existing objects" mode.
>
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 7 Jul 2005, Junio C Hamano wrote:
>>
>> However it does not automatically mean that the avenue I have
>> been pursuing would not work; the server side preparation needs
>> to be a bit more careful than what I sent, which unconditionally
>> runs
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> However it does not automatically mean that the avenue I have
> been pursuing would not work; the server side preparation needs
> to be a bit more careful than what I sent, which unconditionally
> runs "prune-packed". It instead should leave the fil
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> However, I really don't think it's a very useful option in
LT> the first place. Any dumb web-based thing that depends on
LT> "--whole-trees" would suck horribly.
I agree with these two sentences now.
However it does not automatically
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> When --full-objects is specified instead of usual "--objects",
> rev-list shows all objects reachable from trees associated with
> the commits in its output. This can be used to ensure that a
> single pack can be used to recreate the tree associated
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> Again you are right. How about --full-objects instead?
I don't mind the "--objects=xxx" format per se, but it would need to
verify that the "=xxx" was either valid or wasn't there at all. So what I
objected to was not that it was easy to mis-spel
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> This is nasty - if you mis-spell "self-sufficient" (easy enough to do)
LT> you'll never know the end result isn't what you expected. It won't warn
LT> you in any way, it will just make a non-self-sufficient pack..
Again you are right.
19 matches
Mail list logo
