James Henstridge wrote:
On 25/10/06, Carl Worth <cworth@xxxxxxxxxx> wrote:
On Wed, 25 Oct 2006 18:08:22 +0800, "James Henstridge" wrote:
> If there aren't, or you made the merge by mistake, you can make a call
> to "bzr revert" to clean things up without ever having created a new
> revision.
One result of this approach is that developers of different trees
don't necessarily have common revision IDs to compare. Imagine a
question like:
When you ran that test did you have the same code I've got?
In git, the answer would be determined by comparing revision IDs.
Can you really just rely on equal revision IDs meaning you have the
same code though?
Yes. Because each commit contains parent revision id's, which in turn
contain *their* parent revision id's, which in turn..., you know you
have exactly the same revision, code, and history leading up to that
revision. You may have other revisions on top or on other branches, but
all commits, including merge-points and whatnot, leading to that
particular revision id are EXACTLY identical.
Lets say that I clone your git repository, and then we both merge the
same diverged branch. Will our head revision IDs match? From a quick
look at the logs of cairo, it seems that the commits generated for
such a merge include the date and author, so the two commits would
have different SHA1 sums (and hence different revision IDs).
So I'd have a revision you don't have and vice versa, even though the
trees are identical.
Merges preserve author and commit info. You may need to create a new
branch (a git branch, the cheap kind which is a 41-byte file) and fetch
"his" into "yours". This will be very cheap if you both have the same
code but not the same history, as everything but a few commit-objects
will be shared. A more likely scenario though is this;
Bob writes a feature that doesn't work as per spec. He doesn't know why.
He asks Alice to have a look, so he communicates the commits to her by
"please pull this branch from here", or by sending patches and telling
Alice the branch-point revision to apply them to.
Alice creates the "bobs-bugs/nr1232" at the branch-point and fetches
Bobs branch into that or applies the patches on top of that (in the
fetch scenario she wouldn't need to know the branch point, since git
would figure this out for her).
She knows this should create a revision named 00123989aaddeddad39, so if
it doesn't, she doesn't have the same code.
I imagine this works roughly the same in bazaar, although the original
case where tests have already been done and the testers wanted to know
if they had the exact same revision Just Works in git.
In bzr, the only answer I'm hearing is attempting a merge to see if it
introduces any changes. (I'm deliberately avoiding "pull" since we're
talking about distributed cases here).
Or run "bzr missing". If the sole missing revision is a merge (and
not the revisions introduced by the merge), you could assume that you
have the same tree state.
"assume" != "know", or was that just sloppy phrasing?
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html