quoted
quoted
quoted
quoted
"Jeff" == Jeff King [off-list ref] writes:
Jeff> On Thu, Oct 26, 2006 at 12:52:05PM +0200, Vincent Ladeuil wrote:
>> Ok, so git make a distinction between the commit (code created by
>> someone) and the tree (code only).
Jeff> Yes (a commit is a tree, zero or more parents, commit message, and
Jeff> author/committer info).
The parents of a tree are also trees or can/must they be commits ?
>> Commits are defined by their parents.
Jeff> Partially, yes.
I buy that this "partially" means "the other parts are irrelevant
to this discussion".
>> Trees are defined by their content only ?
Jeff> Yes.
So it is possible that : starting from a tree T,
- I make a patch A,
- you make the patch B,
- A and B are equal (stop watching above my shoulder please, or what is me ?),
- we both commit,
- we pull changes from each other repository.
We will end up with a tree T2 with a hash corresponding to both
T+A and T+B, but each of us will have a different commit id CA
and CB both pointing to T2, did I get it ?
Vincent
Vincent Ladeuil wrote:
quoted
quoted
quoted
quoted
quoted
"Jeff" == Jeff King [off-list ref] writes:
Jeff> On Thu, Oct 26, 2006 at 12:52:05PM +0200, Vincent Ladeuil wrote:
>> Ok, so git make a distinction between the commit (code created by
>> someone) and the tree (code only).
Jeff> Yes (a commit is a tree, zero or more parents, commit message, and
Jeff> author/committer info).
The parents of a tree are also trees or can/must they be commits ?
This refers to the parents of a _commit_, not of a tree, and the parents
must be _commits_. The parents allow us to determine what changed
between the previous commit(s), and the current one. If there are more
than one parent, then we have a merge commit.
So, a commit refers to a tree representing the state of the code at the
time of the commit, as well as to any parent commit(s). If there are no
parent commits, then the commit is an "initial commit" (i.e. the first
checkin). A project can have multiple "initial commits", typically where
two previously independent projects are merged together, c.f. gitk and git.
>> Commits are defined by their parents.
Jeff> Partially, yes.
I buy that this "partially" means "the other parts are irrelevant
to this discussion".
Yes.
>> Trees are defined by their content only ?
Jeff> Yes.
So it is possible that : starting from a tree T,
- I make a patch A,
- you make the patch B,
- A and B are equal (stop watching above my shoulder please, or what is me ?),
- we both commit,
- we pull changes from each other repository.
We will end up with a tree T2 with a hash corresponding to both
T+A and T+B, but each of us will have a different commit id CA
and CB both pointing to T2, did I get it ?
Vincent
Yes. That is exactly right.
From there, we can either trivially merge CA and CB with a new merge
commit referring to T2, but citing both CA and CB as parents, or simply
discard one of the lines of development, depending on how much
subsequent development cited CA or CB as parents.