On 28 March 2015 at 19:33, deoren <mailingli...@dawnofhope.org> wrote:
> On 3/27/2015 3:23 PM, Matthew Wild wrote:
>> Summary: I made a mess of merging the branches the other day, so build
>> 117 had some regressions. Zash attempted to fix it with a couple of
>> new merges, which resulted in build 118 - but the nightly page doesn't
>> list merge commits (because they're not supposed to actually make any
>> changes).
>>
>> It's still not right though, so I'm going to re-do the merges now and
>> they'll land in build 119. Sorry for the confusion!
>
> Thanks for explaining that. However when you say:
>
>> because they're not supposed to actually make any changes
>
> Are you saying that individual commits which change something are
> reported as changes for a build, but if you were to report merge commits
> you would end up reporting the same change twice (once when it was
> actually made and then again when merging into a branch)?
>
> I think I get what you're saying. I took a look at the "branch" docs for
> Mercurial and I see that it's a lot more complex than I thought (SVN
> background).

I also came from an SVN background, and Mercurial made perfect sense
to me when it 'clicked'. Git though still hasn't clicked for me
unfortunately (though that might be more of a difference in the UI
layer... the underlying models are very similar).

Anyway, the point of a merge is that user A made commit A, and user B
made commit B at the same time. So you have to introduce a third
commit, C, which is the correct combination of both commits.

Sometimes the system can't automatically merge the two commits because
they 'conflict' - i.e. they made different changes to the same part of
the code. This can happen when we have revamped some code in a newer
branch, but then make a change in the old branch. When we try to merge
the two (which we do to keep bug fixes in sync across all branches),
Mercurial can't apply the change to the new code automatically - hence
the need for a manual merge.

But the merge commit is supposed to be a combination of A + B, it's
not supposed to be an actual change in itself. That's why we don't
list them in the list of changes. Merge commits with no other changes
don't usually happen - it only happened here because we got the manual
merge wrong a couple of times :)

Some links:

   - http://hginit.com/00.html
   - 
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

Hope this helps!

Regards,
Matthew

-- 
You received this message because you are subscribed to the Google Groups 
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.

Reply via email to