James Henstridge wrote:
quoted text
> On 25/10/06, Carl Worth <cworth@cworth.org> 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.

quoted text
> 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.

quoted text
> 
>> 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@op5.se
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html