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 operation
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 spot.
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
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 does. It
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 branch.
As I
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
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 quite
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-spell,
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 files
9 matches
Mail list logo